isn't quite ashamed enough to present

jr conlin's ink stained banana

:: MacGuffin!

Last night, a bunch of friends watched a show called Scorpion. i had no idea it was on, nor did i really have any interest in watching it, but they took to twitter to comment about how bad it was. From what i understand (again, having little interest in actually watching the show) it was the usual Techno-Crime thriller about a group of "geniuses" who use Technology to battle Crime. The show featured such techno crime fighting as driving a Porche behind a plane so that the heroes could grab a network cable dangling beneath, apparently because nobody on the plane had a cellphone or anything that could do wifi, and tossing a few USB sticks would have probably been out of the question as well.

Honestly, it reminded me of something my Sister in law (who is in the entertainment industry) yelled at me while watching a similar sort of show "It's Entertainment! It doesn't need facts!"

That flash of insight into the mind of what's making this stuff really helped me understand quite a bit. i mean, how does one possibly counter something like that? It did, however, make me understand that there's a huge opportunity there for folks.

i realized that what was sorely lacking was a show that treated the rest of the planet the way that technology is horribly abused. i'd call it "MacGuffin"!

It starts off with a sweeping shot of the city that's central to the story:
McGuffin

We see our hero, Jack MacGuffin engaged in a chase with his partner Alan Smithee.

Smithee: "Jack, they're getting away, we need to go faster."
MacGuffin: "Alan! Quick, grab the wheel and start driving!"

Alan grabs the wheel and starts pounding on the brake and gas pedals of the car. With a cloud of tire smoke, the car lunges ahead and quickly overtakes the van containing the enemies, a group of 80 year old women who had once seen a crime drama and were acting out the overwhelming influence of that corrupting medium.

MacGuffin and Smithee soon learn of a gang that plans on flooding the streets of Phoenix with drugs and white slavery purchased using counterfeit Monopoly money.

Smittee: "Jeez, imagine the number of houses you could buy with that kind of money"
MacGuffin: "Houses? you could fill the block with hotels."

They reach their biggest break when they spot a "Classified Ad" in a local "newspaper" that they quickly correlate to a "phone number" using a copy of "Yellow Pages" and with that phone number in hand, race to the abandoned warehouse of the gang.

Before they go in, they quickly construct some guns out of some tinker toys and sheet metal they find outside, before bursting in and taking out the gang with a 2 X machine.

Of course, my biggest fear would be that it actually would be made.

:: Disposable Medium

i'll admit that i generate content that is disposable. i tweet, occasionally post crap to facebook and sometimes toss images up on imugr. Sometimes, i comment on reddit. All of that is disposable.

It's disposable because i don't own or manage the forum or pay for the servers. It's not mine to archive, index or monetize. My account may be blocked or dropped for reasons i have no control over. Whatever i generate may go away tomorrow and i'll have zero say in the matter. If i'm lucky, i'll be able to pull a portion of the content off of these sites, but who knows if i'll be able to do anything with it.

Sites, even very popular ones, shut down all the time. It's a well documented fact of life. All the stuff you put on that site disappears when they decide it's no longer profitable/viable/fun anymore. Heck, there's even a team that tries to rescue your crap before it disappears forever. All of that kinda rose up when i tweeted:

i was half kidding, but honestly a bit serious. For reasons i'm still not quite sure about, Medium has become the latest blog substitute. The replies i got on that tweet were equally unsatisfactory. Yes, posts do look pretty-ish, provided you can figure out to get images to do what you want, but you're pretty damn limited, and let's face it, every post is basically "Large Hipster style banner pic with Headline, followed by paragraphs of 22px Georgia font. Ok, so this blog clearly illustrates that i have zero modern styling sense, but it's not terribly difficult to duplicate that look.

