Re-writing and copying HTML files with Ruby Refactoring

I submitted a previous post on re-writing and copying HTML files with Ruby. I could not let that rather large and unruly script go as is and had to refactor, a.k.a. extract, much of the script code out into a ruby class.

Here are the goodies.

Php 4 Quick and Dirty Model and View Separation Example

I was coding a site in Php and needed to display announcements and needed a quick and simple way to do this. Moreover, I wanted to keep the design in the good ole MVC pattern.

See how I, at least somewhat, did this here.

Re-writing and copying HTML files with Ruby

A personal goal of mine is to read through the Bible this year on a daily basis. To assist me in this I have an HTML file for each month of the year with links that call a JavaScript function passing the text-section value and then putting the value into a URL QueryString and opening a new window with the loaded URL. This worked OK but because the JavaScript opens a new window, the daily links were not showing with the visited style that I set in the CSS file. Here is where Ruby came in.

I thought about just rewriting the HTML but having to create 12 separate files, one for each month, was not what I wanted to do. Why not, as I am learning to use Ruby, use it to parse the existing HTML into a new file, a txt file in this case and then run script to rename the new into the old files, with links that use the traditional target attribute to open a new browser.

Click here to see what I did to parse the existing HTML files into TXT files.

Click here to see the copy of the TXT into HTML files.

What are we thinking?

Okay. So now you have inherited someone else’s code. You typically review the automated tests (if any), available documentation (if any), and then the code itself. It is here that at lease one person in each development group will say, “What were they thinking? This code sucks.” It is at this point that I cringe. Yes, the code may not be the most elegant. But to just simply state, in your self-proclaimed superiority, that the previous programmers were stupid is both unprofessional and short sighted. Don’t misunderstand me. I am not saying that in the name of being nice to overlook and tolerate crappy code. My point here is that there is more than initially meets the eye.

What got me thinking about this was an article that I ran across by Dave Hunt and Andy Thomas entitled, Software Archaeology. In it the authors state:

Archaeologists generally don’t make wisecracks about how stupid a particular culture was (even if they did throw dead bodies into the only good drinking well). In our industry, we generally don’t show such restraint.

As stated above, it has been my experience that in the software development field, we are too quick to criticize. They then go on to write:

But it’s important when reading code to realize that apparently bone-headed decisions that appear to be straight out of a "Dilbert" cartoon seemed perfectly reasonable to the developers at the time. Understanding "what they were thinking" is critical to understanding how and why they wrote the code the way they did. If you discover they misunderstood something, you’ll likely find that mistake in more than one place. But rather than simply "flipping the bozo bit" on the original authors, try to evaluate their strengths as well as weaknesses. You might find lost treasure—buried domain expertise that’s been forgotten.

Therefore instead of just asking, "What were they thinking?” we need to consider “What and how are we thinking?" to get the most out of the code that we sometimes unearth and/or must excavate.