Spitfire Sky Blog

Add Gaming Elements to your Apps

Sun Jun 12 13:37:08 -0700 2011

Add Gaming Elements to your Apps

Gaming is big now - especially mobile gaming. Let's strive to add gaming elements to our 'boring' applications.

Gaming and Real Life

Jane McGonigal did a TED Talk on how gaming can make a better world. It was an exuberant and inspiring presentation. Here's the link to the video.

I liked her ideas about leveling up and +1 strength. Those concepts which are a part of the virtual world but not a part of the real world can make virtual life more rewarding than real life - at least more immediately rewarding.

This is why there is an exodus of people to these virtual worlds like World of Warcraft. 3 billion hours a week is spent playing online games.

Jane sees opportunity in this and I do too. In fact, she says we should be playing even more games. We just need to make games applicable to real life.

I think we as web developers can do this by bringing more gaming elements to the applications we can create.

EpicWin

The iPhone application EpicWin does a nice job of this as a todo task I think. I've used EpicWin for a few months now and like it much better than even Things. This 1 minute trailer for EpicWin sums it up better than I can in words.

I get more done with EpicWin. Its gaming mechanism of earning experience points and leveling up has motivated me to get much more done - exercise consistently to build strength, self-educate myself on a daily basis to increase intellect, and even take more time out with friends to increase my social score.

My Attempt at Adding Gaming Elements

I've only just begun adding gaming elements to my application designs. My first attempt is MotoPermit.

It is a study application for the motorcycle permit test. I launched it by making it "look" like a game. This was a cop-out for the real thing. Apps that integrate gaming elements do not need to 'look' like a game, they need to function more like one.

So after launching the app I set to work on version 1.1 - which would add gaming elements. I've since added a basic experience point and profile mechanism. Each correctly answered question is worth 50 experience points. After you accumulate 1500 experience points, you level up. Reach level 5 and you are ready to take your motorcycle permit test.

I've found myself using the app much more in order to more quickly reach level 5. And I am confident that once I do reach level 5 I will be ready to take the permit test and pass it my first time. It's done it's purpose to help me study better and I think it will do the same for others.

So try to start adding gaming elements to your applications. You will find them more effective. And over time maybe we truly can step towards making the world better through gaming.

Follow me on twitter here

Provisioning a Titanium Mobile App

Mon Apr 25 20:54:43 -0700 2011

Provisioning a Titanium Mobile App

Keys, Certificates, Provisioning Profiles, and AppIDS can be a configuration nightmare. In this article, I step through setting these up with a Titanium Mobile app.

Prerequisites

You need the following:

An Apple Developer's Account
A Mac
An iPhone, iPad, or iPod

Certificates, Keys, Provision Profiles, AppIDs

Generate key

Just follow along.

On your mac open up Keychain Access. In the toolbar click 'Keychain Access' -> 'Certificate Assistant' -> 'Request a Certificate from a Certificate Authority'.

In the pop up window, use the email address you signed up on the Apple Developer's site with. Enter your name, and choose Save to Disk.

Save it somewhere you can easily find it. Keep it safe.

App IDs

Login into your development account, visit the iPhone Developer Program Portal, and go to the App IDs section: http://developer.apple.com/iphone/manage/bundles/index.action

Click the New App ID button, and on the next page enter a name (MissMint) and a bundle identifier (com.spitfiresky.missmint).

After creating the AppID go to configure the id you just created. On the next page, check the box to 'Enable for Apple Push Notification service', and then click the 'Configure' button next to the Development Push SSL Certificate.

In the configuration window, follow the steps, and upload the CerticiateSigningRequest file we created previously using KeyChain Access.

Next download your newly generated push notification ssl certificate.

Double click on this certificate to save it your key chain. Export this key by clicking on this newly installed certificate.

Next, go back to the Apple Developer website, go to provisioning profiles, and choose to a create a new provisioning profile. http://developer.apple.com/iphone/manage/provisioningprofiles/create.action?type=1

Fill in the form with the appropriate info.

Download the newly created provisioning profile.

Open up Titanium Mobile and open up your project. Go to Test & Package, and then the Running your app on a device section. On the 'Select Provisioning Profile' section choose to browse for the provisioning profile we just downloaded.

Choose the provisioning profile we just downloaded.

Open up xcode with your iphone plugged into your computer and drag the provisioning profile onto the window.

