Distributed SCMs: Be Smart, Use the Bleeding Edge

Posted about 7 years back at Wood for the Trees

I’ll preface this title by admitting I’ve not paid much attention to my version control software. When you’re smart (cue 16-ton weight), you try to think ahead and choose software or hardware which will vastly reduce the effort of programming. While staying on the edge with most things, for version control I neglected to really think about it. I had a very brief and painful time with CVS and promptly converted to Subversion because it was already installed, everyone used it, it was much easier, it solved the immediate problems with CVS I had, and it did what I needed to do at the time.

Of course, in programming, we all know that “what I needed to do” is never the same as “what I need to do now”. I have a lot more code to manage, I have a lot of projects which I am developing on my own or manage or take a serious part in, and I have more projects which I want to dip my feet into. The number of snippets, little things here and there, and feedback or changes from other people has meant a lot of branches, tags, svn cp and other management issues.

Now, this might sound like a “shiny thing” moment, but it is completely different from shiny thing syndrome. My advice to practically everyone reading this is to keep moving at the cutting edge of version control… and that doesn’t mean upgrading to Subversion 1.4.4. It means that there are genuine advances in version control which go well beyond Subversion and well beyond what it will ever be. I’ve known about distributed SCMs for a while, but haven’t really bothered looking into it. I’m writing this post because I think a lot of people are in the same boat. Subversion is supported, if not as the default SCM, practically everywhere: Sourceforge, Rubyforge, Google Code, Unfuddle, Lighthouse, etc. Every respectable project hosting service uses Subversion and almost every plugin, gem or developer out there at the moment references to Subversion repositories. Well, I’m going to make a serious splash in this department and say: it’s time to move on from Subversion. I have completely grown out of it, and I’m not even managing a codebase as large as Rails (or even ActiveRecord).

The single biggest development in version control over the last umpteen years, but specifically the last 2, is distributed version control. Basically, that means everyone’s working copy is a repository, every commit is local and every ‘commit’ to another repository is a ‘push’ (every ‘update’ from another repository is a ‘pull’)—that means merging is the default behaviour when you communicate with another repository. In other words, every repository is a branch. This way, distributed version control doesn’t force a single source code management architecture. These systems are completely open and the advantages to this model-less model are (obviously) endless:

  • most importantly, distribution is all about caring more about the coder-to-code relationship than the coder-to-project relationship
  • Distributed SCMs are orders of magnitude faster in almost every department
  • they usually use a bit more space
  • actual commits are almost instant, since they are local
  • merging is simplified enormously—it’s the daily business of a DSCM
  • no need for an update—you merge when ready
  • development can happen anywhere—no connection required
  • no default model of management or hierarchy
  • much more intuitive code structure—do what you like
  • no need for access control, but it’s there if you need it
  • etc.

You’ll see the benefits just in the development of your own code, without merging with anyone else’s repositories but your own, that distribution of management doesn’t require distribution of code. You can use any methodology, any hierarchy, any paradigm of managing your code that you wish.

Returning to my original point, staying at the bleeding edge doesn’t mean upgrade to the next minor or major version to get the latest feature. It means upgrade, or change software if necessary, to use the latest breakthroughs which will cut costs and save time for your own projects or your company’s projects.

Now, you’re probably asking which distributed SCM to use. I personally go for Mercurial for the following reasons:

  • SVK is a lie—it is not distributed; it just distributes SVN, which is like a multiplying a herd of turtles
  • much faster than Arch, Darcs and Bazaar
  • only Git is faster—but that was developed by Linus Torvalds
  • Mercurial and Git are relatively younger, meaning they’ve learnt from the mistakes of other DSCMs
  • Mercurial and Git come from the same background (the BitKeeper drama) and BitKeeper, according to Torvalds, was the only SCM worth using
  • Mercurial compares feature-for-feature with other DSCMs, and then some
  • Mercurial uses less space than others
  • very user friendly CLI—by far the easiest to learn of the DSCMs
  • decent documentation
  • a few project hosting sites already (like ShareSource)
  • ability to have Mercurial support using the HTTP front-end, even where you normally wouldn’t have it (i.e. Sourceforge and Rubyforge)
  • If you don’t have a feature in Mercurial, find or code a Mercurial extension—it is fully customisable

My Forceful Conclusion

