The difference between a tolerable programmer and a great programmer is not how many programming languages they know, and it’s not whether they prefer Python or Java. It’s whether they can communicate their ideas. By writing clear comments and technical specs, they let other programmers understand their code, which means other programmers can use and work with their code instead of rewriting it. Absent this, their code is worthless. By writing clear technical documentation for end users, they allow people to figure out what their code is supposed to do, which is the only way those users can see the value in their code.

During my years of coding HTML I’ve done some bad things. Some really bad things, man. I’ve coded myself into corners, made huge refactors, and so on. One of the main issues I’ve seen is that the HTML hasn’t been flexible enough. I’ve made my markup and styling too tightly coupled. Sadly, one of the factors of that has been my urge to do clean and semantic HTML with few attributes on my tags. Changing one thing made me to changes in another place as well. Not DRY.

An example. Here’s a box for author information in the bottom of a blog post.

<footer>
	<h2>Joe Doe</h2>

	<img src="avatar-joe.jpg" alt="Joe" />

	<p>
One morning, when Gregor Samsa woke from troubled dreams, he found himself transformed in his bed into a horrible vermin. He lay on his armour-like back, and if he lifted his head a little he could see his brown belly, slightly domed and divided by arches into stiff sections.
	</p>
	
</footer>

Minimal but good example of clean HTML. But a bit naïve. How would you style the image avatar in CSS? Piece of cake (assuming the footer element is in an article):

article footer img {
	float: left;
}

Okay. But say you wrap the img tag in a figure for example? Then your styling perhaps doesn’t behave as expected. If you add more images in the box, weird stuff may happen as well.

The author description (in the p tag) is interesting too. I’ve made this example minimal, but now the text is wrapped in a single paragraph tag. But what if you need more paragraphs? Other elements in the description? Then some refactorings has to be made.

<footer class="post-author">
	<h2>Joe Doe</h2>

	<figure class="author-avatar">	
		<img src="avatar-joe.jpg" alt="Joe" />
	</figure>

	<div class="author-bio">
		<p>
			One morning, when Gregor Samsa woke from troubled dreams, he found himself transformed in his bed into a horrible vermin. He lay on his armour-like back, and if he lifted his head a little he could see his brown belly, slightly domed and divided by arches into stiff sections.
		</p>
	</div>
</footer>

Above you see the markup I would write. Notice the additional class attributes and the div element wrapper.

But why, oh why?

Because it lets me write more robust, flexible and portable HTML. In my CSS, I don’t rely on element tags (which may change during time). As long as I don’t nest the styling too far, my markup will stay the same if I decide to alter the HTML structure (which as you know always happens).

In a way, this is what the idea about the roles of HTML and CSS is all about. Remember the markup is for presentation, structure? And CSS is for styling? So why would the presentation and styling be dependent on each other? With class hooks, the CSS is able to keep a reference to the elements in the markup in a much more reliable way than only doing element hooks. It’s tricky to write super clean HTML for small sites, and close to impossible for larger sites, with content and HTML spitted out from a CMS or whatever. It’s your task as a web developer to make your markup and styling go nice together, living in harmony, and using each others’ strengths. I usually keep the mantras modular, re-usable, generalized close to mind.

Classes in your markup is fine. Just don’t abuse it, keep a sane balance. It’s like in sex: if it feels good, it’s probably totally okay to do.

Almost everybody begins OOP with this misconception – objects in real world directly map to OOP objects. Its maybe a good place to start but how many grow up from the initial simplistic rule – map nouns in requirements to classes. So, you end up with objects that don’t really mean anything and don’t do much. Naive use of UML diagrams also leads to this. Discovering abstractions is tricky. One needs to really live with requirements inside out before they present themselves.

From a Hacker News comment on this story about Clojure programming. I’ve seen this myself in school, where we’ve gone through endless examples of OOP where the classes were a Ball, a Car, a Zebra, or other overused objects in the real world. The thing is, most programming isn’t about modeling the real world, our world. When writing code you’re free to do things your way, not being tied to the constraints of the real world thinking.

When we were doing our first large programming project (which was an awesome 2D game: “Frank the Tank”), we went straight ahead with a semi-naïve approach when doing the initial domain model. As we went on, more models were thrown in in order to accomodate all possible requirements we had set up. All models were real world things a regular person could understand (“Player, Enemy, MachineGun”, etc.). Later on in the modeling stage we started to realize things weren’t right. We had represented reality in too fine grained detail, and started to rethink our model from a computational perspective. Thinking in high-level abstractions, working with sensible inheritance and interfaces, we started to re-implement everything the way it should be done in a computer game. It worked very well.

Don’t adhere to everything the professors in university says. Then you’ll hit a brick wall later on, when you realize the computer’s reality isn’t a mirror of your own.

★ Permalink

Programming is a way of thinking, not a rote skill. Learning about “for” loops is not learning to program, any more than learning about pencils is learning to draw.

Bret Victor’s essay on “Learnable Programming” is a really solid piece on how improvements can be made when creating tools and techniques to learn how to program. I love the amount of detail and work he’s put down in the article. It’s not a secret that Victor has huge insights in this area – I’m especially fond of his Tangle Javascript library and the article “Ladder of Abstraction”.

During the past month at university, I’ve acted as a help teacher in the beginner programming course (“Object Oriented Programming using Java”). I’ve tried to push for a more wider understanding for programming: that the students should learn how to think programming – not just how to create a while-loop in Java. Far too many times I’ve seen the students get stuck on petty concepts in Java which isn’t relevant at all in the big plan. The tools to learn are often embarrassingly outdated and weak, and many fail the course. Programming and computer science is a new branch in education – it’s time to start developing modern techniques for teaching it more efficiently.

