Not much to say, I'm just an average computer geek with many eccentricities. I love coding, electronics hacking, reading, writing and music. I just mill around in Poole and Bournemouth in Dorset, living out my life as a professional Ruby on Rails developer and web designer.
Well, we made it to the first RoR eXchange – a mini-conference organised by skillsmatter up in London. On the speakers list were some cool people, namely:
On the whole it turned out well and I’m looking forwards to the next one.
(…)
Well, recently I embraced unit testing. Over the last year I’ve been so busy, with such tight deadlines, often working on existing software (which had no testing framework already setup for it), that I just haven’t had the time. Or, more accurately, I was afraid that taking the time to learn test driven development and using the test framework would take longer than just getting the stuff done so I wouldn’t meet the deadline.
As it turns out, my fears were completely unfounded.
A little while ago we took the plunge and made the commitment to develop something test first. It was slow for the first day. Learning the way tests actually work, and what not, and how to think about what we wanted the code to do – completely – instead of writing it to fit what we wanted as we go was what took up most of the time, but after that, things progressed quickly.
We write the code we wanted to be able to write in our app in the tests, and then wrote the code to make the tests pass. As we developed further, we had to check that our outputs made sense given different inputs. We came across errors as we changed things, but the tests told us where everything was going wrong and we fixed it.
Later on, we reshuffled all our behind the scenes code to tidy it up and DRY out somethings, testing kept us aware of weird issues.
Things went really quickly, and before long our entire things was tested well and finished. We had worked out how to test class method DSLs, private methods and all sorts and quickly. Now we have a fully tested, working library that we can reuse in various apps.
Due to the nature of our library, we made use of FakeWeb, which helped speed up our tests no end. As we develop our tests and testing abilities, we’ll have to look into things like RCov so we can ensure full test coverage and the like.
In the end, testing turned out a hell of a lot easier than I thought it would be, and now we are ahead of schedule in fact for completing our library, which kicks some serious ass. If you are reticent about picking up TDD because you think it will slow down your existing workflow learning how to do it, don’t worry. You’ll find that after a short while it becomes second nature and in fact speeds up your develop no end because you can trust your own code a lot more. However, I wouldn’t recommend starting TDD on an existing, already well-developed codebase because retroactively writing tests sucks and makes the whole idea of testing seem laborious and slow. Of course, getting that done will help you do any future development test-first, but if you are just starting out with TDD you’ll find it easiest with a new project than an existing one.
Eventually I’ll have to take the time to retroactively test my old code for various old projects still being maintained, but I’m dreading it because of the sheer amount of work involved, but it will be nice to be able to pick up things I’ve not handled to make my older code more robust.
Before learning Rails and Ruby, I was a dabbler. I can program in many languages and have written lots of different things, most of which have, and never will be, seen outside my computer because of reasons mostly relating to either shame or the fact that the application is entirely useless. I’d never written any application I was really proud of or was actually useful except a few Python applets and scripts.
However, Rails gave me a purpose and the perfect framework for fulfilling that purpose – creating web applications.
I was first exposed to Rails as part of my first serious job (which I’m still doing and loving ever minute of) as a web application developer. The company was an early Rails adopter and with one of their guys dropping out, they needed a replacement to get there ‘Big Project’ finished. I had to learn Rails quickly, and so I did.
You could argue that the situation was what made me have to get serious with my programming, but that is only part true. It was Rails that provided everything I needed to flourish as a programmer. A wonderful environment in which to culture and grow my ideas, enforcement of doing what was right instead of what was easy. The community around Rails gave me a huge library of quality code and advice to learn from. Best of all though, Rails allowed me to be lazy and not feel bad about it.
After exposure to Rails, now I am always striving to do more with less, to improve my environment and my code to reduce to a minimum the amount of work I have to do. I want to do testing, something that until previously always seemed like a chore, a bore and additional work (the bane of the lazy person!), now I love testing, because it makes my life easier and gives me more time to do new, fun stuff instead of debugging broken code without a clue where to start.
Rails lets me be lazy in the best possible way, one I really can justify calling efficient. Rails has given me a passion for programming which I never had before and it gave me the perfect tool I needed to succeed in my chosen career.
Rails didn’t just make my programming better, it made my life better.
When developing a static site, or editing an existing one, its a bitch to try and remember things like relative and absolute paths, etc etc. I didn’t want to have to mess with that and I certainly didn’t want the hassle of setting up apache or lighty just to serve files from the directory I had mirrored the site.
So, Ruby to the rescue! 2 minutes later and I had this serving my files for me:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
<code class='ruby'>#!/usr/local/bin/ruby require 'webrick' include WEBrick def webserve(port, directory) server = HTTPServer.new( :Port => port, :DocumentRoot => directory ) trap("INT"){ server.shutdown } server.start end port = ARGV[0] || 3000 directory = ARGV[1] || Dir::pwd webserve(port, directory)</code> |
Just run it in the directory that has your files in, or call it like:
|
1 2 |
<code>webserver 3000 /path/to/my/files </code> |
and voila, instant server.
I don’t know how people live without this stuff.
For some reason, mephisto was breaking when comments were posted. Basically it wouldn’t allow you to post comments if one had already been posted – even if you deleted it afterwards.
Turned out it had something to do with comment caching. Therefore, I just turned it off by adding
@skip_caching = true
to the beginning of the dispatchcomments and dispatchcomment functions in the mephisto_controller. I tried messing around with the other ideas mentioned in the Developers Tips page on the mephisto wiki but had no luck. Hmmmm….
It’s a great feeling when you finally manage to put something live that you’ve made for yourself.
Last night we all got that feeling when we deployed the teaser site for Propel’r, a new GTD-based project/time management web application we are building.
If you’re interested in GTD, life hacking and personal productivity, then feel free to check out propelr.com. We are all pretty excited about it at SonicIQ, we look forwards to seeing peoples responses.
At work, we’ve developed some plugins that cause issues when invoked in generators. For instance, you may be creating controllers on the fly, and so when you what to generate a controller to override the automatic one, you can’t as it is ‘reserved’.
Well, you can determine what context in which you code is being executed quite easily using built in globals in Ruby.
To elaborate on the boss’s original post
|
1 2 3 4 5 6 7 8 9 10 11 |
<code class='ruby'> $0 # returns the command executed to run this script, i.e. script/generate, rake, etc unless $0 =~ /generate$/ puts "Code that wont run in generators goes here" end if $0 == 'rake' and ARGV[0] =~ /migrate$/ puts "special code to be run in migrations, like some cool migrations enhancing plugin for instance" end </code> |
I’d love to wrap this in a nice plugin, patch or gem to enable cool things like this:
|
1 2 3 4 5 |
<code class='ruby'> if ['db:migrate', 'db:schema:load', 'db:schema:dump'].include?(Rails.rake_task) or Rails.run_by?('script/generate') puts "do cool stuff" end </code> |
I’ve been taking a look at the Shattered 3D Ruby rails-like application framework recently for something to mess about with, but getting it to work under my Ubuntu Linux install was a complete arse.
Well, I’ve just managed to get it working!
(…)
At work, I discovered that using the standard “form_for” helper with simply restful generated invalid markup, since the secret “fake method” input tag was not enclosed in a proper element.
Therefore, I wrote a plugin to hack it in for the time being. you can get by:
|
1 2 |
<code>script/plugin install http://svn.soniciq.com/public/rails/plugins/iq_fix_restful_method_tag </code> |
It works by hacking the tag helper to put a div tag around itself first if the tag has a name of ‘_method’. Evil, but it works for now.
I was at work till 3am this morning (woohoo 10 hours overtime!), most of which was wasted on a tiny bug which came down to being fixed by one line:
|
1 2 3 |
<code class='ruby'> ::ActionController::Routing::Routes.reload </code> |
Also, the whole ActiveWebService thing seems stupid, when included it was causing all sorts of errors because we were creating controllers dynamically, and so it was trying to do something or other involving loading web service api files for them and getting it wrong, hence breaking everything, even though we weren’t asking for any web service functionality at all. We ended up not loading the framework, but thats hardly an ideal solution.
Why the “neither _api or _api found” error kept popping up even though were werent requesting an api in the first place is beyond me.
Anyway, back to sleep and then into work for round two! Ding, ding!