Like the language you are using (Ruby 1.8), the framework (Rails 1.2), the testing suite (RSpec 1.0 and Mocha), the operating system (Mac OS X 10.4 and Linux 2.6), the web server (nginx, LiteSpeed, or lighttpd), the application server (LiteSpeed or Mongrel), the blogging software (Typo or Mephisto), even the hardware (Amazon S3/EC2 or many dual core 2+ GHz servers with many GBs of RAM), you need to use the latest version control software (Mercurial 0.9.4 or Git 1.5). If you don’t, it’s like using an old server with 333MHz & 256MB RAM, or Apache 1.3 & mod_ruby. But unlike an out-moded application server, SVN will make you a slower developer than the one sitting next to you using Mercurial, Git, Darcs or Bazaar. Oh, and I needn’t mention that he’ll get all the babes too.

Hobo 0.6 release date

Posted about 7 years back at The Hobo Blog

It seems you’re all itching to know when we’ll have a Hobo 0.6 without the ‘pre’ tag :-)

Just to let you know we’re shooting for Tuesday the week after next – 14th August.

Hobo 0.6 release date

Posted about 7 years back at The Hobo Blog

It seems you’re all itching to know when we’ll have a Hobo 0.6 without the ‘pre’ tag :-)

Just to let you know we’re shooting for Tuesday the week after next – 14th August.

Wrightspeed X1 - Best of both worlds

Posted about 7 years back at work.rowanhick.com

And now for something completely different. Old news if you already have heard about it... Quite a few years ago, like many a young IT guy, I had a too little responsibilities and too little common sense, which resulted in a daily driven, highly modified, 450HP Twin Turbo 300ZX gracing my garage - including no less than a Formula 1 derived Launch and Traction Control system... $2000 sets of tyres were dispatched on semi regular occasion, and I learned how to throw a ton of metal and fabric round a racetrack at insane speeds. Now I'm atoning for my environmental and financial sins by daily riding a 0 HP 2 LP 0 Emission mountain bike turned commuter (with some ugly 1" wide slicks). Which does amazing things for your fitness, and is absolutely great for venting any frustration you may have had in the office during the day - there's always a dimwitted motorist who will pull out on you and be needing gentle reminding that you too have a legal right to be on the road. However. It's just not the same really... Then this came along. Built by a fellow expat New Zealander Ian Wright. The Wrightspeed X1. Based on an Ariel Atom, a viciously fast car with one mission in life, to do everything fast, very fast. But this one has a twist. It's called Lithium Ion. Packed with batteries, electric motors and not a drop of smog producing fuel* in sight I'm in technology-love. I'm just putting this out there, you know instead of the 'come join our startup for equity ' type emails, how about you be a bit creative and 'come join our startup and we'll get one of these bad boys in your driveway' ?? That's one way to get my attention.. Better acceleration than anything I've driven or been in (and I'll tell you 600HP is pretty damned quick and this would be faster), limited pollution (the electricity does have to come from somewhere) and it looks like it has fun by the bucket loads. Check out this video. The astute will notice the Porsche has to do a rolling start, no doubt worried about destroying some clutch plates and the X1 *still* wipes the floor with it. Or another.. And to think, you wouldn't have the difficulties of getting a high horsepower sports car off the line, like triple-plate clutches (not fun in traffic), it's just like an on-off switch. C'mon already, what are you waiting for, lets see these in production... People in the performance world are really starting to see the benefit, check out this... Killacycle *Until we have giant solar panel arrays, the energy to produce electricity has to come from somewhere... Image is licensed under Creative Commons ShareAlike 1.0 License

Breaking the silence

Posted about 7 years back at Luke Redpath - Home

I started my last blog entry with the sentence: “It’s been a while since I blogged”. To use the same sentence to begin this entry would be somewhat of an understatement. Its been six months today since my last post.

There are various reasons for this but the main one would be lack of motivation. Whilst working at Coherent I managed to lose touch with the Ruby/Rails community; I didn’t make it to any LRUG meetings, I wrote precious little code outside of work and my enthusiasm just disappeared. This was partly due to me being the only developer at Coherent and partly down to me just burning out towards the beginning of the year.

However, things have changed somewhat over the past few months. I have left Coherent and I am now a member of the great team at Reevoo. Since starting at Reevoo, I have regained some of my enthusiasm and have now finally found the time to post something here. I even made it to LRUG last month.

