Text

· · to read

In the last couple of years I’ve witnessed a disturbing trend: developers adopting free Heroku as their only means of hosting side projects. More disturbingly, I operated this way myself for a couple of years. (Yes, freemium can be a trap for customers just like it can be a trap for businesses.)

Heroku has five megabytes for database space, which often sounds like it ought to be enough when it isn’t. Want auditing and comments? Nah, that’ll take up too much space. Its single dyno free plan serves one request at a time. The next steps up are twenty dollars a month and five cents an hour for databases and dynos, respectively. These aren’t that expensive for a major project, but for several side projects it quickly adds up.

I realized this and switched back to running a VPS, this time on Zerigo, which I pay for annually. There is no limit to the number of apps I have. Concurrent requests are supported. They can use the same databases. Database backups are free and uncomplicated. I’m also happy to be outside of the cloud oligopoly that seems to be forming.

Besides that, it’s fun! I get to try niche language platforms. Node.js was building steam long before Heroku supported it, and it still doesn’t support websockets. It’s not hard to find, with a little thinking, other interesting platforms to try. How about Racket or Factor? Or setting up your own Lucene server, or a web server that uses the git command line tool? Those can’t (easily) be run with Heroku.

I find anecdotally that most developers don’t have their own websites or non-trivial side projects. I only have the first, but I can sense that my personal website is helping me prepare to launch non-trivial side projects. I’ve done very little work to set up this server, yet despite tweeting about it and having visitors and occasional commenters, it stays up. That gives me the confidence I need to launch something bigger.

My plea to other developers (and aspiring developers) out there is to draw parallels between programming and other creative works and find out how much you could responsibly be spending for hosting side projects, and then realize that there’s no reason you shouldn’t have at least a VPS.

Text

· · to read

I like seeing URLs, whether in the link text or by hovering over a link. They are often truer to their content than what the person adding the link writes. I always have the status bar turned on in my browsers. It annoys me that there is no status bar on the iPad. It pleases me that Chrome shows URLs without taking up space for a status bar, by fading them in when hovering over a link. But a significant percentage of URLs aren’t worth a whole lot. They are either too long, or contain nothing identifying but numbers.

Some say that URLs will go away. But do they have to? If people still care about them, I don’t think so. That’s why we need URLs worth caring about. Just like we need buildings worth caring about, and neighborhoods worth caring about:

So how ’bout it?

(Yes, I realize that this blog’s urls suck, and don’t have to. I plan to change that soon.)

Text

· · to read

I got Screenflow and a Snowflake with the intent to make screencasts, but found another use for them, that might be more valuable.

It started with me testing out my equipment. I wasn’t ready to do a scripted screencast, so I just coded for an hour, while talking, and looked at the results. I found that talking to myself out loud helped me figure things out more quickly in a couple of cases. And since I was testing my gear, talking to myself didn’t feel all that strange.

Some time after watching it, I wondered what it would be like to record myself frequently. Maybe if I did something really cool, I could take a look back and try to see what my thought process was, and it would reinforce it. Or, if I was in a slump, I could use it to remind myself what I’m capable of.

Then I asked myself whether it’s practical. The answer I got was a resounding “Sure it is!”. Space and processing power are cheap. With the default settings, Screenflow documents take roughly a gig an hour. 500 gigabyte hard drives can be had for under a hundred bucks. If I record 5 hours a day, which is a *lot*, it’s about a dollar a day for the space. Screenflow doesn’t take much processing power, or if it does, it doesn’t interfere with the work that I’m doing.

I’m not sure what the most clear analogy is to other fields, but there are obvious parallels. Disk Jockeys commonly record their experiments. Team sport coaches record their players’ performances.

I’m really excited about this. I can get part of the benefit of pair programming by talking out loud and learning from yourself, without the need for a willing partner. It’s also a journal that’s remarkably easy to write. It does take a lot of time to read, though, so I’ll probably only play back my favorite sessions, and I’ll only play bits and pieces of them most of the time.

The only caveat is I might feel like I’m my own big brother. I might as well get used to that, though, as I expect in the future there will be wearable video cameras that transparently archive everything. In fact, something like that’s probably already been built.

I still plan to do some screencasting. Stay tuned!

Text

· · to read

Over the last week I’ve been learning how to quickly develop simple applications in Rails without looking at API documentation. Each day I’ve been starting from scratch and seeing what I can create in an hour, only consulting documentation when I really need help. The first day I didn’t use scaffolds and I only got creating, reading, and deleting working with a single model. From the second day until today I’ve been using scaffolds. On Friday I got two models with a has_many association and image attachments (using paperclip) working. Each day I start from scratch, not copying or referencing the code from the previous day (though I do save the code). I think starting from scratch each time has helped me learn more quickly than I would if I were to use the last code each time.

Today I went back to working without scaffolds. Since I’ve been trying to read the documentation as little as possible while developing, I had to figure some things out for myself. One thing I had to think of was the list of actions to type when generating a controller. Here is what I came up with:

script/generate controller Planets index new show edit create update destroy

I’m obsessive-compulsive, so not only did I try to remember what actions are used in scaffolds, I tried to put them in an order that makes sense to me. I put index first because index is special. After that, there were two sensible approaches I could think of to order the remaining actions. I could either order by CRUD or order by whether or not the actions have views. Either way, I would use the other ordering technique within groups. I went with ordering first by whether or not actions have views, and then by CRUD. I started with the actions that have views because it’s nice to have them at the top when jumping from a view to its controller.

Here’s my thought process in a tabular format:

Create Read Update Delete
Has View new show edit *
No View create ** update destroy

Notice that there are a couple of holes in the table. The first one (*) is missing because the interface for deleting is built into the index. It doesn’t have to be this way, and in fact varies widely on the web. It could have its own page, or it could be on the show or even edit page (Side note: I think it’s bad UI to put the delete button on the edit page because the edit form doesn’t fit into the workflow of deleting an item. The user may want to look at an item before deleting it to make sure it’s something they don’t need, but they’re unlikely to want to edit an item). The second one (**) is missing because in the simple case reading is achieved entirely through GET requests.

One thing that’s convenient about having the ones without views at the end is that it makes it easy for me to remember which skeleton views to delete after running the generate command. It’s the last three.

It used to take me a minute or a few to remember what actions I need, but now that I have this mnemonic it should only take a few seconds.

Now, I place a certain level of importance on conventions. After I came up with this mnemonic I looked at a scaffold to see how rails orders things. The only difference between my ICRUDCRUD ordering (index, CRUD with views, CRUD without) or ICRUCUD ordering and the standard scaffold ordering is that the show and new actions are swapped. So rails uses the RCUD ordering. Fair enough. I have pontificated on whether the ordering in CRUD makes sense or is a bacronym. Create and read are pretty useless without eachother. Below is the table with the RCUD ordering. I threw index into the empty cell. If you read the first line left to right, then move down, like a book, the order is the same as it is in a scaffold:

The order of actions in a scaffold
index Read Create Update Delete
Has View show new edit *
No View ** create update destroy

Now, how to remember RCUD? Well, remembering to swap C and R is one way, but I prefer to think of a Rails cow chewing its CUD.

rcud

Original image from cerulean5000 on flickr. Used by Creative Commons license.