Sliced Software

Six Weeks Later

Mon, 01 Feb 2010 09:02:54 -0500

I spent the past six weeks working full time on Limited Pressing and I’m really happy with what was accomplished. We teamed up with some big names to host charity auctions (as of this writing we’ve raised almost $15,000 that will be donated to Doctors Without Borders) and rolled out a lot of new features. The biggest feature we launched was our brand new Stores infrastructure that I think makes it incredibly easy (not to mention inexpensive) to get a site and store up and running for your label or band.

Aside from software work, I was also able to get my feet wet over at Amazon with things like EC2 and RDS. Although there were a lot of new things I wanted to spend time learning that got overlooked, I hope to rectify that in the coming weeks.

Starting today, I begin a brand new project with Gary Culliss that I’m really looking forward to working on.

Why I Spent $60 On An Alarm Clock

Wed, 06 Jan 2010 10:43:00 -0500

For years, I used one of the original iHome iPod dock alarm clocks. I only docked my iPhone a few times - when I felt like listening to an audiobook without my earphones. Otherwise, I used it as an alarm clock. At least, I attempted to use it as an alarm clock.

To set the time or set the alarm, you have to spin a wheel. A slow, loud, clicking wheel. Shortly after getting the clock, the wheel started to break. You would spin it one way and the time would start going in the opposite direction. But that wheel wasn’t even the worst part about it - nor the interference with my GSM phone. No, the worst part about it was that it wouldn’t keep time. It would lose a few minutes every month or so. I never knew what time it was and started looking at my phone to double check. I tried resetting it frequently, but gave up. Instead, I began to set my alarm for earlier and earlier to compensate.

I should have replaced it years ago.

What Do Clocks Even Cost?

Before I was given the iHome “clock” as a gift, I had a regular alarm clock. I don’t remember how or when it came into my possession. I would say a decade, at least, had gone by since I had actually purchased an alarm clock.

Not knowing what alarm clocks cost, I searched Amazon. Wow. There are clocks with big numbers, small numbers, weather reports and ceiling projectors. There are clocks that roll off your nightstand and hide. There are clocks with iPod docks. There are fold up clocks. There are wind up clocks. There are clocks with puzzles on top that, when the alarm goes off, forces you to find the pieces that were thrown into the air and put them back together on the top of the clock before the alarm shuts off. There are $5 clocks and there are $105 clocks.

Learning My Lesson

Page after page, I began to see the problem. Every clock has a gimmick. Every clock does something else. But I had that clock. I had the do something else clock and it was horrible. It was so bad, it couldn’t even keep time.

I tried to find the alarm clocks that were only alarm clocks. Weather reports? I don’t want you. Ceiling projector? Sorry, not for me. The clocks that were left ranged from $5 to $15. Each one had reviews that said something along the lines of “cheap, works well”.

Unfortunately, these all looked cheap. I started to think, what if these clocks can’t even keep time. How long would these cheap clocks last? Sure, they were just clocks which is what I wanted, but I don’t want to have to buy another clock next year.

Then I stumbled on the Neverlate Execute Alarm Clock. I am not an executive. Nor do I need 21 separate alarm “banks”. But, something seemed right about this ridiculously expensive alarm clock. It was expensive, but it didn’t do anything else. Sure, it has separate alarms for each day of the week in addition to seven daily alarms and a quick nap alarm. It also has a gradual wake setting (increasing alarm volume) and a decremental snooze interval (10 minutes first snooze, 5 minutes second snooze, etc).

It has a lot of features, but each feature is alarm clock related. If there is an alarm clock out there that is actually a good alarm clock, I thought, this must be it. Did I spend too much money on an alarm clock? Yeah, probably. But I will say that I was able to set the clock up in just a couple of minutes and I woke up on time this morning to a nice alarm sound with a gradually increasing volume.

It doesn’t matter if you’re writing a piece of software or making an alarm clock. Keep your product focused and you won’t end up with a wheel you need to spin 500 times to get from 12:00AM to 7:00AM or a clock that can’t even keep time.

One of Those End of The Year Posts

Thu, 31 Dec 2009 22:44:00 -0500

I suppose waiting until 11PM on December 31st is as good a time as any for an end of the year wrap up post, right?

2009

The year really started early February for me with my Grandfather passing away. I’ve had relatives pass away before, but this was different. This was someone I was really close to and saw all the time. His death was sudden and was really hard to get past - not only for myself, but for the rest of my family. I don’t think I’m over it yet and I’m not sure I ever will be.

