Meanwhile, back at the farm

So I’ve been messing around with my ruby environment on OS X Snow Leopard today.  I wasn’t sure why, but it looked like the default installation of ruby was interfering with my installed version of ruby.  I have made it a habit to follow the instructions on Dan Benjamin’s Hivelogic web site for installing ruby and rails but having multiple versions of ruby can really mess with TextMate.  The ruby that comes with OS X is in /usr/bin/ruby.  When you go through the installation instructions from Hivelogic, you install ruby at /usr/local/bin/ruby.  In order for you to use the new ruby you have to alter your PATH variable in your command line.  The Hivelogic instructions walk you through doing this.

Here’s the problem, TextMate doesn’t use your command line PATH when it runs ruby.  What it does is run /usr/bin/env ruby and because of this, TextMate will use the PATH available to it.  That PATH isn’t the one you modified when you setup ruby using Hivelogic’s instructions, it’s the one that Finder uses.  You can read more about how that all works with on the TextMate Wiki.  So, during some troubleshooting today, I renamed /usr/bin/ruby to /usr/bin/ruby_old.  That essentially made ruby unavailable to TextMate and the result was the following error whenever TextMate tried to execute ruby:

env: ruby: No such file or directory

So, to fix this you need to tell TextMate to use the ruby and gems that were installed during the Hivelogic installation process.  So here’s what you do:

1. Go to TextMate Preferences
2. Click on Advanced
3. Click on the Shell Variables tab
4. Add a variable named “PATH” with the value “/usr/local/bin”

Here’s a screenshot of what it should look like:

Image via Wikipedia

I’m working on a project where I need to get all kinds of information about dates.  One of the latest puzzles I ran into was how to determine what week of the month a given date is.  I thought of many long ways to do this like iterating through the month and incrementing a counter when I hit Saturday, but that sounded very inefficient and unscalable to me.  So I decided to see if I could figure out how to do it mathematically.  It was a good puzzle and took me about an hour to figure out (math puzzles aren’t my specialty) but I finally got it.  Here is what I came up with:

require 'date'
def get_week_of_month(d, iso?=false)
  dm = Date.new(d.year, d.month, 1)</code>
 
  # i is a format string that sets this to use ISO or not
  i = iso? ? '%u' : '%w'
 
  # x is the day of the week of the first day of the month
  x = dm.strftime(i).to_i + 1
 
  # n is the day number of the month
  n = d.day
 
  # o is an offset used to calculate weeks for months that don't start on
  # the first day of the month. It essentially makes the month always start
  # on Sunday (or Monday if ISO).
  o = (n+(x-1))
 
  # r is the remainder indicator. We have to add 1 if there is a remainder
  r = (o%7) == 0 ? 0 : 1
 
  return ((o/7) + r).to_i
end

The first thing I did was assume that all months start on Sunday which gave me a nice grid to play around with. Then I started playing with the math and realized that if I divide any number by 7 that got me really close.  If I dropped the remainder, then add 1 that did it every time.  Well, almost.  Saturdays were then off by 1 because they evenly divided into 7.  That was easy to fix though. I just rounded up the remainder to 1 if it was there and then left it zero if it wasn’t. Hence the “r” variable.

The next problem to tackle was handling the months when the first of the month wasn’t on Sunday.  To do this I figured out there would have to be some kind of offset.  Simple math showed me the offset was the number of the day of the week of the date I was evaluating plus the day of the week of the first day of the month minus 1.  By applying that to the original formula, I essentially reset my calendar to starting on the first Sunday of the month and my original formula began to work again.

The final problem to tackle was supporting the ISO week number standard which has weeks start on Monday instead of Sunday.  That was easily solved by just changing the beginning of the month reference point.  In ruby, and probably many other languages, that just meant changing the format string from a %w to a %u.

Anyway, this was a really fun puzzle and now I’m glad it’s over so I can move on.

I’ve searched high and low in the ruby documentation for a comprehensive list of the Date and Datetime formatting strings and haven’t been able to find it.  Because I use this so often, I decided to post it on my blog for my own reference.  I hope any other readers will find it helpful as well.

