When looking at formatting Times and Dates in a certain format one quickly looks at strftime for help. Only problem there is that strftime will not take into account the translations configured through Rails I18n gem. So a german representation of 10. Oct 2015 will not render correctly since October is abbreviated in german as Okt.

A solution would be to just define the format pattern through the I18n translations inside the yaml files in config/locales/ - but often you have formats that are set just this once, so externalizing them is not really a good solution.

Looking at the I18n gem the solution is quite easy: I18n.localize(<date>, format: '%d. %b %Y') yields the appropriate result while passing in the localization format. So just replacing the date.strftime(<pattern>) call with I18n.localize(date, format: <pattern>) is the way to go.

You can also pass in the locale you want it formatted in using the locale: :de parameter to localize.

Hope this helps.

I just ran into this quick issue so I thought i'd share it.

When trying to create a Date format for Rails i18n.l you are at the mercy of Time.strftime and my format was supposed to look like this: "%e. %b %Y" - so the quite common 1. Jul 2015. According to the excellent http://www.foragoodstrftime.com/ %e should give me the non-zero-padded day of the month - but my tests still failed because of a leading whitespace on days < 10.

Looking at the reference I noticed that strftime allows flags for each replacement to modify how padding and other things work. The solution to getting rid of the whitespace was to change the format to this: %-e. %b %Y.

Here is the list of flags from the documentation:

-  don't pad a numerical output
_  use spaces for padding
0  use zeros for padding
^  upcase the result string
#  change case
:  use colons for %z

The flags just go after the % and before the format directive. Hope this helps.

CanCan is probably the most widely used authorization solution for Ruby on Rails, and for good reason. But sometimes weird things happen.

Given the following ability:

can :read, User, role: :developer

I was experiencing the following:

@user = User.accessible_by(current_ability).first
can? :read, @user #=> false ???

As you can see, the accessible_by method was returning the user list just fine, so I obviously had the permission to read the user at this point, but once I asked the authorize! or can? methods about the same user they promptly replied with false.

The culprit here is ActiveRecord's indifferent-access of strings and hashes. Something that had me scratching my head at more than one occasion over the last few years. ActiveRecord doesn't care if the keys in a hash are strings or symbols, so a beginner might be tempted to think Ruby does not differentiate between those.

But Ruby does care, 'test' != :test will return true! Whereas ActiveRecord doesn't care:

User.where('role' => 'developer')
# or
User.where(:role => :developer)

This is due to the heavy use of ActiveSupport::HashWithIndifferentAccess that makes this possible in Rails:

a = {}
a[:foo] = 'test'
puts a['foo'] #=> 'test'

Now if we look at the conditions derived from the above ability you will quickly see the problem:

current_ability.model_adapter(User, :read).conditions
# => { role: :developer }

ActiveRecord doesn't care about the symbol, it will happily return all Users with the role column set to the string developer, whereas CanCan will do the can? check in Ruby, doing essentially this:

puts @user.role #=> 'developer'
# user.role is a string - the condition a Symbol
puts @user.role == :developer #=> false

Conclusion: Always make sure your conditions are valid both in ActiveRecord AND Ruby! Where ActiveRecord and Rails in general promote a sloppy type-free behavior, other frameworks don't necessarily see it that way. So keep in mind that a symbol is not a string!

Also when you know you might get a symbol and want to compare it to a string, don't use .to_sym on the string but rather .to_s on the symbol - symbols don't get garbage-collected, so they will stick around in memory forever. Never .to_sym user input or bad things will happen™!

One quick thing I just ran into in my Rails app with Mongoid:

Ids in model instances are not Strings objects and thus their == method doesn't work against normal Strings.

This means:

@post.id == '51abcb7b421aa90cdf000146'   # always false

will never be true unless you explicitly cast the ObjectId to a string:

@post.id.to_s == '51abcb7b421aa90cdf000146'  # correct comparison

Oh and yes: you shouldn't do things like that anyways in your code - but if you have to - be aware.

I am a big believer in not starting out full throttle with things like ember-rails or other crazy asset-pipeline helpers when you have absolutely no clue what you are doing. So naturally when I did my first serious Ember.js application I just went with the basic Ember starter kit and dumped all my templates into script tags in the html.

Well, after getting the basics to work I decided to clean up the mess that was quickly becoming of the HTML and found the wonderful HandlebarsAssets gem that promises to compile Handlebars down to JavaScript and serve it through the Rails 3.1+ asset pipeline. After doing so I can say with confidence I managed to hit every single stumbling block along the way so I decided to write down where I went wrong. Hopefully this helps some other poor soul before he has to dive deep into the bowels of Ember like I had to :).

First step was to move the content of my script tags into a /templates folder inside my app/assets/javascripts and name them accordingly ('slots/create' goes into the file templates/slots/create.hbs etc). Don't forget to require the directory from your application.js manifest file.