The rest of the year, I buried myself in work. I would say that my Grandfather’s death was the reason, but to be honest, I’ve been burying myself in work since as far back as I can remember, so maybe this was just an excuse.

Regardless, 2009 was a year of working hard - maybe too hard.

The year started wrapping up on December 18th with my last day of new development on gawkk. It’s been a long road. I was first hired by Gary to work on gawkk at the start of 2007. Working part time, I was able to lay the groundwork. By September of 2007, I had left a software engineering job I had been at for over six years to work full time on gawkk.

In the past two years, gawkk has grown and changed a lot. Towards the end, we were constantly trimming features and simplifying processes and user interaction. As it stands, I feel that gawkk is a superb video aggregator and discovery engine. Behind the scenes, it scours thousands of video hosting sites and automatically imports and categorizes everything it finds (millions of videos). For our end users, it provides a very simple way to share and discuss videos with their friends. Gawkk suppresses the noise from people you don’t care about, allowing the videos enjoyed by only your friends to surface just for you.

With that said, the time has come to let gawkk do its thing and focus attention elsewhere.

Other than working on gawkk full time through 2009, I’ve worked on a handful of very small freelance projects - all from clients I first did work for many years ago. I’ve released a few simple plugins and worked on a bunch of new side projects that have taken up most of my nights and weekends.

Twenty Ten

I’ll be starting the new year with an entire month of not doing any paid work. Instead, I will spend most days and nights slaving away on a couple of my side projects and reading every technical book I can get my hands on. Another one of my goals for this month is to completely refactor my mornings in an attempt to get a better work-at-home routine down. Lastly, I hope to squeeze in a couple of snowboarding day trips here and there, because there is nothing more relaxing to me than sitting at the top of a snow covered mountain.

I hope to have my new morning routine all straightened out when February comes, because I’m lucky enough to be starting a brand new project with Gary. We’re completely changing direction with this project and I’m really excited to get rolling. It’s going to be really fun to use some of the new things in the Rails ecosystem that I’ve had my eye on as well as just getting to start a new, fresh project (I’m looking at you, Rails 3!). In addition to new Rails specific things, we plan on using AWS for our entire infrastructure. Everything from EC2 and RDS to S3 and CloudFront. I honestly can’t wait to get my hands on that infrastructure. Everything Amazon has been doing with their Web Services continues to impress me. Just the other day they released object versioning for S3 - really neat stuff.

Aside from my plan, I hope that the Rails community continues to thrive and that, for everyone’s sake, this economy picks up in 2010.

Happy New Year!

A Look Back At Staples

Wed, 16 Dec 2009 23:37:52 -0500

In early 2007, I was contracted to implement a document management web application for Staples Digital Copy Services. Customers can register and upload documents for very large jobs to Staples’ regional copy centers. The app handles documents for about ten locations. The only non-rails part was a multi-file uploader I wrote as a Java applet. Staples wanted drag and drop file uploading that also supported dropping multiple files at once, which I was able to do with Java.

Certain privileged Staples employees can log in and download documents, read descriptions and manage which jobs have been completed.

I was contacted a few days ago for a quote to work on a new feature for the application and was happy to see the app has been running smoothly these past few years. They keep adding locations to the system and it’s quickly closing in on managing 100,000 documents.

Automatically Resizing a Textarea's Height

Fri, 18 Sep 2009 17:05:00 -0400

Here is a simple Javascript method that can be used to automatically resize the height of a textarea based on the amount of content inside.

Prototype is used in this example.

Click through if you don’t see the code snippet below.

 id="comment" rows="1" cols="50">
 
          view raw
          This Gist brought to you by GitHub.

I have been slowly building my record collection for a while,...

Mon, 14 Sep 2009 22:33:00 -0400

Silent Majority - Life of a Spectator

The Movielife - Self Destruct

The Movielife - This Time Next Year

The Movielife Has A Gambling Problem

I have been slowly building my record collection for a while, but recently it seems like I’ve been making more moves to pick up the things I always knew I’d want. This weekend, I was able to get my hands on 4 of the records that I’ve been really looking forward to getting.

I was able to get the Silent Majority because, amazingly, Artie Phillie was selling it for a friend on eBay.

The Movielife records came into my possession because a good friend recently started selling off some of his collection. Has A Gambling Problem was purchased new by him and never even removed from the sleeve.

So there you have it, 4 records from 2 of my favorite bands and proof that I actually have interests other than writing software (admittedly, not many).

A Cacheable Hash That Stays Synced