You're also fairly limited in the sort of things you can do in your text. In my blog, i've got carte blanc. There, i've got the limited styling features that they demand i use. i suppose the next item would probably be the network effects, i post there because all the cool kids post there, therefore i'm a cool kid too! This is like standing in front of stuffed toys and claiming to have given a Ted Talk. (Granted, there are some that probably should have stuck with the stuffed toys, like this one:



$7500 spent to hear that talk. Money well spent, huh? And granted, that one was probably for laughs, so there's this one instead). Granted, since folks don't seem to like RSS anymore, it's a bit harder to find interesting articles outside of twitter, facebook, reddit, buzzfeed, digg, slashdot, your aunt's forwarding email, bathroom walls, …

Honestly, it's the message, not the platform that makes one cool or interesting.

i get that some folks don't want to run their own site. That's fine, it can be a hassle to make sure that software is up-to-date. What i don't really understand is the value folks are seeing. Is it like the early days of the internet where things that weren't written in comic sans on a gray background were considered to be believable, published articles? Is it that these folks don't really want to be all that closely associated with what they're creating? Is it that blogger/wordpress.com/facebook/google+ isn't the latest new thing? (Ok, Google+ is probably never really going to be a thing.) Is it that they don't care if what they're spending time making lasts longer than a reddit karma cycle? Do these folks not realize that the most effective way to build a known presence on the web is to have a known presence on the web?

i have absolutely no idea.

For throw away stuff, i don't mind using disposable services, but i think i'll keep using stuff i have some control over for things i want to stick around.

:: The Streetcar Problem

Streetcar-CrashProgramming nerds love theoretical technical problems like The Prisoner's Dilemma, or The Dining Philosophers. Here's a fun mental exercise for your afternoon: What would happen to your favorite library/service/product if the principal engineer was suddenly killed by a streetcar? For an astonishing number of services, the answer will probably not be "continue to work seamlessly".

(i'll note that i decided to break this out of a different post about Being Nice for Selfish Reasons: Work Edition. i decided that it's a question that needed it's own post.)

Most projects, like most movements or causes, tend to have a singular leader. There's a lot of reasons for that, including the facts that running a successful project kinda requires someone to make hard decisions, say "No, we shouldn't do that" a fair bit, and "We're going to go in this direction, in spite of your personal interests". There are ways to present all of those statements, sometimes in friendly, happy ways, other times like a overbearing jerk, but there are ways. The problem is also the Achilles Heel of Open Software Projects: Getting someone else to give a damn about what you're building. You have to be nice enough or provide enough value that people want to help you and deal with your pushy ideas on how to do things.

There's a weird psychological edge to successful software development that many folks don't think about. If you even think about the tools and services you use, you probably associate them with one or a very small group of lead folks. These are the captains of the project and in some respects are cult leaders for their ideas, even if they aren't in direct control. Python has Guido; jQuery has jresig; PhP has Rasmus; etc. Larger projects like Webkit require a large, organizational structure to deal with the huge, complicated code base. However, even these projects have a small group or even an individual who is the acknowledged leader. This is pretty much how humans set things up.

So, what happens when such an individual leaves a project? Usually, it's "not good things". In the sudden vacuum, there can be a power struggle as folks fight to become the replacement, or things drift as the next person in line has a slightly different view of how to do things. In rare instances, it's possible for the project to continue or improve, but that's usually because one of the goals of the individual at the helm was to ensure that he or she is replaceable. Yeah, not a lot of folks think that way. It's very uncomfortable for people to confront their lack of permanence.

All of this does impact you, however. You invest in a given resource. Whether you like it or not, you become dependent on that resource more and more. When the streetcar comes, you're also subject to the repercussions. If you're lucky, skilled and have the time, you can fork the project and keep it alive long enough to find a suitable replacement. If not, well, you're dorked.

It can also be exceptionally difficult to keep your product "Streetcar proof". Sure, there's principals of abstraction, but the big problem is that there are reasons you've picked a technology or service over it's competitors, and those reasons will be reflected in the core of your product's design. Replacing or degrading those will not be easy, or potentially possible for whoever is maintaining your code.

Yeah, that's right. You're also subject to Streetcars.

So, when your personal streetcar arrives, how will folks deal with it?

:: Building A Worse Toaster

Sadly, i'm rolling misses on my Google Fu this morning, but i believe that C.J. Cherryh wrote a short story about an elderly woman who wanted a new toaster. It being the future, the device delivered itself and promptly started doing the laundry, fixing the car, reprogramming the TV and all sorts of other wondrous tasks. The Matron, tutted, jabbed a fork deep into the machine. It sputtered, fell over, sparked and finally a warmed, lightly browned piece of toast popped out of a slot.

While the story is funny, it's also really useful to remember when building a tool.

Ultimately, you want your tool to be as simple as possible. This is the general theory of Unix. Little things that work well together. The problem is that building simple things tends to not be very popular.

As a software engineer, i am both subject to, and constant advocate of, feature creep. i want things that just do a bit more. i mean, sure i could have something that's just a front end to a database that allows me to enter a blob of text and then later display it,… but it could also have an inline editor, ooh, and a search function, and it'd be neat to have plugins… And, well, you wind up with WordPress.

Same with things like jquery, which started off as fairly simple and small, then became, well, jquery1. Even protocols go through that sort of progression (mind you, i already ranted a bit about "human vs. machine readable"). Darn near everything tends to start simple, but get increasingly more complicated.

As is usual, a number of things tweaked me about this point. One was an old rant about how even though people spend most of their lives in front of a computer now, most don't know how to use one. The other post talks about developer inequality and a longing for Hypercard. Both pretty much highlight the same thing, and i could argue against both equally.

For the first, i'll note that computers are media delivery devices and people tend to prefer to consume more than create, and that's ok. A fair number of people have no idea how to maintain their auto or understand the mechanics of municipal transit but use it to come and go. Granted, if they're taking an intro course on how to do car repair, probably a good idea to show them how to change the oil and rotate the tires, much like an intro class to computers ought to discuss programming.

Thing is, you can teach programming to kids. You can teach auto repair to kids. Hell, you can teach quantum mechanics to kids. You just have to make them want to learn about it. Javascript isn't hard. Packing it full of complex crap, frameworks and other stuff to make it "easy" makes it hard, but by-and-large most kids can grok the fundamentals pretty darn fast. No, they're not going to be able to understand using Promises to trigger component events in the Shadow DOM by the end of the week, but i wouldn't expect that.

Give 'em two weeks.

Likewise straight HTML is delightful because it's actually nearly readable. Pretty print it and it's pattern matching you can easily wrap your head around. Heck, explain to someone that The Web® really is basically a bunch of fancy telnet calls, and it's like watching a light bulb go off.

Sadly, that may go away with HTTP22 or SPDY, s/telnet/curl/ and you're basically back in the game again.

The final thing to note about all of this is that folks will surprise the hell out of you. They're not going to follow your arbitrary rules and will pretty much use whatever you hand them as a hammer. Done right, that's not a problem.

In fact, it could be a huge benefit.

Good Sir Tim Berners-Lee never expected people to use his protocol to do face to face video chats. Heck, he wasn't all that hot on documents having things other than links, but he was willing to let folks be creative with his toy. Heck, i've built stuff, given folks instructions on how to properly use it, and they've blissfully ignored me again and again.

This is typical (regardless of my continually trying to either ignore or change it), and should simply be part of any service you build. If anything, that sort of abuse should be lauded.

So, when you're building your next toaster (or library, app, interface, device, whatever), ask yourself:

  • Is this doing the least it can to be useful?
  • Can it talk to other things easily?
  • Does this tool make zero presumptions about the user or the way it will be used?

Answering those questions will pretty much tell you how successful your thing will be.
Otherwise, you're just making a worse toaster.

1i'm not knocking jQuery as bad, i'm just saying that people have decided that jQuery is how you write javascript. Javscript has evolved and adopted a lot of the things that jQuery started. The problem is that folks immediately turn to jQuery $(".foo") rather than use local commands document.getItemsByClassName("foo"). There are good reasons to use jQuery. There are good reasons not to. Ultimately, though, you should balance the decision on what you need to do rather than knee jerk use a tool.

2It's funny how long HTTP2

:: Rules of Deployment

The following are JR's Rules of Deployment:

Note: The following may be sweary.

1) Server, then Client, then Marketing

Everyone's job is hard. So why the hell would you make it even harder by forcing folks to work on highly unstable things? First, build the back end server your thing is going to talk to. Get it to the point where it's stable, reliable, and predictable. It supports all the API calls properly, has reasonable security, sufficient redundancy and nobody is going to ask why the box is down.

Once the server is stable, then start building the client for real. You've got a reliable box and test cases you can use. Yes, there may be some additional tweaks to the server needed, but the core API should be fine enough to do productive work. Get it working to the point it's minimally viable (hell, feel free to roll it out as alpha to get some real usage models and proof the load support).

Once you've got a working client and sufficient knowledge, then you can start marketing and planning on your release, and not a god damn second before then. Yes, this means risk. It also means that customers/vendors/whoever won't be screwed because you're going to have to slip delivery dates because you forgot internationalization, or that we live in a base 10 world.

2) Know What You're Building

