crazycool.co.uk

So it’s been two weeks since we open-sourced Feather. The feedback so far has been great, really pleasing, we’ve had some great coverage, and some great contributions. I figured I’d do an update on where we’re at, and highlight some of the cool things from the last two weeks.

So first of all, the coverage the project has gotten is great. We made it on to the brilliant “This Week In Ruby” on Antonio Cangiano’s blog, for April 28th. We also made it on to the Rails Envy podcast, another great source of the latest Ruby and Rails information, on April 30th. On top of that, after submitting the announcement post link to RubyFlow, it then made it on to Ruby Inside, in a round-up post of the best of RubyFlow for the last couple of weeks. RubyFlow seems to be a great site for the latest and greatest news in the world of Ruby, so it was brilliant to be picked in a round-up post from two weeks worth of links!

We also received numerous links from other bloggers, and there seems to be quite a buzz about the project so far, which is great!

As for the sourcecode itself, thanks to GitHub we are able to keep a great handle on the interest level, and we’ve seen that skyrocket! At the minute, we now have 95 watchers on the main codebase, and 13 people have forked the code! For the plugins codebase, we have 6 forks, with 40 watchers! And each day we have more and more people watch or fork the code.

We’ve also made some great progress with features and bug fixes. In the last couple of weeks since opening up the codebase, we’ve had:

• XHTML/styling fixes from Michael Bleigh
• custom permalink formats from Jake Good
• Mike added pagination for the admin article index, and also for the admin comment index
• Atom feed support for articles/comments from Markus Prinz
• a Mephisto importer plugin from Jake Good
• a Typo importer plugin from Marc Seeger
• a small markup fix from Bradly Feeley
• Mike also nailed a few other fixes

I think that’s most of the major contributions, apologies if I’ve missed anyone (let me know in the comments and I’ll update the list!). Considering that it’s only been open source for two weeks though, I think that’s great! We also have some other contributions in the pipeline, and so things seem to be progressing nicely. A list of contributors is also available on the GitHub wiki (thanks to Mike) here. If you’d like to see your name there, you know what to do!

To try and organize fixes, issues and feature requests, we’ve setup a Lighthouse instance for Feather. It’s available at http://feather.lighthouseapp.com. You’ll be able to add bugs or feature requests, and if you’d like to contribute by tackling any of the issues or feature requests there, let us know and we’ll give you access so that you can be assigned them so everyone knows your working on them. We’ve also setup an IRC channel to hang out and discuss Feather on irc.freenode.net (#feather). Me and Mike are in there quite a lot, so come on in to talk about Feather, whether it’s talking about how to set it up, how to extend it, or specific issues you might be having. The more the merrier!

Something else to mention is those that have switched their blogs to Feather. Obviously me and Mike are running Feather, and Jake finally got his blog over to Feather once he finished his Mephisto importer. And more recently, in the last few days Marc got his blog up and running with Feather too. They all look great, and if anyone else is using Feather, it’d be great to hear about it, so let me know!

Besides logging a few bugs, and hanging out in IRC to help people with some setup issues, I was also able to knock together a basic getting started guide this week. It’s available on the GitHub wiki for the project, here. One of our aims is to make setup easier over the next few weeks, but in the meantime at least there is a set of instructions to hopefully make it easier for people to get up and running.

Also over the next few weeks, we’ll be aiming to get an official Feather site up and running, which will include news, updates, an official plugin repository so that we can have one-click installs for plugins, and some more guides to using Feather, and developing plugins for it.

With more plugins on the way, a few bugs to fix, and some new features to put together, I’m sure the next two weeks and beyond will be just as productive for Feather. If you’re interested in getting involved, drop by #feather and introduce yourself, you’ll be more than welcome!

So one of the really great features within the Merb router is “defer_to”. This enables you to defer certain routing decisions to runtime, allowing you to evaluate and decide what needs to be handled where based on runtime factors. This is used in a couple of places within Feather and its plugins, specifically the main use is the handling of the article permalinks. Each article has a permalink stored against it, and while there is a default pattern for new articles, we allow any url as a permalink for an article to ensure that importing/backwards compatibility is straightforward. As this may not follow any particular pattern, we need to be able to evaluate this at runtime.

