Paul's Software Blog

Resources for Beginning iOS Development

2015-01-11T19:42:00.000-08:00

Recently, a coworker was interested in learning iOS development and asked me to recommend to him a few resources for learning and I thought that I would also share this here.

Here are a couple resources for learning iOS:

Intro Books

1. iOS Programming: The Big Nerd Ranch Guide (4th Edition) - This book only covers iOS 7 and Objective-C, but a lot of the same concepts will apply in iOS 8. This would be good intro to iOS and also learning Objective-C. Some of the text might be out of date since the Xcode UI has changed a little bit. I originally started learning with the Beginning iPhone Development book (below), and I read this one after; I thought that the Big Nerd Ranch book went in to more in depth on almost all the topics and I was able to pick a few tips on how to better structure my code.

2. Beginning iPhone Development with Swift: Exploring the iOS SDK - This book is also gives a good intro to iPhone development, but this one is written for iOS 8 and is in Swift if you want to skip the Objective-C part.

Learning Swift

1. I recommend just reading Apple's book on Swift to learn the language. It's available in iBooks here and on the web here.

2. There is also a second part of the book above that covers using Swift with Cocoa and Objective-C, which goes into more advanced topics but is a good follow up read after reading the first part. The iBooks link is here.

A common question I see is should I learn Swift or Objective-C? I think that if you are looking for a job as a iOS developer, you will need to learn both because most likely the company/client already has existing code that is in Objective-C. You can mix and match Swift and Objective-C code, but you need an understanding of both to do so. If you are able to develop an app from scratch, you can probably get away with only learning Swift. It is also good to point out that the 3rd party library support for Swift is very weak right now, so if you don't mind reinventing the wheel (a good way to learn) then this is the way to go. You can also always refer to open source libraries written in Objective-C and convert them to Swift yourself (another benefit for learning both languages).

Other resources (tutorial sites and blogs)

1. http://www.raywenderlich.com/ - This site has a lot of useful tutorials for not only beginners but also intermediate and advanced iOS developers. When I was first starting out, I frequented this site and tried to do as many tutorials as I could. Even still today, I find myself visiting this site to continue learning.

2. http://nshipster.com/ - This iOS blog is written by the creator of AFNetworking and has a lot of in depth articles on Cocoa, Objective-C and Swift topics that are commonly overlooked.

3. https://iosdevweekly.com/ - This newsletter is a great way to get a pulse on the iOS community. I've been able to learn about a lot of useful tools and libraries from this weekly email.
4. WWDC videos (all years) - The videos from the WWDC presentations are extremely useful, but can be quite advanced and dry sometimes. If you are unsure of what the best practice of doing something is, I would recommended these videos; It's also a great way to learn about the new things that were introduced in every new version of iOS. Also see ASCIIwwdc.

Hopefully this is a good enough start. There is also always the Apple docs (sometimes confusing and hard to find), Google and Stack Overflow. Good luck!

Productivity Tools

2014-12-30T11:02:00.001-08:00

There are several tools that I use daily to help improve my productivity not only as a developer, but also as a regular computer user. I think it is important to share these types of tools, interesting tidbits, or libraries on a weekly basis because there are just so many new things being created all the time.

For example, I went to a few Ruby on Rails meetups and the first item on the agenda was always "Sharing of Tools and Tips"; here people would share new Ruby gems they had discovered or even share their experiences in solving a recent problem. Another great example is the Ruby Rogues Podcast where after every show, each speaker has picks that they share with the group; these picks aren't always technical, but it's a great way to be cognizant of what is out there. At my current job, we have tech talks every Thursday, but before we start, I reserve 10-15 minutes for sharing of tools and tips or just anything that people found interesting for the week. Usually atleast one thing of interest comes from it, and I think just that makes the entire exercise worth it.

Here are my picks:

1. BetterSnapTool

Ever need to compare two windows side by side, but find it a pain to resize and arrange them all the time? BetterSnapTool makes this simple, and can snap windows to any side you want with just a keyboard shortcut. You can also define custom hotspots where if you drag a window to it, it will resize that window to a custom size that you previously specified. This is a paid tool, but I know that there are probably similar tools that are free.

2. Alfred

Alfred allows you to do a lot of things from your fingertips. With a keyboard shortcut, it launches a spotlight like prompt that lets you search for files, launch applications, and even do arithmetic. I have to admit, I have been using this a lot less lately because the new spotlight in Mac OS X Yosemite is quite good. But I use to use this to launch all my development apps after logging in. You can also launch gmail straight from the prompt. I haven't explored this yet, but there is a PowerPack that you can purchase that allows you to define custom workflows. For example, I could define a development workflow, and it would allow me to launch all of my developer applications with one keyboard shortcut.

3. Timeout