You might have to quit Titanium Mobile and iTunes at this point to finally get everything working. Re-open them and then in Titanium Mobile install the app onto your phone by pressing "Install Now".

You should follow me on twitter here

Ad Hoc Distributing a Titanium Mobile App

Mon Apr 25 20:54:43 -0700 2011

Ad Hoc Distributing a Titanium Mobile App

Ad Hoc Distribution allows you to test your app on your iPhone and other friend's iPhones.

1: Create an Ad Hoc Distribution Provisioning Profile

Navigate to the Distribution Provisioning Profiles section of the iOS Provisioning Portal. Then click on 'New Profile'.

In the 'Create iOS Distribution Provisioning Profile' screen, choose the Ad Hoc distribution method, give it a name like 'Your App Ad Hoc Distribution Profile', select the App ID which you created earlier, and then select the Device(s) you want it to work on. Note: you will have to add your friends' devices here in order for the app to work on their iPhone. You can gather this device information using testflightapp.com.

After saving that download it to your computer. Double click on it and it will ask you to add it to 'Add to Library'. Please do.

2: Set Titanium Mobile's Distribute section to use the Provisioning Profile

Open up Titanium Mobile and navigate to Your Project > Test & Package > Distribute. Choose 'Desktop' for your distribution location and select the distribution provisioning profile you just downloaded to your computer in the steps above. (if it asks you to 'Add to Library' again go ahead and do so and replace the existing ad hoc distribution profile)

3: Distribute Your App

Titanium

Quit Titanium and the re-open it.

Navigate to the Distribution section under Test & Package and click 'Package' (make sure XCode is open in the background before clicking 'Package')

Generate the .ipa file

After Titanium is done packaging your app it should open up 'Organizer' on your mac. Click on the Archives tab in Organizer. You should see your app listed in the Archives.

Click on the name of your app and then click the 'Share' button. This will pop up a window. In that window choose iOS App Store Package (.ipa) and for Identity choose the option right underneath the Ad Hoc Distribution Profile we created earlier. It should probably say iPhone Distribution: Your Name.

Click 'Next' and then save the app to your Desktop. It is a good idea to name the app without any spaces - ie YourAppname

Use TestFlight to upload your app

Go to testflightapp.com and create a developer account.

Choose Builds > Upload a Build and upload your YourAppname.ipa file you saved to your desktop. Once the upload is complete, choose your testers and they will receive an email with a link to download your app to their iPhone.

That is it. Best of luck.

You should follow me on twitter here

An App - Scottbalance

Thu Dec 30 23:00:00 -0800 2010

An App - Scottbalance

Scottbalance (portfolio link) is a tiny app with a simple role. It saves a daily history of your Scottrade account balance and emails it to you - automatically.

Why this app?

I have an account with Scottrade where I invest in stocks. Scottrade does not include a feature to view your historical balances. It only shows your current day's balance. Scottrade does not provide an API to gather said historical balances either. I needed to be able to get a hold of my historical balances, so I built Scottbalance.com.

How does it work?

Using your Scottrade login information, the app screen scrapes your latest current balance and saves that information to your balance history. (Your login information is securely encrypted). After saving it, it emails you to let you know your latest balance for that day. Then by logging in you can see a list of your historical balances.

Additionally, the app is smart enough to navigate through Scottrade's new security questions. And the app is designed to look good on your iphone so you can check your balances on the go.

Libraries and Tools Used

The app is hosted on heroku. It is built on Padrino. It uses bcrypt to encrypt all Scottrade access information. It uses warden to handle user authentication. For the automatic logging into Scottrade and for the screenscraping of the balances it uses mechanize.

Conclusion

This was a personal project so it's certainly not polished but it does its job well. So I decided to make it available to everyone. If you also have a Scottrade account, then try it out and see what you think. It's free to use.

To follow me on twitter click here

Riverside Ruby - Introduction to Ruby

Tue Sep 28 09:37:28 -0700 2010

Riverside Ruby - Introduction to Ruby

Here are the slides from my presentation to our first Riverside Ruby Meetup.

Slides

Overview

For this presentation I introduced ruby and some basics about the language. Additionally, I demonstrated the power and simplicity of ruby by using Sinatra to build a hello world app.

You should follow me on twitter here

Getting Started with Sinatra

Mon May 31 18:16:33 -0700 2010

