The magic of haml and sass

As this project has progressed we’ve began using haml and sass to mark up our pages. When I first heard and read about these gems they had me concerned that it was an unnecessary change to the relatively simple languages of html and css. “Why the hell would I want to use percent signs instead of angle brackets?” and “What’s so hard about closing your tags?” were just some of the wtf moments I had initially, not to mention the forced indentation and strict whitespace requirements. “I can format my code however the fuck I please!!” However I did see some immediate benefit with sass, especially in the addition of constants and ease of nesting tags. Even so it didn’t feel like the pros would outweigh the cons, and that having to “learn” a new syntax would be more frustrating than the benefits being gained.

Now that I’ve been using it for all of our pages I’ve realized that it does simplify a lot of the gnarlier aspects of html and css and most of my worries were bullshit. Learning a new syntax took pretty much no time at all, and not needing to remember to close my tags has become very handy. The “forced” whitespace I was so concerned with turned out to be a non-issue because I format my regular code the way they want anyway, which is the cleanest way to read it to begin with. The nesting features of sass were immediately beneficial, even for relatively simple/common nests like ‘div#id p img’. Additionally, I didn’t think much time would be saved from these technologies, even after I began using them the first few times. But the more I’ve exploited them the more I realize that I spend less time typing out code and more time accomplishing tasks. In the end a lot of the complaints I’ve had about html/css for years (and those that I’ve forgotten about, too) have been addressed by haml and sass and ultimately make things easier.

Of course all of this is possible because of Rails, and seeing as how I’m fairly new to Rails, much of the kudos belongs to it as well. Using it on the backend delivers on it’s promises of cutting down wasted time and energy doing menial set up tasks and maintenance. I can make changes in one place and see them reflected all over the app, which is all I can ever ask for from a framework.

So now that I’ve professed my love of haml, sass, and rails, what’s the progress of the app? Well we have some colors on there and forms that aren’t hideous. There’s also a chat feature that’s functional and is rapidly expanding. Basically you can’t DO much of anything yet besides create an account and login, but it kind of looks like a website and acts like one too!

Deploying SQLite to Production w/ Capistrano

This weekend we rolled the innagural deploy of our top secret new rails app to production. We are currently using Rails 2.1, SQLite and nginx proxying to Mongrel. Why bother with Apache (ever) and MySQL before you have to? Additionally we’re on a 256MB slice from Slicehost which is already serving an FB app, so I’d really rather not have the overhead of heavy tools for light applications.

I think I’m a fan of SQLite even though I just started using it. As they say on their site:

The basic rule of thumb for when it is appropriate to use SQLite is
this:  Use SQLite in situations where simplicity of administration,
implementation, and maintenance are more important than the countless
complex features that enterprise database engines provide.
As it turns out, situations where simplicity is the better choice
are more common than many people realize.
...
SQLite usually will work great as the database engine for low to
medium traffic websites (which is to say, 99.9% of all websites).

I’m 99.9% of all websites! And simplicity is important to me, I’m configuring enough already; plus I should probably coding some features or something too. And even if scaling does become an issue, I’d first set up memcached, then analyze and optimize my db tables, then upgrade to a fattier slice, then upgrade to an even fattier slice, then consider a more “enterprisey” database solution: multiple servers and jet-packs for the queries.

Meanwhile, I encountered a “problem” with deploying SQLite to production via Capistrano. This “problem” basicly stemmed from monumental laziness and not reading (or configuring) the default database.yml file. Here’s the thing: on development SQLite works great because you keep updating and committing in your same local directory with your same DB file. In deployment however you usually check out a whole new copy of your app, update some symlinks, and blast off into the night. By default this creates a new SQLite db, and doesn’t include the migrations (they were applied to the old copy). I actually started searching google for the answer to this “problem”, thinking about changing my deploy.rb to update a symlink to the SQLite file… but then it was so much easier to:

production:
  adapter: sqlite3
  database: /absolute/path_to_db/on_server/production.sqlite3 # instead of db/production.sqlite3
  timeout: 5000

I’m actually almost embarrased to post this “solution” but maybe some wayward youth like myself will find it and save some trouble.

Boomtime Development Log – Episode 1

 me:  yo
 pappashaft:  hey
 me:  did you get that console thing going?
 pappashaft:  naw I just got home from basketball
I don't think I'll have time tonight
I have to make dinner and then watch from g's to gents
 me:  what the hell are you talking about?
 pappashaft:  haha
what the hell are YOU talking about?
 me:  touche
 Sent at 8:57 PM on Tuesday
 pappashaft:  we shoudl discuss goals and timelines and features at some point
 Sent at 8:58 PM on Tuesday
 me:  yes
do you read my blog?
 pappashaft:  perhaps tomorrow, I should have more time then
you have a blog?