Matt, M.S.

Here is a simple monkeypatch (duckpunch, donkeykick, squirrelbite, etc) to the Date class that easily allows us to calculate the number of weekdays between two dates. I can’t believe that this functionality doesn’t exist in the standard lib, but I’m normally the last person to mess with Date/Time calculations because they are absolute evil.

Drop this sucker into a file named “date.rb” in your Rails app’s config/lib directory and restart.

Usage: Date.today.weekdays_until(some_date_in_the_future)

class Date
  def weekdays_until(date)
    return 0 if date <= self
    count = 0
    self.upto(date){|curr_day| count += 1 if curr_day.is_weekday?}
    count
  end
  def is_weekday?
    self.wday != 0 && self.wday != 6
  end
	
end

I just translated an old PHP function to its Ruby counterpart. I think it really showcases Ruby’s elegance:

PHP Version:

function calc_pct_complete($job_id, $d) {
  $pc = 0;
  $sql = "some SQL query";
  $res = mysql_query($sql);
  while ($row = mysql_fetch_array($res)) {
    $x = total_days($row[start_date], $d) / total_days($row[start_date], $row[end_date]);
    if ($x < 0) {
      $x = 0;
    } elseif ($x > 1) {
      $x = 1;
    } elseif ($row[name] != "X" && $row[name] != "Y") {
      $x = $x * $x;
    }
    $pc += $x * $row[pct_hours];
  }
  mysql_free_result($res);
  return $pc;

}

Ruby Version:

def percentage_complete(date = Date.today)
  self.phases.inject(0.0) do |sum, phase|
    percent_complete = phase.percentage_complete(date)
    percent_complete = percent_complete ** 2 unless %w{X Y}.include?(phase.name)

    sum += (percent_complete * phase.percentage_of_hours)
  end
end

While starting to enjoy Dan Ariely’s book “Predictable Irrational”, I come across a security tag firmly affixed to a page. I purchased this book directly from Amazon; so they have much trouble with shoplifters?

I understand protecting assets, but this ruined a paragraph of a book that I purchased.

Everyone in the Rails community knows and loves Obie Fernandez (or they should). He gave a wonderfully insightful presentation at RubyFringe that everyone should take to heart.

Obie Fernandez – Do The Hustle

Here are the slides from the lightening talk I gave last night at the Columbus Ruby Brigade meeting:
restful_acl.pdf

Since you’re not cool if you don’t have a vector version of yourself on your techincal blog these days, I’ve decided to create one of myself… after a few beers and using only my trackpad. They call Picaso a genius right?

A couple weeks ago I ran a few benchmarks on Passenger vs. Mongrel. I found that Passenger was much slower than Nginx and Mongrel. Today I read that the Rails Wiki is now running on Passenger; my curiousity piqued, I checked out the site.

Much to my surprise, the site was amazingly responsive.

Alright. Did I do something wrong? Perhaps I missed something? I created a fresh Amazon EC2 instance (m1.large if interested), and recreated my earlier Passenger setup. One thing that I did notice that I may have done differently this time was that I might not have installed my gems with the freshly installed Ruby Enterprise Edition (REE).

(Which looks something like this:)

/opt/ruby-enterprise-1.8.6-20080709/bin/ruby /opt/ruby-enterprise-1.8.6-20080709/bin/gem install aws-s3

One other thing might be that I commented out the ‘PassengerRuby’ line when I updated Apache’s config to use REE.

#PassengerRuby /usr/bin/ruby

RailsRuby /opt/ruby-enterprise-1.8.6-20080709/bin/ruby

Either way, I reran the benchmarks and was really quite surprised:

So what does this all mean? Who wins?

Good question.

It seems that both of the benchmarks are slower than those previously run! My conclusion is that results all over the place as network conditions obviously affect response time. For the sake of clarity, I’ve used a 15Mb/2Mb connection for all benchmarks.

This time around REE seems much more responsive than it did before all the while using 1.35 less load than its Nginx/Mongrel counterpart. The Nginx instance seems about as responsive as it normally feels, but the difference in load is quite an eye opener. This information coupled with Passenger’s ease of use make it quite the contender.

I think I’ll try Passenger for a while on my production server. It’s easier to maintain and hell, maybe even faster. I’ll report back with further findings.

Thanks to the Wayback Machine, I was able to find an blog post I posted almost exactly two years ago bitching about users. This article made the front page of Digg (1338 diggs) and nearly melted my home Apache server in the process. I’m reposting it here for posterity’s sake.

Here is the original text:

July 25th, 2006 @ 5:40:18pm EDT | Category: General | 22,672 Views

My rebuttal to the NetworkWorld article “What Users Hate About IT Pros”:

Users are an interesting bunch. While most are very nice and understand that everything in the world isn’t perfect, many demand miracles. Why six somewhat universal IT gripes? Why not?

1. Users Lie – Many times I chalk up user misinformation to a lack of technical knowledge, but Users will also tell you straight-out lies. Perhaps they feel guilty about breaking something, but lying about the symptoms of the problem at hand only further prevent the solution.

2. Management Doesn’t Understand – Bosses understand what the IT Department does, sort of. Yet they control the budgets, personnel, and usually make IT related decisions without input. We are then expected to make it work right off the bat no matter what else might need our attention. Part of the trouble with being an IT Pro is that we are like a movie editor; you only notice us when we fuck up.

3. Perfection Expectation – IT Pros are expected to know how to fix every model of every device ever manufactured. If it has a screen or plugs into a socket, we are expected not only to know how to use it, but also to troubleshoot and fix it. Immediately. Without a manual. Hey, a copy machine is like a computer right?

4. Every User’s Problem is Our #1 Priority – Many Users will run into the IT Department screaming that their “Internet” is broken and it must be fixed immediately. While we understand the pictures of your Mom’s new dog are insanely important, we might be busy doing something that might rank over your issue, like ensuring that the entire company is receiving email, or fighting off an attack from some Korean kid. IT Pros across the world could work eight days a week and never solve every issue.

5. Some Things Just Won’t Work – We program computers with logical instructions, but as everyone knows, they do not behave logically. Not every device can work with every other device. Standards are not standard, as there are different implementations of every standard ever made. I would love to sync your iPod to your cell phone via a bluetooth connection; it should work right? When we say that it cannot work, take our word for it. We are the professionals after all.

6. Personal Pro – We don’t mind answering a question a User might have about their home computer setup, but they must keep in mind that everyone in the company does the same thing. We try to be kind and helpful, but sometimes we are really busy and tired of the grind. If a local IT Pro starts you off on the right path, GOOGLE for the next steps. We do not have the time to hold everyone’s hand fixing their Mother’s 1986 Packard Bell setup. We understand the concept of “Teach a man to fish…”, but Users need to understand that exterior systems are their responsibility.

To be fair, I’m sure that these issues can be applied to any field of work. Hey, we’re all overworked and underpaid, right?