Mon, 07 Sep 2009 14:53:14 -0400

Rails.cache freezes values in hashes that are cached directly. CacheableHash is a wrapper for Hash objects that prevents that from happening. Changes to the Hash being wrapped are automatically persisted back to the cache store so that everything stays in sync.

You can clone (or fork) my new MIT licensed plugin over at github.

Example

An instance of CacheableHash is used like any other hash. A cache key is the only thing required.

>> fruit = CacheableHash.new('fruit_hash_key', :hash => {:apple => 'red', :banana => 'yellow'}, :expires_in => 1.week)
>> fruit[:banana]
=> "yellow"

Changes are automatically persisted.

>> fruit = Rails.cache.read('fruit_hash_key')
>> fruit[:apple]
=> "red"

>> fruit[:apple] = 'green'

>> Rails.cache.read('fruit_hash_key')[:apple]
=> "green"

About Synchronicity

Whenever a method is called on an instance of CacheableHash, that instance automatically writes itself back to the cache store. Often, this is unnecessary. If you call .keys, for example, there is no reason to write back to the cache store. Only when reading a value from the hash using [], is the copy in the cache store not specifically updated. But, rather than worrying about the specific methods that change the contents of the hash, it’s safer to just update the instance in the cache store whenever not specifically reading values.

Updated: Mobile Twitter Trends Application (2.1)

Sun, 06 Sep 2009 00:08:00 -0400

I wasn’t able to add all of the polish and features to my Trends application that I really felt was necessary last night, so I’ve just rolled out a quick update. This is definitely the last update for a while on this app.

Version 2.1

The front page now lists not only the currently trending topics on Twitter, but it also shows topics that have trended in the past day and the past week.
Hashtag topics are now working (they were broken in v2).
The timestamp on the topic page now more accurately states when the topic was first seen trending.
Added some protection against strange (and actually kind of frequent) errors thrown by the Twitter API when requesting the list of trends.
If What the Trend doesn’t know about a particular topic, rather than throwing an error, you’re now redirected back to the trends list and a dialog is displayed telling you what happened.
Fixed a visual bug in TankEngine related to the top 1px border of the toolbar (it used to be a dark line, it now matches the actual iPhone toolbar element).
Updated the default loading image used for the fullscreen Trends application (accessed through the home screen shortcut) so that the toolbar matches the updated toolbar.

Mobile Twitter Trends Application

Sat, 05 Sep 2009 04:08:00 -0400

Update: Version 2.1 has been released.

Just over a month ago, I released a mobile web application that used the API from whatthetrend.com to present a list of recently trending topics on Twitter, along with their explanations. This little application turned out to be pretty handy, but for a while I’ve wanted to change it a bit. Most importantly, I wanted to have the front page of the application be the list of currently trending topics on Twitter.

Trends: Version 2

The interface has been re-implemented from the ground up (actually the entire application was rewritten from scratch) and is now styled like a normal list-based iPhone application.
When you first load the application, it shows you a list of the topics that are currently trending on Twitter.
Clicking on a topic will bring you to that topic’s page. The explanation as to why that topic is trending is pulled in from What the Trend? and displayed here.

I will be adding lists for the daily trending topics as well as the trending topics for the week - for now, only the current trending topics are available.

Please visit Trends on your iPhone and add it to your home screen for the best experience.

Sweat the Details

For this project, I used Noel Rappin’s TankEngine plugin for the iPhone’s user interface. I ended up having to hack it a bit so that it would run in fullscreen mode without breaking out into Safari when clicking links, but overall it was very enjoyable to use. You can run the Trends application in fullscreen mode by tapping the + button in MobileSafari and then tapping ‘Add to Home Screen’. When you launch Trends from the new icon on your home screen, it will launch in fullscreen mode.

heroku

In addition to wanting to update this application a bit, I’ve been really wanting a reason to try heroku and I thought this was the perfect application to use as my test run. heroku is a service that allows you to deploy ruby applications quickly and easily. You know what? Saying it allows you to deploy ruby applications quickly and easily is an understatement – heroku is, by far, the most wonderful service I have used in recent memory. I set out tonight to rewrite my mobile Trends application from scratch. Once I had a working version, I went to heroku not knowing anything of how it worked, signed up and in less than two minutes my application was deployed to heroku and running perfectly.

If you have a simple application that you’re planning to host on your own server, I highly suggest taking a minute to deploy it over at heroku. It’s free for small applications and I guarantee you will immediately see what an incredible service it is. I honestly can’t say enough.

Conclusion

