Debugging and Visibility

I have recently been developing Spreadsheet::HTML and apart from a handful of mistakes, two particular CPANTS smoke tests (see this and that) always have one specific test fail. And only that one test. Here is the relevant output: Needless to say, i was hard pressed to spot the problem. I usually just ignored these two servers and moved on, but i always kept the notion to eventually solve this issue in the back of my mind. I even once ran the two strings through uniq and it too saw no difference. Finally, today i realized that i was looking at HTML, so i inspected the source and sure enough, there it was! It was very hard to spot, but a ' character was not being encoded into its ASCII HTML entities equivalent, '. Now that the problem is actually visible, a solution can be worked towards. I suspected the problem was that an older version of HTML::Entities was installed on the two smoke test servers that trigger this failure, but Spreadsheet::HTML does not require HTML::Entities, instead it requires HTML::AutoTag (another one of my modules) which delegates the work to HTML::Entities. So i immediately checked the Makefile for HTML::AutoTag and sure enough i was not specifying any version for its build. However! ... because Spreadsheet::HTML is not directly requiring HTML::Entities in its Makefile (as it should not), the test reports will not disclose anything about that module, so i now needed to determine what versions were being used. The next step was completely manual, while a programmatic solution could likely be developed, it seemed easy enough to pop on over to the latest smoke test reports for HTML::AutoTag and just search the web page for the same Perl and OS versions for the two failing servers for the Spreadsheet::HTML smoke tests. Compare those to the newer smoke test servers that pass and we see that yes indeed, the failures were coming from servers that had HTML::Entities v1.27 installed while v3.69 (the current version at the time of this publishing) was installed on virtually all that passed. Enter perlbrew (easily manage versions of Perl) and cpanm (easily install and uninstall modules for those versions). From here it is not hard to recreate the failure: just find the older version of HTML::Entities and replace the one being used with it. Unfortunately that requires figuring out which HTML::Parser distro is hiding v1.27 ... the very first available contains v1.13, maybe this is sufficient enough: Bingo! Failure recreated. And now to finish our test: install the latest HTML::Entities and see if that clears up the error: The solution will be to specify some version of HTML::Entities that is older than v1.27 but not necessarily the current one (v3.69) in the Makefile for HTML::AutoTag. I will start by requiring v3.69 and in the unlikely event that some server cannot use it (highly unlikely) then i can fall back on some older version. I am quite confident v3.69 will work fine for all, however. A new version of HTML::AutoTag will be uploaded the PAUSE, and after a few days a new version of Spreadsheet::HTML that specifies that version of HTML::AutoTag will also be uploaded. The lesson here is not necessarily to always specify certain versions in your dependencies, but to pick and choose the right time to solve bugs that have minor consequence. 2 fails versus 115 passes and the error is within a very minor feature set -- what's the hurry? 🙂

Adding Twitter Bootstrap to Rails (part 2)

When i last left off, i was stuck with an unideal solution for displaying form validation errors -- a very important part of collecting user input on the Web. Furthermore, this unideal solution broke the form layout itself. Rather than start hacking into the source code of Rails, i decided to search the Web for other souls that wanted to "add twitter bootstrap to ruby on rails" ... This led to a discovery of the following article: Twitter Bootstrap and Rails, which proved to be an invaluable source to my edification. The key ingredient was the concept of 3rd party form builders -- gems that replace the default Rails form builder. The author of the article recommended SimpleForm and Formtastic, but neither seemed to solve my problem. My issue now is two-fold: 1) produce well-formed form validation errors and 2) deploy Twitter Bootstrap assets into my web app. Looking at solutions for Problem #2 first, i found a number of gems that purport to be a solution: And there are even more. And yes, we are going to go over each one. You see, the one common feature i have observed from the number of blogs that discuss combining Bootstrap with Rails don't seem to discuss Problem #1. To be continued ...

Adding Twitter Bootstrap to Rails (part 1)