Once done the Handlebars compilation part seemed to work perfectly. Only problem: Ember.js doesn't actually care for the contents of HandlebarsTemplates and will just silenlty ignore them. Instead Ember.js wants it's templates to be registered on Ember.TEMPLATES and even more annoying: It won't complain if a template is not registered correctly unless you turned the right arcane debug setting on (yay!)

To actually get Ember to tell you if your templates can't be found you have to turn on debugging through the Ember.Application.create call:

Ember.Application.create({
  LOG_TRANSITIONS: true
  DEBUG: true,
  LOG_VIEW_LOOKUPS: true  //the important part!
});

Now on to get the HandlebarsTemplates into Ember.TEMPLATES:

First I RTFM and HandlebarsAssets has Ember.js support built in, so to enable it you simply create a config/initializers/handlebars.rb file and put the following in:

if defined?(HandlebarsAssets)
   HandlebarsAssets::Config.ember = true
end

And if you did compile your templates before you'll see absolutely no change. Yes that's right, nothing will happen because HandlebarsAssets caches the template output in /tmp. So to actually see your Ember templates show up you'll have to do a rm -rf tmp/.

Hope this helps - I'm now off raising tickets and maybe fixing some of these stupidities.. There is just no real reason for this to be such a piss-poor experience.

I just ran into this and wanted to share this quite puzzling behavior:

20.times { Fabricate(:post) }
Post.scoped.limit(10).length.should eq(10)
# => Test failed
#    expected: 12
#         got: 20

Weird right? But once you look at MongoDB's capabilities and the Mongoid implementation you'll quickly discover that this is only kind of a semi-bug :). MongoDB supports an .count() command that takes a filter and returns the number of matches documents. This command is being issued by Mongoid whenever you call .length on a criterion (since it's much cheaper than executing the actual query and counting the returned objects).

So don't write tests like this:

# method under test:
def self.most_played
  self.order_by(:play_count.desc).limit(12)  
end

# test
it 'returns the 12 most played items' do
  Video.most_played.length.should eq(12)
end

This test will fail, even though the method is doing everything perfectly right. I'd even say that in a regular ActiveRecord setting this would be a passing test. But since I am utilizing the delayed execution functionality of Mongoid most_played method is only returning a Criteria object that represents the query and can be composed into a more complicated query.

This causes .length to be executed on Criteria where it causes Mongoid to call the .count() method instead of running .length on Array. Since limit is no query parameter it will not be passed to MongoDB and the returning count will correctly be equal to the total number of Documents in the collection.

The more correct way to write that test is to actually force Mongoid to execute it's query and count the result:

it 'returns the 12 most played items' do
  Video.most_played.to_a.length.should eq(12)
end

Carrierwave, my favorite file upload framework of choice in Rails requires something along the lines of 5 lines of code to set up a file upload. The uploader can then be mounted on a model and receive file_field uploads from forms. Especially with the numerous storage backends and the not so common support for ORM frameworks besides ActiveRecord Carrierwave is right on par with other important Gems like Devise.

But then, after having used it upwards of 20 times, just when you think you remember the syntax without having to check the site something unexpected puzzles you:

In my case that was a file upload that was technically working, but seemed to completely ignore the options specified in the uploader. The store_dir was ignored, the different versions were simply never called - but the file upload worked like a charm.

I thought I did everything right (the uploader code looked just fine) and apparently I was uploading files just fine - but it didn't work.

After some investigation and re-doing everything following the getting-started instructions the following code in my model caught my eye:

  mount_uploader :menu_image

Since my uploader was called MenuImageUploader I thought: well that looks reasonable.

Turns out I was wrong (shocking I know) .. Carrierwave requires you to explicitly specify the desired uploader class instead of deducing it from the name.

  mount_uploader :menu_image, MenuImageUploader

Suddently everything started working again, yay. So: If you ever need to just simply upload a file that has no special storage directory or other processing going on - just mount a uploader without a uploader class. Carrierwave will default to Carrierwave::Uploader::Base for you. And if that wasn't you intention - it will still screw you over :).

Maybe I should raise this as an issue with the developers. At least a simple logger.warn would be in order in cases like these.

It's been some time since I did write a blog post, and I must say it was not for a lack of ideas. It was mostly the prospect of having to write these posts in HTML into my Wordpress interface that led me to abandon the idea.

And I think that's the main problem: I believe HTML is a bad format for writing posts. And no amount of WYSIWYG will change that, for all the subtle codehighlights I like in my posts the Wordpress WYSIWYG is just not the least bit useful. And don't get me started on posting source.

There are basically 2 solutions I had with my Wordpress installation: Either use a clientside syntax-highlighter or rely on Gist to post code in a human-readable fashion that's also easy on the eyes.

And I hated that.. I hated doing the back and forth between Gist and the site, and fixing errors in the code was always a pain. And as much as I like the syntax-highlighter script, it slows the page down a lot. Especially the front-page, even when the user may not be looking at a post with code at the moment code on the page will still be parsed.

A good solution to this problem seemed to be Jekyll, where you write your posts in simple markdown or textile and code gets syntax highlighted automatically on the server. I tried that some years ago, but for my style of writing it turned out to be even worse than Wordpress.

Why? Simple: I didn't start from scratch but rather imported my whole Blog into Jekyll when I started the experiment. So I was running Jekyll with syntax highlighting on on about 300 posts all the time. And the compilation did run for about a minute every damn time! To add insult to injury: at the time I didn't have a rsync capable hosting setup so I had to FTP the whole site.

So a few weeks ago I started to tinker around with Ember.js, and naturally I found myself writing a sample blog application. And that's when it hit me: writing a blog is f***ing easy. There is a reason any web frameworks worth it's salt is demoed using a blog engine.

And it turns out, what few features I want from my blog engine are usually all covered by these very simple demo apps :). So I ditched all the Ember.js experiments and started to write my own blog engine that had to do the following things:

• Look exactly as my old blog
• Accept Markdown input
• Provide syntax highlighting
• Let me schedule posts to appear at a later date
• Preserve permalinks

And that's it - almost laughable how simple my requirements actually are. I decided to ditch some more complexity I felt no longer required (since RSS is dead) and built a really simple rails application ontop of the awesome libraries rouge and redcarpet. So my blog now accepts GitHub Flavored Markdown - all with less than 5 lines of code.

And the results are really awesome:

puts "I <3 Ruby"

So I sat down and built the blog in probably half a day. Maybe a bit more since I wanted to have some shiny like: nice tagging with autocompletion, real time post preview while typing and drag & drop file upload for images.

I'll post the code once I cleaned up the deployment mess I created (no secure database.yml management, secret.rb in git etc) but once done I'll post it here anyways.

Next up for me is trying to figure out a good way to make the blog theme-able. I'd love to experiment a bit with Rails engines and how this can be leveraged to separate themes from applications. And now that I've got my own little Rails playground once again it's the perfect opportunity to do so :).

Oh, and I need to leverage caching. After a cursory exploration today it seems caching would turn this blog into a statically generated static site. Only problem seems to be the cache invalidation, but I am sure I can devise some scheme to get around that that (short of doing 5 rm -rf calls).

What rails does very nicely is protect you from XSS attacks through aggressively HTML encoding anything you write between <%= %>. But there is one caveat: At times you may really want to render HTML from a string. So you need to tell rails not to escape your HTML in that case.

There are two methods of telling rails that a string is safe and should not be escaped: raw and .htmlsafe

And both do the same. They mark the string as safe (through the use of the html safe buffer) and rails will not encode it any more. The main difference between the two: nil.

If you are doing things like: "<img src='#{..}' />".html_safe .html_safe is totally fine as the string will never be nil, but if you are dealing with strings that may be nil .html_safe will break since there is no .html_safe method on the nil object. (For example if you are loading something from a config value or the database) In that case using raw(...) will just ignore the string instead of raising an exception.

As always with these things: raw and html_safe make it very easy to introduce XSS attack vectors into your application. So use them wisely and only on strings you are sure to be safe.

I know this sounds like a very simple task to do, but since I just spent half an hour reading up on how Sessions in Rails work I decided it's time to put this up so I can Google it again next time :)

First off, you need to know how you are storing sessions in your application. Rails supports 3 types of session storage: Stored on Disk, in the Database or through Cookies in the client. You can check which one you are using in /config/initializers/session_store.rb.

Cookie based session storage

Rails 3 defaults to storing the session in the client using a session cookie. This means that the user_id along with all the data you put into the session hash is serialized into the cookie and sent to the client. It's also not encrypted, only BASE64 encoded so if you are storing anything sensitive in there you are doing it wrong.

But for simple things like the current user_id the cookie based session store is just fine and also a lot faster than the alternatives.

Expiring the cookie though is a bit more involved since you can't reach out to all clients and delete their cookies at once. But, and that's the important part for what I was doing: This cookie is signed with a SHA-512 digest using a secret key that is only present on the server. So the cookie cannot be tampered with on the client, and this is also your avenue of attack when trying to expire all cookies:

Simply change the secret that is used to sign the cookies. All previous cookies are invalidated as their digest is no longer valid.

Doing so is simple, first generate a new secret using rake:

$ rake secret 10dfec4781b682762a731a5e88af78521fc3e0f...

Then copy/paste that new secret into your config/initializers/secret_token.rb:

MyApp::Application.config.secret_token = '10dfec4781b682762a731a5e88...'

Once done deploy the application and all existing sessions are invalid at once.

Database backed session storage

If you are using the Database to store the session it's rather trivial to expire all existing sessions using rake:

rake db:sessions:clear

File based session storage

Like with the database simply run the following rake command:

rake tmp:sessions:clear

Hope this helps..