I've built a lot of bad habits when using computers since I was young; I use to sit at the computer for 8-12+ hours straight and not take breaks. This has caused me a lot of eye and hand problems as I grew older, and I learned that it is REALLY important to take regular breaks from the computer. This tool helps remind me to take 10 second breaks, every 20 minutes, and 10 minute breaks every 60 minutes. This is all customizable as well. An important exercise I learned from my optometrist is the 20/20 rule, which is every 20 minutes, take a 20 second break and look at something atleast 20 feet away.

3. Evernote

A little more heavy weight than the default Notes app, but I like it because I can type up notes for a presentation on my laptop, and then access these same notes on my phone during the presentation. You can also categorize your notes in to notebooks, which has been useful because I create a lot of notes.

4. zsh and the oh-my-zsh plugin

I've mostly just used bash shell since it is the default on Mac OS X, but I recently decided to try zsh because I've heard a lot about it. There are a few nice features in zsh that bash doesn't have, but I wouldn't say anything ground breaking. To list a few:

Inline glob expansion: For example, type rm *.pdf and then hit tab.
Interactive path expansion: Type cd /u/l/b and hit tab.
Customizable prompt configuration options.

What I enjoy the most is what the oh-my-zsh plugin offers. The plugin basically offers a nice way to manage your zsh configuration, but it comes a ton of built in plugins and themes. I mainly just use a theme and a git plugin (which can probably be done in bash too with aliases), but it is still definitely worth checking out. I am sure that I am only scratching the surface. Here is my zsh config if you would like to take a look.

5. Animated Tabs for Chrome

Lastly, I wanted to show an anti-productivity tool that I use quite often in Chrome. Usually I'll want to search for something, so I'll open a new Chrome tab and then I'll see some funny animated gif and then forget what I was doing and even what I was searching for. Although this interrupts my productivity during the day, sometimes it is nice to take a little break and laugh :).

Here are a few other tools that have been recommended to me by colleagues, but I just haven't had a chance to check them out yet:

Fluid App
Caffeine - Prevent computer from going in to screensaver or turning the display off on battery. This is useful for Skype calls or meetings where you're watching someone else's screen but not interacting with your computer.
Dash - For local copies of documentation for various platforms and libraries. Its nice having a local and searchable copy.
LastPass - For account management
Pauses - An alternative to Timeout
Flycut - Clipboard manager
Filedart - Speedy file sharing

Git Merge Workflow on Github

2014-11-15T14:23:00.000-08:00

How to Merge Code

Below is a guide that I wrote for a recent project explaining a git merge workflow on Github. Often times, when you develop a new feature, you will create a new branch off of master called a feature branch. On the feature branch, you might have many commits to save your progress, or when you complete certain milestones of that feature. Once you finish the feature, you will want to merge this branch back to the master branch. However, you might not want all your commits to show up in the git log history because they were only for development purposes. We can overcome this issue by using a feature of git called interactive rebasing which allows you to squash certain commits and customize the commits that will eventually show up once the branch is merged to master. I have described the steps to achieve this outcome below.

Purpose

This guide explains how to develop and commit your code using git and GitHub. A developer should create a feature branch when developing new code. In the feature branch, a developer may commit multiple times during development including making changes based on comments from a code review. When development is completed and the feature branch is ready to be merged in to the master branch, the developer should squash the commits in to one, so that the git log history is kept clean.

Detailed Steps

1. On the `master` branch, `git pull` to make sure your code is up to date.

2. Create a feature branch `git checkout -b name-of-feature-branch`. Note, you will automatically be switched to this new feature branch you are creating.

3. Write code and develop your feature.

4. `git commit` your code. Note, this step may be performed as many times as you prefer during development in order to maintain a history of your code changes.

5. Once development is completed (and all your code is committed), we should make sure that our code is up to date with the latest `master` branch. On your feature branch, `git rebase master` will ensure that your branch is up to date and your code is compatible with the latest `master`. Also this step ensures that your commits are at the top, which is critical for the next steps. Note that, during the rebase, you may encounter merge conflicts that will need to be resolved.

6. Now we need to push our code to GitHub. `git push origin name-of-feature-branch` (while on the name-of-feature-branch branch) to push the branch to GitHub.

7. In GitHub, create a pull request for the name-of-feature-branch branch and assign someone to review your code.

8. If the reviewer makes comments or suggestions, please address them by asking for clarification and/or committing the changes. The reviewer also needs to give approval on whether or not the code is ready to be merged.

9. Once the code is ready to be merged, it is time to squash your commits. Note, this doesn't apply if you only have one commit to merge, and in that case you can just merge your pull request on GitHub. First we need to know at what point your branch and master diverge. This is required as you only want to squash your commits.

10. To do this run `git merge-base master `. This command should spit out a commit hash such as _918310dca623fac2d46198324814695c4726017e_. You will then use this hash to tell git "_squash the commits from this point on_".

