Ohio Wines iOS application

Posted on February 26th, 2014 by mriley

I finally have an application on the app store.   About two weeks ago my Ohio Wines application was accepted and is now available.  It is a free application that allows users to find wineries in Ohio.  You can find them based on an alphabetical list or you can find them based on the wine trail that they are on.  It also includes directions, a phone number and the website for the wineries.  You can also find Ohio wine events.

I had been working on the application for quite some time but was never really happy with the way it looked.  I would always look at it and think it didn’t look professional.  After all this is a reflection on me and my work.  I really wanted to get it right.  I found some good inspiration sites that helped me get a good idea of what the trends were in OS design.  I worked in Photoshop to do mockups and layouts of the various scenes of the application.  Once I was happy with the final design I took the mockups in Photoshop and started getting all of it ready for bringing it in to Xcode.  The coding was fairly easy.  I saw a great tutorial from NSScreencast that got me in the right direction.  After a bit of tweaking I got the iOS application portion exactly right and working.  I also built out my Ruby on Rails application so it could have the JSON data ready for the application.  When I was ready to release the application I did some final testing on my end to make sure I got everything right.  I found a few minor bugs that I hadn’t noticed and spent the day working on those.  The actual release of the application was fairly easy.  I got everything set up and uploaded in about 30 minutes.  I uploaded my application by Saturday night and by the next Saturday I got a notice that it was in review, approved and then available on the app store.

The technologies behind the application are Core Data, a Ruby on Rails backend data store with an API, AFNetworking for making the URL calls from the application to the Rails application and RNFrostedSidebar for the menu system in the iOS application.  The Ruby on Rails backend data store allows me to make updates on the backend and then have it update the application’s Core Data store behind the scenes in the application.  This allows data updates without having to send a new version of the application to the app store.

Final Thoughts
Developing the application was a lot of fun.  I have been developing on iOS for about 5 years now and never got an application on the app store.  I should have done it much sooner.  I am planning at least two more applications that I have had in my head for the last few years that I have never published.  I hope to do that in the upcoming months.

You can check out the application here .

Contributing to Ruby on Rails – Part 1

Posted on November 2nd, 2010 by mriley


I went to RailsConf this year and really liked Yehuda Katz’s talk about getting involved with the development of Rails.   It really did inspire me to become more active in contributing in the Rails community.  While at the conference I talked to 37signal’s Jeremy Kemper about working through some of the open Rails bug tickets.  Tickets are a thing I am most familiar with working at Engine Yard as an Application Support Engineer.  Working through complex issues and tickets with customers is part of the job.  So, looking at the number of bug tickets with Rails (700+), I felt this was a great way to help out a bit.  My thought was that I could work through the tickets, close some out that were not valid and push ones that had gone stale over time.  Working with Jeremy he helped get me additional privileges with my Lighthouse account on the Rails project so that I could have greater control over the tickets.  I could now close out tickets or mark them as invalid.

Getting Involved

I first started working through the tickets when we had a hack day at Engine Yard.  The hack day was set up so we could work on any single project in which we wanted to contribute.  This could be a simple application that we could build in a day, contribute back some code to open source or anything along these lines for example.  During hack day I worked on about 20-25 Lighthouse tickets.  I was really happy with the progress I had made in that short time frame.   While most people may not have an entire day to work on Lighthouse tickets, every little bit helps.  This is the great thing with contributing with Rails. You may not want to work through patches, code or issues, but there is still many ways that you can contribute.  You can work through these tickets to see if there are ones that can be closed as they are not relevant or there is the Rails documentation project which that you can contribute.   After working on these tickets, I wanted to get more in to the internals of Rails and contribute some code. I wanted to be a Rails commiter.  Before I could get to this point, I needed to be able to have the rails source on my machine and running the tests locally.

Guide on how to get the tests running locally

The first step is to clone the Ruby on Rails repo.   The way I work is by having a top level projects folder under my user’s home directory.  I then created a subfolder called ror_source under projects and then ran:

git clone http://github.com/rails/rails.git

This created a rails folder under my ror_source folder.

The next step was to go in to the rails directory and install the necessary gems using bundler.  Before you do this though you will want to be certain you have the latest version:

gem install bundler –no-rdoc –no-ri

Then run bundle install to get them gems installed:

bundle install

This will install all the necessary gems for you.  Once you have this working, you can then run your tests:

rake test

When you do this, you will get errors since you don’t yet have Postgres, MySQL and sqlite3 configured as of yet.  Ruby on Rails’ tests run against those 3 database types so for your tests to pass successfully you will need to have all 3 of these working.  It is also important to note that if you are working on a bug, patch, etc. for Active Record you will need to make sure that you have tested against all 3 of these or your patch will get rejected.  So, the next step and that is to get your databases set up and working.   First, let’s get MySQL working and configured:

First set up the rails user for access to the database:

mysql -uroot -e ‘grant all on *.* to rails@localhost;’

Once this is done you can then create the databases for the rails user:

rake mysql:build_databases

You now should have Rails running with MySQL.  Let’s get Postgres working now.

This is a little bit different.  There is a rake file that will help you get Postgres working.  First go to the activerecord directory under the rails source.  Under this folder is a rakefile.   The rakefile that is there is used to build the databases.  You will want to run the following command:

rake postgresql:build_databases

This will create the database for postgres.  When I ran the test from this point I got a Postgres error that really stumped me.  It said:

error: in `initialize': fe_sendauth: no password supplied (PGError)

I did a bit of research on this and found that the pg_hba.conf file for postgres needed to be updated.  The method needed to be updated from MD5 to trust.  Once I did this, I was still getting the error.   I was completely stumped at this point. I talked to one of our database administrators at Engine Yard and found that pg_hba.conf is not loaded on each start.   I had to manually reload the config file for it to pick up the changes.

So, here is how you reload the config file:

su to the postgres user, add the path to pg_ctl to $PATH, and then finally run the command: pg_ctl reload -D

Then re-run your tests and you should be in business now. From here you should be able to start looking at patches, bugs and other issues. I will get in to actually working on an issue in part 2.

Mike Riley