With this blog post, I am pleased to announce that A Few Guys Coding has created a service with a different twist. Wedding customs and traditions are changing all the time. Whether it is the customs, music, the attire or even certain colors such as a wedding I once went to that had black and purple as the main colors. I had even heard of online RSVPs. This software stack, WeddingWare, was born out of necessity. For my own wedding, 5 months away now, we needed a way for guests to RSVP. Since we didn’t want to spend al the money on response cards, we are environmentally friendly (it saves trees!) and I am a software engineer, I suggested that we come up with online RSVPs (the guest will still receive a paper invitation with an invitation code). After a couple brain storming sessions later and much, much code, WeddingWare is officially available for license. While the primary focus is custom wedding RSVPs, the software can also handle shower invitations as well has bachelorette party invitations. Being highly customized is a main focus of this software because after all, who wants to go to a URL that looks like this: www.theknot.com/user/123456/mywedding/rsvp.html. Our software is simple and we will work with clients directly to setup a RSVP site where the look is clean and the URL is custom (for example, ours will be, eventually, at www.davidheartsrachel.com). The software has a full-featured backend that allows the party hosts to login and 1) create new parties and invitations 2) have multiple events 3) get metrics on guests that are attending (such as outstanding invitations vs. people who have responded). Guests will be directed to a friendly, intuitive site that the hosts have fully customized, down the color scheme even. After RSVPing, the guest will receive confirmation emails with hotels, driving directions, maps, etc. The site is mobile browser friendly and we are working on coming up with a matching iOS application. Pricing is still to be deteremined – yet will be affordable and based on the number of guests. A live demo is available at http://dhr.afewguyscoding.com.

Disclaimer: I am not a “web guy” by nature. I have recently start experimenting more and more with it because eventually I want to become proficient with web and design. Therefore, this may be a simple tips for “web people” but a typical “desktop application” person might struggle with this.

  1. Debugging in Chrome, Firefox and Safari is easy, debugging in IE is hard: Chrome, Firefox and Safari all make it extremely easy to debug issue related to HTML, CSS and Javascript (AJAX included!) because they Chrome and Safari have built in “inspectors.”  Firefox requires an additional plugin, Firebug, but it is just as useful once you have it.  IE makes this process as painful, however, in IE 8 (I haven’t verified anything before or after this version), the Tools menu has a “Developer Tools” window that attempts to do the same thing as Firebug and the built-in inspector for Chrome and Safari.  While it is kind of like using rock knives compared to the other tools, it did work and I was able to debug my CSS in IE (Javascript is much harder). Microsoft has a nice writeup on this tool here.  In fact, go ahead and use Photoshop or Illustrator to create your designs – that’s fine.  However, when it comes time, always test first in IE since it has the poorest support.  Chances are that if it works in IE first time, it’ll work in the other browsers first time as well.  Oh yeah, and get CSSEdit (sorry Windows people – you’re on  your own).
  2. RAILS_ENV != RACK_ENV in Rails 3: I was having a devil of a time getting my staging server to work with my staging database.  Passenger and Apache would connect and use the proper staging files directory but it would constantly connect to the production database.  The trick is that in Rails 3 (only!!!) you need to set ENV[‘RACK_ENV’] = “staging” or ENV[‘RACK_ENV’] = “production”.  In Rails 2.x.x, you still use the RAILS_ENV to tell it which environment to use.
  3. Having a good deployment strategy and capistrano recipe is key: Many months earlier, I had already put up a plain HTML site (no framworks, *gasp*) at www.davidheartsrachel.com at a really cheap host, iPage (they were $30 for the year and believe me, you get what you pay for but that was OK because it was just text and images). Everything was working there just fine there while I was developing this Rails app. Initially, (before I switched to Rails from Google App Engine), I thought that I would host the application at some place like Heroku, since their deployment looks dead simple. As it turned out, it would be much cheaper, by about $40/per month, to have my primary host (the one this site is using) and just buy some additional upgrades in RAM to my VM to suppose multiple Passenger instances.Anyways, I knew that I would need to start testing outside of a development environment. In addition to the standard development, test and production environments given to you in Rails, I converted the test environment into a local version of a production environment (cache classing, actual mail delivery, etc.), however I kept my database adapter as SQLite. I also created an additional environment called staging. The theory behind this is that I would run exactly as it would in production (using MySQL, class caching, session stored via :mem_cache, using delayed_job to deliver mail, etc.) with test fixtures and data in the database. Obviously production would be production environment with live data. This allowed me to iron out any bugs that might crop up during switching to a more production-like environment and catch any assumptions I had made in development that wouldn’t be valid in production (when switching adapters, etc.). I dedicated a subdomian to deploying my staging environment and password protected it. If you are interested in my Capistrano file, environments file and Apache vhost file, they are here (with the obvious implementation and sensitive path/password redactions).
  4. Radio buttons: I was making some AJAX calls that should have selected radio buttons in the same group when the call returned based on :success or :error AJAX callback. I was having trouble getting this to happen but this code here is solid:
    // this example had a yes/no. it can be extended to any number of radio buttons
    var radios = $('input:radio[name=radio_group_name]');
    radios.filter('[value=val1]').attr('checked', false);
    radios.filter('[value=val2]').attr('checked', true);
  5. Rails UJS: Rails 3 embraces a more MVC way of thinking by abstracting the Javascript choice (whether it is jQuery, Prototype, etc.). Before the implementation was fairly specific and you sometimes had to mix specific JS code into your Ruby code. With UJS, implementation in Rails 3 takes benefit of the new HTML5 data-*@ attributes. So Rails doesn’t spit out Prototype-based Javascript inline (the old helpers are still there). Rather, the helpers just define an appropriate data attribute in the tag, and that’s where Javascript comes in. Obviously this is a more flexible and reusable pattern. You can also plug and play different frameworks without the headache of writing a lot of the same code over again (I swapped Prototype and jQuery in in several minutes – just remember to get the new rails framework Javascript files, such as rails.js, in jQuery or you’ll have weird errors that are hard to track down.  Check out jqueryrails.). Since I am far from a RoR or Javascript expert, this, this and this has a more expert breakdown (why re-invent the wheel).
  6. Remote form_for (AJAX) and :onsubmit(): In Rails 2? and at least 3, form_form, :remote => true overrides the :onsubmit => ‘func();’ method to do the actual form submission.  If you want to bind something to your form before it gets submitted (or during or after!), bind the form using jQuery.bind() and then observe the AJAX callback functions to do what you need. <script type="text/javascript"&gt;
      function get_address_information() {
        // check jquery for all the possible callbacks. there is also success and error. compete get calls after both success and error
        var pars = 'param1=x&amp;param2=y&amp;param3=z';
        $.ajax({ type: "POST",
          url: "/get_invite_address",
          data: pars, dataType: 'script',
          beforeSend: function() {
            // do your before send checking here
          complete: function(data, status) {
            // do some post processing ehre
  7. Rails is as good as everyone says (and other languages/frameworks are as bad as you think): Truly. The only drawback is the lack of internationalization. However, in terms of use, the language, setup, data access Rails is superior in every way. Rails setups up for testing (as well as performance testing) from the word go. The framework allows you to concentrate on coding while it does the heavy lifting.

Report card from here