11. Once you have your merge base commit run `git rebase -i `, for example: `git rebase -i 918310dca623fac2d46198324814695c4726017e`.

12. Your text editor should popup and you should see your commits with the word `pick` in front of them. For all commits except the first one, change `pick` to `squash` or `s`, which will squash all of these commits in to one. Now save and quit your text editor.

13. Another text editor window should pop up now, and here you can enter the commit message you would like to show up. This commit contains all of your commits squashed together.

14. In order for this to work with your existing GitHub pull request (because we are rewriting the git log history), we need to `git push origin name-of-feature-branch -f`, which forces the push to overwrite the git log history in that pull request.

15. You should see that on your GitHub pull request, the history should only contain the one commit that you squashed.

16. Press the Merge button, and don't forget to delete your remote feature branch!

Additional Reading

Coding Styles and Standards

2014-08-19T08:45:00.003-07:00

One of the main reasons for having coding standards is to keep your code readable by everyone. By enforcing standards and formatting, the code base becomes consistent, and anyone can easily understand the structure of the code because he will be more familiar with what to expect. It is also very useful when a new developer joins the team because once he is familiar with the patterns, he will be able to easily read the existing code, which results in a more pleasant experience.

In this example, I will define coding standards for an iOS project (which uses Objective-C). We will take advantage of the fact that code formatting can be automated in XCode by using a plugin. The coding style that I chose is based on the Chromium style guide, but I made a few modifications, which can be found in the `.clang-format` file. Feel free to make changes as you see fit; All of the options are defined here LLVM Coding Standards.

Installation
1. Install Alcatraz, the package manager for XCode.
`curl -fsSL https://raw.github.com/supermarin/Alcatraz/master/Scripts/install.sh | sh`
2. Select `Package Manager` from the `Window` menu and search for `ClangFormat` and install that plugin.
3. Select `Clang Format` from the `Edit` menu, and click on `File`. This will load formatting settings from the `.clang-format` file that is located in the repository.
4. When you want to format a file, go to the `Clang Format` menu and select `Format File in Focus`. You can also enable `Enable Format on Save` to have the plugin automatically format the file when you save it. You can also bind formatting to a keyboard shortcut, refer to the ClangFormat homepage for more options.

Additional Standards

The automatic code formatter does not implement all the standards we would like to follow. There are some standards that need to be enforced by the developer himself because they can't be automated. Please refer to https://github.com/paulsfds/objective-c-style-guide to see some examples.

Other Languages

Coding standards are universal and there exists some popular ones for other languages. I would also suggest searching on Google for popular standards for your favorite language. Also, many well established companies such as Google have their own coding standards that are available to the public. Here are a few popular ones to take a look at:

JavaScript

Ruby

Objective-C

C++

What are your favorite coding styles and standards?

Upgrading Your iPhone App to iOS 7: The New Status Bar

2014-02-03T20:38:00.002-08:00

Hi everyone,

It's been a while since I last blogged. I've been neglecting my blog posting duties, but I hope to start posting more here this year. I've picked up iOS development in the meanwhile, so I'll be posting some posts on that topic in addition to the usual Ruby on Rails ones.

I'll start with this post that I wrote for work: http://blog.grio.com/2013/10/upgrading-your-iphone-app-to-ios-7-the-new-status-bar.html

Ruby Metaprogramming with class_eval

2012-04-19T20:00:00.000-07:00

One of the really cool and exciting aspects of using a dynamic programming language like Ruby is that you can generate code dynamically at runtime. Yup, you heard me, at runtime. Try doing something like this in Java. This is one of the features that allows all the magic that happens behind the scenes in Ruby on Rails possible. For example, this is how Rails' attr_accessor automatically creates getters and setters for you. If you don't remember, you can call attr_accessor in an ActiveRecord class to define a "virtual" attribute, or in other words an attribute that isn't persisted in the database table. I want to explain this idea in more detail by creating a new method called attr_accessor_with_history, which is similar to attr_accessor, but it will also store the attribute's history. Say we have the following class:

class Test
   attr_accessor_with_history :sample
end

Then this is how the attr_accessor_with_history method should work in the Ruby console:

t = Test.new
t.sample = "test"  # => "test"
t.sample = 1       # => 1
t.sample = :abc    # => :abc
t.sample_history   # => [nil, "test", 1, :abc]

So how can we do this? Let's first create a new file called class.rb and put the following inside:

class Class
   def attr_accessor_with_history(attr_name)

   end
end

By defining our method in the class Class, all Ruby classes will be able to use it. This is because in Ruby, all classes are an object of the class Class. You can find more information in the API here. The second thing we want to know is that Ruby provides a method called class_eval, which takes a string and evaluates it in the context of the current class. So in our example, the class Test is calling our method, so when class_eval is called, it will be evaluated as if it were called in the class Test.