I don’t sleep enough and heroku is awesome.

Rails Rumble Reflections

Mon, 24 Aug 2009 23:03:00 -0400

I competed in Rails Rumble 2009 over the weekend. It was my first time competing, so I wanted to share some of what I learned while working on a project from start to finish with other people in a 48 hour window.

Get a real designer

Our team consisted of three developers and no designers. We could all write HTML and CSS and develop front ends, but we weren’t designers. We didn’t possess the talent necessary to develop a really stunning interface, while actually developing the rest of the application in the time allotted.

Although we produced a full featured application that ended up looking halfway decent, there is no doubt in my mind that we would have benefited immensely if we had a real designer. And by designer, I mean someone who actually makes a living doing design work for web applications.

Be opinionated, but be flexible

Any project with multiple engineers is bound to bring about disagreements. People are going to discuss and argue their points. I believe that when it comes to software development, you must be opinionated to develop good software. Having strong opinions about something means you are passionate about it. When you’re constrained by a 48 hour window, being opinionated is even more important. You don’t have the luxury of having an entire discussion about every little thing that comes up.

The problem is that when opinionated people disagree, they spend a lot of time in heated discussion. Normally, these discussions will lead to a better overall implementation and everyone benefits, but when you’re constrained by time, you must not only be opinionated, you must also be flexible. You have to pick your battles and make concessions.

Working with people you trust

Being able to make concessions is related to another point I have. You should work with people you trust. If you don’t trust the people you are working with, you are going to have a hard time giving in when the other person yells louder. You aren’t going to be able to sit back and say:

“I’m working with this person for a reason. I have to trust them, they are very passionate about this.”

Being able to trust your team members is not only important during a competition like this one, it’s always important. The difference with a competition, though, is that you just don’t have the time to spend on every disagreement.

Don’t write tests

Nowadays a lot of people talk about test drive development. Write tests for code that doesn’t exist yet. When you write the code, you know you’re done because it passes the tests. The problem with TDD is that it can be time consuming. Additionally, because you only have a 48 hour window, the scope of your application must be small enough to complete. If it’s small enough to complete, it will probably be small enough to manually test throughout the competition.

I spoke to some other contestants who feel the same way. Some even went into the project doing tests and quickly abandoned them because they were too time consuming. Even Lowdown, a Rails Rumble entry specifically built to help developers, designers and managers collaborate on Cucumber feature stories said:

Ironically – especially considering the purpose of our application - we didn’t test, spec, or write features. There were times we could have benefitted from TDD, but many other times it would have just slowed us down. We considered the app to be a prototype/proof-of-concept anyway, not a polished and hardened work of craftsmanship.

I think this is the key. Testing is good, but testing during the competition could prove fatal. If you only finish a third of your application because you were busy writing tests, you don’t get more points - even if that third is really perfect. It’s better to get to a feature complete state as early as possible and then iterate and iterate and iterate until the last moments of the competition.

Conclusion

As you can probably tell, I am very opinionated when it comes to software development. Being opinionated can also leak into the rest of my life. This article, these reflections, are my reflections. I’m sure many other participants, possibly even my own teammates, don’t agree with me - I’m okay with that. The fact is, nothing I said here (other than having a real designer on your team) is necessarily “right”. It is, however, right for me and probably a lot of other people.

In the end, I was lucky enough to work with smart people and smart people can work through differences to deliver something they are proud of. And despite our differences, the three of us were really happy that we were able to deliver the application we set out to develop. Being proud of that accomplishment is something we could all agree on.

I’m really looking forward to Rails Rumble 2010.

Making Your Existing User Base Play Nice With Your Facebook User Base

Thu, 20 Aug 2009 21:40:00 -0400

This is the second article in a series dedicated to getting your existing rails application on Facebook without clawing your eyes out. You should read the first article if you haven’t already.

In the previous article, I talked about how to use facebooker to extend your existing rails application with Facebook only views. Requests that came into your application from Facebook, were authenticated by facebooker to be genuine Facebook requests, the Facebook user was required to add your application and all of your Facebook specific .fbml.erb views and layouts were automatically used instead of your standard .html.erb views. While all of this was happening for requests coming from Facebook, your regular application kept chugging along, doing its own thing, unaware you were cheating on it with that blue haired girl from your Calc class.

Chances are however, your application has users (at least you hope it does). What you really want, is for users on your existing Rails app and new users coming in through Facebook to be treated like equal citizens. Sure you may email one and you may notify another, but aside from how you communicate with them, the content they generate in your application should be shared by everyone. If data generated by regular users and Facebook users couldn’t be seen or accessed by one another, there would be no reason to having a single action with two different views (html, fbml).