Allow me to give you a brief update on some of the projects that I have been involved in:

  • RSpec article part two: unfortunately this has just been far too long coming. RSpec has changed a fair bit (for the better) since that article and is now quite out of date. There are plenty of other great developers out there writing about RSpec as well now. What I intend to do is revisit my original article and update it to reflect the latest version of RSpec. And while there will not be a “part two” per se, I do intend to write about RSpec more in the future.
  • UJS – the UJS project has come to a grinding halt over the past six months for several reasons on both mine and Dan’s part. We are still undecided on where to go with the project at this point but it is unlikely that development will continue on the plugin unless somebody else volunteers to take over the project. Read this entry on Dan’s website for more information.
  • Refactoring REST – the subject of my last blog entry; I still have this code lying around and whilst I haven’t had much of a chance to explore it further I still intend on developing this, time permitting.
  • Rails Plugin Repository – work on this, too, has unfortunately come to a halt. I still speak to James Adam who just so happens to be joining us here at Reevoo in the coming weeks. So maybe this will be resurrected, or maybe it won’t.

So to the future…things are going great here at Reevoo – we’ve just launched a brand new version of Reevoo. Be sure to check it out. We have some other exicting developments in the works too.

Because I don’t always have the time to post full-length blog posts I set up a tumbelog some time ago which I never got around to using (I didn’t even publicise it). However I plan to start posting to it frequently from now on, so add it to your bookmarks/news reader feeds.

Finally, I will be attending “RailsConf Europe 2007”: along with my Reevoo colleagues Paul and Ben. I look forward to seeing you all in Berlin.

Dangers of Cargo-culting

Posted about 7 years back at The Rails Way - all

“Cargo culting”, when used in a computer-programming context, refers to the practice of using techniques (or even entire blocks of code) seen elsewhere without wholly understanding how they work. (The term “cargo cult”, if you are unfamiliar with it, has its own fascinating etymology, which is covered nicely at wikipedia.) Cargo culting is a dangerous phenomenon, watering down the state of the art and encouraging cookie-cutter code shoved blindly into black boxes.

Consider the following snippet of code, taken from a project that was submitted to us some time ago. (Alas, I cannot find the original submitter—I apologize for that!)

1
2
3
def account_code?
  !! @account_code.nil?
end

To me, this looks cargo-culted, since it is seems that the programmer did not understand what the ”!!” idiom was all about. They probably saw it used somewhere and “cargo culted” it, using it without knowledge, assuming that it was, for some reason, “necessary”.

Now, the way ”!!” works is this: take the value behind the ”!!”, negate it, and negate it again. It’s just double-negation: !(!(@account_code.nil?)). The ultimate effect is to take some value, and convert it into an honest-to-goodness “true” or “false”. (In my ever-so-humble opinion, the ”!!” idiom is an abomination: it’s far too clever for its own good. First of all, you rarely ever need a real boolean value, and for those times you do, it is better to be explicit in the conversion, by using a ternary operator or full-blown if statement, for instance.)

In other words, the double-negation of nil? results in absolutely no difference from the use of nil? by itself, since nil? will return a true/false value. This, in turn, means the effect in the original is actually not what was intended for the account_code? predicate. It should have returned “true” if the account code existed (was “non-nil”), not “false”. Thus, the method should have actually been written thus:

1
2
3
def account_code?
  ! @account_code.nil?
end

In this case, cargo-culting resulted in the code being buggy. This is not an uncommon outcome of using techniques or code without understanding their purpose. If you ever find yourself copying something into your own code, with a justfying “I-don’t-know-what-it-does, but-it-appears-to-work”, stop immediately. Do some research. Figure it out. Learn what it means.

Further, note that unless you actually need a true boolean value from that, you can shorten the implementation of the account_code? predicate even further:

1
2
3
def account_code?
  @account_code
end

This works because Ruby treats nil and false as false, and everything else as true.

If there is one thing that Koz and I want you, our readers, to come away from this site with, it is an understanding of why you should do things one way and not another. Ultimately, it makes the difference between being a mediocre programmer, and becoming a great programmer.

Positive Reasons for Typo

Posted about 7 years back at Wood for the Trees

I highly respect quick responses to a post. In Simeon’s post, he laments my lack of a positive reasoning for choosing Typo, so I’d like to quickly outline why I originally selected Typo and why I was drawn back to it.