Let's take care of the easy part first, which is creating the attribute's getter methods. This is pretty straight forward because we don't really need to do anything special here.

class Class
   def attr_accessor_with_history(attr_name)
      attr_name = attr_name.to_s         # make sure it's a string
      attr_reader attr_name              # create the attribute's getter
      attr_reader attr_name + "_history" # create bar_history getter

      # write our setter code below
      class_eval %Q(
                  def #{attr_name}=(attr_name)
                  end
                 )
   end
end

The %Q is Ruby syntax for an interpolated string, which allows us to create a string, and it will also interpret Ruby values such as anything in #{}. So in thinking about how to define our setter, we need to store the previous history of the variable. How can we do this? Well we can store stuff in an Array. If we push things in to the Array like a Stack, we can also figure out the order in which things were inserted. The one thing we need to be careful about is the initial case where we should initialize the array, and also insert the first value as nil. This is what we get:

class Class
   def attr_accessor_with_history(attr_name)
      attr_name = attr_name.to_s         # make sure it's a string
      attr_reader attr_name              # create the attribute's getter
      attr_reader attr_name + "_history" # create bar_history getter

      # write our setter code below
      class_eval %Q(
                  def #{attr_name}=(attr_name)
                     @#{attr_name} = attr_name

                     unless @#{attr_name + "_history"}
                        @#{attr_name + "_history"} = []
                        @#{attr_name + "_history"} << nil
                     end

                     @#{attr_name + "_history"} << attr_name

                   end
                 )
   end
end

First we set the value of the variable. Second, we check if the _history array has been initialized yet, and if it hasn't, then go ahead and initialize it. Lastly, we insert the new value into the _history array.

That was just a quick example of some of the cool things you can do with metaprogramming in Ruby. I want to end by showing a real world example of how I used metaprogramming on a project I'm currently working on. If you haven't read my previous blog posts, I'm working on a Rails site using MongoDB (with the Mongoid gem) that deals with computer games. I have a class called Event, and I need to define some scopes based on the game type so that I can do queries such as Event.all.starcraft2, which would return all Events that have a game attribute of 'starcraft2'. I could easily hard code these scopes, but it will be annoying to always have to add a new scope every time we add support for a new game. Instead I can dynamically create these scopes using Ruby metaprogramming.

  class_eval %Q(
              #{Constants::GAMES}.each_pair do |key, value|
                scope key, where(game: value)
              end
             )

First I need to explain the Constants::GAMES variable. I created a dynamic_fields.yml file that stores all the games that my application supports. Please refer to my previous post here for more detailed information. So when my application loads, it reads in that YML file into the Constants::GAMES variable, which is a hash. The key is the game name as a symbol, and the value is the game name as a string. For each game, it will create a scope with the same name (as the game), and it does all of this automatically. I could have wrote a line of code for each game, but this is much cleaner to write and easier to maintain in the future.

Installing and compiling Ruby from the source code

2012-04-06T15:22:00.000-07:00

There are several different ways to install Ruby with the most popular being RVMand rbenv. Both have their advantages and disadvantages, but rbenv is a newer and more "lightweight" Ruby installer. I'll let you Google the differences between RVM and rbenv if you are more curious. I decided to install Ruby by downloading the source code and then compiling it myself. I'll be installing Ruby 1.9.3-p125 (the latest version as of writing this) on Debian Linux 6 (Squeeze).

1. First we need to install some development tools and libraries that Ruby needs to compile. Run the following commands from your terminal:

   apt-get install build-essential vim git-core curl

   apt-get install bison openssl libreadline6 libreadline6-dev zlib1g zlib1g-dev libssl-dev libyaml-dev libxml2-dev libxslt-dev autoconf libc6-dev ncurses-dev

   apt-get install libcurl4-openssl-dev libopenssl-ruby apache2-prefork-dev libapr1-dev libaprutil1-dev

   apt-get install libx11-dev libffi-dev tcl-dev tk-dev

Note you may need to run these commands as root or use sudo.

2. Download the latest version of Ruby here: http://www.ruby-lang.org/en/downloads/ under the Compiling Ruby — Source code section.

3. Extract the tar.gz file e.g. ruby-1.9.3-p125.tar.gz by typing:

tar -xvf ruby-1.9.3-p125.tar.gz

4. Open the README and follow the instructions on how to compile and install Ruby.

./configure
make
make test
make install

The install process will probably take a while, but once it's done, we can test to see if ruby installed successfully by typing "ruby -v" in the terminal. You should see something like, "ruby 1.9.3p125 (2012-02-16 revision 34643) [i686-linux]" if ruby installed correctly. Next we can install the Bundler and Rails gems to make sure Ruby is working correctly.

gem install bundler
gem install rails

