Computing Expertise

In higher education, and I imagine within IT support in most small organizations, where the “IT Gal” or “IT Guy” is called upon to do everything from run the servers to manage the routers to “doing the web page” to answering “how exactly do I do that in Word again?” they’ll find that people that aren’t the “Eye-Tee” person attribute computing expertise to one’s proficiency (or even beginning-icy) in the company’s/organization’s software packages.

Let me make something absolutely, positively clear. Knowing how to create a table of contents in Microsoft Word is not a function of computing expertise. Knowing how to do anything in any given consumer software package is not an activity reserved for “eye-tee”

Knowing how to use a hammer and a drill does not make me an architect, or a builder

This myth, that somehow software expertise is an Information Technology function, is one of the worst myths that ever pervaded the currently-heavily-dependent-on-software society. It means that ordinary, hard-working people that in every other area of their life would roll up their sleeves, break out the instruction book and learn whatever task (and tool) they have in front of them, give up, and ascribe some mystical, magical wall that even being a beginner in a piece of software is a scarce, specialized skill.

Yes, being an expert in a given software package is a scarce skill. But the best qualified to learn that are those that the software was written for. Just like a Chemistry PhD is going to know far more about the intimate details of their field, but everyone has the ability to understand that Dihydrogen Monoxide is safe in low doses.

Quite honestly – those of use in “eye-tee” are actually the absolute worst people to rely on for specific expertise in software – be that word, or photoshop, or Google Reader, or whatever the software application. It’s like the faculty member in Math answering Physics questions. Of course they get the math, but it’s not like they have the same expertise.

And for those of you that are proficient in a given software package and have proficiency in several or beginner knowledge in several? You aren’t computing experts. So give up thinking that – and stop trying to tell people otherwise. Because you are just as bad as the people that aren’t trying. (there are no computing experts, btw, the more you know the more you realize that there’s way more that you don’t know).

I have specialization in certain areas of computing technology. I know the fundamentals. I know how programs are constructed. I know how the operating systems work – at least a certain level of their architecture. I can make use of software written for folks like me to deliver services – but like I told a colleague today: I use software like everyone else does – one menu option or button at a time. The only reason I know how to use Photoshop, or use Firefox, or use anything, is the fact that I clicked on it and I started exploring menus, and trying things. I don’t use them 1/10th of the power they hold, but my beginner level usage has nothing to do with the fact that I have computing specialization.

It just means I tried.

p.s. it’s never really about a single post

so I went into snarky overdrive with my vendor dependencies post. it wasn’t quite as funny as last year when I went off on the people that can’t unsubscribe from lists either. Nor was it as funny as some other commentary on Rails I’ve snarkily made

I really do love the guys – – they have the best rails blog – bar none – that I’ve ever found – I even have their toolbox post burned into my retina I think.

They really know their stuff. Rails needs devs like this – and they do a great service educating other folks about the framework.

But I don’t agree (obviously) with packaging up all the dependencies with an application. I get all the reasons for doing so. It just sets a really dangerous precedent for the people that are going to take it as the gospel and never think about the ramifications of what packaging up everything with your application means. (like simple things – remind me to tell the inode story sometime. 20 capistrano delivered copies of edge rails might not kill your storage but it dang sure can eat some inodes)

But hell, you can’t really trust the system administrators to get it right either about not breaking dozens of rails apps that they don’t have a clue about. I, um, er, have known some sysadmins to do that (more than once even).

p.p.s Oh, man, I forgot about the sponsorship link. This post sponsored by the Static Linking Historical Society. And support also comes from Microsoft Corporation. Proud facilitators of DLL Hell for all the static linkers that decided to go dynamic, but distributed their own libraries.

Good Grief People, stop with the local gems

From Err The Blog: Vendor Everything

For hosted environments? sure.

But if you are responsible for the application AND the server? (or your shop is?)


Not just no. But HELL No. And I’d really like to write “HELL No” in an <h1> but I’m going to avoid that for the sake of sanity

I’ve yet to figure out why the rails community has this inbred desire to cause harm to their reputation in organizations that aren’t pure dev shops. I’m not even talking about the enterprise, I’m talking about small business, non-profits, companies they contract with, academic shops…

I don’t disagree with Chris’s reason here for using vendor for WayCoolFunkyGemThatYouThinkIsTheBeesKnees (WCFGTYTITBK) and not being “That Person” for breaking the build (and your peeps) is laudable. But really – I don’t buy it. If you are small Rails shop and you plan on using test/spec or any other WCFGTYTITBK – for goodness sake you communicate that with the rest of your team (hello? IM? email? even that ringy thing on the hip or desk we all hate to use?)

If you think that someone else’s code is so great that it ought to be in your application – well then it ought to be in everyone’s install too. Go get up and install it for them (take the train if you can’t fly there) That’s what good developers do. They have sane development environments set up and they are completely proficient at “gem install blah” – and makes them completely aware that a brand-new third-party dependency just showed up in the application. I dare say that “gem install blah” is a lot less intrusive than “why in the sam heck did 1000 lines of crap just show up in vendor – I evaluated that third-party code last month and it was crap then and is crap now”

