Today I was about to backup some files to my external drive, I realized I hadn’t installed anything to allow writing to NTFS on OSX Lion yet. After researching the problem, it’s relatively easy, but not entirely perfect.

Install OSXFUSE

Hop on over to the new successor to MacFUSE and grab the download here: http://osxfuse.github.com/. I installed this including the MacFUSE compatibility option.

Install NTFS-3G

The free NTFS-3G we need to install next. You can grab that here.

It looks like this has been defunct for a while, but there is a paid version that is replacing it.

Reboot!

Your drive should now be writable. You may find that you are getting this timeout error:

This shouldn’t cause any problems, but if you would like, you can install this fix: https://github.com/downloads/bfleischer/fuse_wait/fuse_wait.pkg based on the code here: https://gist.github.com/1100318

Everything seems to be working splendidly after that. It’s a little more trouble than you’d imagine it should be, but all in all, not too bad.

Source

Calendar gems for Rails are known for being kind of ridiculous. They’re typically messy and/or bundled with a whole bunch of css and js that you don’t really need or want. If you do, you’re probably going to want to roll your own anyways.

Announcing simple_calendar

Using simple_calendar is easy. You simply query for your items in the controller as normal:

  def calendar
    @events = Event.all
  end

And then in the view (for example: app/views/main/calendar.html.erb) you can display them in a calendar:

<%= calendar @events do |event| %>
  <div><%= link_to event.title_column, event %></div>
<% end %>

You can also add the following line to your css to guarantee that dates in the calendar have the same height and widths:

  .calendar td { height: 100px; width: 14.28%; }

And voila! You’re ready to go. If you toss up Twitter Bootstrap on the site, you can get a slick looking calendar in a matter of minutes:

In Progress

This gem is definitely just getting started. There are lots of future additions I’d like to add, and I’m sure people have great ideas for things I can add as well.

You can find simple_calendar here: https://github.com/excid3/simple_calendar

Be sure to discuss ideas in the comments!

There are a lot of times I hear people talk about wanting to do things. I talk about things like this all the time myself. The problem is most of the time we want success, but we don’t want to go through the hard work to get there.

As a high school student, I spent a lot of time naively working on Keryx. It was WAY above my knowledge level, and so I invested tons and tons of hours into building it. This ignorance allowed me to push my boundaries because I was completely unaware of the investment it would take to achieve my goal.

When you’re older, that problem flips sides. You realize how much time it will take, so you don’t even start. Instead of being able to charge head cluelessly, you have to face the problem of gauging whether or not you want to actually spend time on this idea.

This can be devastating to your ability to push yourself sometimes. If you deal with this feeling ever, watch this video:

How Bad Do You Want It from Greyskale Multimedia LLC on Vimeo.

Does this kind of content encourage you to get back in the saddle?

Something that isn’t necessarily that well documented in Devise, is authenticated routes. Take, for example, most websites that allow you to login. When you visit the root url without being logged in, you get the homepage as normal. When you login however, the root url is now rendering your dashboard.

Sure we could do this with logic inside of the controller like so:

class MainController < ApplicationController
  def index
    if user_signed_in?
      render "dashboard"
    else
      render "index"
  end
end

But guess what? That’s ugly. And if you’re querying the database in here, it gets even MORE ugly. Wouldn’t it be nice if we could dynamically set the routes to change where the root url points when a user is logged in?

Devise’s authenticated route allows you to do this nicely.

  authenticated :user do
    root :to => "main#dashboard"
  end

This feature has been around since Devise 1.4, but was never very apparent when searching through the docs and Stack Overflow. You can find the original pull request here: https://github.com/plataformatec/devise/pull/1147

Bonus: There is also an authenticate route that you can use to force authentication. Warning though, if you use these, they’ll redirect to login whenever they’re matched which can cause problems. I recommend you stick to using before_filter :authenticate_user!.

Devise is an awesome library for authentication with Rails. Things are extremely simple to setup for most cases but when you begin implementing slightly trickier business logic, it can become a pain. And the real reason is mainly just because the wiki needs a little love. They iterate quickly, and documenting everything in a newbie friendly wiki page is often hard to do. So I’m going to take a quick stab at documenting my implementation:

The Problem

I’m working on an application that runs on multiple domains and subdomains. Each domain has it’s own set of admins and users. The admins are tied to a domain, and users are tied to a subdomain of that domain. Both of these need to allow authentication via a username field as opposed to the standard email field.

Starting out, we implemented the models just like normal with Devise. Generate custom views for each, and follow this tutorial for adding username authentication.

After I got everything setup, admin users could login just fine, but users could not. What was worse, was the Devise Sessions controller was executing but never calling find_for_database_authentication on the model. I had no idea what was going on, and all I could get Devise to do was return a Completed 401 Unauthorized error and immediately re-render the login form.

This is where we differentiate a bit. In that tutorial, they suggest that you set the authentication_keys in devise.rb like this:

  config.authentication_keys = [ :login ]

Well this is actually going to be the source of our problems. In order to authenticate admins based upon a specific domain, we’re going to include the domain_id inside of the login form as a hidden field. In order to use the domain_id inside the model for authentication, we added it to the authentication_keys array:

  config.authentication_keys = [ :login, :domain_id ]

But wait! That works for admins because they are based upon the domain. Users authenticate against a subdomain, not a domain_id. The users need authentication_keys like this:

  config.authentication_keys = [ :login, :subdomain_id ]

And we put the subdomain_id as a hidden field in their new session form. This is a problem, because the initializer only runs once. We need some way to change this at runtime based upon which type of user is authenticating.

The solution

After a long time searching for a solution to the 401 Unauthorized, I found out that the authentication_keys was the cause of the problem (after having a hunch). The bad part was that I wasn’t able to find a method for debugging the issue.

I found the solution on Stack Overflow that pointed out that you’re actually able to set authentication_keys on the model itself in the devise call like so:

  devise :database_authenticatable, :registerable, ..., :authentication_keys => [:login, :domain_id]

Nifty! We can set these dynamically without touching the initializer. This lets us cleanly customize the authentication without much work. I’ll be updating the wiki to add this functionality because I certainly can’t be the only one who searched long and hard for a solution!