Lastly, create a new Rails project to test to make sure everything works!

Dynamic attributes and MongoDB/Mongoid

2012-03-07T00:39:00.000-08:00

I recently started learning more about MongoDB, and how to use it in Rails 3.1 with the Mongoid gem. MongoDB is not your typical relational database; It is considered a NoSQL database because it stores your data in one huge JSON document instead of a bunch of relational tables. Actually, instead of storing the data in JSON, it stores it in BSON (Binary JSON) for performance reasons. The really cool thing about MongoDB is that it is schema-less, which allows you to store non-homogeneous objects in your database.

Why is this cool you might ask? Well let me explain my problem; I want to create a web service that allows CRUD operations on objects called Events. Events have a name, start_time, and most importantly a game. Depending on the game attribute, each Event will have different game specific attributes. For example, I have an Event with a game value of 'starcraft2'. Only Starcraft 2 Events have a region and a league attribute, while League of Legends Events have a min_elo attribute. How can we store these Event objects that have different attributes in our one document? We could do this in a standard MySQL database, but our table would be very wide, meaning we would have to have a column for every game specific attribute. This isn't very ideal because for each row, there would be a bunch of columns that wouldn't be used depending on the game.

The great thing about Mongoid is that it supports dynamic attributes. I quote this from their website, "By default Mongoid supports dynamic fields - that is it will allow attributes to get set and persisted on the document even if a field was not defined for them." This sounds like exactly what we need. We can just define the common Event attributes in the model itself, and then specify the game specific attributes at run time. So how do we go about doing this? Well, let's start with the Event model:

class Event
   include Mongoid::Document

   field :name, type: String
   field :start_time, type: DateTime
   field :game, type: String
end

This is pretty straight forward. Now the way I chose to define game specific attributes is by defining them in a YML file. I created a file called dynamic_fields.yml and put it in the Rails.root/config folder. Here is how I defined it:

starcraft2:
   attributes:
      regions:
         name: regions
      leagues:
         name: leagues

You can define your dynamic attributes however you want, but this is just how I decided to do mine. So now that we have our Event model, and our Starcraft 2 attributes, how do we set these when an Event gets created, and how do we make sure these attributes only get set if the game is Starcraft 2? First we need to understand what mass assignment is, and how it could be a security vulnerability. Here is an excellent RailsCasts on that topic, but the gist of it is that when the server receives a POST request to create a new Event, it will take the parameters it receives and mass assign themto the matching attributes of the Event model. For example, if we had a User model, and a is_admin attribute, the user shouldn't be able to set the value of the is_admin attribute. If they could, then everyone could make themselves an admin when they create a new account. So how do we prevent this? In Rails there is a very useful method called attr_accessible that we can set on attributes in our model. Only the attributes you set using attr_accessible will be available for mass assignment. So let's do that for our Event model for all the common fields:

class Event
   include Mongoid::Document

   field :name, type: String
   field :start_time, type: DateTime
   field :game, type: String

   attr_accessible :name, :start_time, :game
end

This reason this is so important, especially in Mongoid is that since we enabled dynamic attributes, a user can create an Event with any additional attributes they want. They can add an attribute called "some_random_field" by including it in the POST parameters and it would be inserted in our database no questions asked. By setting attr_accessible on name, start_time, and game we are saying users can only set the values for these attributes and that's it. But there's a problem now, how do we set the values for our game specific attributes?

Good thing for us, we can dynamically set attr_accessible thanks to this great RailsCast here. I'd recommend just watching the RailsCast to learn how to do this, but I want to mention that there are a couple changes that need to be made. The RailsCasts was filmed using Rails 3, but now that Rails 3.1 is out, we need to make some minor changes.

class Event
   include Mongoid::Document

   field :name, type: String
   field :start_time, type: DateTime
   field :game, type: String

   attr_accessible :name, :start_time, :game

  # :accessible is a variable used to store the game specific dynamic fields so that they can be set through mass assignment via attr_accessible. this allows the attr_accessible to be set dynamically.
  attr_accessor :accessible

  private
  # Overrided so that extra variables can be added to the attr_accessible dynamically to allow mass assignment.
  def mass_assignment_authorizer(role = :default)
    super + (accessible || [])
  end
end

We can now use the accessible variable in the EventsController to dynamically allow mass assignment of game specific attributes. The accessible variable is actually an array, and anything we put in that array will be added to attr_accessible since we overrided the mass_assignment_authorizer method.

One last detour before we get to the final step. We first need to figure out how load the YML file that contains our dynamic attributes in to memory so that we know what attributes to add to attr_accessible. I want to load the dynamic attributes in to a global variable so that we can use it during the lifetime of the server. To do this, we can create a file called event_config.rb in our Rails.root/config/initializers folder. Whenever the rails server starts up, it will automatically load all the files in the initializers folder. We can load the YML in to memory by calling YAML.load() and passing it a file.