Typo leverages the modern technologies that are out there and, true to a Rails application, has a love of shiny things without overdoing it. Nevertheless, it is fast (70 req/sec is my entire readership in a second, which makes me feel very warm and cuddly). Despite the speed, it’s not stripped down at all. What it comes with built-in (every social networking/bookmarking sidebar imaginable, multiple feed formats, multiple database support) is easily supplemented by its easy-to-use plugin architecture. It now uses the Rails plugin architecture, which makes it even easier. Adding themes is a doddle. Even editing the core code gives you the result you want, more often than not.

Basically, Typo is written to offer complex features using the simplest code. There are areas you could quibble with me on that score, and I may agree, but generally Typo is a sleek and sexy blogging engine with lots of features and yet which still has limitless potential. Just look at their Trac. The active development suggests a project which is going somewhere and getting there fast. I stopped using Typo after 4.0 and came back at 4.1. Already I see a lot of changes under the hood that would suggest more than just a minor version change. Even with all these changes, reverting back to Typo took me no less than 10 minutes. That says a lot to me.

Sure, WordPress and other blogging engines may have plugins or built-in features which rival those in Typo, but the sheer speed and flexibility of development behind Typo is peerless. I like that. It feels edgy.

I’m no old man and I don’t need Zimmerframe 2.2.1. Give me the bloody nose brawls, the midday groggy writer’s block, the street-vomiting hard nights, the raving ecstasy of Typo any day. She’s the kind of girl you can take out for a walk in the park or on a bruiser’s night and return home proud and glowingly post coital, because she’s always good fun, day or night.

Typo’s no dumb blonde.

Positive Reasons for Typo

Posted about 7 years back at Wood for the Trees

I highly respect quick responses to a post. In Simeon’s post, he laments my lack of a positive reasoning for choosing Typo, so I’d like to quickly outline why I originally selected Typo and why I was drawn back to it.

Typo leverages the modern technologies that are out there and, true to a Rails application, has a love of shiny things without overdoing it. Nevertheless, it is fast (70 req/sec is my entire readership in a second, which makes me feel very warm and cuddly). Despite the speed, it’s not stripped down at all. What it comes with built-in (every social networking/bookmarking sidebar imaginable, multiple feed formats, multiple database support) is easily supplemented by its easy-to-use plugin architecture. It now uses the Rails plugin architecture, which makes it even easier. Adding themes is a doddle. Even editing the core code gives you the result you want, more often than not.

Basically, Typo is written to offer complex features using the simplest code. There are areas you could quibble with me on that score, and I may agree, but generally Typo is a sleek and sexy blogging engine with lots of features and yet which still has limitless potential. Just look at their Trac. The active development suggests a project which is going somewhere and getting there fast. I stopped using Typo after 4.0 and came back at 4.1. Already I see a lot of changes under the hood that would suggest more than just a minor version change. Even with all these changes, reverting back to Typo took me no less than 10 minutes. That says a lot to me.

Sure, WordPress and other blogging engines may have plugins or built-in features which rival those in Typo, but the sheer speed and flexibility of development behind Typo is peerless. I like that. It feels edgy.

I’m no old man and I don’t need Zimmerframe 2.2.1. Give me the bloody nose brawls, the midday groggy writer’s block, the street-vomiting hard nights, the raving ecstasy of Typo any day. She’s the kind of girl you can take out for a walk in the park or on a bruiser’s night and return home proud and glowingly post coital, because she’s always good fun, day or night.

Typo’s no dumb blonde.

Apache2 Redirect To Feedburner

Posted about 7 years back at Mike Mondragon

This is how I’m doing a 302 redirect to Feedburner from my Apache2 virtual host settings for this blog. Its only for the main articles syndication in RSS and Atom . Everyone is redirected to Feedburner except for their web crawling bot. I’m doing this so people can see Feedburner’s shiny widget ( ) in the sidebar showing that only 1 or 2 people subscribe to my blog.

I put the following in between the RewriteEngine On statement and the static maintenance statement RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f covered in this post describing an Apache vhosts setup for a Rails app

# 302 temporary, 301 permanent
RewriteCond %{HTTP_USER_AGENT}  !^FeedBurner/.*
RewriteRule ^/xml/rss20/feed.xml$ http://feeds.feedburner.com/mondragon/PQVR [R=302,L]
RewriteRule ^/xml/atom/feed.xml$ http://feeds.feedburner.com/mondragon/PQVR [R=302,L]