%a – The abbreviated weekday name (`Sun’)
%A – The  full  weekday  name (`Sunday’)
%b – The abbreviated month name (`Jan’)
%B – The  full  month  name (`January’)
%c – The preferred local date and time representation
%C – century number (the year divided by 100 and truncated to an integer, range 00 to 99)
%d – Day of the month (01..31)
%D – same as %m/%d/%y
%e – day of the month as a decimal number, a single digit is preceded by a space (range ‘1′ to ‘31′)
%g – like %G, but without the century.
%G – The 4-digit year corresponding to the ISO week number (see %V). This has the same format and value as %Y, except that if the ISO week number to the previous or next year, that year is used instead.
%h – same as %b
%H – Hour of the day, 24-hour clock (00..23)
%I – Hour of the day, 12-hour clock (01..12)
%j – Day of the year (001..366)
%m – Month of the year (01..12)
%M – Minute of the hour (00..59)
%n – newline character
%p – Meridian indicator (“AM”  or  “PM”)
%r – time in a.m. and p.m. notation
%R – time in 24 hour notation
%S – Second of the minute (00..60)
%t – tab character
%T – current time, equal to %H:%M:%S
%u – weekday as a decimal number [1,7], with 1 representing Monday
%U – Week  number  of the current year, starting with the first Sunday as the first day of the first week (00..53)
%V – The ISO 8601:1988 week number of the current year as a decimal number, range 01 to 53, where week 1 is the first week that has at least 4 days in the current year, and with Monday as the first day of the week. (Use %G or %g for the year component that corresponds to the week number for the specified timestamp.)
%W – Week  number  of the current year, starting with the first Monday as the first day of the first week (00..53)
%w – Day of the week (Sunday is 0, 0..6)
%x – Preferred representation for the date alone, no time
%X – Preferred representation for the time alone, no date
%y – Year without a century (00..99)
%Y – Year with century
%Z or %z – Time zone name
%% – Literal character %

To use these formatting strings use the strftime and strptime methods of the Date and Datetime classes.

Apple Insider posted a short writeup about the latest benchmarks on Internet Explorer 8 pre-release build. These two graphs show the benchmarks and you can read the ZDNet report that generated the benchmarks here.

I believe that not making javascript rendering one of the primary focuses of IE 8 is a huge oversight by Microsoft.  It also seems out of whack with there interest in jQuery and its integration with Visual Studio.  As web sites move more and more to a JavaScript heavy implementation the ability for the browser to quickly parse and execute JavaScript will become a key reason for picking it as your primary browser.

I’ve already seen issues with this in BlackBoard, the Learning Management System (LMS) at BYU-Idaho.  Blackboard’s most recent release of their GradeCenter underwent a major overhaul to add AJAX in a more rich implementation.  It wasn’t long before the faculty started to complain about how slow it was.  I did some initial tests and didn’t notice any slowness that was significant.  After doing some research I realized that I was using Firefox 3 and the faculty were using IE (6 and 7).  After doing some very unscientific benchmarking on my own I found that the GradeCenter would load in under 3 seconds on average in Firefox 3.  On Internet Explorer it was taking up to 20 seconds!  This research led us to start recommending Firefox 3 to faculty, a decision that was not easily swallowed by the IT department.

I was really hoping that IE 8 would improve their JavaScript rendering to help us support this issue, but alas, it is not to be.  In the meantime, I will continue to encourage individuals to move from IE to Firefox or Chrome if they want a better / faster browsing experience.

Developers are lazy and that is a good thing. Developers that aren’t lazy are bad developers. What am I talking about? It’s simple. Good developers are always looking for ways to simplify what they are doing. The result is simplified code that is very effective and reusable. Without this, we would all still be writing code in Assembly.

That being said, there are good ways and bad ways to be lazy. One of the most common ways is to do as Dreamweaver does and provide code generators for common programming tasks. Beginning developers love this approach and do benefit from it to some degree. For example, code generators are like built in tutorials that can show how to perform a common operation. For example, let’s say I need to run a query on a database and return the results. I could go to the PHP Website and start to look around for instructions on how to do that, but that could take hours if I’m really new to php. Instead, if I’m using a code generator, like Dreamweaver, I simply setup my database in the UI and then choose an option to perform a query. Using a simple UI that uses language that newbies understand I can setup my query and when the wizard is finished I have a bunch of code in my doc that will perform the query I need. When I look at my website it works great and I’ve saved a ton of time.

But what if the website doesn’t look like, or work like I wanted? Herein lies the biggest problem with code generators. Newbies can use them as a crutch instead of learning the language like they should. When things break or don’t work the right way, they are stuck. Then come countless hours stepping through code that looks like it was written in greek trying to figure out what the problem is. Not my idea of a good time

An alternative approach to code generators for streamlining development is utilizing frameworks. Frameworks are simply libraries of code that abstract menial and repetitive coding tasks and also provide you with a more organized way of doing things than from scratch. Although they do automate things for you, they don’t rid you of the privilege of writing your own code. Another advantage they provide is that they take care of a lot of the gotchas that newbies often run into when trying to learn a language for the first time.

Although frameworks can also break and leave you hanging, in general they work really well. In addition, if you are using a popular framework then there is bound to be a blog post or a discussion thread online where someone has run across the issue and has found a solution. Frameworks typically follow a “convention or configuration” approach and because of that, the learning curve can be a little steep on some of them. They don’t, however, hide you from the language itself and in most cases, will demand that you learn the language really well to use them effectively.

My experience with frameworks is that they can get you up and going really quickly and in the process teach you a great deal more than code generators about the language you are coding in. As such, for a teaching tool, they are far more effective than code generators. After spending a month in a framework, you will have a much better running product and a more in-depth understanding of the language by using a framework than you possibly could using a code generator.