Getting Started with Sinatra

Sing me a song mister Sinatra. In this tutorial I get you started with sinatra, plus improve the folder structure of your app, and serve it up with unicorn.

Installation

The Basics

Type sudo mate hello.rb and in the hello.rb put the following:

Now you just need to run the app. Shotgun is great for this. It's a lot like script/server for unicorn apps. (We'll use unicorn to do this later, but for now we'll keep it easy with shotgun)

haml

I like haml so let's bring it into the app now. We've already installed the haml gem so just change your hello.rb file to the following:

Move to folder structure

I like an organized application that can handle future complexity. Let's setup a folder structure to make room for that possibility.

To begin, create a folder with the name of your app. I'm going to call my app careengine. Then, create the directory structure we'll be using.

In app.rb put the following:

This tells our / route to use index.haml from our views. Let's create that file now by type sudo mate views/index.haml.

Unicorn

Now that the app is contained inside a folder structure (slightly similar to rails), let's set the app up to serve itself with unicorn instead of shotgun. (Unicorn is what we will be using on our production server, and It's nice to keep development and production as similar as possible.)

Don't forget to install unicorn: sudo gem install unicorn

Unicorn works with a config.ru file so let's create that.

Type sudo mate config.ru

Now just run the command 'unicorn' in terminal and then browse to http://localhost:8080 to view your app. Alternatively you can type unicorn -p 3000 to specify the port as 3000.

Great work, you setup a basic sinatra app, improved on the structure, and served it up with unicorn. You are well on your way to building more complex sinatra applications.

You should follow me on twitter here.

How you should be doing testing in Rails and how to get started

Sat Oct 03 16:00:05 -0700 2009

How you should be doing testing in Rails and how to get started

Here I show you a good way to do testing in Rails (especially if you are a beginner tester) plus instructions on getting started.

Why test?

Testing is a good practice. You should be doing it. It will make you a better programmer and save you a great deal of headache as your web app grows up. It is especially important when working alongside other programmers. Testing is not perfect though so don't try to be perfect. Just get started, and you will improve as time goes on.

How should I be testing?

You should be:

#1 using rspec
#2 testing your models
#3 doing some integration tests

Ignore all the other test strategies and tools out there - especially Cucumber (cuke makes me want to puke). It's awkward and arguably a significant waste of time. But it's even more a waste of time to test your controllers, helpers, and views separately. Don't.

Let's get started.

rspec

Installation

That's it, you can now run 'rake spec' in your terminal, and it will run through all your specs (which are currently at zero count).

Model testing

Setup

