Blog Archives

Sending Apple Push notifications in rails with Redis and apn_sender

Posted in Code, Featured, Inside TFG, Ruby on Rails, Tips and Tricks

Sending iOS push notifications from a Rails application is very easy to do these days, thankfully there are many great Ruby gems that can be used to handle most of the magic for you. Recently I ran into the apn_sender gem which handles sending push notifications in a really neat way.

Sending push notifications directly from a Rails application can be slow and we probably don’t want to have the user waiting until the notification is sent, instead apn_sender can be setup to run a worker which is constantly connected to the apple push notification service. When there are new notifications to send, the notifications are queued up and sent through the always open connection that is maintained by the worker.

apn_sender uses redis as a message queue to keep track of the notifications waiting to be sent, you’ll need to install it before using the gem.

To add apn_sender in your Rails 3 application, just add the gem to your Gemfile. We’re going to need the daemons gem too so we’ll include that as well.

Can’t see this Gist? View it on Github!

Now we can create our daemon which we will be using for sending push notifications, this can be placed anywhere, I’ve put mine in script/apn_sender. Make sure to add execute permission to the file after creating so we can run it.

Can’t see this Gist? View it on Github!

Before the daemon can start running we’ll need to put our iOS push certificate into the application. Instructions for generating the certificates are available at the Apple Developer site. The certificates need to be placed inside of /config/certs and should be named apn_development.pem or apn_production.pem for production.

Once the certificates are in their correct locations, we can start up the daemon. The daemon does not know about the Rails environment so we need to specify this when starting it up. The daemon supports start, stop and restart commands. There is a verbose flag available to output more information (which can be helpful when debugging).

Can’t see this Gist? View it on Github!

Our application is now set up to send push notifications, this can now easily be performed by adding a new notification to the queue. The notify method on the APN class will take a push notification token and then our parameters, we can specify the alert message to show the user, whether or not we want sound as well as the number to display on the badge icon. Anything else we pass to notify will be sent as metadata in the push notification. Here’s an example of creating a notification.

Can’t see this Gist? View it on Github!

The worker should pick up the notification within a few seconds and send it off. The apn_sender has many other features that I haven’t covered, you can view the full documentation over at https://github.com/kdonovan/apn_sender.

Setting Up an iMac Pairing Station for Rails Development

Posted in Inside TFG

I used this post today as a guide on how to get another iMac up and running so I thought it was probably a good point to chuck this up here, if only for our own reference.

We are starting with a 27″ iMac and a base Snow Leopard install.

The first step was to install Xcode from the Snow Leopard disc, you’ll find it in the Optional Installs part of the disc.

Ruby and RubyGems comes with Snow Leopard by default so we’ll use them. You’ll likely need to update the RubyGems system :

    sudo gem update --system

Now we can install Rails :

  sudo gem install rails

This will install the latest stable version of Rails. We need a specific version for some of our applications (until we’ve tested it under the newer version) and you can do this by adding the -v switch :

  sudo gem install rails -v=2.3.4

After this we can switch on Apache and install passenger, the module that runs Rails on Apache. So turn on Web Sharing in the Sharing panel of your System Preferences.

  sudo gem install passenger
  sudo passenger-install-apache2-module

This will compile the Apache module and give you some text to paste into your apache conf file to load it. I keep this in a separate config file in /etc/apache2/other/passenger.conf. It should look something like :

  LoadModule passenger_module /Library/Ruby/Gems/1.8/gems/passenger-2.2.8/ext/apache2/mod_passenger.so
  PassengerRoot /Library/Ruby/Gems/1.8/gems/passenger-2.2.8
  PassengerRuby /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby

Next download the Passenger Preference Pane so you can control your Rails sites from the OS X Preferences area. You can get it from http://www.fngtps.com/passenger-preference-pane. You should now be able to run Rails websites on your local machine very easily.

We use Git for our source control and Git X is the best GUI for this on OS X at the moment. You can download Git for OS X from http://code.google.com/p/git-osx-installer/ and you can get GitX from http://gitx.frim.nl/.

I like to use a Pomodoro timer when pairing and the one I like the best for OS X is just called Pomodoro Desktop. It will keep people focussed and also can serve to keep the control swapping in a fairly regular way. You can find out about how Pomodoro works here.

