The Glorious Githubbers at Github recently released a polished gem that will transmits data to the Github API using a command line. This gem also shipped friendly push/pull commands to handle your repository easily. It is ridiculously easy!
http://github.com/defunkt/github-gem Read the README file for documentation.This is all pretty understandable: it’s easy to define community in terms of what we’re not. A common enemy focuses and drives us. Competition can take a positive form: when it’s friendly and constructive both communities benefit.
Lately, though, I’ve noticed the tone of the arguments in the Django community getting nastier — especially when it comes to Rails. Again, I’m far from innocent in this regard: I’ve certainly done my fair share of Rails-bashing, and I regret it.
Neat article - seeing Rails from a Django persons view.
This is a method I use when working with slow ruby scripts that operate on huge datasets.
It caches the return value of a block of extremely slow code in a file so that subsequent runs are fast.
It's indispensable to me when doing edit-debug-edit-debug-edit cycles on giant datasets.
http://github.com/blog/543-new-resque-web-ui
http://github.com/defunkt/resque
I'm thinking of implementing something like how ActionMailer does their dynamic deliver_* methods for this opensource rails messaging plugin I'm currently working on, but I'm not sure how should I go around working it.
I'm thinking of doing an easy-to-configure HTML templating system that would allow users to customize the output of commonly sent out messages.
But what do you think? Is it even necessary? Or am I adding code bloat.
Last friday Eloy and I participated in the Ruby en Rails Rails Rumble 2009, we had 8 hours to write an application which helped developers find out more information about the dependencies in their Rails application.
Our submission is called Apprise. Apprise is a tool to check gem dependencies and external repositories for newer versions of the currently installed ones in your Rails application.
To be more specific, it looks for three sources of dependencies. Git and Subversion externals in vendor/plugins and bundled Gems in the Gemfile. Checking for Gem dependencies is delegated to Bundler. If you don’t use Bundler to manage Gem dependencies you will still see outdated externals and submodules.
Outdated dependencies are listed and you can decide to update the externals, submodules or gems.
$ apprise Outdated dependencies * forestwatcher (Subversion external) * risosu-san (Git submodule) * miso (Gem)If you want to try it out you can easily install the gem and run the command in the root of your Rails application.
$ gem install apprise --source http://gemcutter.orgUnfortunately we did not win, but our patch for Bundler to list outdated gems was pulled by Yehuda Katz right after the competition.
Apprise is a tool to check gem dependencies and external repositories of the currently installed gems in your Rails application.
I'm not one for spending time applying micro-optimisation to code, but when it's relatively simple and potentially improves the user-experience I'm willing to give it a try.
I recently worked on a complex Merb site with a large amount of CSS and JS. With the client complaining of sluggish page load times I invested some time in exploring the results of Yahoo's YSlow plugin for Firebug. I started with optimising the filesize of the Javascript and CSS.
Merb's asset helpers already has built in bundling, which is a step in the right direction (reducing the number of HTTP requests):
This takes the three specified CSS files and bundles them all into one file called "app_bundle.css". This syntax can also be used for bundling JS. Note, by default assets are not bundled in development, meaning all three files will be included when testing. If you want to enable bundling in any environment set :bundle_assets in the Merb config to true:
However, this simply concatenates all the files together - maintaining the file structure and whitespace. To further optimise we can minify the contents of the files. For this I use Cory ODaniel's ruby-yui gem, which wraps Yahoo's YUI Java command line compressor. To apply this to our bundled files we add callback to the asset bundler. Add the following code to your init.rb file:
This overwrites the bundled file with the compressed format, saving bandwidth and reducing HTTP requests! Good, right?
Be careful with your bundled CSS. I've found that bundling invalid CSS can cause rendering problems in Safari that don't appear unbundled in Safari but still render fine in Firefox. The solution is obviously ensuring all your CSS is valid, but I think it's worth noting.
Remeber, ruby-yui is just a wrapper for the Java command line YUI compressor. Deploying to a live server without Java installed means no compression! (now, who would make that kind of mistake?)
Enabling Gzip on static files achieves a similar goal for the CSS files, but the minification reduces the size of the JS by replacing variable and function names with shorter names (amongst other things), something Gzip can't do.
Or the wrong one. It just seems like over-inheriting is definitely one of the bigger maintainability nightmares I have had; and pulling the constructor entirely into the parent.... Well it better be exactly the parent, and cleanly done.
It's like those overly abstracted resource_controllers. They seem like a great idea, but once you start deviating at all, you spend more code and more time thinking about how to write that code to get out of the straight-jacket over over-inheritance than you would have had in the first place.
I'm starting to feel that while abstract constructors *can* be done right they are often are a smell. Compare these three approaches and let me know what you think:
