Nerdlife

Recently I’ve been working on a project that involves a lot of data visualization, with a lot of non-technical stakeholders. I needed a way to both play around with the ideas in my head and convey these ideas to non-technical colleagues.

I’m not a fan of HTML prototyping, since I find it takes too long and results in too much detail work, and Photoshop seems like overkill. Luckily, I follow Hacker News religiously, which had a few links to the Balsamiq blog over the last few months. So I gave Balsamiq a try, and boy was I impressed!

Balsamiq is, in its simplest form, a drag-and-drop board with a bunch of UI elements. But the incredibly simplicity of it really works, as it gets you down to the basic components of a page. My only gripe is that this does get frustrating for customized uses. For example, I wanted to show certain types of charts, but instead had to settle with doing funky things with their “progress bars”, which only matched the shape of my desired elements. I’d really like to have the ability to add my own UI elements. Also, pulling images from the web reloads them constantly instead of just downloading the image locally.

All in all, one of the few applications that I would be willing to actually pay for. Also, a great demo of what can be done with Adobe Air, and actually makes me want to poke around with Flash for the first time in years…this is an entirely new niche for Flash.

Full disclosure: Balsamiq gives away licenses to bloggers, so I didn’t actually pay for it, but I was on the verge of pulling out my credit card when I saw that exception.

development, programming, software

So I figured I’d jump on the blogger bandwagon in the debate on whether or not PHP is a good first language.

First, a little context.  PHP was the first language I did anything useful in.  I learned QBASIC in middle school, which I used to make some neat games.  Around 7th grade I taught myself PHP by hacking on phpBB installations.  I didn’t learn any other language until college, where I quickly picked up Java, C, and SML (in that order).  I agree that PHP is a horrible language to teach proper programming practices, but that’s not the point of it.

I’ve had the privledge of talking to Rasmus a number of times over the last few years, and while I didn’t get permission to reproduce his comments and so I won’t (I will say he has some funny stories about David Filo…), I can quote an article he wrote approx. 4 years ago on PHP:

PHP was never meant to win any beauty contests. … It was designed to solve a single problem: the Web problem.

It does this very well, as shown by it’s outstanding adoption rate.  The truth is that PHP is hacky, but it’s hacky in a logical way.  It was written to help a programmer have an easier time writing for the web by one in that exact situation, and it does it’s job.  If you need to throw a page together in 5 minutes, you can do that!  Which is exactly what budding programmers should be exposed to.

Think of it this way: why do people learn programming in the first place?  Nowadays, it’s either as a career path, in which case they probably aren’t destined to be hackers in any sense, or because they need to solve a problem and writing a program is the best way to do it.  What is going to turn a newbie on to programming faster: learning proper structure, or being able to pump out a solution to his/her problem in 5 minutes?  I would bet a lot it’s the later.  That’s what hackers do, they pump out a solution to a problem quick and, quite possibly, dirty.

“But Brian, have you ever seen dirty code?” you ask.  Of course I have, and I despise it.  But I contest that proper style is something that can be learned after the fact.  The ability to pump out a prototype in 5 minutes can’t be learned as easily.  The ability to ignore all convention and generate an import script to move all of your data from A to B to get your site back up, or hack together a script to bulk rename files in a really wonky way, while trivial to do for most programmers, can be done much faster with a hacker mentality.

I am a hacker, but I have no problem following convention.  I don’t like to, since it slows down coding, but when I’m in a group of programmers, or working on code that needs to be maintained, I do recognize the point of doing so and follow them (to the letter even).  Of course, I’m by no means the norm on anything, so take what I say with a grain of salt, but it seems to have worked well for me: I can follow convention, but at the same time I can adjust, I can change my style as the situation demands, and I can code up a storm when need be.

programming