There are a few things we need to get our different types of users to play nicely.

A place to store a user’s Facebook user id and last session key.
A way to catch authenticated Facebook sessions for new users to our application.
A way to automatically log in an existing user who has authenticated via a Facebook request.

Tracking Facebook account details in your users table.

If you only plan on doing Facebook related stuff (you have no interest in having Twitter oauth support in your app in the future), the easiest thing to do is just add a couple of fields to your User model. We can just pull these migration lines from what facebooker does:

add_column :users, :facebook_id, :integer, :limit => 20, :null => false 
add_column :users, :session_key, string

Tracking Facebook account details in a separate object.

Alternatively, if you plan on having not only Facebook authentication, but Twitter oauth at some point, you may want to create a new model called FacebookAccount to store your user’s Facebook account details (as well as a foreign key back to the User it belongs to). Then you can add a TwitterAccount object as well and do what you have to do.

For this example, I’ll assume you just added some fields to your User.

Hey, do I know you?

Now that we have a place to store Facebook account details, we need a way to make a new User for a new Facebook user. Let me preface this by saying that there are probably a hundred different ways to do this. What I’m going to detail, however, is the approach that worked well for me.

Let’s go back to our application_controller and see how we left it:

before_filter :require_login_for_facebook

def require_login_for_facebook
  if params[:format] == 'fbml'
    ensure_authenticated_to_facebook

    if !session[:facebook_session].nil?
      # we'll do something with users
      # here in the next post about fb
    end
  end
end

If you follow a Facebook request coming into our application, you’ll see that it hits the require_login_for_facebook before filter, it should pass the (params[:format] == 'fbml') test because facebooker will have forced the format to be fbml because it already verified the request came from Facebook. Next, the famous ensure_authenticated_to_facebook method is called to make sure we get a Facebooker::Session. After that, I do one more test to ensure we really do have a Facebooker::Session sitting in session[:facebook_session] and we can be on our way.

Inside of the if statement checking if !session[:facebook_session].nil?, we’re going to want something along the lines of:

unless user_logged_in? or (controller_name == 'facebook' and action_name == 'connect')
  facebook_session = session[:facebook_session]
  if user = User.find(:first, :conditions => {:facebook_id => facebook_session.user.uid})
    session[:user_id] = user.id
  else
    redirect_to :controller => 'facebook', :action => 'connect'
  end
end

I should probably mention that I don’t use restful-authentication. I generally roll my own. Please, take a minute to yell and scream about what a horrible person I am. Blah blah blah. Okay, done? Despite not using the norm, you can see some of the same basic things here. First up, I have a helper method called user_logged_in?. Can you guess what that does? Good. I’m sure you have the same kind of method. Just make sure there isn’t already someone logged in. Don’t worry about that next part of the unless statement ensuring we aren’t in FacebookController#connect, you’ll understand that soon.

So, after we ensure we have a Facebooker::Session, we make sure there isn’t someone already logged in. Next, we try and locate the User in our users table that has a facebook_id that matches the user id of the Facebook authenticated user (session[:facebook_session].user.uid). If we find someone with that facebook_id, we can automatically log them in. For me, I set session[:user_id], for everyone else in the world, do what you normally do to log someone in.

The reason we can automatically log this person in is because that user already had to log into Facebook and when Facebook made a request to us, facebooker did the heavy lifting to ensure that this was a real Facebook request. We wouldn’t have gotten this far if it wasn’t a real Facebook request. And, since this is a real Facebook request, we can assume the uid of the user inside of the Facebooker::Session is really who they say they are. Thus, they are sufficiently authenticated.

But how do we actually get a user object with a facebook_id into the database so that we actually have someone to automatically log in? It’s actually pretty easy. First, generate a controller called FacebookController. Inside of this controller, create a method called connect. I know, I know, Facebook Connect! Although I won’t be talking about it in this article, this is actually in preparation for allowing users to add your Facebook app inside of Facebook, then go out to your existing external application and log in using Facebook Connect while still retaining the same user object they used from your Facebook applicaiton.

Inside of the FacebookController#connect method, you’re going to want to prepare a new User model. This method is going to act like a Users#new and Users#create method. The idea is that we need this user to essentially register for our site. User’s in our existing rails app register, so why not Facebook users? The difference, however, is that we want to ask for as little information as possible while still being able to have full fledged accounts for Facebook users that can be shown on our existing site. For me, that means I need a username. Just pick a username and I’ll be happy. Oh, and don’t forget to add an app/views/facebook/connect.fbml.erb view for this method (for Facebook Connect, we’d have a connect.html.erb - get it?).

