ajax analysis api apple apps atom automator backpack browsers camping capistrano cheatsheets code console design editors ergonomics fluid fowa games gems google helipad hpricot internationalisation javascript lies littlebigplanet mac marketing optimisation patterns performance personal php plugins productivity programming projects prototype rails rapidrails rsi rss ruby server sms snippets ssb standards sysadmin terminal testing textile textmate theory tips tools vim workshops writing xslt
Here’s an idea I’ve been playing with today: Captor, a GUI for Capistrano management. It’s a very rough prototype right now.
Goals:
Caveats:
I just posted this article to my company’s blog: Analytics with Capistrano
If you want realtime stats on your web site, why not try using Capistrano to collect data and create graphs and tables? It’s pretty easy to do this, and the beauty is you don’t need to make any modifications to your application.
My Rails tutorial (part 1 of 4) has been published in Linux Format 108. It shows you how to build a Rails-powered photo gallery, by using basic techniques and popular plugins.
Grab it from your favourite newsagent and let me know what you think!
This article is an introduction to testing Rails plugins. It’s a relatively lengthy post, so if you’re reading this in an RSS reader flag it and come back when you’re not too busy. It follows the “taxonomy” style of my previous plugin article, A taxonomy of Rails plugins, where examples are used from open source software.
Knowledge of both unit and functional testing is assumed. The following topics are covered:
There are now almost 1000 entries in the main resource for Ruby on Rails plugins, Agile Web Development’s Plugins Directory. Of these, 596 have repositories listed that are accessible. I wanted to see how many of these plugins came with some form of tests, so I created a spider (using a web spider library) and performed some basic analysis on each repository.
After reading a few magazines, and watching two entire TV shows, the spider came back with a result: 54% of the plugins have tests.
It’s amazing to …
Despite leaving it for a while, I’m going to continue my previous article, “A taxonomy of Rails plugins”, relatively soon. I’ve been inspired by the excellent plugins by errfree and come up with a few ideas of my own during the heavy workload of 2007. In particular, I’d like to clarify testing Rails plugins. But more of that in the near future.
For now, have a look at 10 essential ruby gems. It’s hosted on my company’s new blog, where you’ll eventually find more articles by me with a greater emph…
A common stumbling block for Rails developers is learning the basics required to write plugins. This is made more complicated by the fact that Ruby is inherently dynamic and offers many techniques for code reuse. Luckily, if you can write Rails applications you can write plugins by simply drawing on a handful of basic patterns.
The purpose of this article is to demystify writing plugins using examples of common patterns used by popular plugins.
Writing a plugin will:
Boards of Canada wrote a song called Constants are Changing. In Ruby even constants are dynamic, holding a reference to an object rather than the object itself. This consistency makes modifying constants possible, and rather than being something considered distasteful it may form an integral part of the design of a system.
Changing a constant’s reference will result in a warning, but there are times when ignoring these warnings might be arguably legitimate. I wrote a simple tool that runs for long periods of time, and …
Writing test code isn’t easy at first, and writing good test code is even harder. I’ve reviewed several tools to help write better tests here, focussing on ruby.
Code coverage tools attempt to analyse how much of your code has been tested. Reports are generated based on your test code, with columns expressing how much code has been tested.
Incentives for using code coverage tools are:
Have you found that any of your Rails projects get hits to controller methods that expect parameters? A neat way of handling this is the ActionController::Verification module.
By adding calls to verify in your controller, you can elegantly catch all kinds of unexpected but reasonable uses of your system: from mistyped URLs and browser history auto-complete to web crawlers blindly following links. This way, you can redirect people somewhere logical instead of flashing them with an error message.
You can even insert a message into the flash:
verify :params => “user”,
:only => ...
With hpricot you can do anything!
puts ((Hpricot(open(URI.escape(“http://www.google.com/search?q=#{term}”))))/”a.l”).collect { |link| ”#{link.innerHTML}: #{link.attributes[‘href’]}” }.join(”\n”)
I needed a quick way of exporting data as zlib from a controller in Rails, so I came up with this:
def export
send_data compress_string(Document.find_all.to_xml), :filename => 'backup.xml.gz'
enddef compress_string(data)
gz = Zlib::GzipWriter.new(StringIO.new(''))
gz.write data
gz.close.string
rescue
gz.close
raise
endAnother way would be to use tempfiles with Tempfile—I wanted to benchmark and profile using files compared to StringIO, but that’ll be an exercise for another day.
This could also work nicely with Minitar.
Imagine your own little mac os app written with the Camping framework, that you can easily share with other mac-weilding friends. It’s all possible with next to no ridiculous hacking at all!
All you need is Platypus. Set it up to create a ruby app that outputs to a text window. Click on “advanced” and select “remain running after completion”, then create the app. Take a look inside the application folder at the script it creates at the script:
YourApp/Contents/Resources/script.
Coaxing the old version of ruby supplied with mac os into running Camping and its required ge…