We use Github for our repository and exchange is done via SSH, so you’ll need to generate an SSH key and put that into your Github account.

  ssh-keygen
  cat ~/.ssh/id_rsa.pub

Copy the output and put that into your public SSH keys in Git Hub.

When pairing with Git the ability to have both parties responsible for the work they’re doing is appreciated sometimes. Especially twelve months from now when you can’t remember why you did something. Not that you don’t comment your code, or always write beautifully understandable code. There is a nice gem called hitch. It comes out of Hashrocket and handles the ‘hitching’ and ‘unhitching’ of partners on a machine. We have a pairing station so generally we just want to change the pair that’s in operation, so it works well. You’ll need to be inside a git repository to do the initial setup. I cloned one of our projects and then you issue :

  hitch -m

Which will prompt you for your main email address, this is the email address that all devs in your team receive, or a group email of some sort.

Now to hitch two devs you’d do :

  hitch dev1 dev2

This will prompt you for names of the dev1 and dev2 users so that they’ll be displayed in your commit. It’ll also associate your commits to the email address devs+dev1+dev2@company.com if you setup devs@company.com as the email address when you issued the hitch -m command. If you setup gravatars for all your devs+user1+user2@company.com email addresses then you’ll get a nice picture in Github too.

I think that’s about it really. We obviously just install gems as required and make customisations on a per developer need. We generally use Textmate for editing so this means installing a theme (we use the Railscast theme) and the relevant bundles for Rspec, Haml and Sass.

Updating your mail client to use the correct mail server

Posted in Inside TFG

Below are the steps you’ll need to take to change your email client to use the correct mail server, mail.thefrontiergroup.net.au

Outlook 2002

From the menu select Tools, E-Mail Accounts. View or change existing email-accounts. Next. Change “Server Information”, “Incoming mail server (IMAP)” or “Incoming mail server (POP3)” to mail.thefrontiergroup.net.au

Outlook 2007

From the menu select Tools, Account Settings. E-mail tab, highlight the account. Click “Change” button. Set the “Incoming mail server” to mail.thefrontiergroup.net.au

Outlook Express

From the menu select Tools, Accounts. Highlight the account. Click “Properties” button. Change “Incoming mail (POP3, IMAP or HTTP server)” to mail.thefrontiergroup.net.au

Apple Mail

From the menu select Mail, Preferences, Accounts. Select the account and change “Incoming Mail Server” to be mail.thefrontiergroup.net.au

Battery Technology in the 17″ Macbook Pro

Posted in Product Reviews

There are five developers here at The Frontier Group and four of us have partners. That’s nine people, between them there are eight Apple laptops of various vintages. Five of them are our own Macbook Pros. If you were to say that we are impressed with Apple products and enjoy using them daily then I’d say you are dead right!

Apple have recently released their new 17″ Macbook Pro and have given it an embedded, non-removable battery pack. On initial impression this seems to be quite a limitation. In reality given that they are touting 8 hours of battery life and 1000 recharges the battery could quite legitimately last 2-3 years of even the most heavy use.

Their video detailing why they went with an embedded battery and how the battery pack is manufactured is pretty interesting. It explains how the batteries are manufactured and where they saved space and weight as well as the improvements they made to increase the lifespan of the battery pack.

My assumption is that the battery is replaceable, it’s just that you’ll need to take it to a service centre to have it done. They don’t seem to mention this on the website though so I may be wrong.

If the battery is truly and completely irreplaceable then I think their claims of environmental friendliness and so on would be debunked. I guess we’ll hear about it in a couple of years time.

All in all though I’m pretty excited about the new Macbook Pro and after having seen one in the flesh at work I’m keen to see one in my own hands some time this year or next.

UPDATE : According to Gizmodo the battery is replaceable after all for US$179. To me that seems like an entirely reasonable price if the battery life lives up to the claims.

Twitter

Great web stats at @petrescue , the driving force behind the rebuild of their systems by @frontiergroup . http://t.co/MTvfoxnU

@frontiergroup about 3 weeks ago #

Search Posts

Featured Posts

Categories

Archives

View more archives