Right after the swimming lessons of my youngest son, we both headed by bike to the center of town to do some shopping on the market. This plan was foiled when a humongous banner screamed “DISCOUNT BOOK SALE!!!!!” at me. If there is one thing I can not resist, it’s a book sale. Forget the food, I’d rather go hungry than miss buying books at cut-rate prices.
And I swear, I covered every present shelf, box and bin present. Some books for my son of course, who is just starting to read. In the IT-department (in this context a very expensive nomenclature for two plastic crates), I stumbled upon three titles related to Ruby on Rails with prices slashed by 75% or more.
They are:
- RailsSpace – Building a Social Networking Website with Ruby on Rails; by Michael Hart and Aureluis Prochazka, Addison-Wesley.
- Advanced Rails; by Brad Ediger, O’Reilly.
- Deploying Rails Applications – A Step-by-Step Guide; by Ezra Zygmuntowitcz, Bruce Tate, Clinton Begin et al, The Pragmatic Programmers.
Do I have a need for these books? Well no, but a wise rule of thumb for serious discount book scavengers is: If it is remotely interesting, do not hesitate to buy it. You most likely will never get the same chance again, and you might regret it later. Better to snatch it up and dump it later on when its conclusive worthlessness is apparent. Book sellers love me for this mindset, and it happens that I get greeted personally at such events.
In any case, it’s about time that I delved into Rails. I’ve been holding it back, partly because of negative commenting on the RoR development community, Zed Shaw being a prime example (Interestingly, he retracted the original text on this posting). The other part is that I perceived it as a bloated, oversize framework which excessively forces you to play according to the rules of its choosing. I have also spoken to developers who worked with it, and the message that I received is that it is very easy to do the standard stuff with RoR, but you have to bend over backwards to implement anything outside of the standard tooling in the Framework. And naked Ruby on Apache suited my purposes excellently, thank you very much.
But I’m perfectly aware that this reeks of unjustified prejudice, since up till now I never bothered to even sniff at it. In the meantime, I have become proficient in Ruby the language, up to the point that using it doesn’t impede my line of thought, and that I dread the day that I have to return to java. I would say that I built a pretty solid foundation for exploring the second ‘R’ in RoR. So on to Rails it is. The book RailsSpace looked like a decent place to start, so it was promoted to my default reading material on my daily commuting train voyage.
And what a fantastic introduction it is. For the life of me, I can’t understand why this book was in a discount sale; hordes of clamoring would-be Rails programmers should have been assaulting the book stores for it. It is comprehensively written and has a excellent progressive buildup of the technical stuff, without treating you as a moron on the subject of Ruby. Apart from the intended-as-witty form of humour (eg. footnote: “Ruby regular expressions are virtually identical to those from Perl and PHP. And there was much rejoicing.” ) which I can quite frankly live without, but have come to expect from young technical writers aching to be popular, this is a great, absorbing read and the best introduction to Rails I could wish for. Score one for the book scavenger’s mindset.
As for my RoR inhibitions, I can confidently say that I’m doing a 180 degree turn; literally everything described in the book up till now (I’m halfway through) sollicits a reaction in the form of “Hey, I’m doing that already”, or “Actually, that’s a good idea”. This personal opinion of mine that RoR is a rigid, inflexible mistress of a framework is rapidly dissolving into absurdness.
The bottom line: I. Am. Definitely. Going. To. Do. RoR.
Thanks, Michael and Aure, for writing this. I hope that finding your book in the discount bin isn’t representative of your overall success, because you definitely deserve some credit for your work. You rock.
Look, I love FreeBSD, I really do. I run it on my webserver. The OS is rock-solid and totally transparent. I really get a kick out of the uptime: 182 days at time of writing. The major reason for it not being longer is groping little toddler’s hands that can not resist the interesting reset-button on the front (Mental note: host server elsewhere when I can afford it). Okay, that’s one reason, the other being the occasional power outage due to blown fuses. Shit happens.
Actual publish Date: Jan 21, 2009.
This post was written in a red haze. I try to avoid rants, but on the other hand, this writing is straight from the heart, and if there’s one thing I learned about blogging, it’s that you should write about stuff that you’re passionate about. So here it is.
But my nerves get cross-wired when I need to do an update of any importance. Something as apparently trivial as installing a new version of an application becomes a gruelling death march. It’s not only the waiting, because you wait a LOT, it’s also the agony of not knowing in what state your machine is in afterwards. Upgrades shouldn’t be like that.
FreeBSD uses a system in which source files of applications are loaded and maintained on your machine. Any application you wish to install gets compiled on the spot, which given time and patience is a great thing because you get the best possible compile-time optimized version of the application, specially customized for your machine. No major complaints there.
The essentials of the combined heap of the source files, known as the Ports Collection, are maintained in a local database. This keeps track of the relations between the packages, as the bundle of source files related to a given app are called, and warns you when things get awry. Also, on itself a great feature.
Okay, up to this point, I’m still loving FreeBSD. From here on, the crescendo of despair starts building up…..
The ports collection needs to be updated regularly, this doesn’t happen automatically unless you perform some magic with cron. No problem there, there are various tools to achieve this, such as cvsup, which fetches the latest stable versions from (as you may have guessed) the source repositories. Great!
However, this only means that the local source files are updated. Any installed application needs to be recompiled with the new shit^H^H^Hource and reinstalled. Again, not a problem, well not really. For simple updates you can get away with ‘make clean install’, but this gets tedious when you have many applications to update (FreeBSD purists are curling their toes here, there is a meaningful semantic difference between ‘update’ and ‘upgrade’ on this platform).
In addition, some dependencies between packages may be broken and need refixing, meaning that you have to locate the dependent packages and recompile those in a relevant sequence. You don’t really want to travel this distance on the keyboard, do you? Better to automate the procedure: enter portupgrade, again a great utility.
Here’s the scenario:
I’m working on a new apache-log viewer, because the old one using SQLite is slowly grinding down to unbearable fetch times, what with the traffic picking up. My intuition whispers that speed improvement might be attained by switching over to MySQL. So, having thought about it long enough, I decided to finally bite the bullet and do it. The other motivation was that I needed a reason to do some more or less serious coding work in Ruby, of which I’m still climbing the learning curve. The initial tryouts where encouraging, queries are an order of magnitude zippier.
But I’m missing some serious features in my old, old version of MySQL (4.0.27). Inspired by the success so far, I feel confident enough to install the latest version (6.0.11), fully aware that I can expect some long, long wait times.
So here goes:
- Update the ports collection. No problem here, except for a long, patient wait. I don’t do this often and the amount of files updated is humongous.
- Update the package databases. You shouldn’t really need to do this, but often problems arise due to internal inconsistencies. Best to be paranoid about it.
- Close down Apache (the major MySQL user) and the MySQL server. I try to keep my nervousness under control about my websites being offline for a significant amount of time.
- Upgrade the MySQL client. Uh-uh, can’t do that, the previous version is in the way.
- Okay, so remove the previous version. Can’t do that either, various apps depend on it. Catch-22 has you in its cross-hairs. Trying various combinations of normally useful commands leads me nowhere.
- Let’s be smart about it; portupgrade should handle dependencies, so if I upgrade a dependent app, the database should follow along, right? So I do a portupgrade on Joomla. Bad call, Joomla needs a load of stuff and an incredible amount of applications get upgraded, including some heavyweights such as python, perl and big-ol’ apache itself. OVER TWO HOURS LATER, a compilation fails and the whole collective update gets cancelled. Countless gazillions of burned memory cycles result in exactly nothing.
- And here comes a peeve screaming down on me like a banshee: some package installations throw up a fricking install screen where you are supposed to select the options you want included. The darn warts sit there waiting for goddarn user input, even it the input consists of pressing ‘OK’. Meaning that you have to goddarn babysit the entire install, even if it takes hours. You can’t just walk away and come back two hours later, because after 15 minutes one of those option screens might have popped up and 90% still has to be compiled after all that time. Did I mention I’m doing this on a Sunday, when time is better spent with your kids?
- OK, no more mister nice guy, I’m going to force the upgrade of the MySQL client, dependencies be damned. Google has shown me how to repair the dependencies later on. It worked, but now the package database complains about stale dependencies.
- OK, so we fix that. ‘pkgdb -F‘ it is. Keep in mind, this is supposed to fix the package database. So how would you react if the database-fixing script started reinstalling the same MySQL client (4.0.27) you are so desperately trying to get rid of? I personally would react in detached coolness, restricting myself to mundane reactions such as tearing my hair out and screaming at the screen. Fricking database-fixing scripts should do as advertised, not have a mind of their own about what’s best for me.
- Luckily, the install failed at the very last moment, because the new client is in the way. Before continuing, I delete the old mysql server and start installing the new one…..which is now taking over an hour and still going. Talk about cliffhangers.
I’m still fond of FreeBSD but this kind of upgrade shit is sort of getting in the way. I have better things to do with my time than babysit installations, even more so when I’m in the role of entrepreneur running a startup. I know, the webserver is puny with respect to clock speeds. But for web stuff it is more than adequate. Why should the installs be so time consuming?
Just for the sake of being a pedantic bloody-minded asshole, I upgraded the MySQL server on my Ubuntu workstation. It took 95 seconds, including the time to check and recheck the root password. The webserver install has now passed the ten hour mark with no end in sight. Oh yeah, and my webserver is still down, look what this does to my nails.
The thought I’m trying to supress now is: “‘T was nice knowing you, FreeBSD”.
Aftermath
The next day was spent upgrading packages for php, ruby and perl, and fixing the databases. The main point is that I am actually making progress, this makes all the difference in the world. Nothing is worse than continually hitting your head against a brick wall in various manners.
Caveats for today:
- The database dump I diligently created before trying anything out has its idiosyncrasies. First, the SQL syntax has changed between versions, meaning I have to manually weed out the bad stufff. Really, couldn’t compatibility be preserved? Second, and worse, not all the tables have been saved, and in some tables column definitions have been left out. This hurts, how can I be confident of the integrity of the saved data?
In the end, all appears to be working correctly, except for Joomla. Perhaps I can fix that, but I couldn’t be bothered. I’m not using it anyway and if I want to pick it up again, I’ll reinstall. So goodbye to you.