Apache2 Redirect To Feedburner

Posted about 7 years back at Mike Mondragon

This is how I’m doing a 302 redirect to Feedburner from my Apache2 virtual host settings for this blog. Its only for the main articles syndication in RSS and Atom . Everyone is redirected to Feedburner except for their web crawling bot. I’m doing this so people can see Feedburner’s shiny widget ( ) in the sidebar showing that only 1 or 2 people subscribe to my blog.

I put the following in between the RewriteEngine On statement and the static maintenance statement RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f covered in this post describing an Apache vhosts setup for a Rails app

# 302 temporary, 301 permanent
RewriteCond %{HTTP_USER_AGENT}  !^FeedBurner/.*
RewriteRule ^/xml/rss20/feed.xml$ http://feeds.feedburner.com/mondragon/PQVR [R=302,L]
RewriteRule ^/xml/atom/feed.xml$ http://feeds.feedburner.com/mondragon/PQVR [R=302,L]

Using Rails with Flex to manage long running tasks

Posted about 7 years back at work.rowanhick.com

UPDATE Jul 2008 - The API for BackgroundRB has changed and docs improved significantly since this blog post. Read the latest API calls over here http://backgroundrb.rubyforge.org/rails/. Don't reference the Rails code below if using latest BackgroundRB As soon as you start doing anything with photos sooner or later someone says "It would be really nice to upload these in a zip file", which then leads into a whole rabbit warren of issues, one of which you will inevitably come across is how to deal with a long running task on the server, in terms of a) getting it to actually complete and b) telling the user what's going on. There are various hacks for doing these, like running a shell script and writing out tmp files all over the place. Just plain ugly. Enter Backgroundrb, probably one of the greatest little inventions for Rails. It lets you kick off a background process, outside of the main rails app process, with the option to interact with the rails models or not. The beauty of this plugin is a little thing called MiddleMan, as the name implies it lets you interact with your background processes (Workers) from your Rails app. So, this gives us the ability, from your Flex app to invoke a Worker on the server side, then monitor that Worker until it's finished, and/or kill off the worker if need be (for slacking on the job?). What do we need. 1. First off install BackgroundRB from here. 2. Next we need to create our worker in your Rails app dir 'script/generate worker ResizerWorker . Here's a simple chunk of worker code. class ResizerWorker < BackgrounDRb::Rails def do_work(args) @total_images = 50 @current_image = 1 50.times do @current_image += 1 sleep(1) end end def get_progress @current_image < 50 ? status = 'In progress' : status = 'Finished' info = { :status => status, :current_image => @current_image, :total_images => @total_images} return info end end As you can see we have a do_work method which is generated by default, this is called whenever the worker is instantiated so it kicks off our work to be done. Then I added a get_progress method to return a hash of the worker's current status. 3. Great so now we need to kick it off, there's some options to do this automatically at timed intervals, but I'm not going to go into that here, all we're doing is getting our rails app, by a web request to start/stop and monitor the progress (the web request is then called from Flex) . So we create a watcher controller, with actions 'start_task', 'status' and 'stop_task' as below which is all pretty self explanatory: class WatcherController < ApplicationController def start_task session[:worker_key] = MiddleMan.new_worker(:class => :resizer_worker) info = {:message => 'job_started', :key => session[:worker_key]} render :xml => info.to_xml(:dasherize => false) end def status @worker = MiddleMan.get_worker(session[:worker_key]) if @worker info = @worker.get_progress if info[:status] == 'Finished' MiddleMan.kill_worker(session[:worker_key]) end else info = { :status => 'Finished' } end render :xml => info.to_xml(:dasherize => false) end def stop_task @worker = MiddleMan.kill_worker(session[:worker_key]) info = { :status => 'Task Stopped' } render :xml => info.to_xml(:dasherize => false) end end Gotcha! I found out the method names in the Documentation, on MiddleMan, were wrong compared to the version I had installed. I needed to use .new_worker, .get_worker and .kill_worker. 4. Fantastic, so go into console, do "rake backgroundrb:start" in your rails directory, then fire up a rails server. You should now be able to hit http://localhost:3000/watcher/start_task, http://localhost:3000/watcher/status, http://localhost:3000/watcher/stop_task and see the appropriate results. 5. Now you can fire HTTPService requests on the Flex side and consume the results as required. For example : (for the sake of berevity I haven't put in any timer function to recheck the status, just a manual click event) import mx.rpc.events.ResultEvent; import mx.controls.Alert; private function onSvcWatchTaskResult(event:ResultEvent):void { trace(event.result.valueOf()); var info:XML = XML(event.result); pbProgress.setProgress( info.current_image, info.total_images ); } private function onSvcStartTaskResult(event:ResultEvent):void { Alert.show('Task Started'); } And there you go. A few seemingly simple lines of code has knocked off one of the age old problems of dealing with long running tasks. I heart Rails (and Flex). (As always with code examples, don't copy and paste, rewrite it yourself. You'll understand it better and won't copy in any errors I've made whilst cutting it down for blogging)