Originally, Feather handled this with a custom Rack handler, that ran before the main Merb application handler. It checked the request uri, and if it matched an article permalink, it dispatched the call to the articles controller to show the appropriate article. If it didn’t match, it simply went on and processed using the Merb app handler as normal. This worked fine, but looked like in the long run it might be difficult to maintain – it would certainly be nice to have a way to handle it all from within Merb routing.

Lo and behold, there is! Enter, defer_to. Let’s take a look at the article matching code from Feather first of all to see how it works:

  r.match("").defer_to do |request, path_match|
    unless (article = Article.find_by_permalink(request.uri.to_s.chomp("/"))).nil?
      {:controller => "articles", :action => "show", :id => article.id}
    end
  end

So what is this doing? Well it’s basically starting by matching all routes. It then calls “defer_to”, specifying a block to be used to evaluate a request at runtime. This block is passed the incoming request, which is all we need for our purpose here (the second argument is a set of parameters containing information about the route matched so far – in our case we are matching everything to try and then match the permalink at runtime, so we don’t use this argument).

We then basically use the incoming request uri to evaluate whether it matches an article permalink, and if it does we return the routing information for that particular article. Otherwise, the block will just return nothing, and so the Merb router will then continue on its way attempting to find a route that matches for the request. This means that the moment a new article is posted, or perhaps old articles are imported with specific permalinks, they are available and will be handled, all using Merb routing, thanks to “defer_to”. It’s a tidy, lightweight, great way of handling a complex routing problem.

The response to us open-sourcing Feather has been great so far, with some contributions, some questions, some comments, all good stuff. And now, thanks to the guys over at ActiveReload, we've got a public facing instance of Lighthouse to be able to track bugs, issues and feature requests, in both the core code, and the plugins! So if you discover an issue, or want to request a feature, then log it on there at http://feather.lighthouseapp.com and we'll get to it! If you'd like to tackle the fixing of a bug, or the implementation of a feature, get in contact and we'll set it up so that we can assign that particular request to you so everyone knows you're on it!

This should make managing and co-ordinating development a lot easier! Thanks again to the guys at ActiveReload for a great product, and for hooking us up with a free account for our open source project! And thanks to everyone so far who has contributed with code, comments and queries, keep 'em coming!

So after a few weeks of teaser posts, we've finally opened up the code on the software that powers this very blog, Feather. It's been a collaborative effort so far between me and my boy Mike, but now it's time to open source it, and hopefully people besides us will not only find a use for it, but will also find new ways to extend and improve it.

So what's in the current codebase? As alluded to before, the core itself is lightweight. Basic article posting, and user management is all you're really getting. The beauty is in the wide variety of plugins that are (and will be) available to extend the software further. Within a separate plugins repository, there are currently twelve plugins, that extend Feather to provide comments for articles, feeds, formatters for article content (Textile and Markdown), basic RSS importing for articles and comments, integration with ping services, the ability to setup hard-coded redirects on your site, sidebar and snippet content, overridden css styles, tagging, Twitter integration (to display your tweets in line with blog posts), and file uploads. The code in core and for these plugins probably isn't perfect, but it's good enough to power a few blogs already - and improvement is where you come in.

If you've got an idea for a new plugin, improvements to existing functionality, or you've found a bug, then by all means fork the project on GitHub, implement your code, and send us a pull request so we can merge the changes into the main trunk. Alternatively, send us your patch via e-mail, and we'll look to include it within the application. If you submit two patches to either feather, or feather-plugins, then you'll be given commit access to the repository in question, and will effectively become part of the core team. So what needs doing right away?

The biggest deficiency at the minute are specs - there are some specs in the core code, but it doesn't cover a lot of the application, and ideally we'd be aiming for 100% coverage of the core controllers and models. We then need to devise a decent way of similarly shipping specs with plugins. When we start updating and improving plugins, we'll need a way of handling data migrations smoothly and efficiently. On top of this, there are still outstanding useful plugins that need to be written, such as content search, and trackbacks, as well as integration with services other than Twitter. Lastly, there are bound to be bugs, so roll up your sleeves and fix them, it'll be much appreciated!

We'll be rolling out a Feather website soon, along with an official plugin directory to make installing plugins easier - for now, there's a basic getting started page on the wiki over at GitHub, and there will be more information over the coming days on both mine and Mike's blog. Any questions in the meantime, then let me know.

Other than that, what are you waiting for? Get your Feather on!

