Though you hear it all the time, comparing Ruby on Rails to PHP really is not fair - they are different animals entirely, only sharing the goal of creating websites that do stuff.

Rails, being a framework, could be more aptly compared to PHP frameworks, such as CakePHP, or Zend View. But even then they are still very different - and the difference is Ruby.

Ruby is beautiful, elegant and easy to read. PHP is pragmatic and direct but disorganized (imho).To Ruby, everything is an object, which serves as a good organizational mechanism. In PHP everything is a global function, usually with funky names that give little indication to what it does. It is like the difference between an organized toolbox, with all the right tools in all the right places and one big box with all the tools thrown in haphazardly.

Let’s look at a overly simplified example of some Ruby code, often used in Rails.

1.day.ago

What do you think that means?

Let’s look at it in PHP.

time() - 86400;

Hmm, I think most of us could figure out the PHP but anyone could read the Ruby. Which brings up another subject. The Ruby code above is actually an extension of a core class/object in Ruby, which Rails does - a lot, to great effect.

There are many more/better reasons for choosing Ruby and Rails, of course. But, for me, it is the simple things that Ruby allows which makes Rails … different and better.

Curious on how the pros handle marking required fields on their forms?  Wonder no more!  Below I’ll describe a technique I employ on my own forms to make marking required fields a simple and straight-forward process.  I will assume you have at least a basic working understanding of CSS, but even if you do not you should be able to still employ this technique.

First lets start with the HTML:

<ol>
<li class="required">
<label for="item1">Item One</label>
<input name="item1" id="item1" value="" />
</li>
<li>
<label for="item2">Item Two</label>
<input name="item2" id="item2" value="" />
</li>
<li class="required">
<label for="item3">Item Three</label>
<input name="item3" id="item3" value="" />
</li>
<li>
<label for="item4">Item Four</label>
<input name="item4" id="item4" value="" />
</li>
</ol>

This is a standard ordered list.  You may be curious why I choose to wrap my form elements inside a list?  It’s a recommended best practice, as is the use of the for attribute in the label.  If you want to learn more you can google for “form fields li best practices” to read the opinions out there.

Now to style our two required fields with *’s is a simple matter of some CSS code.  Our goal is to not actually use text in the html itself.  The reason we don’t want to do this is that “required” is not really content, it’s meta-information.  Marking a field as required or not therefore is something that should be treated as a style, not content.

If a client came back and asked to have the mark for required fields be treated differently, say instead of a * (star) they wanted an ! (bang), we only have to edit one little line of code.  What if they didn’t want a mark at all but instead wanted to have it highlighted with a red box?  You start to see the wisdom in handling this through a style than in the html itself.  We’ll need just a handful of styles to accomplish our goal:

 ol { list-style: none; }
li.required:after {
content: "*";
font-size: 18pt;
margin-left: -5px;
}
label {
display: block;
font-size: 14pt;
align: right;
margin-right: 0.5em;
}
input {
margin: 5px;
font-size: 14pt;
}

The :after pseudo-selector on the li element is a special selector for a marker.  You can think of a marker as a sub-element of the primary element that appears before or after it (in this case the li element with the class of required).  We could also select the marker that appears before using :before.  The resulting web page will look as below:

Somehow, I ended up on this mailing list about leadership.  The articles–put together by a local company–focused on teaching leadership and team building, and I always looked forward to reading them.

Last September, I took a few minutes to write the author and company owner.  I told him that I enjoyed the articles, and said I had considered signing up for his seminars. I concluded my email:

“As a reader of many business books (Good to Great, Breakthrough Companies, Small Giants), I can appreciate your references to Polaris and themes aimed at helping businesses grow.  Just my applause for a job well done.”

Guess what his response was?

Nothing.

Two months went by before another article appeared in my inbox from the author.  At the conclusion of the article, he suggested that readers share their ideas and feedback.  In fact, he welcomed it, he said.