But, how will you be able to build a server, then client like that? Easy. You write up requirements. Not "User Stories" because i have yet to see anyone figure out how to build Integration tests off of "Bob wants a sandwich, so he presses a button on his phone and a sandwich arrives." You don't have to generate MILSPEC-25 compliant requirements that detail every action of every menu choice you're ever going to need, but you had better figure out the overall functions, interactions and compromise points before you even fire up your editor.

NASA doesn't send probes to Uranus by chucking cellphones "Somewhere. In that direction. i guess". The think that crap out because they DON'T have a huge budget and unlimited resources.

If you're a developer, demand to see the competitive product feature comparison chart. You're going to be building stuff that uses it, it's every bit a required resource as a man page. Yes, this means you can't be "agile". It means you know what the hell you're building and lets you recognize if you're making a mistake.

You will make mistakes. You will toss code, ideas and work out the window mercilessly. If you find you're incrementally redesigning your entire project, stop that project and design a proper one.

3) Know Your Critical Path

If you have a delivery date. Write it in large type on a very visible wall. You know what you're building, and the order it needs to be built in. You know that you'll need to do at least two weeks of systems testing, plus at least two weeks for patches, two weeks for deployment. Those are not things that can be done in parallel, so that's a month and a half of blocked time. You'll also need to build the damn thing, so figure your time, accounting for one additional month for every "cutting edge" or unfamiliar tech you're going to use. That IS being optimistic. Reality will probably demand more time because "cutting edge" means "broken and unsupported features" and unfamiliar generally means "you have no idea what it really does". These are common words you don't like hearing from your doctor or car mechanic so why should you want to hear them from your own team?

Lay out the critical path. Know what impacts what lays beyond it. Recite the critical path every morning in unison in the parking lot. Whatever it takes so that folks know that having a problem isn't what's bad, it's not communicating that there's a problem.

4) Build for One or Infinite

This gets into design and deployment bit again, but basically, you either need one of something, or you need an infinite amount of them. If you only need one, focus on that, and don't bother adding in clever crap. If you need infinite, build it as a service. (Again this is where "knowing what you're building" really helps.)

5) Make It Safe From Yourself

As a VERY smart paranoid security person once said: "Hackers have infinite time and resources. If there's a weakness, they will find it. If you, the person that wrote the code, can't figure out how to break it and do anything other than what was intended, hackers will have that much harder a time."

i constantly look for exploits against my own code. i sandbox anything the user has access to whenever possible. i always ensure that the owner of the server has the least amount of access possible.

6) Build Simple.

More moving parts == more things that can break.

If you're bringing in hundreds of libraries and support frameworks, you had damn well better need every line of code from them. Libraries are feature and code sinks. Very seldom are they pruned, and honest profiling can show how bad a lot of those "easy-*" or "simple-*" things really are. Be brutal about how little you need. If you're using a 10 line function out of a 2,000 line library, yank those 10 lines (and credit in the comments). If nothing else, this will let you see how crapped up those 10 lines are and if you can't do it simpler yourself.

i mean, it'll all show up in the profiler anyway.

You're running a profiler, right?

7) Document

Code is self-documenting if you never want someone else to deal with it. You don't need API guides if you never plan on someone else reusing your code. There are a lot of corners you can cut if the code is disposable.

If, however, you want to do other things with your life than support a 6 year old XML parsing library, write some damn documentation. If you're writing in some edge language, give people a reason to want to learn it so that they can help pitch in. You could write the most amazing thing ever in heavily obfuscated Perl that generates Pentium byte code and people would treat it like toxic waste unless you explained why the hell you needed to do that.

Granted, if you did that for "fun" you're an idiot and deserve to have the project rewritten on you, but that's beside the point.

Your documenting for your QA, Ops, NOC, and Customer Support groups. Even if those folks are you 2 years from now when things break due to expired dependencies.

Before you can tell someone to RTFM, you have to WTFM.

There are other rules, and if need be, i'll define those as well.
These are the core.

You're welcome.

Blogs of note
personal Christopher Conlin USMC memoirs of hydrogen guy rhapsodic.org Henriette's Herbal Blog
geek ultramookie

Powered by WordPress
Hosted on Dreamhost.