★ Permalink

Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

In the design world, content is everything. Design without context and content is just noise. In the programming world, code is (usually) nothing without data and the structuring of that data. Fail to manage the content and you fail to build a stable and extendable system.

★ Permalink

While I was getting our sailing boat in order for a trip during the past weekend, I had an insight.

Good software code is like a reliable knot

I was tying some ropes and it hit me how knots can be as beautiful, simple, messy and complex as code is.

• A good knot should be elegant but robust
• A good knot should be simple enough to understand and solve by another person
• The more complex the knot is, the more open it is to vulnerabilities and weaknesses
• Using existing knots which are proved to work in certain conditions is good
• A good knot in one situation may not be the optimal choice in another

Now switch knot above to piece of code or software.

I reckon you might be able to draw parallels about programming to many areas, but I think knots are one of the clearest comparisons.

To my mind that’s a craft. I think the best programmers are closer to watchmakers than bridge builders or physicists. Sure, it looks like it’s science or engineering because of the application of logic and mathematics, but at its core it’s taking tools in your hands (almost) and crafting something.

So many gems in there.

★ Permalink

Visit the app on systemet.johanbrook.com oppet.systmt.se. The source is on GitHub. I built it with mobiles in mind, but it’s of course usable on all other web devices. If you’re on iOS, feel free to add it to your homescreen for quick access and the full experience (I said that because I’ve made an icon and adjusted the app for native mode …).

Thanks to Niklas Jakobsen for the awesome subdomain! (“Öppet” is Swedish for “open”).

The “why”

1. I wanted to build it
2. I wanted to learn more about Node.js, MongoDB, CoffeeScript, and web APIs and services

The process

I started to research ways of getting a list of all stores along with their coordinates and opening hours. Seemed rare at first: 3rd party APIs only offered the product index. But it turned out Systembolaget has official, open API resources for this on this page. They are served in XML (uhh ..) and XLS (argh!) format, and are quite badly formatted.

On top of that, the coordinates for the store XML file are in RT90 format – not the “standard” WGS coordinate system. Since the app gets regular coordinates from the built-in GeoLocation sensor, I had to convert them from the XML file. My father is a surveyor, and along with some research I found neat formulas for converting RT90 to regular coordinates. The Gauss-Krüger method is common, and I also found existing Javascript code for the conversion.

After a lot of testing I could start doing the real thing. I began with getting to know Node.js, Express.js better along with basic conventions. Everything went quite fast since the language (Javascript) itself wasn’t a problem, but instead the Node way of doing things were new to me. I separated the code in two parts:

1. The main app which should serve a start page where client side JS would get the device’s coordinates, send them as parameters via XHR to my Express app route which should find the closest store and send the data back as JSON.
2. The import script which should get the XML from Systembolaget’s website, parse it as JSON, and insert it into a MongoDB database.

I of course didn’t want to get the whole XML file from the API on every app request, as it would be the only way of doing it. Systembolaget’s “API” isn’t that sophisticated. Instead I put it all into a Mongo database, which meant I could use all the very useful geospatial indexing features of MongoDB:

collection.ensureIndex loc: "2d"
collection.find(loc: $near: [50, 50])

Where [50,50] are the coordinates I would get from the client. Neat.

Hosting

I began glueing everything together, and it worked quite well locally. Win! The closest liquor store showed up with the correct dates and hours. But I of course wanted to host it online for me and everybody. I instantly thought on Heroku since they offer Node.js hosting nowadays. They also have free MongoDB instances which would serve my purposes well enough. Since I needed to parse XML from Systembolaget’s service when it’s updated, a cronjob service was required. Heroku offers that (for free!) as well.

Node.js deployments on Heroku was something I had never done before – I’ve only worked with Ruby stacks. Turned out everything went smooth. After fiddling with the MongoDB connection for a while I got everything to work almost painlessly. Kudos to Heroku.

Conclusion

The user base of my web app is limited to Swedish readers, but it was fun hack nevertheless. I learned a lot about Node.js and asynchronous programming, which wasn’t that easy to wrap my head around at first. Node.js was more low level web server stuff than I had previously done before.

Check out the source code in the GitHub repo and give feedback.

Our proposal: BDGT for iPhone

BDGT is an iPhone app which keeps track of daily transactions and will let you overlook your flow of money. In a simple and quick interface, you’re able to add a transaction, put it in a category, and you’re done. Boom. For now: in BDGT you specify a budget which always is present and shown for you.

The general idea for the app is to simplify people’s everyday home economy, and help you keeping track of the flow.

Feel free to visit bdgt.me and follow us on Twitter (@BDGTme), Facebook (BDGT), and Tumblr (blog.bdgt.me). Feel free to ask us anything or give feedback through any of these channels. Don’t forget to sign up for the newsletter as well.

We hope to release further info, screenshots, and videos during the period until release.

Thank you!

If you’re doing the right amount of testing, there should be a good chance, whenever you kick off a test run, that your actions for the next hour will change depending on the results of the run. If you typically don’t change your actions based on the information from the tests, then the effort spent to write tests gathering that information was wasted.

David Heinemeier Hansson writes about sane amounts of software tests, which he ranted a bit about on Twitter today. I haven’t enough experience with tests yet, so I can’t give valid comments, but I’ve begun to understand what he and others are talking about thanks to a heavy focus on unit tests in a university course. Putting tons of time on writing tests instead of actual code seem insane to me, and David’s thoughts about having advice on what not to test seems legit to me (I recommend reading the comments on the Hacker News entry as well).

In the end I think it boils down to a healthy balance, as with everything else in life.

★ Permalink