Ah, he did, huh?

So, I wrote him again expressing my thoughts and informed him that I had in fact written to him once before–over two months prior, I told him.  This time, he did write back with a terse response that didn’t feel like he welcomed my feedback at all.

I decided that maybe this guy wasn’t the person I should be learning leadership from, because the way I saw it was this “leader” offered more words than actions.  So, I took action.

I unsubscribed.

Now that I’ve been here for a couple months, I guess it is time to post a blog, but about what? Since, in large part, testing is new to me, (and an important part of developing Thundertix) I thought I’d start there. So read on if you want to hear about my experience. It’s been a wild ride.

Auto testing your code is a sexy idea to any programmer who has asked themself - ‘does my code work?’ Most importantly, ‘will it work when I move it to production’. Most of the time, the answer is “I think so, let’s see”. So testing, in theory, should allow you to forgo that nerve racking question altogether.

But testing, in my experience, is hard. More difficult than writing the code to begin with. By a long way. Not only because you are learning new constructs to exercise, poke and prod your app but also because you have to think differently about how your code is structured. Is the code in the right place - is it simple enough? Should I be moving my code out of the controller and into the model, as many of the best Rails programmers suggest? (When you start testing complex controllers, I can tell you, the answer is YES!)

So far, testing for me is like taking vitamins - it’s good for you - but may not taste good. So I tell myself, “every test makes your code stronger”. It’s a bit like exercising. The more tests you have the stronger your code will be. And you will know it - especially when you have to make sweeping changes.

I’ve got a long ways to go before I can say for sure that my code will work but, as I learn and get better, I can see the light at the end of the tunnel.

But, at the end of the day, if I never have to ask “Will my code work when I move it to production?”, it’ll all be worth it.

Nicholas writes clean, elegant code.  Paul contributes beautifully to interface interaction.  Scott is a master of programming languages, and Manish and Manasi possess an enviable stick-to-itiveness attitude.  Then there’s me.

Fumbling as I am in learning Rails and attempting to pick up Scott’s reigns, I realize that I have been very fortunate in my reliance on great programmers.  So, if I haven’t said it to the guys and gals around me worthy of the title “programmer”, let me say it now, “My hat’s off to you!”

For two days and many hours, I slaved over a Ubercart issue that insisted I must have “javascript enabled” in order to display missing credit card fields.  Posts on the Ubercart forum suggested I look for javascript errors that might conflict with the onclick display of the credit card pane.  I sought but did not find.

I finally began to remove page elements from our custom template to ferret out the problem.  Still the error persisted.  Finally, I removed the entire custom template, and lo and behold, the heretofore unseen credit card fields appeared.

The problem?  In our template, we needed to make one simple call:

< ?php $scripts ?>

This simple variable allowed javascript calls to be made and rendered on the page, but recognizing that fact took far too many hours. It’s these little issues that can make Drupal such a bear!

In software, usability refers to the design of the interface that reflects an intuitive relationship between what a user wants to do, and how to do it.

We are in the midst of the exciting redesign of one of our core services, ThunderTix, our online box office management system.  In addition to creating an array of new functions for the software, we spent a considerable amount of time designing a streamlined web interface with responsive AJAX-y controls.

Yesterday, we were at a crossroads as to how to implement our seat pricing assignments.  The evening before, I spent several hours fine tuning the layout of various pages, and I was struck by just how far our system had grown. Yet with that growth in great new features,  we had also introduced more complexity.  As a company whose roots lay in educating a largely non-technical user base and boiling down lots of functionality into simple excercies, I was a little worried that the new features might prove a little challenging to our clients.

During our discussion about pricing, we were weighing issues that might affect the performance of the system against usability.  In a nutshell, in order to improve database performance, we had to introduce a new concept and series of steps to enable our clients to reach their primary goal–selling tickets.

