b a d p o p c o r n

Installing Mysql with MacPorts for Rails on Leopard

Written by Moe on September 19, 2008 | 3 Comments

I just spent a hour going through this so you won’t have to. I thought I installed mysql using mac ports but I kept getting this error.

Errno::ENOENT (No such file or directory - /tmp/mysql.sock):

Below are the three steps you need to get Mysql running on Leopard for MacPorts.

sudo port install mysql5 +server
sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist
sudo ln -s /opt/local/var/run/mysql5/mysqld.sock /tmp/mysql.sock

Posted in Rails

3 Comments

Authentication and Authorization in Rails

Written by bill on September 16, 2008 | 4 Comments

Some say Rails is “missing” a lot of things you might expect to find in full-featured web development framework, but it doesn’t matter - what’s it’s NOT missing is a plugin system which allows you to add any functionality you need by pulling a few bits of code from other authors into your site. What I’ll be using in this example are the restful-authentication plugin for authentication and the role_requirement plugin for authorization. Both of these are hosted on github, which hosts loads of Rails plugins along with other open projects. As the name implies, they use git for their repositories, so you should install git to grab these plugins.

Setting up authentication

First, you’ll need to set up authentication. In the vendor/plugins folder of your project, run:

git clone git://github.com/technoweenie/restful-authentication.git restful_authentication

This will grab a copy of the restful_authentication plugin; you don’t need to mess with any of the code in the plugin itself. go back to your project’s root and run:

script/generate authenticated user sessions
rake db:migrate

This will set up the user model for you and insert the users table in your database. You can add arguments to the generate script such as –include-activation –aasm to enable activation emails but we’re not going to cover all of that right now.

Now, you’ll have two new controllers in your application, sessions_controller.rb and users_controller.rb. Go to each of these files and remove or comment out the line that says ‘include AuthenticatedSystem’, and copy this line to the top of the application controller instead, right at the beginning of the class definition:

class ApplicationController < ActionController::Base
  include AuthenticatedSystem

and so on. The generate script should have also added these lines to routes.rb:

map.logout '/logout', :controller => 'sessions', :action => 'destroy'
  map.login '/login', :controller => 'sessions', :action => 'new'
  map.register '/register', :controller => 'users', :action => 'create'
  map.signup '/signup', :controller => 'users', :action => 'new'
  map.resources :users

  map.resource :session

These give you some prettier URLs rather than, for example, /users/new to sign up and /sessions/new to login. Generally you want the first thing a user sees to be the login page, so if you want to you can make that the default by adding

map.root :controller => "sessions", :action => "new"

to your routes. You’ll also need to remove or rename index.html in the public folder.

At this point you have a basic authentication system, which is great considering how easy it is to set up, but alone it’s pretty useless. You’ll notice, no matter if you’re logged in or not, you still have full access to your app. So why did we even bother? Because now, you can add authorization to lock down actions based on roles you set up.

Setting up authorization

There are a few different ways to do this; if you want a very, very granular authorization system you can install padlock authorization which allows you to set roles per each object in your application. We decided this was probably overkill for our latest project, but I may touch on it in a later blog if we decide to use it after all. We’ll be using the aforementioned role_requirement plugin.

Back to github with us! Head back to your /vendor/plugins folder and run:

git clone git://github.com/timcharper/role_requirement.git role_requirement

Go back up to your application’s root, and run:

script/generate roles Role User
rake db:migrate

Now, you’ll have to make some manual database changes. You need to add one or more roles to the roles table, and if you have any users, assign them initial roles, if you want them to have roles, in the roles_users table. You can, of course, just add a new controller and view to make all this changeable from your application, but you’ll probably still be setting up one admin user by hand to start things off when you go live.

Now you can go about editing your controllers to make each one accept and reject your roles. For example, say I have a simple model with with a TV show, which can have one starting date. To allow only administrators to make changes, you can set up your Shows controllers like so:

class ShowsController < ApplicationController
  require_role "ADMIN", :for_all_except => [:index, :show]
  def index
    @shows = Show.find(:all)

(The rest is standard Rails boilerplate)

A later post will probably deal with setting/changing roles within your application.

Posted in Rails

4 Comments

What it’s like to work in the game industry

Written by Aaron on September 15, 2008 | 1 Comment

The title is loaded. I can not pretend to know what it is like for everyone in the industry, and I won’t even attempt to give an exhaustive depictions of even my own personal experiences. Trust me you wouldn’t be reading this post now if I had titled it “A rough overview of generally what it’s like to work in the game industry”.

The short answer

GOOD

The long answer

The experience of being in the Peace Corps is commonly described as “The Toughest Job You’ll Ever Love”. I hate that they have dibs on the line because, besides being a great quote, it captures a good bit of the heart of working in the game industry. If you work in the game industry you probably love games and most of the people that you work with do too.

The other people often end up being the best part –Warning– The money will probably never end up being the best part. Not to say that everyone in the industry lives with their parents, just don’t expect golden toilets. Most people in the industry make enough to support themselves, and even their families, just trust me, you’ll be richer in friendship than wealth…unless you’re a complete prick (In which case you’ll probably end up in charge of a game studio and swimming in cash and–if there’s a God–cutting yourself every night as you drink yourself into unconsciousness wondering what is wrong with everyone else that makes them not like you).

Yeah the goods of being in the game industry = Going to work everyday with people you like, working on something that you love.

The con of being in the game industry = More money would be nice.

So that’s the lovey-dovey perspective on the industry, don’t get me wrong, it’s not all Kumbaya and s’mores but it passes the “Office Space” Test. If I had a butt-load of money and I didn’t need to work…God help me I’d still get up and drive through L.A. traffic to show up every morning.

This was going to be the part where I say that I wouldn’t actually show up every morning if I was suddenly rich, but I can’t. I’m scared to death to admit it, but I would show up every morning…it beats the hell out of daytime TV.

Posted in Gaming

1 Comment

Rails Observer Field

Written by Moe on September 11, 2008 | 1 Comment

The Rails observer field is an easy way to add an ajax select menu to your site. Below is an example to get you going.

Problem

Let’s say you have a list of users on your site and want to filter them by a group. In the example we will be using gym members.

View

<%= select "gym", :gym_id, Gym.find(:all).collect { |p| [p.name, p.id]}, {:selected => params[:gym]}  %>
<%= observe_field "gym_gym_id", :url => { :action => :members_by_gym ,