module EventConfig
  DYNAMIC_FIELDS = YAML.load(File.open("#{Rails.root}/config/dynamic_fields.yml"))
end

Great, now we can access the DYNAMIC_FIELDS variable anywhere in our code. We have all the tools we need, so let's just jump right in to it. The DYNAMIC_FIELDS is a hash of what is defined in the YML file. So we can iterate through it by accessing the 'starcraft2' key, and then that will return another hash. Inside the 'starcraft2' hash we can acess the 'attributes' key, which will give us another hash that contains the attributes we want. Then we can just iterate through the attributes hash's keys to get the attributes we want to set to be mass assignable.

def create
   # we don't want to pass in the params right away because 
   # we have to set the accessible variable first
   @event = Event.new

   # the keys of the attribute hash are the game specific attributes 
   # we want to be assignable, so set the accessible variable to them
   game = params[:event][:game]
   @event.accessible = EventConfig::DYNAMIC_FIELDS[game]['attributes'].keys

   # lastly, set all the other attributes for the event using the params
   @event.attributes = params[:event]

   respond_to do |format|
      if @event.save
        format.html { redirect_to @event, notice: 'Event was successfully created.' }
      else
        format.html { render action: "new" }
      end
    end
end

That's it! It should work now, but how can we test this really easily? We can test it by using a tool called curl, which allows you to generate and send HTTP requests from the console. The most common use case will be a user filling out a form to create an Event on our server. Curl has a -F parameter, which we can use to emulate a filled-in form and it will send a HTTP POST request to the server.

curl -F 'event[name]=curlTest' -F 'event[game]=starcraft2' -F 'event[regions]=North America' -F 'event[leagues]=Grandmaster' 'http://localhost:3000/events'

This should successfully create a new Event object in our database! We can also test to make sure that our attr_accessible is working correctly by not letting users set attributes that they shouldn't be setting. For example, we can try this:

curl -F 'event[name]=curlTest' -F 'event[game]=starcraft2' -F 'event[regions]=North America' -F 'event[leagues]=Grandmaster' -F 'event[some_random_field]=should not get assigned' 'http://localhost:3000/events'

In the rails server log, you should see this error message, "WARNING: Can't mass-assign protected attributes: some_random_field." And we can see that it did create the Event, but without the some_random_field attribute.

That's it, you are all set and ready to go! I hope that this post was helpful in understanding how dynamic attributes can be a cool and useful feature for your projects. Good luck, and until next time.

Rails 3.1 testing with RSpec, Paperclip, and Mongoid

2012-02-15T16:51:00.041-08:00

Coming in to this, I did not know much about how RSpec testing worked. I watched a couple of RailsCasts (here and here) to obtain a quick primer on the subject, but I still felt like it was not enough. So I decided to write this blog post in hopes that it will help anyone else who has had the same troubles as me. After watching the RailsCasts, the first thing I did was set up my test environment by installing the RSpec, FactoryGirl, and Guard gems. I will be writing tests for a model called Event and here is the basic structure of it:

class Event
   include Mongoid::Document
   include Mongoid::Paperclip

   field :name, type: String
   has_mongoid_attached_file :banner_image,
                 :storage => :s3,               
                 :s3_credentials => "#{Rails.root}/config/amazon_s3.yml",                
                 :s3_permissions =>'public-read',                
                 :s3_protocol => 'http',               
                 :s3_headers => {'Expires' => 1.year.from_now.httpdate},                 
                 :url => ':s3_alias_url'

   validates_presence_of :name, allow_nil: false
   validates_length_of :name, minimum: 1, maximum: 50, allow_blank: false
   validates_presence_of :start_time, allow_nil: false
end

So if you installed RSpec before creating this Event model, it should invoke an RSpec generator to automatically create the file Rails.root/spec/models/event_spec.rb, but if you installed RSpec after the fact, then just create the file manually.

require 'spec_helper'

describe Event do

end

So what are the most basic kinds of things that we can test in the model to start off? The easiest things I have found to test first are the model validations. The RSpec syntax is meant to be very human readable as you will see. The first validation to test is the mandatory presence of the name field. First we want to create a mock Event object to test with; we can do that by using FactoryGirl. To set up FactoryGirl, create a factories.rb file in the Rails.root/spec folder. This is where we will define what mock Event objects will look like, like so:

FactoryGirl.define do
   factory :event do
      name 'TestEvent'
      start_time { Time.now }
   end
end

Basically all our mock objects will have the name 'TestEvent' and a start_time of right now. There are many more advanced options and features in FactoryGirl that are available (here), but for now let's keep things simple.

