Rails vs MS SQL Server

So, I am finishing off a couple of Ruby on Rails apps that fell to me (from where I had just a supporting role) to finish and deploy. Several bugs that appeared in the production app where it had worked fine in development gave me fits.

Most had to do with the way that the development SQlite seemed to be more permissive than the production's MS SQL Server. Sometimes, updating rails to 3.2.x would fix it. But that would also introduce new problems.

The worst was when I finally got my bug list squashed only to have new bug for settled issues appear. Suddenly my .empty? statements stopped working. So I switched to .blank? on advice from Ruby Quicktips. I suppose I need to do some deeper reading on the language rather than just Googling when I need a function. Part of the trouble is that I will have to pay attention to Ruby versions and what might or might not work with a database.

I think it is also time to stop doing tutorials and actually write an app up from scratch.

Client and Server Side Form Validation Pt. 3

So, with a nice looking form, and some decent JavaScript processing my form works very nicely. However, I need to make sure that the server receives good data even if the JavaScript was turned off or not in play. All that form niceness is to help the user, now it is time to help the server.

Currently, my thinking on this isn't very solid. I'm asking the server to do a lot of work to double check the form and then determining if it should pass on the information to be processed or if the form needs to be displayed again.

This is not too bad if the form is small and has a predetermined set of fields. However, many of these forms are dynamically generated, so the processing has to be dynamically processed as well. This is where I try to take advantage of frameworks and partials to keep my display code in modular chunks- breaking out the form from the rest of the page.

Basically, I try to cfparam all the form fields and then validate the results and report them with the form. So if JavaScript does its job on the original form, great. If not, it still is taken care of before it hits the server. Regardless of the amount of work the server or I have to do, it is probably for the best.

Client and Server Side Form Validation Pt. 2

So continuing from oh, so long ago. I have moved from the previous basic form and posting and blended in Bootstrap, jQuery.Validation and a lot of Googling/research.

Styling up a nice, easy to read and flow form with Bootstrap's form code is straight forward and pleasant. Even if radio button groups can be tricky.

Next, I needed to bring in some jQuery validation. Pretty much the go to is the jQuery Validation plug-in from bassistance.de. It seems to have the most work and there were many tutorials and references in the Bootstrap issues discussion about getting it to work.

My starting point to getting from Ben Nadel's basic form upgraded is this little code sample called jQuery Validate Demo from aLittleCode.com. This will punch up your forms nicely. But the forms I work with extensively use radio groups (evaluation ratings of 1-5, sometimes with N/A and some need to be required).

From here it takes a little fixing and JavaScript to include radio buttons to put the error message in a decent place. I got my notes from these two posts: Mihir Chitnis and this discussion (starting with the last half of kwilliams's post) on the Bootstrap issues.

I'd like to see Bootstrap fold in jQuery Validation to their JavaScript library or for a solid plug in to be developed. But with some tweaking I think I got a code base to work for my code set up.

Lets see if I can find some place to put code...


Form HTML
Form JavaScript

Client and Server Side Form Validation

Something that has bothered me for a while is how to combine Client and Server Side form validation as painlessly as possible (as a developer) while still maintaining a pleasant user experience. Its not just about being able to fall back when Javascript is not available, but having secure input to the database. I like to consider the Ajax-y/jQuery to be mostly in service of making data entry more efficient.

To that end here is my form design thoughts.

1. Writing clear and concise labels and instructions (too many instructions means that my form has business logic problems)
2. Scripting input events to alert the operator to problems as they enter data and as they submit
3. Checking and sanitizing the data on the server before making changes to the database
• If the form is deemed valid, proceed to processing
• If there are problems, re-post the form and repopulate the data with error messages

From the reading I've done, there will always be some amount of duplication of code. This is the nature of web applications. This can be mitigated by having reusable code, both as JavaScript libraries and having modular server side code. How to do this will be the subject of this experiment.

My starting point is the article by Ben Nadel from December 2011 called How Client-Side Validation Is Changing The Shape Of Server-Side Validation. Part of the issues will be integrating the code into our style of FuseBox, finding a decent jQuery plug-in, I may have to buckle down and figure out how CFCs really work, figure out how to use Ajax and standard posts with the same code (probably related to CFCs) and lastly how to deal with dynamically generated forms.

Tall order. I should have done this years ago.

Temporary Break

So, I've hit sort of a slow down here. A few things will keep me away from posting on a schedule.

1. Seasonal family activities
2. Seasonal work load
3. Temporary hold on the Expired Passwords script

This time of year is very busy with family, (uninteresting) work back-log, and deployment of my script is on hold until various stakeholders can get together to talk about deployment.

I'm not ready for this to become a link-blog, so I'll return with new code when I get a chance to explore new scripts and ideas- hopefully mid August.

Put it All Together

After beating myself up over the last post, I rolled up my sleeves and got working logic code and it is sending me notifications of who's account password is expiring. I'm still having trouble with getting useable information out of the LDAP hash. I'm probably doing it wrong, so I've asked for a code review and maybe we'll get to the bottom of how Ruby is doing this. I keep getting values in the format of:

["gcolasurdo"] in stead of just gcolasurdo

when I try to get the cn, mail or other LDAP key field.

First, an outline of my code's logic (based on the previous ColdFusion script):

1. Loop over the relevant OUs (organization units in the LDAP)
2. Query the LDAP
3. If there is an expiration date and mail then...
4. Find the expiration date and calculate the difference from today (script will run daily)
5. If the daydiff is on a warning interval...
6. If the OU is for the College of Nursing or everyone else, prepare personalized email text
7. Then send an email with the details of the impending password expiration

Two questions that came up from the CF code. Should I:

1. Set a timeout at some point so as to not choke the mail relay
2. Log the results

One independent question I had:

1. Should we do anything about already expired passwords (I'm sure the business reason was already set, but as the programmer, I kinda want to make sure)

This is all working locally, so we will need to start in on the deployment process.

Ok, here is the code I'm using:

S is for Stalled

I was hoping to not have to do this so early on. It's the biggest problem in writing a blog; maintaining consistency and finding a voice. But here I am.

I've run into a block and I don't have any code to talk about this time.

Fortunately, I am learning something from this.

My difficulty with Ruby, and by extension Rails, is that it seems easy to get an application up and do fun things like utilize Ajax, query an LDAP or send email. The part I'm having trouble with is manipulating results.

It seems funny to stumble on the simplest of things, but when it comes down to it, that is the whole reason for an app: to manipulate and present data.

I'm just not getting the the pointers and hashes. I'm not getting the syntax and conventions. I'm not getting the methods that can be used on an object. It is going to take some reading and re-reading to get it. And beyond re-reading, I need to make some code samples and play with the results. Maybe I can show that next time.