2008
I Heart Complexity
Like I said, I think the market for simple applications is probably saturated and now is the time for Ruby and Rails to go up-market and tackle bigger problems. We’re well equipped to do that, having learned from what sorts of simplicity help reduce tricky problems to tractable problems.
In my RailsConf Europe 2008 presentation, I play the role of the messenger. I’m not bringing any new science that makes building more involved applications easier. Instead, I’m trying to tie it together into an understandable package. You take the gems described herein (money, acts_as_state_machine and acts_as_versioned) and a couple concepts (domain driven design and queueing) and you can build some really cool applications that solve pretty tricky problems. To me, that’s big fun.
You can check the presentation out on Slideshare or grab the PDF. Also, make sure to check out the code on GitHub. Enjoy!
Pretty Parallax
jParallax - a JavaScript gizmo for composing images using a parallax effect. In other words, insanely cool.
Freakonomics
Freakonomics. Its not about economics in the dry, dismal sense that I remember from college. This is more about counterintuitive turns of logic, data showing causations that no one really supposed made sense. In the end, its about economics in the sense that real estate agents, sumo wrestlers and criminals respond to financial, social and lifestyle incentives.
Oh, and the book features twenty misspellings of the name “Jasmine”, a bit on two brothers named Winner and Loser, and a person named Shithead. Predictably, the last was my favorite.
RailsConf Europe, here I come
RailsConf Europe is next week. I’m so there!
I’m giving a talk on complexity and how I heart it. Ruby, and Rails in particular, started out with a very strong statement against complexity. Mostly this was about the complexity that imposed by ceremonious frameworks and technologies.
My stance is that all the really simple applications are done. But perhaps there are some ideas, some complexity, we can add to our problem-solving repertoire that let us tackle much larger applications. Some levers we can use to apply a little force and get a lot of result. Please to be joining me!
I took a couple years of German in high school, which is hopefully going to pay off as Courtney and I travel about Germany. If you’re at the conference, please come say hi, but forgive my Texan drawl. Ich spreche ein bisschen Deutsch! How little? Here is the translation of my first attempt, from my memory of German: “I am a small German language!”
(Oh, and rumor has it that there may be one more MVC video. Maybe.)
Guns, Germs and Steel
Guns, Germs and Steel is one of those essential books that makes more sense of the world. Specifically, it address in rational terms, how it came to be that the modern world is arranged as it is where it concerns the haves and have-nots on the global scale.
The author, Jared Diamond, does so by taking an extremely long view on history, over the course of the last ten thousand plus years). From there he tries to build models and theories that predict why some societies advanced faster than others. To make a long story short, the societies that have become the contemporary first world were able to:
- Move knowledge and technology on an east-west axis, an axis that allows easy migration and translation of farming knowledge because the climate is roughly the same
- Develop immunity to epidemic diseases like small-pox that are tied to living near agriculture, thus making them less likely to get killed off by certain foreign invaders or to kill off natives as they travel to foreign lands
- Organize people into ever-large structures that can sustain invasions, research and other useful forms of specialization
Of course there’s more to it than that. It’s a great read and illuminates all sorts of topics I’d never even thought of, let alone correlated. If you, like me, seek a greater understanding of the abstracts that define the world, this is a book for you.
"with" for Ruby
Use with caution:
That said, @with@ is discouraged in JavaScript. If you can, its better to have methods return @self@ so you can chain like so: @people.get_dressed.put_on_music.and_party!@
Last.fm's shame aggregator
Most Unwanted Scrobbles - Last.fm aggregates the tracks and artists that people don’t want the internet-at-large to know they listen to. Britney Spears appears twice in the top five songs, along with Nelly Furtado, Amy Winehouse and Avril Lavigne. The Beatles, Radiohead, Britney Spears and Avril Lavigne are the top 5 arists (along with Unknown.)
So I guess Last.fm users are just too damn cool to admit to some of their tastes. Me, I’m fine with letting you know I listened to Sir Mix-A-Lot’s Mack Daddy in its entirety this week.
Domain Driven Design
Designing software is a tricky thing. It’s tempting to front-load it on a project. That won’t work because the start of a project is when you know the least about it. So some folks try to do as little design as possible. I’m guilty of this. However, that can lead to software that doesn’t adequately express the problem it’s trying to solve. Further, there is often a temptation to over-design software with lots of ceremony and architecture. Contrary to this is the temptation to not design it at all, which again leads to software that doesn’t express itself.
There’s a book that draws a reasonable compromise between these forces. I’ve been meaning to read Eric Evans' Domain Driven Design for a while now. The emphasis of the book is in collaborating with domain experts and other developers to find the essence of the problem space and then express that in software (as objects). I’ve often pointed out the utility of building applications from the language up and the problem domain down. DDD focuses precisely on the latter.
One of the core concepts in the book is the ubiquitous language that is used to describe the problem at hand. This language is used by the domain experts (customers) and the developers. The language is then woven into the design of the system. This leads to software that is more likely to succeed, both in business terms and in terms of development effort. Evans spends the first part of the book describing the particulars of this language.
He then moves on to describing the technical side of the software. Entities, value objects, services, factories, modules and repositories are terms I was already somewhat familiar with that Evans gave a more crisp and satisfying definition to. For most people, this is probably the tasty meat of the book, illuminating the way from a competent developer to an outstanding developer.
The last part of the book focuses on the larger scale issues of deep design. I was particularly pleased that he covers how software design is affected by various good and bad social issues. It also gives a strategic view of the forest, where most books on software development focus on a more tactical view of each tree.
I’m fond of pointing out books that are inflection points in my way of thinking about software development. Code Complete, The Pragmatic Programmer, The Dragon Book and My Job Went To India all fall under this category. Domain Driven Design is certainly the latest edition. It makes sense of trends I see in great software and illuminates a path to make software like it myself.
If reading this review didn’t make you want to vomit, you should probably read the book posthaste.
Interview with David Flanagan, part 2
The second part of my interview with David Flanagan is online. This time around we talk about the craft of programming in general. Its good stuff.
Io's intriguing design
I didn’t manage to touch on this in What Has Ruby Done For You Lately, but Io is a really impressive language. Mostly in the minimal number of concepts one needs to grasp in order to deeply understand the language.
To pick on Java (sorry), a list of concepts you need in order to grasp Java:
- Primitive types
- Objects
- Classes
- Interfaces
- Inheritance
- Iteration
- Conditionals
- Operators
- Type casting
- Generics
- Method calls
I’m sure I’m missing some. Further, that’s just what you need to write a program with one class. To build a realistic system you need to know about class paths, packages and all sorts of arcane details.
In comparison, to build a simplistic Io program, you need to understand:
- Lazy evaluation
- Objects as prototypes
- Short circuit evaluation
- Messages
- Closures
That list ended up about twice as long as I thought it would, actually. Really, all the average practicing programmer needs to learn is prototypes and lazy evaluation.
Io's guiding design principle is simplicity and power through conceptual unification.
That quote, from the Io Programming Guide, pulls it all together and summarizes why the language nerd in me is quite interested in Io.
Catch up with 30 Rock
OK, here’s the deal. If you’re not watching 30 Rock, you’re not watching the best show on TV. There I said it. Fortunately, you’ve got time to catch up; the show doesn’t come back until October 30th. To whet your appetite, I give you clips summarizing the “lives” of the two main characters, played by Alec Baldwin and Tina Fey.
Interview with David Flanagan
Last week I interviewed the author of The Ruby Programming Langauge, David Flanagan. We posted the first part of it today - Five Questions with David Flanagan, Part 1. The second part will go up next week. Enjoy!
American demographic inversion
In the past three decades, Chicago has undergone changes that are routinely described as gentrification, but are in fact more complicated and more profound than the process that term suggests. A better description would be "demographic inversion." Chicago is gradually coming to resemble a traditional European city--Vienna or Paris in the nineteenth century, or, for that matter, Paris today. The poor and the newcomers are living on the outskirts. The people who live near the center--some of them black or Hispanic but most of them white--are those who can afford to do so.
A fascinating read for those who like to think about how our cities evolve.
Refactoring to more code
Refactor my code is a neat site where you can post your code and watch others refactor it. I saw an interesting bit of code whiz past and thought I’d take a crack at it.
Removing conditionals from code is one of the little games I sometimes play while coding. Here, I’ve extracted the logic of the conditional into another class. The resulting class is much more code than the original. So why do that?
Well, I say you get a few benefits:
- The logic is now far easier to test. It’s a standalone object now rather than a Rails functional test.
- The flow of what’s being done and tested is more decomposed and easier to follow.
- Most importantly, the code explains itself. No need for comments (which will undoubtedly go out of sync over time) here!
While I delight in deleting code and writing as little as possible, refactoring this to more code seems the right way. What say you?
Update: Make sure you check out Marcel Molina’s refactoring. Its probably better than mine ;)
Program is information.
Its retro, its cool. It’ll come in handy when I need slides on the sameness of code and data in good programming languages.
Via Square America.
Realtime challenges
beyond rest - if publishing data in realtime, XMPP, Comet and scaling HTTP services pique your interest, this thread is an excellent read. Lots of smart people disagreeing here.