Interesting reading if you’re a UNIX geek. I’ve always wondered what the difference was between bin, sbin, usr/bin and usr/sbin. Turns out it has a lot to do with disk sizes back in 1971.
Well, this looks pretty darn cool!
I don’t know how much a Kindle Fire weights but who holds it like this? She barely has a grip on it at all! One slip and it’s falling to the hard floor below.
Why Signing and Dating Code Comments is a Good Practice
I’ve been signing and dating my code comments for a couple of years now. I started doing it because it seemed like a good idea at the time. First, you should be aware I believe most comments should explain why instead of what. The why comments comprise the vast majority of my comments and those are the ones I sign and date. It’s like a simple signature for code.
For example:
# This Combustible model class was originally designed for the '2012
# Exploding Things' promotion. Only the objects/fields required for this
# promotion were put into the data model but it is intentionally generic
# enough to be expanded upon to create a more robust explosion system in
# the future should the need arise. Only the most basic relationships and
# validations are included at this point.
#
# --mluton (2012-01-11)
This is helps for a couple of reasons. First, people reading this in the future (myself included) will know who’s responsible for the decisions that went into this chunk of code. Experienced developers know that simply being aware of who originally wrote something can tell you a lot about the kind of thinking (or lack thereof) that went into the design of it. Version control tools can tell you who touched specific lines over the course of time but a signed comment will give you a better idea for who truly responsible for it. A subtle but important difference.
Secondly, it tells you how fresh the decisions are that went into the code. If you’re dealing with a particularly convoluted piece of code it’s nice to know if originally developed two years ago, two weeks ago or somewhere in between. If it was two years ago chances are good you have more freedom to challenge those decisions and rewrite it to conform to more current needs. Or not. Either way, it’s useful information to have.
Often times developers will comment out code instead of deleting it because they have reason to believe the removal is only temporary. Uncommenting it later is much easier than looking through commit logs for the old code to restore. However, many times the removal does indeed turn out to be permanent but the code stays in the source file commented out forever because nobody can remember why it was commented out in the first place and nobody wants to take responsibility for deleting it. Anytime I comment out code which I have reason to believe should be completely removed at some point in the future I leave a signed and dated comment as a way to mark it for permanent deletion if enough time passes. For example…
# We're removing the 'ultra-wide skyscrapper' ad to see if the new
# 'big box' unit works out better for us. If this is still commented out
# after August 1st 2012 then please delete this for good.
#
# --mluton (2012-01-11)
Finally, another benefit is that you have a unique string you can grep for. Being able to quickly find all the places where you have signed a comment can come in useful.
via Matt Gemmell. So much potential with iBooks 2 and iBooks Author.
Code Comments Should Explain ‘Why’ Instead Of ‘What’
I’m a comment minimalist. I don’t believe in commenting what code does. That should be plainly obvious by reading the code itself. More useful is why a block of code exists or why it was written a particular way. These are the questions I ask most often when reading code (including my own) so I try to be conscious of it when writing code.
If I’m writing something I think might be challenged other developers I’ll write a comment to defend my position and explain the circumstances and tradeoffs which had to be made for that piece of code to exist the way it does.
If I’m writing something based on assumptions which I’m fairly certain will change over time I’ll write a comment to explain the assumptions and speculate on how they may change over time. I’ll try to provide ideas on how to deal with those changes when they inevitability happen.
If I’m cutting corners because I’m working under unreasonable time pressures and need to ship something in the extremely near future I’ll write a comment to explain why I’m cutting a particular corner in a particular way.
If I’m writing a complex piece of logic I’ll try to summarize what’s happening in addition to why it has to be complex. Further down the road other developers may try to simplify this complex logic so it helps to anticipate how someone might attempt this and explain why it won’t work.
If I’m writing something in a non-obvious way for performance reasons I’ll write a comment to explain why along with some sample benchmark comparisons if appropriate. Someone in the future may try to rewrite it in the obvious way but will be unaware of the performance tradeoffs involved. It’s good to explain these things to ward off future regressions.
Of course, this ignores the whole world of documentation comments. These are the style of comments which conform to a standard format which can be parsed to produce nice looking API documentation for references purposes. This is a great thing and I fully support it. It’s practically required for certain types of projects with developer APIs. However, in my experience working on ‘custom/closed’ projects I’ve found it extremely difficult to get everyone to actually write these kind of comments consistently. For documentation comments to really work they have to be applied completely and consistently. My overall philosophy is this. If you are willing and able to write good documentation comments then please do. If not, then fine. But you must at least write comments explaining the why of a chunk of code in any of the above cases.
Really? 30MB of save game data? I wonder what’s in there?
Most interesting tidbit from this article is that Steve Jobs carried his iPhone in the same pocket as his keys. Really?! My iPhone doesn’t share pocket space with anything else specifically because I don’t want to scratch it.
Jonathan Coulton has some intelligent things to say about the SOPA/PIPA/MegaUpload drama of this past week. I know there are a lot of people who will pirate stuff just for the sake of pirating it. It’s not a “lost sale” because they never would have bought it in the first place. But having it on their hard drive illegally somehow makes them cooler. Go figure.
While I don’t agree with everything in this article — many people rely too heavily on metrics rather than their own intuition — I particularly like the section which describes how a website can become totaled.
While there are many ways to tackle tech and UX debt on an incremental level, there comes a point when the website, in essence, becomes “totalled.” Like a car that has sustained damage greater in cost than its value, your website gets to the point where starting over would be cheaper than fixing all of the items on your debt list.
This reminds me of a quote I learned in college which goes, “Build one to throw away because you will anyway.” The key phrase being “you will anyway”. Of course, nowadays we put this under the umbrella of “iterative development”. Not all iterations are the equal in size though. Sometimes you need to take a step back and embark on a larger iteration which involves rethinking the entire structure of your site. If you don’t chances are good your site will slowly become irrelevant. Or worse, never become relevant in the first place.
Look at the amazing transformation Path made when they redesigned their product not long ago. One rule I would add is this. If after 12 months you haven’t gained significant traction in your market you seriously need to rethink your product.
