by Dave Morris

Horn Ok Please

The first time I was in India, I travelled to Bombay, Agra, Delhi, Jaipur, and Udaipur mostly by van. It was impossible not to notice the multicolored painted vans. They are covered in painted flowers, designs, and the ubiquitous “Horn OK Please.”

And why does it say this? Driving etiquette in India requires that drivers honk before passing, “to let them know you are there.” Driving with a friend and his dad, I was most amused when his dad scolded him for not honking enough. You can’t even imagine how much honking there is on a four lane highway, with each car honking every time they overtake another. It brings new meaning to the word cacophony!

A few years ago I went to Goa, India. While there, I had the chance to drive both a scooter and a car. It was so much fun. Like a video game. It was the 5th or 6th time I’d travelled in India, and I’d consistently been impressed with how traffic works, often without signals, in some kind of natural organic flow. Different types of vehicles blending together to share space.

Though Goa is far tamer than other parts of India, I still found driving very inspiring. It was fun like the best kind of driving video games — which got me thinking…

Wouldn’t it make a great video game? Imagine that you drive different kinds of vehicles. Maybe you start out with a push cart that you push yourself, move up through ox drawn carts, rickshaws, scooters and motorcycles (with at least 5 passengers), cars, and, of course, horn-ok-please trucks. You have to negotiate traffic, avoid hitting cows sleeping on the median strip, and achieve goals (like delivering the vegetables on the push cart, or picking up and dropping off customers in the rickshaw). Meanwhile, trying to incarnate up levels to better vehicles. And if you do hit that cow? Definitely incarnating downward…


It’s amazing how the traffic flows… somebody build this please? Otherwise I’ll have to go back to India for the real thing. :)

Photo Credit: Horn OK Please by Dave Morris

by Christina B Castro

Rails is mucking up my CSS – Already!

Or is it Ruby? I’m not really sure. I’ve been building the sample app in Chapter 2 of this Ruby Tutorial, and straight away I can see that my CSS is getting structured incorrectly for long term maintainability.

I used rails to generate the User automatically…

rails generate scaffold User name:string email:string

And Microposts…

rails generate scaffold Micropost content:string user_id:integer

I did not order these stylesheets

I took a look inside /app/assets/stylesheets/, mainly because I wanted to spend a bit of time in a part of the app that was likely to look more familiar to a front-end developer. ;)

What I found surprised me. There were already four stylesheets – none of which I would have created were I rolling a brand new app by hand.

application.css
microposts.css.scss
scaffolds.css.scss
users.css.scss

Erm, weird. Our CSS architecture should certainly not match our back-end architecture if we want it to scale. It seems like rails creates a new stylesheet every time I make a new model (and some other times too, because scaffolds aren’t a model).

How could Rails handle CSS better?

As a first pass, it seems like it would make sense for rails to add command line options to add CSS components. So you could ask rails to add buttons and it would create sass files for buttons, add .erb templates, etc. Maybe they could even be dependencies? I’ve been thinking that it would be cool to add components like buttons, boxes, grids and media blocks to NPM so that a project could require buttons and automatically get any code required for them without including an entire front end library. Maybe rails needs something similar.

Is that nuts? What do you think? Has your CSS stayed maintainable on Rails projects? I’d also love to hear about it if I’m misunderstanding aspects of Ruby, Rails, or the line between the two.

Photo credit: Christina B Castro

Error messages are my friends, pair programming buddies are my best friends

This, like most things I’ll ever learn, I learned the hard way. It is difficult to admit, but for a long time, I thought I was doing programming wrong™ because I kept getting so many error messages. I thought that if I were a real programmer, I wouldn’t get any error messages because I would write it correctly the first time. I didn’t realize that success in programming looks like a succession of error messages, each a little further into the problem you are diagnosing than you were before. This. Is. Huge.

I wish someone could have told me years ago, but I think for anyone who is comfortable programming it would feel like telling me to remember to breathe. Luckily I had the chance to pair program with some great developers and I learned by watching them go through the process – watching them deal with the ego bruising frustration and eventual elation of solving a problem, one error message at a time. Without them, I never would have felt the rush of “Wahoooo! Different error message than before!” It is amazing. One minute you think you will never, ever, ever solve the problem… and the next, zomg, I’m king of the world! Rinse, repeat.

It is beautiful to experience such joy (and pain) in solving problems, and it helps me remember that I’m neither the king of the world nor the developer who will never, ever solve the problem, but a bit of both, and a lot in between. In CSS, after 13 years writing the language, I can often just look at a bug and say “this has to be x, y, or z.” If I hadn’t gotten out of my comfort zone, I never could have had so much fun. :)