Seriously Sick of WordPress -- Back to Typos

Posted about 7 years back at Wood for the Trees

I should have listened to myself ages ago when I discovered Ruby and said to myself: “I hated PHP before there was an alternative. I hate PHP even more now that there is one.” So why did I convert from Typo to WordPress? I really, really do not understand why there are more posts about converting from Typo to Wordpress than vice versa.

My dear peers, pelt me with rancid tomatoes. I don’t know what I was thinking when converting to a PHP monstrosity. WordPress is such a bloated and badly coded blog engine (and that is much due to the way PHP itself encourages you to code). Every time I try to dig into its code, I become nauseous and frustrated, despite years of PHP experience.

What brought me to this realisation is an innocent attempt to upgrade… the quality of a software distribution and its development practices always reveal themselves when you upgrade, because it is in the care and attention to backwards compatibility which show developers have really considered what they are doing, not just chasing the new shiny thing.

So in trying to upgrade from WordPress 2.0 to 2.2, I found my entire day wasted chasing down errors, discovering none of my plugins will work, finding my theme broken in numerous places, and just plain frustrated by the idiotic process of removing, moving, copying, overwriting and double-checking files and directories. Upgrading WordPress is the most painful form of manual labour I’ve experienced in a while.

So, without further ado, my list of complaints before saying Adieu! to WordPress:

  • Biggest of all: upgrading is a serious pain in the arse, even with my upgrade.rb script (notice the irony)
  • Upgrading breaks almost every plugin you use
  • Plugin compatibility is atrocious. There may be a lot of them in their plugin repository, but look at the fine print and you’ll see they range from pre-1.x to 2.2 compatibility, and that doesn’t mean 2.2 works with 1.5 or vice versa. You need the right version or, more likely than not, it won’t even be recognised. So, really, each version has more like 30 plugins available, not 3000.
  • With every upgrade, you are welcoming security bugs (the worst kind) and I just don’t like the idea that upgrading to fix one is just introducing a new one. The reason for this is that WordPress is not a framework; its core functionality is part of its higher functionality, and with every upgrade they are mucking with both. I’d suggest to the WordPress development team that they extract the underlying HTTP management and the overlying CMS functionality… but then, why not use something like Django, CakePHP or Rails?
  • Their plugin architecture is horrendously 90’s
  • The admin interface is hideous and unintuitive—where do I set pings and trackbacks again? Why do plugins enable new menus in weird places? I can never remember where anything is because nothing is organised properly
  • Creating and editing posts is so slow I find myself making a 10-cup cafetiere every time.
  • Does WordPress send pings? I never see my blog appear after a post. I can only assume it doesn’t, even when I tell it to.
  • The WordPress helper functions are megolithic and cryptic. I can’t cuss them more, really. And they don’t even cover every situation. I’d rather have thousands of little ones to learn that three which do vastly different things, none of which do what I want. That means editing themes is a serious pain.
  • Lastly, I just despise PHP and giving it support by using it.

But this isn’t just about me whinging. I have positive reasons for moving back to Typo:

  • It’s written in Rails, which lets me do whatever I want with it, in a pleasurable way. I know Rails well enough to muck around. All I need to do is learn how Typo works, and it isn’t that complicated—nothing written in Rails, that I’ve encountered, is too complicated to grok in a day or two.
  • Typo 4.2 is going to introduce multiple blogs within a single installation, which I really would like to have. So I’m in for the long haul.
  • The latest Typo (4.1) uses Rails 1.2, which was one of my concerns with 4.0.
  • The rumour of an admin interface redesign is rather thrilling, but then, I still really like Typo’s admin interface as it stands. I’m very curious what they’re going to do.
  • Typo now uses Rails plugins to do everything. I intend to write a FeedBurner plugin that lets you do all sorts of things, like FeedFlare, Feedburner redirects and other nifty FeedBurner stuff. Now that it is easy to write a plugin, I’m keen to test it out and prove its worth.

