Julio's Blog

Follow me at @julio_ody.


Too much fucking abstraction

You know what the problem with Rails Ajax helpers is? It’s not that they’re done wrong. Well, up until 3 they were done VERY wrong. But in the upcoming Rails 3, they adopted a set of practices popularly known as UJS (Unobtrusive JavaScript, I guess). Which is short for “JavaScript done right”, and nothing particularly groundbreaking since people who know their JS/HTML have been doing that for a while. Though it’s definitely a step in the right direction in you consider where things were before with embedded JS going all over the place.

But the problem is this: it’s still too much fucking abstraction. It seems like a good idea. It’s there so people who don’t know JS can use Ajax, right? Were Rails merely abstracting browser incompatibilities, for instance, I’d be buying Rails UJS t-shirts and wearing them at meetups. But that’s already done by libraries such as jQuery, or Prototype. And that is the level you want to work at.

These libraries are OK because 1) they abstract differences between browsers, specifically DOM and events related stuff, and 2) they give you a few constructs for building proper proper JS apps with less code. See what I coined when I said “JS apps”? You can’t build those with Ajax helpers. So if you only know JS through Rails helpers, make that your next objective as a developer: learn how to use either jQuery or Prototype properly.

Other frameworks such as ASP.NET, Spring, and GWT, also offer Ajax helpers, either directly or through libraries. Having worked with developers coming from all those 3 backgrounds, I have to say: it’s scary. If a task falls outside the realm of what the framework offers, either the fix will be VERY ugly, or they won’t be able to come up with one. That’s what happens when you’re out to build front-end centric applications without the slightest understanding of how the underlying tech works.

On a more philosophical level, this discussion illustrates a human problem: the more you abstract, the less you know. As a knowledge-hungry programmer though, you should strive to tune your throughput equation to stay as close as possible to the core concepts while retaining as much development speed as you can.

Software architects

Koziarki’s recent post inspired me to share my opinions on the matter, seeing that throughout the years I experienced a handful of similar situations myself.

First of all, let’s understand the role per se. Someone gets hired for defining those requirements, generally by talking to the customers. That person is usually a software architect with some experience in development, which gives him/her the necessary understanding to anticipate when a requirement will have a big impact on the development timeframe and thus the final cost. During the consultation process, said person negotiates with the client so he will buy only the bare minimum he needs, and agree to further iterations based on real needs that develop over the course of actual usage of the software.

Right? No, not really.

Strangely enough, someone with next to zero experience with software architecture/development often ends up in that position, selling unrealistic expectations to a customer who’s even less informed on the topic, because whoever hired him/her went for a “people person”. That’s terrible because you’re going with the assumption that your customer’s expectations need  to be handled as opposed to looked after. Your business will have to do a lot less explaining if you get into the business of exceeding expectations. You’ll also make more money in the long run.

So here’s a crazy idea: If you’re out to hire a consultant who will bring in requirements for building software, hire someone who actually can give valuable advice based on personal experience. Go for an ex-software developer, or a designer with some development background. No such thing as crazy requirements will land on your developers because they won’t even leave that first conversation with the customer.

For the record, this isn’t about shielding the precious developers from the evils of the real world. It’s about not having your company enmeshed in one of these two situations: having to go back to the customer to explain that due to unforeseen circumstances, X amount of days/money extra will be required to complete the project, or having to squeeze your developers for extra time to cover for the mistakes of whoever brought in the plan.

Small and sexy

UPDATE: The latest version is now hosted at Forrst.  

Since the days when it was less than very popular, I’ve been a huge fan of Sinatra, among many, many good reasons because:

  • massively sexy HTTP DSL.
  • single file apps. Though I confess I write very few of those, it looks neat because it’s minimal.
  • possibly the thinnest layer between your app and HTTP that can still be called a framework. Think of it as if you’re just being handed the C in MVC. As for the rest, you’ll roll your own.

This minimalism I’m giving such high regard to has nothing to do with performance. It has, however, everything to do with craftmanship. While crafting an app, your mind is set on simplicity and beauty. The difference is similar to what you see between mass produced goods and artisanry.

Rails 3

So we’re more and more seeing news about Rails 3 coming out. Other than being my day job, I haven’t found myself using it since Sinatra happened in my life. But seeing that the minds behind it made all the right decisions they could’ve possibly made, and on top of that Yehuda says the magic words that grab my attention, I set to find out how one can write small, sexy, and functional apps, in a single file, using only what I really need from Rails 3.

For this piglet, I decided for no interface whatsoever. All I want is something I can curl requests at and get JSON responses back. It’ll be a simple HTML page storage REST-ish HTTP interface.