def connect
	if request.get?
		# Lets collect some information about this user
		@facebook = Hash.new
		@facebook[:id] = facebook_session.user.uid
		@facebook[:name] = facebook_session.user.name
		@facebook[:description] = facebook_session.user.about_me
		@facebook[:image_small] = facebook_session.user.pic_square_with_logo
		@facebook[:image_large] = facebook_session.user.pic_big
		@facebook[:profile_url] = facebook_session.user.profile_url.gsub(/^http:\/\/www\.facebook\.com\//, '')

		# We're going to want this later, no point in hitting the API again
		session[:facebook_credentials] = @facebook

		# To make things easier, I like to suggest a username.
		# I won't do it here, but generally I run the suggested username
		# through a unique_username? check about 3 times, appending a 
		# random integer on the end to try and make it unique.
		# If I can't find a unique username quickly, I let the user worry about it.

		@user = User.new
		if !@facebook[:profile_url].blank? and !@facebook[:profile_url][/^profile.php/]
			# This user has a new vanity url so that is a preferred username
			@user.username = @facebook[:profile_url].first(15).gsub(/\s/, '').gsub(/\./, '')
		elsif !@facebook[:name].blank?
			# This user doesn't have a vanity url, just use their name
			@user.username = @facebook[:name].first(15).gsub(/\s/, '').gsub(/\./, '')
		end
	else
		@facebook = session[:facebook_credentials]

		# Create the new User object from params[:user]
		# Make sure to store the @facebook[:id] and session key (see facebooker docs)
		# Fetch and store their avatar locally (Facebook likes you to use their (x)fbml
		# tags to display a user's current profile picture, you could do that instead.)

		# Log the user in
		session[:user_id] = @user.id

		redirect_to path_to_front_page
	end
end

I know it looks like there’s a lot going on in the connect method, but it’s pretty straight forward and the inline documentation should really explain everything. Obviously, you’ll want a form in your app/views/facebook/connect.fbml.erb view. You’ll need a username field and you’ll probably want to display the image in @facebook[:image_small] on the page somewhere.

Now, whenever an existing Facebook user comes back to your application, they will automatically be logged in with their full fledged account. They never have to worry about logging in or the fact that they “registered”. In fact, I tell my user’s they are just picking a username. That is technically all they’re doing. Having to “register” scares people off. Picking a username is easy.

I may write another article that explains how you can setup Facebook Connect to allow your existing Facebook users to log in directly at your main external rails app (outside of Facebook), using Facebok Connect. Doing this would actually allow you to get users to sign up using Facebook Connect directly from your main site as well. After the post connect callback from Facebook Connect, you’d just the same kind of the check in the application controller to see if you have the user with that facebook_id, either log them in automatically or send them off to your FacebookController#connect method (only it will be the .html.erb version this time) to finish the account sign up. It’s really very similar to what we do here.

Getting Your Existing Rails App on Facebook

Wed, 19 Aug 2009 22:07:00 -0400

There’s a ton of information already out there about writing a new Facebook app with Ruby on Rails. You use facebooker, you call a method at the top of your application_controller and you’re done. It’s pretty easy. The problem is that when you have an existing Rails app and you want to extend it to support alternate fbml views for a Facebook application, things are a bit trickier.

Here’s how I did it:

You’ll have to start with the usual setup:

Create a Facebook app from the Developer Application
Install the plugin
Setup your ssh tunnel for development
Setup your config/facebook.yml

I won’t bother explaining how to do all of this stuff. There are tons of resources out there.

After you get that done, it’s time to start serving authenticated fbml views for requests coming from Facebook. In the facebooker world, you need to call ensure_authenticated_to_facebook. Unfortunately, if you do that in your application_controller, it will try and do a Facebook authentication for every request coming into your application, not just the ones actually coming from Facebook. Since you are trying to extend your existing application with Facebook views, this isn’t what you want.

It turns out that facebooker does two very important things for you by just having the plugin configured in your application. The first is that it forces the format of all of the Facebook requests to be fbml. Next, it adds an object to session[:facebook_session]. It’s safe to say that if your request has a format of fbml and there is something in session[:facebook_session], you’ve got yourself a Facebook request.

To catch and authenticate just the requests coming from Facebook, you’ll want to add the next bit of code to your application_controller:

before_filter :require_login_for_facebook

def require_login_for_facebook
  if params[:format] == 'fbml'
    ensure_authenticated_to_facebook
    
    if !session[:facebook_session].nil?
      # we'll do something with users
      # here in the next post about fb
    end
  end
end

Now, let’s say you have a movies_controller that uses an app/views/layouts/movies.html.erb layout. You’ll want to add an app/views/layouts/movies.fbml.erb layout for requests coming from Facebook. Next, you want a Facebook specific view for your index action. You already have an app/views/movies/index.html.erb right? Well, just add an app/views/movies/index.fbml.erb.

That’s it, you’re done! Now, when a request comes into your regular application for /movies, the regular index.html.erb view will be rendered inside of your regular movies.html.erb template. But, when a request comes in from your Facebook application to /fb-app-name/movies, it’s authenticated with facebooker, the facebook user will have to have added your application and your new index.fbml.erb view will automatically be rendered inside of your movies.fbml.erb layout.

I will post another article soon talking about how to approach integrating your existing user base with a Facebook user base.

Like this article? Be sure to read the second article in this series titled: “Making Your Existing User Base Play Nice With Your Facebook User Base”.

Consume At Will - RSS Feed Changed

Mon, 17 Aug 2009 09:23:00 -0400

The RSS feed for this blog has been changed. It now lives at http://feeds.feedburner.com/SlicedSoftware.

I would appreciate it if you updated your subscription.

Carry on.

This Economy Sucks - Do Your Job Better!

Sat, 08 Aug 2009 21:33:00 -0400

In this economy, it’s difficult to go a day without hearing someone say “in this economy”. Aren’t you sick of hearing that phrase? Well I sure am and I work from home where most of my talking is to my dog, Napoleon. What better way is there to get people to stop saying “in this economy” than to do your job better? The better everyone does their job, the faster we get this economy to stop sucking so much, right? I think it works something like that.

So, if you work with databases all the time and PGnJ helps you do your job better, do yourself a favor and donate to the project. Keep PGnJ going and feel good about yourself with a just a few clicks!

Disclaimer: I have not taken economics since high school.

Keeping Text Fields and Text Areas Consistent With CSS

Sat, 08 Aug 2009 13:42:00 -0400

Let me just start by saying that I don’t claim to be good at design at all, but as I don’t work with a designer, I have had to fend for myself over the years. I’d say I “get by” in the design department by sticking to things that aren’t overly complicated. It’s probably also worth noting that I can be a perfectionist at times. I care a lot about the code I produce - whether it’s 5 lines of code that can be written more simply or a few pixels lining up better (admittedly, I’m way better at refactoring code than I am at interfaces).

What I’d like to explain is a very simple thing I do to keep my text fields and text areas looking consistent with just a couple lines of CSS.

By default, most browsers like Safari and Firefox render text fields with a simple 3D type depth. It makes the field stand out. Text areas, on the other hand, are usually rendered without that 3D type effect. They are given a simple, flat border. This is what 2 text fields look like compared to a text area, by default, without any CSS:

The first step to keeping things consistent looking is to simply set the border of text fields and text areas with CSS. Now both widgets are at a level playing field.

Just setting the border is a nice first step, but that slight 3D depth given to text fields by default is actually pretty useful to indicate to the user that she can click and type into the area. To do this, you can simply set the border-top of the text fields and text areas to be slightly darker than the border you set in the last step.

I suspect that most users looking at this form wouldn’t even think twice about this subtle tweak, and that’s the beauty of it. It’s so simple yet still does such a great job of making your forms look way, way sexier.

Sample CSS:

.textfield, textarea {
  border: 1px solid #c9c2c1;
  border-top: 1px solid #999999;
}

Maybe the word for me is neurotic.

PGnJ 1.1 - Free For Good, QuickJoin, Crasher Fix

Fri, 07 Aug 2009 01:51:00 -0400

After 8 months of being on sale, I would like to announce that PGnJ 1.1 is now available and that it is completely free (and that it will absolutely stay free).

It comes down to the fact that the vast majority of PGnJ’s user base decided to stay on 0.8 (the last free version). There wasn’t huge interest in a pay version of PGnJ and because of that, interaction with customers along with feedback totally dropped off the map. But I still had things I wanted to add to PGnJ. I still use PGnJ every day. I wanted people to get those new features. So, the PGnJ-for-pay experiment is officially over.

What’s new in 1.1? The changelog may look pretty slim but it comes with a couple of very major improvements as well as a fix for a crashing bug that came about in the past couple of weeks.

Changelog:

PGnJ is now free. Enjoy!
When using the DataBrowser (double click a table from the database tree in the sidebar), you can how double click any cell to edit the contents (PostgreSQL and MySQL only).
Developed a brand new, one of a kind feature that I call QuickJoin. When you open the DataBrowser, it will automatically add a QuickJoin bar to the top of the window with a list of all foreign keys for the current table. Clicking a foreign key will bring up a drop down list of all fields in the referenced table. Selecting a column (you can select as many as you want, across as many referenced tables as you want) will automatically generate JOINs under the hood and display the selected column right inline next to the fk column. See below for a quick demonstration.
Fixed a major crashing bug that came about with OS X Java Update 4. Essentially, the application must be run in 32 bit mode.

Watch a short demo of PGnJ’s innovative new feature called QuickJoin!

Download PGnJ 1.1

Using Partials as Reusable Inner Layouts

Wed, 05 Aug 2009 16:56:00 -0400

You may find this pretty basic, but it’s useful nonetheless.

Using partials in Rails is a wonderful example of code reuse. For example, you may have comments that use polymorphism so that you can attach comments to different models in your system. If you always want your comments to display using the same UI (and why wouldn’t you) on not only Project Messages but also To Do items, you can create a /comments/_comment partial and render these partials from either the Project Message page or the To Do item page. But, we all knew that.

Sometimes, however, you may want to use a partial like an inner layout inside of your page’s layout.

Update: If you have problems seeing the code snippet below, just click through.

 
      <%= yield %>
    
<% render(:layout => "/dashboard/container", :locals => {:selected => 'inbox'}) do -%>
    <%= render @messages %>
  
<% end -%>

view raw This Gist brought to you by GitHub.

Above is a really simple example, demonstrating how you can use a partial as an “inner layout”. Essentially this allows you to have a reusable partial with contextual, custom view code somewhere inside that reusable template - just like you’d use a regular page layout, except now you can have them scattered about your application.

Yes, this example in particular is really simple, but if you’ve never seen partials used this way, your brain is probably already cranking on how immensely useful this can be.

Updated: iPhone Optimized What The Trend App

Fri, 31 Jul 2009 21:46:00 -0400

I rolled out a few updates to my iPhone optimized What The Trend? webapp last week.

If the app is added to the home screen using the + in Mobile Safari, the application will launch in full screen mode rather than in Mobile Safari with the top location bar and bottom bookmark bar.
What The Trend?’s Matt Mayer graciously allowed me to use his graph icon as the app’s home screen icon.
Improved the design of the trend list on the front page.
Tapping a trend goes to the trend’s single page explanation and gives a link out to the whatthetrend.com single trend page.

What’s coming in the future?

Matt of WTT has recently added the ability to update trend explanations from the API. Soon, I will extend this mobile webapp to utilize this new API method.
I will add an additional link on the single trend explanation page that will do a Google News search on the selected trend.
I’m going to juggle some things around. The front page of the app will be replaced with a list of current Twitter trends. You’ll be able to quickly change to the daily and weekly trend lists as provided by Twitter’s search API.
Each Trend on these new trend lists, when clicked, will send you over to the single trend page to explain what the trend is about.
There will be a link out to the current full trend explanation list as provided by WTT (which is used on the front page of the app now) so you can see more than just the top current, daily and weekly trends.

Please feel free to send me feedback, feature suggestions or questions (you can use the contact link in the sidebar).

A Mobile What the Trend? Application

Mon, 20 Jul 2009 01:39:00 -0400

I’ve just released a simple little iPhone optimized webapp that hooks into the API of the awesome What the Trend? site. Enjoy!

Updated: Mobile LIRR Schedule Application

Sun, 19 Jul 2009 23:40:24 -0400

I have just released an update to my iPhone optimized, mobile LIRR scheduling application. Most importantly, this update brings the service back online after being off for a couple of months due to underlying system changes on the MTA sites.

Full Changelog:

Entirely re-written to work with the MTA’s new website.
Each schedule now notes whether it is a peak or off peak trip.
Each schedule now includes the total trip duration.
Each transfer in a schedule now notes what time the train at the transfer station leaves.
If a transfer is not direct (meaning if the first train is late, the following train may not wait) it is noted with an * and a message at the bottom of the page.

Shoot me an email with the contact link in the sidebar if you have any problems, questions or other feedback.

I plan on adding some quick reference materials, including station orderings on each branch line, maps and links out to the standard HTML train schedules in the near future.