Posts Tagged rails

Undocumented strftime directive

2007-12-06 at 13:04 · Filed under Uncategorized ·Tagged , ,

So, you’ve got to display a clearly readable datetime. You might put something like this in your environment.rb file:


[Time::DATE_FORMATS].each{ |format| format.update(:slashes_with_time => '%m/%d/%Y %I:%M %p') }

That works, but it produces an hour with leading zeroes, which is a little less readable for most people. When you search through the docs for strftime, you might think you’ll need to resort to String manipulation to get rid of the leading zero. But there’s a nice AFAICT undocumented strftime directive that’ll do the trick for you: %l (lowercase L).


[Time::DATE_FORMATS].each{ |format| format.update(:slashes_with_time => '%m/%d/%Y %l:%M %p') }

Now, you just use it like this:

my_datetime.to_s(:slashes_with_time)
=> “10/15/2007 3:48 PM”

There’s an extra space there between the date and time, but I can live with that.

Comments (2)

Resourceful Plugins

2007-11-05 at 23:04 · Filed under Uncategorized ·Tagged , ,

This is a woefully tardy followup to my last post on Clinton Nixon’s raleigh.rb presentation. Clinton discussed some pretty cool stuff about building Rails apps around customizable plugins. His team at Viget Labs has produced two of these Resourceful Plugins: Bloget, a cleverly named blog engine, and a CMS called Sandstone. What follows are my bullet-list notes from the talk.

  • Deployed and working but there are still some pain points and edge cases.
  • Decided separate apps wouldn’t work, but plugins would.
  • More flexibility with plugins as opposed to full Rails apps.
  • Boss: don’t make a Rails Engine.
  • Polymorphism as inspiration.
  • In bloget, Poster must have a name.
  • Modules not classes.
  • Generators are key to the entire concept. Use them to copy over any files that are going to be customized: controllers, views, tests (as they add customizations). Views are completely copied over.
  • Running tests inside plugins is painful, especially when testing how a plugin integrates within an app.
  • Testing plugins is a sisyphean task.
  • Many customizations get unwieldy.
  • Using other plugins. The code for integrating with other plugins gets ugly. Plugins they are integrating with: acts_as_authenticated, acts_as_taggable_on_steroids, will_paginate
  • You end up with a lot of files copied over. The original goal of the project was not to do this, but it’s sort of necessary with Rails plugins now.
  • Upgrades also a consideration.

Leave a Comment

Raleigh.rb preview on building apps as plugins

2007-10-16 at 12:32 · Filed under Uncategorized ·Tagged , , ,

I’m pretty psyched about tonight’s raleigh.rb meetup where Clinton Nixon will be discussing building Rails apps as plugins. Are vertical application slices an area where Rails could stand to improve? Probably. Does that fit into DHH’s vision of what Rails is and should be? I’m not sure, but it doesn’t seem to be something the core team is focused on.

Having spent a few years with Zope2, I got sort of accustomed to using and writing Zope2 Products, which are Zope’s version of vertical app slices. If you can grin and bear the pain of the Zope2 API, Products aren’t too bad. Django also has something along these lines called, appropriately enough, “apps.” Of course Rails has Engines and Plugems. I haven’t looked into either of these too deeply, but neither seem to have gathered mainstream adoption within the Rails community.

For a more in-depth look at the components argument, checkout John Long’s post on the subject as well as his proposal for Rails2.0.

At any rate, I’ll be the one furiously clackety-clacking notes into Textmateduring tonight’s presentation.

Comments (1)