You can grab the gist here.

The first thing you might notice is it is sexy, but it has love handles. I’m banking on the reason being my lack of understanding of how Rails 3 works. If you know of a better way to do it, hit me up on Twitter.

How it works

Create a config.ru file, and presuming you copied the contents of the gist into a file named “single.rb”, write this in:

$.unshift '.'
require 'single'
run SmallNSexy

Get Unicorn installed. As of when I last tested this example, Webrick failed to recognize any routes that Rails 3 creates. Then in the console:

$ unicorn 

By the way, I’m running Ruby 1.9.2 that I installed via rvm:

$ ruby -v
ruby 1.9.1p378 (2010-01-10 revision 26273) [i386-darwin10.4.0]

So let’s create a document:

$ curl -d 'name=test1&body=stuff written in this document' localhost:8080/pages
{name: test1, body: stuff written in this document}

Retrieving that same document:

$ curl localhost:8080/pages/test1
{"name": "test1", "body": "stuff written in this document"}


Yeah but, why?

My own biggest reason for a comeback to Rails is not having to be stuck with that same old way of building Rails apps. All I want is a few classes to handle HTTP-related stuff. I don’t need not even a suggestion for an ORM or a testing framework. I’m into Lego. I’ll assemble what I need quick enough for it not to be a hassle, and fun.

Yeah but you didn’t come up with this one

Disclaimer: this is an opinion piece. Probably as much as the subject anyways, except that Joe Hewitt wrote Firebug, and is generally known for being awesome, unlike me. So at any rate, I’m from now on allowed to say whatever the fuck I want without linking any evidence because I’m just saying how I feel towards his thoughts.

What’s it about?

Joe Hewitt recently wrote a series of tweets ranting about how the web in general sucks, more or less starting here as far as I can tell. First and foremost, I agree that this whole web pages deal could’ve been done a lot better, so I’m not defending the status quo as a great job. Though I am however saying that when you have tech that is as politicized as HTML, we gotta be thankful that we somehow managed to dig ourselves out of what we got thrown into by a certain company that had an agenda in hindering it as hard as it could, before 2020.

So, tweet by tweet, my thoughts:

Redirect your hatred of Flash to the W3C, whose embarrassingly slow pace forced devs to use a plugin because the standards were so weak.

I sure hope he’s not in favor of those full-page Flash websites still alive around the web. While I agree that portability-wise it was great that you could write once and see it working (almost) everywhere, I fail to recall a single one of those websites that were as nearly as usable as what HTML would give you. I’m specifically talking about bookmarking, back/forward buttons, linking, and forms.

Browser makers need to go nuts with non-standard APIs and let the W3C standardize later. Waiting for the committee to innovate is suicide.

Oh but they do. I’m sure he knows that and meant something else in here.

10 years ago we bullied Microsoft into stopping innovation on IE so the W3C could take over. How’d that work out?

I’m still thinking Joe is awesome, but that’s despite this particular tweet. Their very move against Netscape (heck, Google it, but I just take you all heard the story) shows what happened to what they perceived as a threat. So if anyone did anything, it was making sure we wouldn’t have Internet Explorer as the gateway to the whole interwebs.

For those too young to remember, IE was innovating like crazy from 4.0 -6.0, right up until the DOJ and web standards commies intervened.

I’m not sarcasm impaired, so I’ll ignore commies. Shades of grey right? That’s fine. I believe that apart from working hard to ensure no one would be using anything other than their own browser for the next few decades, they did bring some good stuff in, like XMLHTTPRequest (fuck knows why “XML”, though it had to suck somehow). But is it hard to see how a situation where everyone needs to use your own company’s web browser or else everything looks broken, a bad idea as far as said company can see? Not strictly related to web, but please do check this out.

I want desperately to be a web developer again, but if I have to wait until 2020 for browsers to do what Cocoa can do in 2010, I won’t wait.


I am ranting because I want to drop Cocoa and go back to the web, but I am upset about how much power I have to give up to do that.

And I’d love to be able to write HTML/CSS/Javascript for nothing else other than Webkit too. If you’re coming (back, as I understand) from an environment aimed at a certain platform (Cocoa), onto another that’s aimed at working at a number of, then yeah, you’ll be annoyed as hell for having to deal with problems that just don’t exist where consistency is the norm.

Were the standards whatever comes out of the Webkit nightlies and nothing else, you bet we wouldn’t be having this conversation. The point being: you’re comparing the outcomes of software running on one platform versus many. The former will always win, but that’s just not an option when we’re talking about browsers.