Wii Fit is great, I'm all setup, BMI calculated, I've got an initial Wii Fitness age, and I've set myself a goal (dropping 6lbs in 2 weeks!)

So I've put merb-manage up on RubyForge, and uploaded the latest gem release, 0.4. This now means that you can do "gem install merb-manage" and have it installed to your machine, ready for use! For more information on how to use it and setup your apps, see the README over in the source at GitHub.

Any questions or comments, let me know!

Hacking Twitter integration into Feather as a plugin, while watching So You Think You Can Dance.

@mleung Thanks for the shout out dude, I hope others find it as useful as I have! And it's all open source if people want to contribute!

It also provides an easy way for you to have your Merb apps startup when your server does, for those unexpected restarts!

Check out merb-manage, a tool I wrote for managing Merb application configuration quickly and easily - http://tinyurl.com/67pehr

So in getting this blog up and running on a server of mine, I needed a simple way to control and configure the Merb application, preferably with the ability to quickly alter the amount of servers, the logging, or indeed the adapter being used, amongst other things. I also wanted it so that much like Nginx, the Merb application itself would automatically restart if the server got bounced for whatever reason.

Introducing... merb-manage! Hosted over at GitHub, and open source, this is a simple tool that allows you to quickly and easily manage your Merb configurations on a server, and start/stop/restart your Merb applications as per your configuration. It also includes a bash script that can be installed to act as a startup script (such as in /etc/init.d) so that when your server restarts, your Merb applications spring back to life too! You can store the configuration within your application, and simply symlink it to a central configuration directory for merb-manage to go to work on (defaults to /etc/merb-manage), and you can change the adapter, amount of servers, port, user, group, and logging level straight from the configuration! It'll handle multiple applications and their configurations so you have a one-stop shop for configuring and managing your Merb instances!

It's fairly simple at the minute and I'm sure there's some more useful features to be added, so if you have any ideas then simply fork it, add them in, and send me a pull request! Likewise any bugs, issues, either let me know, or even better, fix them and I'll add them back in to the main tree!

Just got back from putting petrol in the car, at 108.9p a litre. Ridiculous!

Just updated my blog to use the new Merb backed blogging engine me and my boy Mike wrote, Feather. Check it out http://crazycool.co.uk.

So anyone that isn't reading this in a feed reader will see that my blog has had a serious overhaul - and I'm now running on Feather. Me and Mike spent quite a bit of time last week or so expanding the Feather feature set, and it now more than copes with my existing blog. I was able to import all my old posts, customize the default theme to something a little bit different, and add in a few custom snippets (Analytics, FeedFlare etc). I was also able to add redirects for old links to ensure that (hopefully) there isn't too much broken by the move. All old posts will have the same permalink too, handled as part of the import process.

Currently I'm running without caching, but I see my partner in crime Mike has gotten caching up and running on Feather, so I'll get that setup and running shortly too, to improve the performance of the blog still further.

As far as I can see the blog should be running ok, but any issues - let me know with a comment, or an e-mail, and I'll get right on it!

@bryanthompson Hey, maybe this post I wrote on getting up and running with Merb might be of some use: http://tinyurl.com/5swu3u.