Now back in the event_spec.rb file, I'll create a test called "should require a name", which will test that our validates_presence_of :name is working correctly. First, we need to use FactoryGirl to create a mock Event object. We can do this by calling FactoryGirl.build(:event). Notice that I am using the build method (creates an object, but does not save it to the database), rather than the create method (creates an object, and does save it to the database). We actually want to test that an Event object without a name should not be valid. So to create a mock Event with no name, we can actually set the Event's name by passing it in like so: FactoryGirl.build(:event, :name => nil). Putting this all together we get:

describe Event do
   it "should require a name" do
      event = FactoryGirl.build(:event, :name => nil)
      event.should_not be_valid
   end
end

The rest of the validation tests are similar and straight forward. I want to move on to the controller RSpec tests next. If this file is not already created, you should create it here Rails.root/spec/controllers/events_controller_spec.rb. Initially I had a lot of trouble trying to figure out how to write tests for the controller, but I came across a book called Rails Test Prescriptions: Keeping Your Application Healthy that was quite helpful. Now I didn't buy or read this book, but I downloaded the free sample code from the book here, and it contains some great examples of how to write simple tests for your basic CRUD controller methods. If you're interested in looking at the code, it is located in huddle3_rspec2/spec/controllers/projects_controller_spec.rb.

Let's start with a simple test of making a GET request on the index method of the EventsController. Just like in the model tests, we want to create some mock Event objects by calling FactoryGirl.create_list(:event, 10), which will create 10 mock Event objects. Now when we perform a get :index in the test, it's going to run the code that we have in the controller. Looking at the index method, we can see that in order to get all the events, it calls @events = Event.all, which is great for regular use, but not so much for testing. During testing, we would like to have a controlled environment where we can control the data being returned. We can accomplish this by something called method stubbing. Method stubbing allows you to intercept method calls within a function (so the method in question will not actually be called), and allow you to return whatever data you want. Luckily, this is very easy to do in RSpec. Here is the code:

describe EventsController do
   describe "GET index" do
      it "should assign all events as @events" do
         events = FactoryGirl.create_list(:event, 10)
         Event.stub(:all).and_return(events)

         get :index

         assigns(:events).should eq(events)
      end
   end
end

Let's walk through this code. First we create 10 events that we are going to make the Event.all method return. Then we actually stub the :all method so that it returns the events we created. Now in order to invoke the controller code, we need to send a GET request to the index method, which is what get :index does. Finally, we need to check to make sure that the @events variable (in the index method in the controller) gets correctly set to what we expect it to be, which are the Events we created with FactoryGirl. The assigns() method in RSpec allows you to access the instance variables (variables with an @ in front of it) of the controller. This test should pass because we stub out the :all method and therefore the @events variable gets set to the 10 events that we created in the beginning.

Now that we've had a crash course in RSpec, we can write a test to test if file attachments are working correctly with Paperclip. Before we start, I need to mention that Paperclip comes with RSpec matchers, which allow you test Paperclip specific attributes such as should have_attached_file(:file). This is great, but when using Mongoid, we have to use the mongoid-paperclip gem, which does not support these matchers. I did some research on Google and Stackoverflow, but I could not find a clear cut answer. So what I decided to do was just test if the object had the Paperclip fields defined and were set. When you define a Paperclip attachment in a model, it will create several fields for you. For example, if my Paperclip attachment is called :banner_image, then it will create the following fields in your model automatically: :banner_image_file_name, :banner_image_content_type, :banner_image_file_size, and :banner_image_updated_at; I wanted to test to make sure that these fields were not nil. Now you can just put these checks directly in to your test, but I wanted to be able to reuse these file checks without copying and pasting code. We can do this with something called RSpec Matchers, which allow you to define conditions that get tested after the should method. I won't go in to too much detail about them here, but you can watch this Railscasts for more information. I created a file called banner_image_matcher.rb in Rails.root/spec/support/matchers and put this inside:

# An RSpec matcher used to test the banner_image file attachment of the Event model. It tests whether the Paperclip fields for file attachments exist or not.
RSpec::Matchers.define :have_banner_image_attached_file do |expected|
   match do |actual|
      actual.banner_image_file_name != nil &&
      actual.banner_image_content_type != nil &&
      actual.banner_image_file_size != nil &&
      actual.banner_image_updated_at != nil
   end

   failure_message_for_should do |actual|
      "expected that #{actual} would have a banner_image file attachment"
   end

   failure_message_for_should_not do |actual|
      "expected that #{actual} would not have a banner_image file attachment"
   end
end

More detailed information can be found here, but basically inside the match block, you want to test your condition, and then return true or false. You can also modify the error messages that get printed when a test fails.

Now we can finally write the test. Here is what I did:

it "should assign a newly created event as @event with an image attachment" do 
   event = FactoryGirl.create(:event, :banner_image => File.new(Rails.root + 'spec/support/images/bannerTest.png'))
   Event.stub(:new).and_return(event)

   post :create, :event => event

   assigns(:event).should eq(event)
   assigns(:event).should have_banner_image_attached_file