Customer service time and training is a huge part of our business.  And every minute we instruct users how to get up and running, we lose profitability.  And for every second a user pokes about the interface trying to accomplish their goal, we are at the risk of losing a client.

So, we opted for a potential yet tiny performance drop for a greater increase in the ease of event setup.  Because in the end, usability is performance.

Over the last six months, I began looking into Agile programming practices leading me to the Agile Austin users group.  In April, Stacy and I attended our first meeting where we were fortunate to meet Nicholas Cancelliere–an active Agile Austin member, Certified Scrum Master, and agile instructor.  Nicholas joined our team on May 1st excited about the opportunity to introduce agile programming and Ruby on Rails, and we were thrilled to have Nick at the helm in leading us in this new–for us–programming methodology. 

While Rails itself is an exciting rapid development language stirring up a lot of media buzz, it is our adoption of agile programming practices that has transformed our business.  Previously, we scheduled client projects in a seemingly aimless juggling act.   With agile, our Monday mornings are dedicated to planning the week’s work, and we know exactly what we expect to accomplish. 

In addition to ramping up our own development and reducing our backlog, we’ve had other significant benefits.  Stacy and I confidently inform our clients about expected completion dates, and following the agile way of rapid development and customer collaboration, we schedule software demos weekly.  These weekly iterations allow us to unearth potential errors in communication early, which helps keeps development costs down.  Our clients thrill in seeing their software ideas take shape, and the open communication fosters their own confidence in us.  And our programmers set realistic expectations, gain satisfaction in achieving goals, and have control over their own work. 

Like Scott said today, yes, we could have learned and adopted agile and RoR on our own with help from the agile community and committed effort.  But having Nicholas lead the group allowed us to see dramatic results in a very short period of time, and the impact has been one of the most significant in our short history.   Sometimes, all the buzz is justified. 

After a long, interrupted day at the office of phone calls and emails due to our mass mail blunder today, I decided that I was due for a late night michelada (for our non-drinkers: i.e. a Dos Equis Beer with tomato juice, a lime, and a salted rim). 

This week marked my fourth year at Thunder Data, and January thankfully always brings our only quiet time of year to catch up and tie all loose ends.  At this time every year, we find ourselves with time on our hands to better our website and reflect on the previous year’s business sales, goals, and practices.  So, it is here I have found the time to inspect our own site for needed updates to our portfolio, page enhancements, search engine optimization and other general improvements. 

Like a carpenter’s home, our own site has sat neglected behind the day to day work of our clients.  So, with my laptop, great pub grub, and a michelada, our site received much needed attention.

As a tech company, we’re supposed to “mind our Ps and Qs” among all things technical.  (As a tangent, the term “Ps and Qs” refers to both diligence in your work or minding one’s manners.  With roots in the old Brittish pubs and referring to ”pints and quarts”, the term was used when too much brew caused misbehavior.)  Today, after I carefully crafted an informational tutorial for our ThunderBits section, we sent it out to our mailing list.

We haven’t been particularly diligent about using a mailing list to market ourselves even though we strongly suggest that our clients use mailing lists to roll out product ideas, helpful hints, and updates.  So, here we are, starting our 8th year in business, and we’ve used the mailing list less than a dozen times–all without a glitch until today.

Wouldn’t you know that an email address on our own server had an “auto-responder” indicating the recipient was on vacation.  Her email responded back to our list, in turn spawning yet another email to the list updating them about our  party’s whereabouts.   As loops go, our gal on vacation received a second email from our list notifying itself that our gal was out, and another loop began.  And again.  Twelve times.

It didn’t take long for our phone to ring and our Inboxes to fill up with requests to notify us of the error.  Thankfully, we realized the mistake early and stopped it quickly enough that only 12 spam messages went out.  But the whole fiasco was embarrassing, and I hope this type of public humiliation doesn’t happen again.

With that said, I’m drowning my sorrows at Sherlock’s in Austin, but I promise that while I drink my pints, I’ll mind my Ps and Qs!