Before we get to the rspec testing we need to delete the test/* folder that rails creates by default. (We are using rspec, not test/unit, so we won't need the test/* folders. All our tests will live under spec/*.)

Next let's create the models folder and the person_spec.rb model spec.

Writing the model test

Open up person_spec.rb in textmate or your text editor of choice and let's write our first spec.

Run 'rake spec' in terminal, and you should get back the response of "1 example, 0 failures". Congratulations. :)

Time for some test driven development. We have decided that every person should have a first_name and last_name. (No use in having a person without one). Let's write two specs to test for this. They should both fail.

Run 'rake spec', and you should receive the response back '3 examples, 2 failures'. Open up the person.rb model and add the validates_presence_of.

Run 'rake spec' again, and you should receive the response back '3 examples, 0 failures'. Nice work, you just did test driven development.

Next let's refactor things slightly using our spec_helper.rb to store some reusable code. This is optional and isn't so useful with such a small suite of tests, but once your test count climbs to 50 or more it is really nice to have a setup similar to the following. It basically uses helper methods inside of spec_helper.rb (which is being required with the line 'require File.expand_path(File.dirname(__FILE__) + '/../spec_helper')').

person_spec.rb

spec_helper.rb

Good work. You've written a few model tests to test your person.rb model pretty well. Let's move on to integration testing.

Integration testing

Before I demonstrate integration testing, let me say that many programmers test their views, helpers, and controllers separately. This is not smart and if you are doing that you should stop. Take Merb's testing approach as an example. Merb's testing framework encourages the developer to test the final http response rather than worry about testing your views, controllers, and helpers separately. Afterall, these three items are working together to create the final http response. It makes a lot of sense and saves a lot of time. (Yehuda Katz can tell you more about this in his video on merb testing).

Rails doesn't have Merb's fancy response testing, but it does have integration testing using the powerful webrat. (Cucumber uses Webrat - which is about the only thing I like about cucumber.)

Setup

Add config.gem 'webrat' to your config/environments/test.rb file

Open up spec_helper.rb and add the webrat configure block.

Create the spec/integration folder and file

Write the integration test

Now you are ready to write your first integration test using webrat. We are going to test some basics from the people scaffold we created. Edit spec/integration/people_spec.rb, make it look like the following, and run 'rake spec' again. You should receive the response back '5 examples, 0 failures'.

What is going on here?

The majority of the above code is your standard rspec (before(:each) blocks, describe blocks, it "should do something" blocks, etc). The webrat methods we are using are 'visit' and 'response'.

visit simulates an actual user visiting your website. You don't see it happen, but webrat is actually (sort of) visiting the site just like a normal user would in their browser. To visit other pages just do visit '/your/path'.

After the visit command is employed, webrat returns a response from the webpage. This is essentially the http response a visitor's browser would receive. Here we are checking the response.status to verify it returned a 200 OK. To inspect the available response options use 'puts response.inspect'.

Now let's test that the response contains certain text. You can use webrat's have_selector or have_xpath methods to determine this. In fact, most of the time with webrat those are the methods you will be using in conjunction with visit and response. Let's check that the people/new page contains the correct form fields.

Depending on how you built your scaffold all these tests will pass or you might get 2 failures back. I got two failures. Let's fix those two errors by adding the appropriate form fields to our views/people/new.html.erb file. It should look something like the following.

Great work. You've already created 8 specs to test your application. Now just repeat the process while consulting the rspec docs andthe webrat docs, and before you know it you will find testing a joy and a valuable addition to your programming knowledge. Good luck, and you should follow me on twitter here if you have questions.

Also, the example app I built along with this tutorial is here on github.

Sdruby Presentation on Titanium-Mobile

Mon Sep 07 09:37:28 -0700 2009

Sdruby Presentation on Titanium-Mobile

Here are my slides from my sdruby presentation on Titanium Mobile.

Slides

Overview

For this presentation I covered getting started with Titanium mobile. Plus, I included example javascript code from the app I am currently building.

You should follow me on twitter here

Counter Caching with MongoMapper

Sat Aug 29 00:11:46 -0700 2009

Counter Caching with MongoMapper

MongoMapper makes column based counter caching simple. I think you'll be delighted.

What is counter caching?

Counter caching is a way to display the record count (or total - using the term loosely) for a has_many assocation. Ryan Bates did a screencast on it and many apps today employ counter caching. (aside: You should be doing things like counter caching before you just go and grab memcache.)

For example, I am building an application that keeps track of pilots' flights. A pilot is able to log their flights, and the application returns their total flights count. At first I displayed this value using Flight.count(:user_id => id) in the view. This was ok at first, but once a pilot had one thousand flights, page load times were noticeably longer so I added a counter cache column.

Counter caching works well. I received some significant speed improvements.

Ok, let's get on it with it.

How to setup counter caching in MongoMapper

Scenario

I want to store the sum of a column in a cache. In my application a User has many Flights, and each flight has fields like hours, landings, night_hours, etc. I want to have methods like @user.total_hours, @user.total_landings, and @user.total_night_hours that cache themselves so my app can get similar speed advantages like you saw above.

To do this, I:

Added @user.total_something instance methods to my User model.
Added callbacks in my Flight model to clear the cache whenever the pilot adds/updates/destroys a flight.

Step #1: Add the instance methods to User.rb

Step #2: Add the clear cache callbacks to Flight.rb

That's it. You're done. You can now use @user.total_hours, @user.total_landings, etc in your views and your app will stay snappy.

Conclusion

Counter caching with MongoMapper ended up being just 14 lines of code. You don't have to hassle with migrations and you can meta-program your schema into the model. (Thanks to John Nunemaker for building it that way. Thought: I really don't like the way ActiveRecord uses migrations. Plus, it decouples the schema from the model.). It works with floating point numbers too.

Keep updated at twitter.com/spitfiresky

Recap of my sdruby presentation on mongodb

Fri Aug 07 09:30:06 -0700 2009

Recap of my sdruby presentation on mongodb

Here I recap my presentation on mongodb at sdruby last night.

Slides

Introduction

I am using mongodb on Twinstang redesigned. I started with couchdb, but encountered difficulties grasping the concept of map/reduce for more powerful but necessary querying.

Because of this limitation in my skills (and partially because couchdb is limited to doing map/reduce on your documents and cannot do an additional map/reduce on top of a previous map/reduce) I began running into barriers in development of features for my app, and I foresaw more issues on the way.

I switched to mongodb using MongoMapper and have been super satisfied.

Dynamic queries are a welcome return
There is a good balance of speed, features, and schema-less freedom
It should scale better than mysql with less effort
MongoMapper makes it a pleasure to work with

Installation & Running it

Installation of mongodb is from source but is quick and painless. After installation type sudo mongod run to run mongodb. You will probably want to use something like monit or god to monitor the process.

Mongo vs Couch

Couchdb is really cool and I can't say enough how much I've enjoyed it - especially the concepts it is pushing. It has huge potential to open up applications to the masses with its embedded apps. It is essentially a framework and server rolled into one. And it has convinced me that the language of the future is javascript. Furthermore, it's idea to run apps in the browser locally and then replicate/sync is mouthwatering. There are a lot of promises and hopes.

However, map/reduce is difficult to grasp and couchdb's map/reduce feels like a neutered version. How come I can't do map/reduces on already built design documents? In the end, couchdb left me somewhat disappointed. It was wrong for my app but was so exciting. I will be using couchdb in the future to build simple api based web apps that users can hook into.

Mongodb on the other hand feels more traditional. It is not trying to shake things up. Instead, Mongodb accomplishes its main goal very well - to bridge the gap between key/value stores and sql databases. It's fast, is focused on solving scaling issues that have haunted mysql, and it maintains the ease of use and power of dynamic queries.

Use mongodb for your traditional web app - where your users are doing a lot of updates but where you are generally controlling the interface and features. Use couchdb for focused web apps that are mostly an api or web hook and where your users are controlling the interface.

Mongodb (C++)	Couchdb (Erlang)
drivers (php driver, ruby, python, and more)	REST (very cool, but slightly slower. not really slower in practice though - except when it comes to replication as a tool to scale)
bson, document, schema-free	json, document, schema-free
Dynamic queries, indexing (familiar, and great for development time. it works.)	map/reduce (needs a way to do map/reduce on a design document - essentially a map/reduce on top of a map/reduce)
gridfs (needs an nginx/apache module. using send_data through an app or even through rack is too slow. however, supposed to be comparative to S3 if a module becomes available)	embedded attachments (think email attachments. i really like the way couchdb handles attachments)
RAM	http cache
Good at the web, faster development time (dynamic queries are what we are used to User.first(:login => 'jennifer'))	Good at the web, slower development time (because of map/reduce and you have to construct all your queries from javascript)
Update in place (good for high update rates)	MVCC (fault tolerant, but requires compacting.)
master-master (auto-sharding is under development and planned. which should make things quite easy to scale. *thanks Mark)	replication (great for peer shared apps, but will be slow for large traditional web app databases replicating across servers - it's http)
50s kid (Traditional, yet rock n' roll, fast cars. Feels comfortable yet feels like the future. good for traditional web apps)	indy kid (Untraditional, crazy cool ideas (like embedded apps and running in your browser), but uncertain. better for untraditional web apps right now)

Mongodb orms

If you are a rubyist use MongoMapper. Hands down it's the best orm. It basically makes the driver easy to use and familiar with rails/merb.

Using MongoMapper

Installation

sudo gem install mongomapper

config.gem 'jnunemaker-mongomapper'

dependency 'jnunemaker-mongomapper'

Model

Controller

Validations

Callbacks

Relationships

Embedded Documents

Additional info

created_at and updated_at are included automatically by MongoMapper
_id cannot currently be set with MongoMapper like it can in Couchrest
cannot currently do @doc[‘custom_field’] like in couchrest.
indexing: @doc.ensure_index :login

Conclusion

Overall, I think mongodb with mongomapper is a smart way to go for a traditional web apps that are somewhat complicated (think facebook, basecamp, social networks) where you are providing an interface for your users to put information and then doing all kinds of things with that information.

I think couchdb is more suited to simple applications with express purposes (think blogs, a 'twitter' of your friends, apis) and where replicating that data from computer to computer and going offline is important.

You should follow me on twitter here