So, back to Typo 4.x. Let’s hope its developers sorted out some of the issues that put me off it and caused me to so whimsically (and stupidly) change to WordPress.

Note: Over the next week, my dear readers, you may encounter a few problems. These are only temporary as I muck around with Typo 4.1 and juice it for all its worth.

Oh, and thank you for waiting the few months while I was deeply involved with a major project. I’m back permanently now, on freelance. It’s good to be free and back on the Rails.

Seriously Sick of WordPress -- Back to Typos

Posted about 7 years back at Wood for the Trees

I should have listened to myself ages ago when I discovered Ruby and said to myself: “I hated PHP before there was an alternative. I hate PHP even more now that there is one.” So why did I convert from Typo to WordPress? I really, really do not understand why there are more posts about converting from Typo to Wordpress than vice versa.

My dear peers, pelt me with rancid tomatoes. I don’t know what I was thinking when converting to a PHP monstrosity. WordPress is such a bloated and badly coded blog engine (and that is much due to the way PHP itself encourages you to code). Every time I try to dig into its code, I become nauseous and frustrated, despite years of PHP experience.

What brought me to this realisation is an innocent attempt to upgrade… the quality of a software distribution and its development practices always reveal themselves when you upgrade, because it is in the care and attention to backwards compatibility which show developers have really considered what they are doing, not just chasing the new shiny thing.

So in trying to upgrade from WordPress 2.0 to 2.2, I found my entire day wasted chasing down errors, discovering none of my plugins will work, finding my theme broken in numerous places, and just plain frustrated by the idiotic process of removing, moving, copying, overwriting and double-checking files and directories. Upgrading WordPress is the most painful form of manual labour I’ve experienced in a while.

So, without further ado, my list of complaints before saying Adieu! to WordPress:

  • Biggest of all: upgrading is a serious pain in the arse, even with my upgrade.rb script (notice the irony)
  • Upgrading breaks almost every plugin you use
  • Plugin compatibility is atrocious. There may be a lot of them in their plugin repository, but look at the fine print and you’ll see they range from pre-1.x to 2.2 compatibility, and that doesn’t mean 2.2 works with 1.5 or vice versa. You need the right version or, more likely than not, it won’t even be recognised. So, really, each version has more like 30 plugins available, not 3000.
  • With every upgrade, you are welcoming security bugs (the worst kind) and I just don’t like the idea that upgrading to fix one is just introducing a new one. The reason for this is that WordPress is not a framework; its core functionality is part of its higher functionality, and with every upgrade they are mucking with both. I’d suggest to the WordPress development team that they extract the underlying HTTP management and the overlying CMS functionality… but then, why not use something like Django, CakePHP or Rails?
  • Their plugin architecture is horrendously 90’s
  • The admin interface is hideous and unintuitive—where do I set pings and trackbacks again? Why do plugins enable new menus in weird places? I can never remember where anything is because nothing is organised properly
  • Creating and editing posts is so slow I find myself making a 10-cup cafetiere every time.
  • Does WordPress send pings? I never see my blog appear after a post. I can only assume it doesn’t, even when I tell it to.
  • The WordPress helper functions are megolithic and cryptic. I can’t cuss them more, really. And they don’t even cover every situation. I’d rather have thousands of little ones to learn that three which do vastly different things, none of which do what I want. That means editing themes is a serious pain.
  • Lastly, I just despise PHP and giving it support by using it.

But this isn’t just about me whinging. I have positive reasons for moving back to Typo:

  • It’s written in Rails, which lets me do whatever I want with it, in a pleasurable way. I know Rails well enough to muck around. All I need to do is learn how Typo works, and it isn’t that complicated—nothing written in Rails, that I’ve encountered, is too complicated to grok in a day or two.
  • Typo 4.2 is going to introduce multiple blogs within a single installation, which I really would like to have. So I’m in for the long haul.
  • The latest Typo (4.1) uses Rails 1.2, which was one of my concerns with 4.0.
  • The rumour of an admin interface redesign is rather thrilling, but then, I still really like Typo’s admin interface as it stands. I’m very curious what they’re going to do.
  • Typo now uses Rails plugins to do everything. I intend to write a FeedBurner plugin that lets you do all sorts of things, like FeedFlare, Feedburner redirects and other nifty FeedBurner stuff. Now that it is easy to write a plugin, I’m keen to test it out and prove its worth.