Local copies of every gem is madness – especially gems that are core to your application (and would break builds) It creates situations where the whole team (and often the people that run the servers and are ultimately responsible for the application) is not fully aware of the dependency needs of the application. Let me repeat that again – EVERY DEVELOPER ON A SMALL TEAM SHOULD KNOW EXACTLY WHAT AN APPLICATION DEPENDS ON, WHAT VERSION, AND SHOULD TASK THEMSELVES WITH CHECKING UP ON THOSE VERSIONS.

One app? not a big deal either way. 5 or 6 apps running in the same environment? It’s a Big deal. (of course it’s probably a complete architectural failure to have your 5 person team working on 5 or 6 apps at the same time – but that’s another post)

We had pinned rails in our applications – at least until the “Upgrade Your Rails NOW NOW NOW” event – and going through multiple applications on multiple staging servers and multiple versions was a complete pain in the ass. Okay, so that’s a little hyperbolic – but it was more trouble than it needed to be. You upgrade the server – when you control the server and your application – and you know that that the dependencies are handled.

I had these arguments a few months ago with a developer that was contracting with us – and it was like imposing a little (certainly not anything like some waterfall corporate development shop) structure on the process (“Hey – tell us exactly why you are using edge rails so that we all understand the issues”) was like we were impeding progress (“no, we are trying to make sure we understand what you’ve done when you get bored with us”). I know that new software introductions are disruptive. But that’s what developers (and I’m counting myself here for the sake of that sentence) do. Things break, we tell others, and we fix them. (and some of my other colleagues think WE are the lack of planning ones – you have no idea)

While every application should have a definite lifecycle – you know, and I know, and everyone else knows that in many, many, many environments apps get written, and they live well beyond the developers, the systems people, and everyone else that every had any responsibility for it – and local copies of everything creates a maze of having to upgrade the third-party dependencies all over the place when some script kiddie decides to take advantage of that 2-year old failure to sanity check POST.

Rails developers have to start figuring out that someone beyond them is going to be responsible for inheriting what they’ve done – and they have to start thinking more seriously about dependencies, third-party code, add-ons, and the lifecycle of what they do. It’s like two-bytes for the year value all over again. Seriously people, no amount of “unit tests,” “syntactic sugar,” and vendor kung-foo will ever trump communication and documentation (I don’t mean constantly out-of-date systems analyst documentation – I mean documentation about decisions and why something was done, or why it was added, etc.)

Lightroom Direct Positive, redux

About a month ago I wrote about Adobe Lightroom’s Direct Positive effect and the dramatic effects it had on several of the pictures I had taken.

Well, I should have been shooting in raw. Applying the Direct Positive settings to Raw photographs has a much more understated impact – at least for some of the raw shots I was taking today. For example, the skybox complex for the NCSU football stadium (click to go to Flickr and see the larger sizes)


Vaugh Towers


Vaughn Towers - Lightroom Direct Positive

It’s still a little dramatic here – but it’s very, very different from the effects that it had on the jpg’s I was shooting before.

It’s even better with pictures of cows with holes in their sides (I was too far away to get a good picture, so I’m just showing the effect):


This effect really works well, and gives this image a much better color contrast.

I really think I’ll be shooting predominately in raw from now on, Lightroom also seems a bit snappier with the NEF images – believe or not (you can choose “not” – I’m still not completely convinced myself)

Uploading KML files to MediaWiki

So you want to upload KML files to your MediaWiki install? Simple as putting ‘kml’ in your allowed file extensions right?


Through the almighty power of a string match that’s not actually a regular expression, but instead a strpos match in the SpecialUpload:detectScript function (yes, that’s right, a strpos match, not a stripos match – but a strtolower takes care of that a few lines before – that’s probably faster anyway).

The strpos looks for <head in the chunk o’ text that’s in the uploaded file – which of course matches the KML heading tag – producing a detectScript match

Yes, one could modify the function in MediaWiki to handle KML file uploads – pulling <head out of the following code block:

		$tags = array(			'<body',			'<head',			'<html',   #also in safari			'<img',			'<pre',			'<script', #also in safari			'<table'			);		if( ! $wgAllowTitlesInSVG && $extension !== 'svg' && $mime !== 'image/svg' ) {			$tags[] = '<title';		}    		foreach( $tags as $tag ) {			if( false !== strpos( $chunk, $tag ) ) {				return true;			}		}

And then writing a regex to match <head and not <heading

Which is certainly do-able due to the beauty of open-source software(*) But thankfully (very thankfully) there’s a KMZ (scroll down) format. Which should upload just fine with just a file extension addition. (And the bonus is that it’s far more feature-rich to use.)

(* which, of course, making custom local modifications to your open-source software packages that don’t merit patch submissions back to the package authors is a whole other discussion topic, look for the future post and/or Conversations with Plastic Dinosaurs about being on the hook to maintain custom changes change for any and all future updates to the open-source software packages you use, which inevitably, you’ll forget you made, and then you’ll upgrade, and you’ll break expected functionality, which won’t be noticed for months after you’ve forgotten you ever even upgraded, at which point someone will complain, memos will be written, you’ll get blamed, you’ll bitch about getting blamed, everyone but you, given that you actually do the work, will promise not to forget about it again, which you’ll promptly do six months and thousands of tasks later on the next upgrade. Lather, Rinse, Repeat. )