Petri Wessman's weblog

Minireview: Rails Antipatterns, by Chad Pytel and Tammer Saleh

Ruby on Rails, nowadays sporting a major version number of 3, has become one of the more popular web development platforms – for good reason, in my opinion. The design is quite elegant, and the emphasis on “convention over configuration” lets you design apps with surprisingly few lines of code. Also, being based on Ruby gives it another layer of elegance (again, in my opinion).

However, all this seeming simplicity hides the fact that both the language (Ruby) and the platform are actually quite complex, underneath the simple exterior. Things work well if the designer follows the Rails (and Ruby) conventions and has at least some understanding of how a web app stack works. Unfortunately, in reality all too many programmers try to use Rails to emulate what they are already familiar with (PHP, in many cases), and even “professional programmers” seem to sometimes have only the faintest idea of how web apps actually work underneath the hood. The result can be a horror show.

Which brings us to this book, Rails Antipatterns. While it’s nominally about Rails “antipatterns” (design patterns that should not be emulated), it’s more properly a book about best practices and refactoring Rails apps. Written by people with extensive and painful knowledge about the horrors involved, it contains a ton of useful advice about how to (and how not to) design Rails apps. Each section focuses on a certain area of the software stack, and highlights the most common mistakes (and how to fix them).

I found it to be a great read, and even though Rails itself is nearing the publication of version 4.x at this point, virtually all of the advice within still holds true (the tiny part that doesn’t is the stuff about plugins, which are being phased out completely). If you already know Rails to some extent, this book will probably teach you a thing or three. If you don’t, you’ll be better of first reading some intro text and doing some coding of your own, and then going back to this book to see all the ways you screwed up.

As always with power tools, Rails only works properly if you know how to use it, and a large part of that is conventions, best practices and other not-initially-obvious design factors.

I personally most enjoyed the section on how to “thin down” a “fat” controller action, using ActiveModel callbacks and other related tricks. I used the advice here to refactor some of my own code with similar problems, and the end result was much cleaner.

Published on by Orava, tags , , , ,

Minireview: Effective Java (2nd Edition), by Joshua Bloch

It’s been a good long while since I last read a book on Java. I’ve been using the language in my professional work for well over a decade, and while I don’t consider myself an authority on the language I do consider myself quite competent in using it. However, there is a tendency for a certain type of statis to set it in these matters; once you learn something to “good enough” levels and find techniques that work for you, you tend to settle into using those techniques and being happy. There’s nothing wrong with this as such, but with a dynamic environment it does mean that you may be missing out on new stuff – and Java has gotten quite a few tweaks and additions since I originally learned it. Some of these I use all the time, some I use now and then but don’t deeply understand, and some I’ve only heard of but never used.

Effective Java is a book than attempts to encapsulate best practices in programming with Java, including the new 1.6 additions. As the book notes, a lot of books concentrate on the basics of languages and the mechanical details, but the “how best to use this in practice” part is typically either missing or an afterthought. This book is only about that, it assumes you already know Java and have some experience with it.

The book has a ho-hum name and cover illustration, and doesn’t really scream “read me now!”. However, it’s been getting consistent rave reviews ever since the first edition, and this new edition is an updated one which (also) covers new features in the language and how to best use them (generics, enums, all that stuff). I mostly bought it based on the reviews, and I’m glad I did.

The book is a long list of “how best to” articles on various Java subjects, grouped by general subject. While the book says it’s not really mean to be read cover to cover, that’s precisely what I did and I found it a good read – the language used is light enough, while staying focused on the subject, and the discussion is quite fascinating. I learned a lot of stuff from this book, and while there are lots of things here which I do not do in my work programming, I at least know that I should be doing them. There’s very little if anything here that I disagree with, though some of the details here do not really apply in my work; the author has been involved in creating parts of the Java main libraries, where there is need to protect against hostile code linked with your own. In my own work, the danger of hostile code in the same EAR package is not a realistic one, so some of the issues here can be sidestepped. That said, it’s good to be aware of what is dangerous in theory and what isn’t, even if that danger isn’t a valid one for you at the moment.

All in all, I fully endorse the five-star reviews this book has been getting. If you consider yourself a Java programmer, you really can’t go wrong in reading this book. Chances are you’ll learn quite a bit (I did), and this book doesn’t insult your intelligence and try to teach you obvious things.

Published on by Orava, tags , , ,

Good programmers and other mythical beasts

Haven’t written here for a while… had a nice Christmas & New Years, there was an interesting VTES tournament, lots of stuff to write about.

… but as it happens, I’ll get to that later, due to a weird coincidence. During lunch at work yesterday I was thinking about good programmers, and why they seem to be so rare. Then last night I ran into an article (via Slashdot) on how to recognize a good programmer – and it was spot on, and pretty much mirrored my own thoughts on the subject.

