Working with Rails

Last fall I had written a post where I noted that I had a problem to solve at work which I thought might be well suited for Ruby on Rails.  Like a lot of side projects, this one never went anywhere but I did end up playing around with RoR enough to get an idea of how it works and how quickly things can be developed with it.

I do some volunteer work with our High School Booster Club and last year built them a WordPress based site which is largely used to facilitate the purchase of memberships.  While it seems like overkill, the plan is to use the web site to host more content relevant to the various athletic teams.

A couple months ago I was approached about how the Booster Club’s mobile app could be improved or replaced as the currently technology is being withdrawn and no longer supported.  I learned that the back end for the mobile app was extremely cumbersome to use and was a source of frustration for the people who maintain rosters, schedules, results, etc.

I am now working on a replacement for the Mobile App and the backend infrastructure.  Because we already have a WordPress site, I had considered using the WordPress site to host all of the data and leverage the WordPress JSON REST API plugin to serve content up to a Mobile App.  But I had some reservations.

jQueryMobileBookI’ve never done Mobile App development and in the interest of time, am not sure I want to take that on right now.  Based on my jQuery experience with WordPress, I thought a jQueryMobile web app might be a reasonable compromise.  I picked up a copy of jQuery Mobile Up and Running a while back when I had heard it referenced on a Podcast.  At the time I didn’t have an immediate application for it but it was interesting reading.  I dusted it off and realized jQuery Mobile would be a good solution for building a prototype mobile web app.

So now I have some thought in my head of a mobile web app I want to build but wasn’t sure about how to feed it.  While I could see putting all of the data in WordPress, I was worried about maintaining it.  I need something dead simple to enter rosters, teams, schedules, results, etc. into a system.  Ideally it should be accessible from a phone so scores can be quickly entered by unsophisticated users.

What I’ve decided to do is build a mobile first (maybe only) application using Ruby on Rails.  I have made all of my HTML views based on jQuery Mobile.  Within a week or so of working on it for a few hours a day, I have the basic application up and running on my Ubuntu VM.  I can set up teams, coaches, and athletes, and assign coaches and athletes to teams.  I have started on venues.  There is a ton left to do – events, schedules, user login, Google Maps, and a lot more.

While I am excited about how much progress I have made in a relatively short time frame, I am worried I am “doing it wrong” or have made a decision that will be difficult to unwind.  I’ve learned a fair amount about Rails in the past two weeks and much to my surprise, have not had to learn a whole lot of Ruby yet.

The ability to quickly add database columns and connections in RoR is pretty slick.  During my first couple of scaffold generations I was worried about getting the database “right” but having dropped some columns and added others, I’ve found it relatively painless.

While I am impressed with RoR, I am really impressed with jQuery Mobile.  It is pretty amazing how quickly a mobile web app can be assembled.  I’ve been using a regular web browser for developing my app and even using jQuery Mobile with a regular browser is pretty nice.  I had forgotten that the laptop I borrowed while my Vaio was being repaired has a touchscreen.  Using the app on Chrome with a touch screen is pretty effective at mimicking a mobile device.

I still have tons more to learn as I get ready to deploy the first build for some people to play with and populate with dummy data but I can already see other uses for Ruby on Rails.  I am still not a big fan of the Ruby syntax but I can live with it for the benefits and development efficiency I am seeing with Rails.

Google Forms v0.70-beta-1 available

This weekend I spent some time looking at adding support for regular expressions as part of the Google Forms validation functionality.  This seemed like a reasonable and useful request.  I was surprised to find that the jQuery Validation plugin doesn’t offer regular expressions as a standard check  however, I found a fairly simple solution on Stack Exchange.

It took me a little while to get it working as Saturday morning I went down a wrong path initially following another post I had found.  When I first read the post I linked to above, I convinced myself that I didn’t want to use the AddMethod solution.  I am not sure why, I guess it was because I haven’t been into the code in a while so I was trying to avoid it.  It turns out it is definitely the right answer and fairly easy to implement.

The beta build also contains a Serbo Croation translation provided by Borisa Djuraskovic
of www.webhostinghub.com.

To see the new functionality in action, check out my Validation Demo Form where the last entry field must begin with a capital letter.  The regular expression “[A-Z]” is used to match a capital letter when setting up the validation.

GForm_SS_72

Google Forms Beta (7732 downloads )

Google Forms v0.65 finally released

This morning I released v0.65 of Google Forms, a long overdue update.  I have been sitting on this release for a while because of one outstanding issue I was aware of which I simply haven’t had time to chase down.  The ability to email the end user upon form submission broke at some point, I am not exactly sure when but it has been reported a few times recently.  It turns out, it only worked if email to the admin was also enabled.

Here are the highlights from the Change Log:

  • Implemented “save_post” for custom post type eliminating general purpose “save_post” (only option prior to WordPress 3.7) action which could potentially, if not handled correctly by another plugin, corrupt post data.
  • Formally deprecated the gform shortcode by updating README file.
  • Added flush of rewrite rules upon plugin activation and deactivation.
  • Implemented protocol relative URLs for loading jQuery script from Microsoft CDN to avoid mixed-content warnings when serving over https.
  • Fixed layout of CAPTCHA options on settings page.
  • Fixed bug with preset values as part of the URL which contain spaces.
  • Fixed bug sending End User email upon form submission.
  • Refactored construction of email headers based on experience with Email Users plugin.

You can find the update in the WordPress plugin repository or on your WordPress Dashboard.

Google Forms v0.64-beta-3 available

This evening I uploaded v0.64-beta-3 of Google Forms.  This version adds a check for the WordPress HTTP API cURL transport and issue a notification if it isn’t present.

There was a substantial change to the WordPress HTTP API between 3.6.1 and 3.7.  I don’t know the full details of the change but what I found in pretty extensive testing is the streams and fsockopen transports work in 3.6.1 with the Google Forms plugin but from 3.7 and later, they do not.

However, the cURL transport does work and as long as it is available, the plugin will work as it always has.  The problem is I cannot find any way to work with sites that don’t have the cURL transport available so I have added this check and issue a notice when it isn’t present.

GForm_SS_70

 

Please download and test out this beta version and report any issues found.

Google Forms Beta (7732 downloads )