So, back to Typo 4.x. Let’s hope its developers sorted out some of the issues that put me off it and caused me to so whimsically (and stupidly) change to WordPress.

Note: Over the next week, my dear readers, you may encounter a few problems. These are only temporary as I muck around with Typo 4.1 and juice it for all its worth.

Oh, and thank you for waiting the few months while I was deeply involved with a major project. I’m back permanently now, on freelance. It’s good to be free and back on the Rails.

ActiveRecord and mysql: show my databases

Posted about 7 years back at Saaien Tist

Working on a ruby API for the Ensembl databases, I bumped into the issue of having to connect to a database without knowing its name.

The ensembl database server hosts databases for each species. Every two months or so, there's a new release which means a new database for every single species. To see what databases are there, you can login to the ensembl server with mysql:


mysql -h ensembldb.ensembl.org -u anonymous

(for more information, see here).

The command "show databases;" on the mysql prompt lists a total of 1035 databases at the moment, a short selection looks like this:

bos_taurus_core_41_2d
bos_taurus_core_42_2e
bos_taurus_core_43_3
bos_taurus_core_44_3a
bos_taurus_core_45_3b
bos_taurus_est_36_2
bos_taurus_est_37_2a
homo_sapiens_core_36_35i
homo_sapiens_core_37_35j
homo_sapiens_core_38_36
homo_sapiens_core_39_36a
homo_sapiens_core_40_36b
homo_sapiens_core_41_36c
homo_sapiens_core_42_36d
homo_sapiens_core_43_36e
homo_sapiens_core_44_36f
homo_sapiens_core_45_36g
homo_sapiens_core_expression_est_34_35g
homo_sapiens_core_expression_est_45_36g
homo_sapiens_core_expression_gnf_34_35g
homo_sapiens_core_expression_gnf_45_36g

To connect to the homo_sapiens_core_45_36g database, type "use homo_sapiens_core_45_36g;" at the mysql prompt. However, as all 'core' databases have the same database schema, the API applies to all of these species, and just has to connect to different databases. But how do you go about doing that? What you could do, is provide the full database name in the establish_connection statement. But having to memorize these full names, or having to open mysql connections prior to writing your scripts is, to say the least, far from optimal. But how do you query a database system without connecting to a particular database?

Basically, you make a connection to the host without specifying a database, and send the raw sql query "show databases;" over that connection. The code below does just that.


ENSEMBL_RELEASE = 45
DB_ADAPTER = 'mysql'
DB_HOST = 'ensembldb.ensembl.org'
DB_USERNAME = 'anonymous'
DB_PASSWORD = ''

class DummyDBConnection < ActiveRecord::Base
self.abstract_class = true

establish_connection(
:adapter => DB_ADAPTER,
:host => DB_HOST,
:database => '',
:username => DB_USERNAME,
:password => DB_PASSWORD
)
end

class CoreDBConnection < ActiveRecord::Base
self.abstract_class = true

def self.connect(species)
db_name = DummyDBConnection.connection.select_values('show databases').select{|v| v =~ /#{species}_core_#{ENSEMBL_RELEASE.to_s}/}[0]


if db_name.nil?
warn "WARNING: No connection to database established. Check that the species is in snake_case (was: #{species})."
else
establish_connection(
:adapter => DB_ADAPTER,
:host => DB_HOST,
:database => db_name,
:username => DB_USERNAME,
:password => DB_PASSWORD
)
end
end
end



And then just have your classes (e.g. CoordSystem, SeqRegion, Gene) inherit from CoreDBConnection instead of ActiveRecord::Base.

To make the actual connection, start your script with:

CoreDBConnection.connect('bos_taurus')


I'm currently at Ensembl for a week ("Geek for a Week") to work on the full-blown ruby API, and am planning to give an introduction on how to use it in one of the later posts.

Episode 64: Custom Helper Modules

Posted about 7 years back at Railscasts

Rails designates one helper module per controller, but that shouldn't stop you from making custom helper modules to help structure the code. Learn how in this episode.