My boy Mike is back blogging his ass off again, and this time, he's doing it on some decent software! Last few weeks me and Mike have been working on an ultra-cool blogging platform written using the Merb framework, and it's now in production use for Mike's blog. This very blog will follow suit shortly as I migrate over, and within a few weeks we are hoping to have the codebase in a good enough state to be able to open up the source, and start to invite contributions from anyone that feels the need to help out. The idea behind Feather is the same as Merb - lightweight core framework, extended heavily by plugins, allowing you to choose the pieces of functionality you need, and leave out the guff that you don't. Keep it dialed in here for further updates on Feather over the next few weeks, and keep a keen eye on Mike's blog too for more great posts. In fact, he's already in the thick of it with this great post on why Ruby does it for him (and why .Net doesn't).

Rails 2.1 is shaping up to be real nice; built-in timezone support, gem dependencies, dirty object tracking, partial SQL updates and more!

Just setting up all my apps after installing Mac OS X 10.5. So far, Leopard rocks!

Watching a Two and a Half Men marathon

Finished up the Honeymoon DVD while watching the Formula 1; took me ages to get the right settings so it looks good on TV, but I got there.

Just watched the latest Zero Punctuation videos (http://www.escapistmagazine.com/articles/view/editorials/zeropunctuation), absolute genius.

Watching the football while working on the DVD of our honeymoon pictures. iPhoto/iMovie/iDVD rock!

Waiting for the pizza to arrive, drinking an ice cold Bud. It's the weekend.

Wow, it had gotten sunny again, but now it's hail and thunder. Hello, Easter weekend. Typical British weather.

On a traffic spike with my blog today - my article on Merb (http://tinyurl.com/3277az) is on the DZone front page at the minute.

It's gone from lovely Spring sun, to horrible and overcast in about 20 minutes here now...

Trying to fix some issues with the Disqus comment system on my blog

Watching the "Guitar Hero" episode of South Park, brilliant.

I decided to give Merb a go, and after doing a fair bit of reading up on it, I took the plunge. It's a little rough around the edges, but that's probably to be expected given it's youth - however there are a number of cool features and benefits to using it, and it's getting better and better as it's being refactored. I did however come across a few interesting issues getting up and running, so I thought I'd share these to try and make the process easier for others.



I installed the gems from http://merbivore.com, by doing the following:

sudo gem install merb --source=http://merbivore.com --include-dependencies

This gave me the merb-core gem, along with merb-more. However, to get up and running with a database, we really need a database plugin - let's try DataMapper.

sudo gem install datamapper --source=http://merbivore.com --include-dependencies
sudo gem install merb_datamapper --source=http://merbivore.com --include-dependencies

Now you'd think that a dependency for merb_datamapper would be datamapper itself, however it doesn't get included, and so you need to download that as a gem, and then download merb_datamapper. We then need a few other gems, including one specific to the database you'll be connecting to:

sudo gem install data_objects --source=http://merbivore.com
sudo gem install do_sqlite3 --source=http://merbivore.com

As you can see, I chose to install do_sqlite3 for accessing a sqlite3 database. However you could install "do_mysql", or "do_postgres" to access MySql or PostgreSql databases respectively, and I'm sure there are others. Sqlite users using Mac OS X 10.4 (Tiger) should bear in mind an issue I came across, whereby a strange error is received when attempting to do any database related activity with the do_sqlite3 gem and the default native sqlite3 version that comes with the operating system. This manifested itself as a couple of different strange errors (including a "DataMapper constant not found" error when starting Merb), however the solution was simply to grab the latest sqlite source from www.sqlite.org, build it, and install it. Then try re-installing the do_sqlite3 gem as above, and you should find that they play together much better!



We can now proceed with creating a Merb app to play with:

merb-gen testapp

Looking in the "testapp" folder now shows us the initial structure Merb uses, which is fairly similar to how Rails applications are structured. The main differences that you'll need to know straight away are that routes are defined in the "router.rb" file within the "config" directory, and that the main settings and application initialization stuff is within "init.rb" in the "config" folder. Let's setup our app to use DataMapper by changing the "init.rb" file. Find the following lines:

### Uncomment for DataMapper ORM
# use_orm :datamapper

### Uncomment for ActiveRecord ORM
# use_orm :activerecord

### Uncomment for Sequel ORM
# use_orm :sequel

and uncomment the datamapper line, like this

### Uncomment for DataMapper ORM
use_orm :datamapper

### Uncomment for ActiveRecord ORM
# use_orm :activerecord

### Uncomment for Sequel ORM
# use_orm :sequel

This then tells our application to use and load the DataMapper database plugin. Further down in that file you'll see something similar for testing, and you can choose whether to use rspec, or test_unit. Using rspec is the default. After we change the database settings, we run:

merb-gen

to get it to generate database config. This will create the file "database.sample.yml" in the "config" folder, which we can rename to "database.yml", and configure correctly. Here is a sample development configuration set to use sqlite3:

:development: &defaults
  :adapter: sqlite3
  :database: db/testapp_development.sqlite3

Remember to create the "db" directory. Now to finish off our test application, we can create a dummy controller and views, to see our application in action.

merb-gen resource person first_name:string last_name:string date_of_birth:date

Now we need to migrate the data to take into account the new model. Note there are no migration files like in Rails, however there is a Rake task to migrate the data based on the DataMapper definitions with the model classes:

rake dm:db:automigrate

That should now create the database file ("db/testapp_development.sqlite3"), and we should now be able to play around with the model within our application. First, let's run the application via the console, and inspect the new model:

merb -i
>> Person.count

This will display a count of 0, as there are no people in the database yet. Let's create one:

>> Person.create({:first_name => "test", :last_name => "dude", :date_of_birth => Time.now})

Only this returns an error!

DataObject::QueryError: Your query failed.
table people has no column named date_of_birth

For some reason, the migrations within DataMapper tend to be a bit erratic - there is a console command you can run however that will often fix issues and sync the model definitions to the database more accurately:

>> DataMapper::Persistence::auto_migrate!

Running our create command from before should now work as expected, with a Person object returned and saved with an ID of 1. You can check to ensure that there is a Person object:

>> Person.count
=> 1
>> Person.all
=> [#Person]
>> Person.first
=> #Person
>> Person[1]
=> #Person

The above queries show how to retrieve all Person instances within the database, just the first, or a specific Person by ID. In this case, the same (and only) Person instance is returned (it's returned as an array with a single element in the "Person.all" query). But now let's check out the real deal, and see the web interface - fire it up by just running:

merb

This will start the server, and you can now browse to http://localhost:4000 to see the application. This will show a Merb error page, saying that no route matches the request "/". This is because while we have a single resource within the application, it's setup to be exposed by default at http://localhost:4000/people. Browse to that url, and you'll see the default Merb generated view. Let's hook this up to the root of the application so it's accessible at the easier to remember url http://localhost:4000. Within the "router.rb" file in the "config" folder, look for the following lines:

# Change this for your home page to be available at /
# r.match('/').to(:controller => 'whatever', :action =>'index')

and change the second line to read the following (uncommenting it, and changing the controller to our "people" controller):

r.match('/').to(:controller => 'people', :action =>'index')

Now browsing to http://localhost:4000 will show you the same default view for the "people" index as it would if you were browsing http://localhost:4000/people. You can now customize these views to display and interact the models, in a similar fashion as you would do in Rails!



One other thing to bear in mind is that Merb apps default to port 4000 - however running different apps on that default port at differing times will cause issues because of the way the secret session key is managed. This will most likely be fixed in due course, but at the minute running a second app on the same port at a later date will often result in a secret key error - you can run each app on a different port, or simply find the cookie that represents the "lock" on that port by a specific application, and remove it; then a different application won't have issues using that port. You may well find that re-using a Merb app port with a Rails app also causes an issue, again removing the cookie should fix this.



So that's pretty much it - a very basic Merb app, some potential pitfalls found and sidestepped, and a powerful, lightweight web application framework at your fingertips. While it's obvious Merb is a work in progress, it's also obvious just how useful this framework might become, especially for those looking to create more streamlined, better performing applications.

While driving home after picking my wife up yesterday, about two minutes away from our house, we suddenly had a loud banging noise start up, and immediately we both thought "flat tyre". I pulled over as soon as was possible, and took a look around the car. It had already got dark, and I couldn't see anything obviously wrong with any of the tyres. None of them were flat, that was for sure. I took a look under the car, still nothing. It was obvious there was something wrong, and I thought it had to be tyre related, as the noise quickened slightly if I got a few miles per hour faster, and slowed as I slowed down. I drove home at around 10 mph, letting people pass where I could, and then we took another look at the car.



My wife noticed a hissing noise from the right rear tyre, and it became obvious that it was that tyre that had a puncture - however it must have only just happened, as it wasn't yet flat at all. After a bit of investigation with the help of a flashlight, we found the culprit - what appeared to be a screw or bolt in the tyre. As it was already late, I left it until today to sort it out - I ran the tyre into a local place to see if it could be repaired, as the screw/bolt had gone in straight in the center of the tyre, and not on either side, so I was hoping the tyre itself and outer walls were largely intact.



It turned out it was irreparable, and this is the reason why:







What you see in that picture is a bolt, around four or five inches long, the kind that are used in door handles. It wasn't obvious from the outside how big it was, but with the tyre off of the wheel, you can see just how big an item it was. Somehow it went in dead straight, and considering the speed I was traveling at when I picked it up (around 35 mph), it was fairly lucky that no further damage was done. It was also lucky that we weren't too far from home. However what that bolt was doing in the middle of the road, and how exactly it got wedged the way it did, I don't know - the guys at the local tyre place seemed fairly amazed by it too!