Thing is, most IT companies want to recruit good programmers. Many of them think they have them. In actual fact, what they tend to have is what Daniel in the article calls “career programmers”: the people who do it just as a job. They don’t have any real interest in programming, it’s just something they know well enough to get hired (but often no better than that). These people will never spontaneously teach themselves new tech, most of the time they are blithely unaware of what the “new tech” even is at any given moment. They code with the “least effort required” style; if they can cut+paste existing code that’s always the preferred solution, regardless of suitability. If they are forced to write something from scratch, they will take forever to do it, and produce something that only works with some very loose definition of “works”. They never produce elegant code, in fact they are somewhat confused by the very concept.

There’s nothing wrong, as such, with doing programming as “just another job”, without any real interest in it. It pays the bills, and there’s enough demand for programmers that even mediocre ones tend to find jobs. Problem is, it’s also a trap of sorts: the actually competent people in the company will come to realize that a given person isn’t all that hot, and the management will also probably realize it at some point, just by looking at how much the person actually gets done. This usually results in the person being given the simple, repetitive jobs (routine maintenance, implementing a new slightly different version of something that already exists, that sort of thing). This is natural, since you simply can’t give anything actually complicated to these people; it will either never get done or will be implemented in a way that will need a total rewrite in order to work. So people like this end up painting themselves into a corner, where all they will ever get to do is boring, routine stuff. For some people this is fine, for some it isn’t (and they eventually move to something more suited for them).

Don’t take this as complaining about newbie programmers, it’s not. The critical difference is what’s #1 in the article, too: “passion”. Good programmers are fascinated by the tech they use, and constantly look for new and better ways of doing things. They teach themselves stuff constantly. A good beginning programmer is not a problem, since he’ll be constantly improving himself; you just need to point him in the right direction sometimes. These people ask questions, and ask the right kinds of questions. Career programmers can’t be bothered; if they don’t know something, they expect their employer to get them on a training course (which of course won’t do much to help).

Naturally, things aren’t this black and white. There are good programmers who as totally stuck in a rut, and see everything through a lens of a single technology. There are mediocre programmers who are slowly crawling towards being competent; they might not have the real drive, but they don’t feel like sitting still either. In addition, technical skill is just part of the equation – some good programmers are insufferable prima donnas, some have way too much of a “my way or the highway” attitude, some have a total lack of all social skills… nothing is ever totally cut and dry. I consider myself to be a good programmer, but I’ve been known to have some of those faults at times. I’ve gotten better. Mostly.

Anyway, the truth of the matter is that good programmers are very hard to recruit. They are rare, they tend to already have jobs they are happy with, and they tend to be picky about recruitment terms. They also tend to be somewhat tricky to keep, since they usually want to work on cool stuff. And let’s be honest here, 95% of all IT business is anything but. Every single company pretends they have revolutionary new ideas and highly valuable proprietary information, but in reality their “valuable IP” can usually be written on the back on a napkin, with large font. Sure, some companies actually are creating interesting new stuff, but most aren’t. So, it’s a challenge to find something that’s interesting enough to keep your good people… interested.

The classic “Mythical Man Month” remarked that good programmers can be multiple times more productive than mediocre ones. That’s still true… but it’s not quite that simple. Good programmers (and, I suppose, all real professionals) are very productive when they are doing something they find interesting and/or challenging. Give them routine work, and chances are they they won’t be all they productive – they’ll be bored out of their minds, and thinking about other stuff.

So… I guess it boils down to “good people are hard to find”. Nothing new there. It was just funny reading that article, having thought about the subject just previously. Another facet was reading Zed’s infamous rant some days ago; though it’s a bit of a stupid and misguided rant, the part which struck true was the complaint that some consulting companies provide people who are… not very good in reality, and charge a silly price for it. At worst, I’ve seen and heard of cases where the management refuses to provide decent workstations or software for their own people, and is stupidly tight with money in all respects… but then some crisis or another crops up, and suddenly it’s ok to hire a consulting company for huge amounts of cash. The saddest thing here is that more often than not, the consultants will totally fuck everything up. Mediocre people working for a project they have no real interest in, for a limited time – it would be a surprise to see anything actually good come out of that. At best, you get a pile of “more or less works” code that’s a nightmare to maintain. And who does the maintenance? That’s right, the in-house folks.

I could comment more here on Zed’s Rails rant, but I’ll mostly pass – this has turned out long enough as is. What I will say is that I agree with Daniel’s reaction. Rails is a smart framework, and lots of smart people like it. Lots of smart people also hate it, and lots of dim people also seem to like it, perhaps thinking it’s the Visual Basic of the web world and that it will let them design web apps without understanding the technology. It isn’t and it won’t.

In case you are wondering, this post isn’t aimed at any particular company or person. It’s just a commentary of what I’ve seen, over decades in the business.

I love programming and IT, still. I’m glad to be doing it, and getting paid to do it. But oh boy, the idiocy I’ve seen at times…

Published on by Orava, tags , , ,

Powered by Publify – Thème Frédéric de Villamil | Photo Glenn