Douglas Crockford has a very interesting article on fixing HTML. He points out many of the most annoying things about HTML that make web development difficult. The currently proposed HTML spec only fixes one thing as far as I can see (being a developer), the addition of more specific types of inputs: time, date, email, etc. The W3C has consistently done a poor job, as do most standards bodies, at rapidly improving their spec due to the semi-understandable fear of pissing people off by breaking standard. Yes, I know that backwards compatibility is important, but is it worth the years upon years of expense in training, debugging, extra staff, etc just so that companies don’t have an extra inconvenience of having to maintain two versions for a few years?

But this post is not about new HTML standards (nor is it an IE bash, though it may appear so initially). It’s about the cost of developing to different specifications, and a proposed solution.

I’ve noticed that at every company I’ve been with, at some point I have this discussion:

Me: Man, these cross-browser bugs are annoying
Coworker: Yea, I spend more time adding in hacks than I do developing
Me: I bet if there was one browser out there web companies would save billions in development
Coworker: Yea, I can’t really thing of a reason not to only have one browser

Then we both go back to coding out IE hacks

It’s an undeniable fact that cross-browser compatibility is a huge black hole when it comes to productivity. Design, development, QA, nearly the whole process is bogged down by having to take this into account. Why? When it comes to developing for Windows/Macs/*nix it is at least justifiable: there’s big money in OSes (at least for now). Browsers? Maybe, though it’s arguable, especially since there are free open-source ones with fast release cycles and mature feature sets. My question is why are there different rendering engines?

And that leads into my proposed solution, which, for perspective’s sake, warrants an analogy:

Consider the consequences if the DNS namespace were like the current browser situations. There would be one major DNS provider, the default on most computers sold, along with one popular one with around 20% market share, and some smaller ones. There are a bunch of hacks in place to try and ensure that people using one DNS could still view sites from another provider, and sites will register with a bunch of DNSs, but if your not using the hacks and the company doesn’t have the finances to register with all these DNSs, you’re out of luck.

Sounds ridiculous, right? The solution to prevent this is supposedly ICANN. Granted, this organization has its issues, the internet as a whole seems to be better off with it. So why not do the same thing with rendering engines?

Why not have an organization, say for example the WHATWG, be the sole developer and distributor of a rendering engine. Just like how the Linux kernel is used by all Linux distributions, make this renderer’s source code the de facto standard for web parsing. Changes to the way it parses things would be discussed in a public forum, with significant input by all browser developers, and implemented accordingly. Of course, there would be a distinct line between renderer features and browser features, with things such as default style of buttons and how spell checking is visualized left to the individual browser, but things like size of default buttons, graceful failing, etc, specified in the renderer.

Granted, I’m sure this solution has been proposed before, but usually more along the lines of “why doesn’t everybody use Firefox.” I feel this is a better compromise…browsers can still have their silly little war, users would no longer have rendering issues, companies would no longer have twice the development time, new specs would be adopted much faster, bug fixes could be implemented much more quickly, and so on and so forth. Everybody wins!

I can see Mozilla and Opera going for this very quickly. Apple shouldn’t be hard to convince. The big issue would be Microsoft (not to single them out, but they do seem to be the most stubborn). Development resources are nothing to them, and they have a lot of IE-only sites that take advantage of IE’s quirks, such as Outlook Web Access, along with lots of sites. They also probably see IE-only sites as a hindrance to Firefox growth, which would discourage participation.

The solution? There’s always the “because the government said so” option, where they provide either massive incentive or legal requirement to use this spec (i.e. giving the body that makes this spec a legal monopoly, just like the power companies). Then there’s the PR option. Similar to Intel’s Intel Inside&rest; campaign, make the render brand a household name. Make people question why IE doesn’t use it. The final nuke that can be dropped on Microsoft’s headquarters is an idea that also came from my workplace conversations. If two or three major websites, say Google and Yahoo, which control over 75% of the search market (up to 90%, depending on who you ask), do one of three things, alternative browser usage would jump significantly:

1. If they block all users not using the recommended renderer, even for a day, and provide easy instructions on installing another browser, millions would switch. Of course, they would lose millions of dollars, but the amount they would save in development costs would make it worth it. Even the mere threat of this, coupled with a deadline, could cause MS to change their minds.
2. If they put up a prominent icon recommending a compliant browser, it would cost them a few pixels and virtually no revenue, and would get plenty of people to switch, again, doing this, if it yields results, would force MS to reevaluate their stance so as to not risk losing significant market share
3. Stop developing for IE, allow it to become deprecated. This would have to be done carefully, perhaps with a notice at the top explaining that other “better” browsers provide enhanced functionality. If not done well, users would simply go to a competitor (as is the risk with option 1, but that’s short term, whereas this isn’t), but if done carefully and over enough websites, it would slowly force either IE to conform, or users to switch (browser or website, hopefully the former).

Note that I’m singling out IE here since Microsoft is historically stubborn…these methods would work with any browser, especially smaller ones who don’t have as much pull as IE.

So there you have it, a perfectly reasonable solution to the browser wars, or better yet a way to not let it impact other fields. Stop being stubborn internet (like that will ever happen…)!

browsers, html, internet, programming

...
// NOTE(mcslee): ok, at this point we know we are going to display the full
// page, so it is time to do a PHATTY PHATTY MULTIGET of all the shit that
// we are going to need to make this page, or at least the most common things
...

Yea, so Simon from Facebook’s legal department sent a very nice Cease & Desist email politely demanding that I take down the code (note that I never implied anywhere on this site that it was Facebook’s code, nor have I broken any laws in obtaining said code), but I figured the above lines, used for the sake of comedy, are kosher. Funny how the last name in those parenthesis matches up with one of Facebook’s (and Google’s, and Motorola’s), though I of course imply no connection.

Sorry Simon for making you log on late on a Friday to send that email.

Completely Random Pretty Code From Nowhere in Particular (Removed due to Facebook’s very quickly sent Cease & Desist)

cease and desist, facebook, programming

IP Carrier: 25 Startup Commandments: Great Stuff

Has some funny stuff and seems to hits the mark pretty well. There is something that I feel is worth elaborating on:

“Your software sucks. So what. Everyone elses does also, and re-architecting is the kiss of death for a startup.”

This is a hard transition to make for students because the structuring of programming projects in school is so linear: you have a strict set of requirements that do not change from the beginning, and they must be implemented in the best way possible.

Real life is not like that. In real life, you start out with an idea and wind up with something completely different. Your product spec will change more times than you can imagine, and you will have to constantly adapt to the demands and requirements of users, partners, employees, VCs, and so on. Learning this early and accepting it is very valuable, because when someone says “we need to change this core component” you will be ok saying “do it however you can” as opposed to “well, I guess we better write up a new DB spec, rebuild our architecture, and create a migration plan to our new setup”. It is true that “re-architecting is the kiss of death for a startup”, especially for web based startups, where one day can mean the difference between being first to market and being out of business. You also need to be able to work with and modify existing code better than writing new code, because you only write new code for a project once, and the rest of your time working on it is spent changing code. This is far more difficult than writing new code, especially if you didn’t write the code you are modifying.

If I had complete liberty to create a truly useful course for a university, it would be a software engineer simulator. I would give students a program that was moderately well written, and every few days throw a new curve ball at them. The DB they’ve never had to touch will crash, one of their partners who they have integrated into the site will go out of business, they will have to upgrade all of their deprecated code to comply with some new standard, they will be asked by a major client to find a way to generate 2,000,000 images of charts in under two hours, etc, etc. I would spare them has-to-be-done-now deadlines and blackberries that ring at 3am, but it would still be one hell of a course. And the ones who finish it and say “well that was fun”, those are the ones truly ready for the world of software development, whether or not in the form of a startup. The rest will have to sit down with a bunch of lawyers, who will then inform them, in extremely monotonous voices, of every little thing they’ve done in the last few months that could result in a massive lawsuit.

Note: Every one of these stories is based off of something that happened in my department in the last month, many of which landed on my plate. I’ve come to expect it, and it sure was fun.

programming, school, startups