Man i love me some Twitter Bootstrap. It's the bomb. I don't care if you convert or not. It's mine. Thhhhpppppppttttt!!!! Jog off ... Still here? Awesome! 😀 If you've been reading along so far (i'm obviously talking to myself now ...) you know that i have been implementing the Depot example from Agile Web Development with Rails (4th ed.) and i have been very excited about Ruby on Rails in general. But i ran into a snag when trying to replace the author's stylesheet declarations with the ones used by Twitter Bootstrap. The author selected class names based from the default Rails form helpers -- the default Rails form helpers DO NOT conform to Bootstrap. I realize now that there are better form builder gems "on the market" but i did not realize such initially, as most newbies wouldn't. 😉 But rather than jumping ahead, why not share the journey of discovery? So here goes: I wrapped up Chapter 7 and decided to backtrack to the beginning of the chapter and go about jabronying Twitter Bootstrap (TB) into the mix. The first step was to download the requisite TB files and move them into the respective directories inside app/assets/ and then modify app/views/layouts/application.html.erb to include them ... only to discover that the existing code would automatically include the TB files for me: The files, however, are listed in the generated output in alphabetical order which will break TB components that require jQuery but since i wasn't using any components that required jQuery (yet ...) i would deal with that ... later ... (Such issues sometimes resolve themselves with enough time.) The next step was emptying all lines from app/assets/stylesheets/scaffolds.css.scss so that any generated class and id names would no longer work. Then i went back to app/views/layouts/application.html.erb and modified it to wrap a nice two-column fluid layout around the call to <tt>yield()</tt>: Piece of cake! Now my pages were wrapped in a column and i have a placeholder for adding a left-side vertical menu later. The next step was to modify the generated form and validation errors. I was able to modify app/views/products/_form.html.erb and easily change the existing <div> class names to those that would work with TB, but changing the <form> class name proved to be a bit more tricky: but nothing out of the question. From here, getting the rest of the ERB tags to emit definitions and values for the class, id, for and placeholder attributes used by TB was straightforward and dare i say intuitive. Firstly, it was very easy to wrap the error summary into a dismissible error alert message: And with some digging around in various online documentation and forum Q&A search hits i was able to emit the proper things to produce a nicely aligned horizontal form: But it all came crashing down once i tested the validation error display. The problem was something else was wrapping a <div> tag around both the offending form element label and input control and was controlling the class name which needed to be changed. After digging around i found what seemed to be the best solution, but i was not convinced. The solution was to add the following line to config/application.rb: This does mostly work but now we have presentation logic mixed into the configuration of the view action handler. There has to be a better way, and there is! But first, why doesn't that solution completely work for me? Well, the reason is because even though i now have my desired class name, the handler wraps <div> blocks around the label and the input ... and that breaks the horizontal alignment of the offending controls. (See image.) Sure, you may not mind it but the $Client is surely going to sooner or later. Plus, the placement of the solution itself is totally unideal. What if there was a way to build in TB support like with a magical gem or something ... turns out there is ... to be continued ...

First RoR Project

I went ahead and uploaded my first RoR project to github: This project is simply the example web app from Agile Development With Rails (4th ed.). I am sticking very closely with the instructions but i am using Twitter Bootstrap instead of the author's stylesheets. I am also using Travis CI so i am getting some experience with basic deployment issues: I have a few issues to solve before i should move on, such as obtaining fine control over which stylesheets and javascripts are included and which order they are included in; discovering a proper way to call rake db:migrate - right now i am using a hack: This works and even though bundle install will be implicitly called (again), the build process is aware this instruction has already been run and does repeat the instruction. But it's a hack. There is a proper solution ... 🙂

Comparing Rails to Catalyst

I recall (Central Park in fall ...) man i digress. I recall attempting to learn Catalyst many years ago and being hit with a lot of arcane rules and well ... just plain bizarre usage of Perl in general. I didn't like Mason nor Krang very much either but i managed to learn them. Catalyst just seemed ... nasty. Well, now i really feel like i was correct. Catalyst sucks. And so does Class::DBI for that matter. Ruby on Rails and ActiveRecord blow each counterpart out of the water, respectively. These commands, with no need to edit any code, produced a full MVC driven CRUD interface for a fictitious "products" database (SQLite): So far i am sold on Ruby/Ruby on Rails ...

Moving onto Ruby?

Looks like I am finally making the switch away from Perl. I starting learning Ruby yesterday and so far it is everything i wanted from Perl 6, which has yet to see the light of development day. I am also enjoying Ruby far more than Python, a language i still somewhat despise. The following quote from the 2nd Edition of Ruby Programming by Dave Thomas illustrates why i prefer Ruby over Python:
... Ruby is a transparent language. When you write a Ruby program, you concentrate on getting the job done, not on building scaffolding to support the language itself.
And the following quote from "To Ruby From Perl" illustrates why i feel comfortable switching from Perl to Ruby (rather than waiting one second longer for Perl 6)
Although $ and @ are used as the first character in variable names sometimes, rather than indicating type, they indicate scope ...
But the latter quote warrants further discussion: Ruby is not afraid to use sigils like Perl (Python) but it is also not afraid to challenge the fundamental design choices that i feel really matter as opposed to ones that otherwise serve egos (Perl6). I am not saying the Perl6 community did not make fundamental changes, they did. I am saying they made the wrong changes/choices. Speaking of which, what you just read are all my personal choices/opinions. And as such i don't have to defend them. But i do want to announce that from this day forward i am serious about Ruby.