I’ve been hard on Flash, but we should all thank Macromedia/Adobe for 10 years of picking up the slack of the W3C, Microsoft, and Mozilla.

I don’t even believe they had the same kind of challenges to begin with. Macromedia for one, despite having ubiquity when it came to adoption of their plugin, they did one hell of a sucky job making it perform well, not crash, and even be portable (who can forget the whole episode of the GNU/Linux Flash player) and more importantly: develop a culture that praised developers for how usable their apps are. I know the tools were there to make it so (for the record, not so much a few years ago) but then what the hell is wrong with these people? Who figured that floating animated menus of 3 layers and bubbles was a good deal for the end user?

I would prefer to see web standards managed the way Python is - in the open, with a “benevolent dictator” who has a coherent vision.

I’d love that too, probably in the short term. Long term, you can rest assured whoever got a hold of it would do what MS did back in the IE days: make damn sure they’re the only one selling tickets to this show.

And final

Things that succeed as standards: TCP/IP, HTTP, URL, XML, JSON, CLI. Things that fail as standards: HTML, CSS, SVG, DOM, JS.

Had Big Government back in the day anticipated we’d be now looking at things like Wikileaks, the music industry and their piracy crusade, political scandals generally making it to the internet way before The Media picks them up, you think at least TCP/IP and HTTP would’ve gotten through unharmed? Namely: geared exclusively towards solving technical problems as they are rather than addressing concerns like “how do we track this person?” or “is this person authorized to publish this content?”.

I just think MS had the foresight and acted on it early. Hence, the mess I admit we are in now.

Another disclaimer

I’m assuming here that a lot of what he said can’t be properly summarized not in 140 characters, not a in a series of. So I’m definitely not having a stab at his persona or his intelligence.

Free learning material

There’s two things that happen when you visit a web page.

  • you get to see it from a end-user’s perspective (see images, read content, interact).
  • you get to read the source and styles or inspect the document and all that comes with it, should you choose to.

Surprisingly not enough people who have an interest in understanding how to write good HTML / CSS do the second.

In the circle that I sometimes hang out, there seems to be a legitimate interest from developers to learn how to write markup, as evidenced by Ben Schwarz’s workshop having sold out rather quickly (if his tweets are any indication). If you get the chance to go to one of these events, do yourself a favor and go. I say that not because I believe that’s the only way you can learn (keep on reading), but because learning from developers instead of teachers means you’ll waste a lot less time. You’ll get to see some of what the tutor has done for real projects, and the chance to ask why it was done like so.

But in the interest of giving people something to do until they decide to take on a course, there’s something I do often that I find it works pretty well: building small scale prototypes of parts of websites you like. Bear in mind that this is not an argument in favor of copying others. Though that’s a rather decent self-teaching methodology, it’s also pretty scummy if you’re actually launching things this way.

Think of it like this: the blueprints to lots of high quality work are being throw at you. Now all you need to know is how to catch it.

I want you to start bookmarking websites of low to medium profile design / development studios out there. These are the guys who care about doing it right. A few sources I have on my Google Reader: Line25 (the Sites of the Week section), Six Revisions and BeCreative Magazine. Keep an eye out for the bottom of the articles where in general, authors link the firms where they work. Check them out, and look for a portfolio section. Stay away from Facebook, Google, and the likes. It seems most of the giants don’t give a damn and just do whatever they want when it comes to markup.

Now go get Firebug installed if you’re using Firefox, or enable the development tools in Safari or Chrome. As for IE, you can get Firebug Lite set up as a bookmarklet. Now start poking around by firing up the DOM inspector. Look for how they laid the base page structure, headings, comments section if any, navigation, etc. That’s all fine and dandy, but you can do that all day and you won’t learn fast enough. You need to sing along. So open up a text editor, and start writing a document in parallel, copying bit by bit. Use inline stylesheets if necessary to keep things minimal. Don’t bother trying to replicate every asset they have. That’s not important. What’s important is that you understand why the markup is written the way it is. Forget about the right way to do it. You’ll start understanding the patterns once you go through 10 or so of those.

Done? Move on. Don’t be tempted to fix anything. It most likely won’t look as good as the original, and that’s fine. You’re better now than you were when you started. Win. When you get into the habit of doing that, you’ll go through markup like it’s fine food.

One of the most intriguing pieces of markup I read recently was http://camendesign.com/. Open that website up on your iPhone (or whatever phone you have that has a remotely decent web browser). If you’re trendy and you have an iPad, open it up on it too. Now put both your phone and your iPad next to your monitor, and behold: valid, gracefully degrading, mobile friendly HTML5. I don’t think I learned as much from any HTML5 article as I learned from reading how this guy did it. It’s brilliant. If you can make your mini prototype off of this website, while keeping it portable across devices, odds are you now understand how it works, and you can roll your own.