end

Basically I do the same thing as my previous tests, but I add an extra check for the banner image using the RSpec matcher I just created. Also, I want to mention that you can provide a file to test with by reading one in using File.new. I put a test image in the Rails.root/spec/support/images folder and reference it there. This all works great, but there's on thing we're missing. If you're using Amazon S3 to upload your files to, these tests will actually upload your image every time you run your test. This is something we probably don't want to do, so we can prevent that from happening by stubbing out the method that uploads the file. That method is called save_attached_files, and we can stub it out by using the following code: Event.any_instance.stub(:save_attached_files).and_return(true). So now our test should look like this:

it "should assign a newly created event as @event with an image attachment" do 
   # stub out this method so that this test does not actually upload the image to amazon s3
   Event.any_instance.stub(:save_attached_files).and_return(true)

   event = FactoryGirl.create(:event, :banner_image => File.new(Rails.root + 'spec/support/images/bannerTest.png'))
   Event.stub(:new).and_return(event)

   post :create, :event => event

   assigns(:event).should eq(event)
   assigns(:event).should have_banner_image_attached_file
end

We can run this test (or have Guard run it for us) and see that it passes.

I hope that this post was helpful in getting started with RSpec testing, and also how to test with Paperclip and Mongoid. Feel free to ask questions in the comments and I will do by best to answer all of them.

Getting mysql2 gem to work with Ruby on Rails 3.0 and Windows 7 64bit

2011-06-03T11:52:00.000-07:00

Edit: For Rails 3.1, these same steps should still work. I had some issues at first, but try uninstalling (gem uninstall mysql2 -a) all previous instances of the mysql2 gem before installing the latest one.

The mysql2 gem recently added support for Windows (https://github.com/brianmario/mysql2/issues/8), but it sure was a pain in the ass to install. Hopefully this blog post will help save you the time and swearing that this gem has caused me. I had a lot of issues just trying to get the gem to talk with my MySQL server, and it seemed like there was some issues with using the 64bit version of MySQL server, so I eventually downgraded to the 32bit version. Also, you cannot just do a bundle install or gem install mysql2 to get this gem installed. Lastly, once I finally got the dam gem installed, it would always hang when I tried to use it (e.g. rake db:create), and I found that there's an issue on github here: https://github.com/brianmario/mysql2/issues/142, but I was able to still make it work.

First off, here are the versions of my software:

Ruby 1.9.2p180 (2011-02-18) [i386-mingw32] installed from RubyInstaller
RubyInstaller's DevKit: DevKit-tdm-32-4.5.1-20101214-1400-sfx.exe
Rails 3.0.7 or 3.0.8RC2
MySQL Server 5.5 32 bit (It's really important that you install the 32 bit version of MySQL because the 64 bit version doesn't play nice with RubyInstaller. Refer to here for more information: https://github.com/oneclick/rubyinstaller/wiki/Troubleshooting#gems_mix_bits

Assuming you have all this already installed, here are the steps you need to follow:

Copy C:\Program Files (x86)\MySQL\MySQL Server 5.5\lib\libmysql.dll to C:\Ruby192\bin. I think also if you just add C:\Program Files (x86)\MySQL\MySQL Server 5.5\lib\ to your environment variables it might work too.
Uninstall all previous version of the mysql2 gem just in case. e.g. gem uninstall mysql2 -a
Go to the mysql2 github page and select the 0.2.x branch, then click the Downloads button to download the gem (or you can go here: https://github.com/brianmario/mysql2/zipball/0.2.x). We're going to have to manually compile and install the gem. The latest mysql2 version 0.3.x only works with Rails 3.1 and not 3.0.
Unzip in to a folder called mysql2-0.2.7 in your Ruby installation folder here: C:\Ruby192\lib\ruby\gems\1.9.1\gems, so that afterwards it looks like: C:\Ruby192\lib\ruby\gems\1.9.1\gems\mysql2-0.2.7
Now load up Git Bash (I couldn't get this to work in regular Command Prompt) and go to C:\Ruby192\lib\ruby\gems\1.9.1\gems\mysql2-0.2.7 and type: gem build mysql2.gemspec
Now you should have a file called mysql2-0.2.7.gem in your directory. Let's install the gem now. First type: subst X: "C:\Program Files (x86)\MySQL\MySQL Server 5.5" (or wherever your MySQL Server is installed).
Then type: gem install mysql2-0.2.7.gem --platform=ruby -- --with-mysql-dir=X: --with-mysql-lib=X:\lib
Congrats, you're done now! We can test it by typing rake db:create or rake db:migrate in one of your projects. If all went well you shouldn't have gotten any errors. Good luck!