This advice goes not only for HTML, but for any programming language. If you’re not reading source code, you’re doing it wrong. Learning how to build things strictly (or even mostly) from the perspective of a language’s syntax is slow and unrewarding. That’s like kids having to learn math by running equations over and over. Get them to build a shed while applying geometry instead and you’ll get not only people who really get it but also potential engineers. So screw formal learning methodologies. Go to http://github.com, pick a small project of renown, clone it or read it online, and try to understand how people who are more experienced than you did it.

ps: and quit bitching about my blog’s layout / style. I’m just using a theme from Tumblr since I didn’t think this whole blogging business would go anywhere. I’m well aware it could be done a lot better. And it will be.

Why Tony Stark is better than you

My all time hero as a developer is Tony Stark.

It has nothing to do with the fact he’s rich, famous, or that he gets the ladies. It’s because Tony Stark builds his tech, front-end and back-end. He doesn’t make things that just do the job. They do, but they look awesome while at it.

You see, most developers nowadays fit in one or more of the following brands of bad: “I’m a developer, hence:”

  • I don’t have to care about how things look. I have a designer who handles that for me.
  • it’s ok for me to be ignorant about how to lay down a good interface, because I’m a right side of the brain kind of person.
  • I’m happy with unusable interfaces that look plain bad. Hey, as long as my forms get posted, I’m set.

Now picture Tony Stark coming back from the cave where it all began, and hiring a team of designers to come up with the Iron Man suit. Then having 2 meetings per week until finally, after 2 years, they come to a consensus, after which he retreats to his lab with the final design, and proceeds to build the suit, only to find out that turns out the groin region looks weird, so he re-submits the design to be amended. Another few months of back and forth and he’s done. By then, the world has been taken over by the evil guys.

If you can’t design, don’t be proud about it. That most likely is so because either you learned to accept as gospel whatever negative remarks people made about your attempts at making something that looks good, or because you never tried. And then because you decided it wasn’t worth learning. Listen up: there’s nothing clever about limiting yourself.

This mindset makes you a code monkey. You will never come up with anything that has any decent wow factor to it. If you justify that by saying you like to write libraries exclusively, I’d hedge my bets on them being average at best. Why? Because you’re not spending enough time solving end-user problems, hence, you got no clue on how you could make your library feel great to use. It probably reeks of old school, cryptic software made for other mediocre programmers like yourself.

So what can you do about it?

Stop believing Photoshop, Pixelmator, Illustrator, or anything else is too hard. These tools can have a steep learning curve (not as bad as you’d think), but so did programming when you were starting on this game. Nothing was immediately clear, you’d see people writing awesome code all around and you had no clue on where to begin. But you went on for over 30 minutes, asked questions, annoyed your programmer friends, and wrote bad code until you learned from a bunch of mistakes, and (hopefully) you got good at it. That’s the whole formula, and you already knew it.

Still don’t want to fork the cash for these suites, or you consider yourself really incapable of learning any of them? Design straight in HTML and CSS. It will be fast as hell once you master it, and like anything else, you will only master it by doing a lot. HTML came a long way since the 90s. Things do look great nowadays if you know how to write good markup and stylesheets.

What do you get in all this?

Freedom and power. The moment you’re capable of make things look good AND on top of that, build fast and efficient back-ends, there’s no stopping you. Don’t get me wrong, you might still work with specialized designers (and you probably should), but you’ll be in a very different position: you’ll be a qualified collaborator. Your knowledge of How Things Work™ combined with good architecture and style is what software nirvana is made of. You’re officially out of the bag of cats that a lot of self-appointed designers like CEOs and managers are, into the land of your input counts.

Don’t side with mediocrity. If you hear someone tell you you can’t do it, assume this person has an agenda in keeping you low. Go aggressive on them. Better yet: laugh. Don’t take full negatives as truth. Your average work today is the half way through to awesomeness. They don’t have to believe that, but you do.

Then take suggestions well. Which doesn’t mean accepting them as they come. Hear people out, and if it sounds like something you could like, then give it a try. Come back to the person who made the suggestion and show your work. If they like it, accept whatever compliments you get. If they seem to find nits to pick ad nauseam, walk away. It’s poison. It’s likely that they’re concerned about you becoming better than them so they just can’t hand that one to you.

And finally, hone those skills at every goddamned chance you have. A few hours a week will do. When you get any good, it will stop being a chore and start paying off.