You are here

Home › Archive

February 2009

Books

2 February 2009 - 10:40am — Chris Ess

Books are probably my preferred medium of learning. I prefer books to the degree that I chose to look into Ruby last year rather than concentrate on Python because of the availability of good quality Ruby books and a dearth of good Python books.

I know that I prefer books partially because of personal, fluff reasons. I know books. Books have a physical presence. Books are old-fashioned, just like me sometimes.

Books are "offline" resources. If I read something in a book and need to go back to it, I can pick up that book, page to where it was, and reread it. As long as I have physical access to a book, I can find that information at any time, no matter where I am. Computer resources instead rely on the presence of a computer. I tend to forget to bring my aging laptop with me so I can't rely on that. Internet resources rely on being connected to the internet, which is not likely in some circumstances, such as on a train.

Books are "permanent" resources. Barring physical destruction, a book is going to last a reasonably long time. Texts dating back at least a millenium are known to still be usable and readable (assuming you understand the language). Internet resources are, by comparison, "transient." A web page that you look at today may not be available tomorrow. The site maintainer could take the site offline. The author could delete the page. The page could be moved as part of a site reorganization and the maintainer could fail to put redirects in place to send visitors to the new location.

Books are more useful to me than web browsers for accessing many things at once. However, this is likely because I only have a single screen for development. If I had multiple monitors (two, or even Jeff Atwood's three), this may not be as much of an issue.

Books have their drawbacks too. They're heavy so they're not really portable. I think two decent-sized books (thinking the hardback first edition of W. Richard Stevens' Advanced Programming in the UNIX(R) Environment and Martin Fowler's Refactoring: Improving the Design of Existing Code) are heavier than all but the largest laptops. Computers clearly win for information density. (The PDF for the second edition of the Pickaxe book (or, if you prefer, Programming Ruby) is not quite 6 MB. Since you can get light, less-than-a-pound flash drives that hold 8 GB, you could carry over one thousand books on a key chain.)

The search function of books sucks. Unless you know about where the content you want to find is, you have to consult the index and then use that to try to find it. There's no ready indicator of fluff versus desired content. And, in the end, you are at the mercy of whoever created the index. If they did a poor job of making the index, you will encounter difficulties finding what you're looking for. The internet clearly wins here. Google can search a vast repository of human knowledge which easily contains more information than some libraries.

There are some compromises. Several publishers offer their books in eBook or PDF format. This increases portability and, in some cases, search as well. I imagine you could possibly write a local search engine to search PDFs if you can access their content. O'Reilly and Pearson Technology Group created Safari Books Online, a service by which you pay money every month (or year) to get internet access to a large number of books. $42.99/month gets you unlimited access and there are cheaper although limited options. I personally find this service invaluable for what I do but your mileage may vary.

I personally believe that books and computers (including the internet) will eventually balance themselves out and complement each other. In addition to services like Safari Books Online, I expect most of the short-term information, e.g. what goes into books like Python Cookbook, will eventually end up online. A wiki equivalent of O'Reillys Cookbook or Hacks series is where I see that going. The longer-term information, more "language agnostic" topics, e.g. Refactoring or the Gang of Four's Design Patterns will continue to be seen in book format. Books will never completely vanish, not even from the developer culture.

Random

Drupal, Subversion, CVS, and Piston

4 February 2009 - 5:36pm — Chris Ess

When I decided to start this blog, I decided to maintain the site almost exclusively in subversion. Having worked with this for a few weeks, I've found it to be much easier than the "traditional" method of setting up Drupal.

I'm not the only one to do this. Agaric Design's approach was helpful but left me scratching my head.

To do this, first, I created an area for Drupal in the vendor directory of my repository: svn mkdir drupal/5

I use a vendor directory because I have some projects that, while unrelated, rely on the same software. I could use a vendor branch in each project but I decided that more overhead than I wanted. (If I had a single repository per project, vendor branches would be fine. Instead, since I have multiple projects in a repository, a separate vendor directory makes more sense.)

(For those wondering, the 5 denotes the version of Drupal. Versions 5 and 6 are incompatible so it's necessary to separate the Drural code and modules by major version.)

Before I can import Drupal core into my repository, I need to check it out from Drupal's CVS. So in the directory I created and, following the directions, I run:

cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal co -r DRUPAL-5--14 drupal

Now, to add it to the repository:

svn add drupal
svn commit

To import a module, the steps are mostly the same but using the different CVS parameters: (the globalredirect module used as an example)

cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -r DRUPAL-5--1-4 -d globalredirect contributions/modules/globalredirect
svn add globalredirect
svn commit

Now, to add this into the site, create a repository for the site. I use 'web' as the main directory of the site and I want to install Drupal in that directory. So in the repository, I run:

svn update
piston import http://svn.ithiriel.com/svn/vendor/drupal/5/drupal ./web

Piston is a tool that synchronizes including code from other repositories or locations. It works like svn:externals but allows for local modifications and tracking those. This is useful since each Drupal site has different configuration files.

Piston requires the local directory to be at the latest revision. In almost all cases, this requires running svn update before running Piston.

To install a module, say the globalredirect module from before, I go to web/sites/all/modules and check it out in the same fashion:

svn update
piston import http://svn.ithiriel.com/svn/vendor/drupal/5/globalredirect ./globalredirect

This may seem a lot of work to do at first but I'm pretty sure it pays off the next time you need to update the site.

Since I first started work on the site, Drupal 5.15 was released and a new version of the globalredirect module was released. Both of these needed to be updated.

To update the local copy of the original Drupal source, I go back to the directories created before. In /vendor/drupal/5/drupal, I run:

cvs update -r DRUPAL-5-15 -dP

It's necessary to see if any files have been added or deleted. svn status will tell you if there are any. I add or delete as necessary. When the status checks out, I commit it with svn commit.

Back in the repository for the website, I go to the directory above the web directory and run:

svn update
piston update web
svn commit

Now the upgrade for Drupal core is done. All that's left to do is run the update script. All of that done with very little fuss.

To update the globalredirect module, I go to /vendor/drupal/5/globalredirect and run:

cvs update -r DRUPAL-5--1-5 -dP

As for the core, I see if any files have been added or deleted. When everything is ready, I commit the revision.

To update the module on the site, I go to web/sites/all/modules in the site's repository and run:

svn update
piston update globalredirect
svn commit

As before, I run the update script and it's done.

Upgrading modules isn't such a big deal but upgrading the core tends to feel like a pain. Being able to do it with a set of easy commands makes the process much more tolerable.

There are two issues with this method though.

The first is that when checking directly out of the Drupal CVS, the version numbers will not be set correctly. If using Drupal 6 or the update status module for Drupal 5, the CVS deploy module is required so the version numbers can be determined correctly.

The second is that this process exposes the CVS and .svn directories to the public. However, I can deny access to these with Apache with these directives:

RedirectMatch 404 /\\.svn(/|$)
RedirectMatch 404 /CVS(/|$)

(For those following along, if you do not have access to the Apache configuration file, the documentation for RedirectMatch indicates that it can be placed in .htaccess files. I haven't tried it so I make no guarantees.)

Edit: Made some grammatical and wording changes because I wasn't happy with the originals.

Drupal
Version Control

Touch-typing

9 February 2009 - 2:01pm — Chris Ess

My dirty secret (well, not secret much longer) is that I don't touch-type in a traditional sense. I do type reasonably fast and I do type with more than two fingers but it's not touch-typing. I don't follow the standard home row method that is taught in typing classes everywhere.

I've had plenty of chances to learn how to touch type and, to be honest, I squandered them. I'm certain that some of my teachers throughout middle and high school would love to hear that, fifteen to twenty years too late.

The issues I have with my typing, compared with normal touch-typing, is that I have a comparatively lower (but not significantly so) accuracy rate and sometimes I find myself looking at the keyboard.

Jeff Atwood states "We are typists first, programmers second." This is true for system administrators as well, although perhaps less so for those who work solely in a Windows environment.

I used to say "Well, I type well enough, right?" However, Steve Yegge says "If you have two hands, then 70 wpm, error-free, is easily within your reach." And while I might have 70+ wpm, I'm certainly not error-free.

What most people don't realize is that typing errors cost. As if to underline my point, I made an error when typing that sentence. I originally typed "that typiung er" and then I noticed, backspaced back, fixed it to say "that typing" and went on with the rest of the sentence. Fixing errors breaks flow and costs keystrokes. It cost six keystrokes to backspace and remove the error and then five keystrokes to retype what I had erased. (I could have kept the cost to eight keystrokes if I'd been paying attention: Left arrow 6, delete 1, end 1.) Eleven keystrokes is more than a word and possibly might be counted as two by most wpm counters.

If I can improve, it behooves me to do so.

Since I was waiting for something to finish running in the background, I decided to practice for a bit. I loaded the TI-99/4A emulator and started the Touch Typing Tutor cartridge. Touch-typing has not changed significantly over the past thirty years so I figured this should work as well as anything else.

What surprised me most going through even the basic exercises is that I had to think about which key to press. Being asked to type 's' made me have to remember which finger was over the 's' key. As it went on, I was hard-pressed to keep myself from reverting back to my existing habits just so I could finish it. By the end of the second sublesson, my hands hurt although that could have been a posture issue.

Tonight, I'll do the same thing again. Until I'm no longer thinking about which finger to use, I'll keep doing it these sublessons. Then I'll do the next one. And maybe, in the end, I'll have this figured out.

Random

Practicing TDD

11 February 2009 - 1:04pm — Chris Ess

I have been rereading Thomas Limoncelli's Time Management for System Administrators. One of the points Limoncelli makes is: "[P]sychologists tell us that it takes 21 days of doing a new behavior to develop it into a habit." Give or take a few days, of course.

Test-driven development (TDD) is something I keep revisiting. I have Kent Beck's book on the subject and have read it at least twice. I have tried doing TDD on at least four separate occasions but I seem to stop usually a few hours or a day into the process.

Mark Mzyk wrote of having similar issues with TDD. I disagree with his statement that the issue with TDD is a lack of experience. Instead, I think it has to do with a lack of practice. If you don't do it consistently for any length of time, say three weeks, you're not going to adhere to it. If you follow it, even if not deliberately, you eventually find yourself, as Peter Harkins put it, "drifting into test-driven development."

I think it's kind of like learning to touch-type properly. It's painful and difficult and slow now because I lack experience. As I said before, I spend time actively thinking about which finger should be used to press which key. However, even just a few days into it, I find I spend less time thinking about it.

"How can I practice TDD?" I ask myself. Well, my big thing recently has been problems from Project Euler. I can use it there!

Most of the problems from Project Euler provide a sample test case. For example, problem 1 states:

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.

Find the sum of all the multiples of 3 or 5 below 1000.

From this, I know that we are solving for the sum of all multiples of 3 or 5 below 1000. We also know that the sum of all such multiples below 10 is 23. This means that I can set up a test script:

  1. require 'test/unit'
  2. require 'euler1'
  3.  
  4. class TestEuler1 << Test::Unit::TestCase
  5.   def test_euler1
  6.     assert_equal( 23, euler1( 10 ) )
  7.   end
  8. end

Running it complains that it can't find a file for euler1. After touching euler1.rb, it complains that there is no method euler1. And after each new error, more changes are made until, eventually, euler1.rb looks like:

  1. def euler1( n )
  2.   23
  3. end

and the test passes. This obviously won't answer the question correctly but doing this proves that the unit testing framework works. It also proves that it considers 23 to be equal to 23 which indicates that there are no silly math errors in the language interpreter, at least at this point. From here, I know I can implement an algorithm and as long as it meets the given criteria, the test should pass. If I'm uncertain about this, I can find other points to test as well. The values for any given n up to 58 are listed in sequence A126592 at The On-Line Encyclopedia of Integer Sequences.

Since this process appears to work for one problem, it should work for all of them. I'll try it and see how it goes.

Random

How To Offer Poor Customer Service

13 February 2009 - 4:20pm — Chris Ess

Customers judge the quality of customer service based on their expectations. So, in order to offer poor customer service, fail to meet to your customer's expectations.

Let me share with you the worst customer experince I have had recently:

I purchased something with a credit card Wednesday morning. What I purchased is irrelevant. I've purchased the same product before with that card.

This time around, something about this transaction was flagged by the credit card company. I came home to a message from their fraud prevention service asking for me to return the call as soon as possible. It was an automated message, complete with taped voice and a low quality speech synthesizer mixed in where the information differed between calls. Given the nature of the call, this didn't surprise me.

So I call the number that was left on the answering machine. I navigate through a bunch of options to verify the card in question. Then I am given information about the charge and asked to push a button on the keypad to indicate whether or not the transaction was authorized. Since it was, I pressed the appropriate button and the process ended after another canned speech.

The entire process took a couple minutes and was entirely between me and this computer on the other end.

There was nothing horrible about the steps in the process. If anything, the process was too streamlined. "Press one if this is the phone number on the information for the credit card." "Press one if you are the cardholder." "Press two if this is an authorized transaction."

What bothered me most about the process was that it was completely automated. At no point did I interact with a person. During the process, I expected to interact with a real person. Every other call I have made to a credit card company has featured a real person at some point. (The only exception has been when I called to my balance which I haven't done for at least seven years.) I expected to need to say "Yea, verily, this was an authorized transaction" while talking to an operator and being recorded. If nothing else, this would cover the credit card company in case of legal issues. Instead, I got the computer.

My expectation was that I would deal with a real person at some point. At some point in the process, my identity would have been challenged and I would have needed to present a recorded statement. What I received failed to meet these expectations. As a result, I feel that the customer service experience was poor. Further, because the perceived quality of service was so poor, I am inclined to regard the company poorly. Since my identity was never challenged, what's to stop my roommate from "borrowing" that card, purchasing things, and then dealing with the fraud prevention hotline himself before I even find out about it? I come away from the experience feeling that the fraud prevention hotline is just a fake system they have set up to make their customers feel good.

If I had dealt with a real person at some point, my expectations would have been met. Even if it were a mediocre experience with that person, I would still have had my expectations met and I would have come away regarding it as sufficient customer service. However, with no interaction at all, they failed to meet my expectations and I regard the customer service as being poor.

(In defense of the credit card company's system, if this had been about an actual fraudulent transaction, I'm sure I'd feel differently because my set of expectations would have been different.)

Random

It's Harder Than It Looks

16 February 2009 - 9:41am — Chris Ess

The problem with practice is remembering to practice. This is especially true if you are trying to practice as a way to break a bad habit.

It's been a bad weekend for me. I forgot to practice touch-typing. And while I keep starting with tests for my Project Euler problems, I keep slipping to implementing large parts of the algorithm without further testing.

At least according to Thomas Limoncelli, "[P]sychologists tell us that it takes 21 days of doing a new behavior to develop it into a habit." Twenty-one days doesn't seem that long, does it? It's only three weeks, right?

Let's face it: It's hard.

It's not just three weeks of doing it. It's three weeks of making yourself do it. It's three weeks of making sure you don't miss a single day for whatever reason.

This is a common thing for people who decide to start exercise regimens. They start and keep going for a week and then stop. Something comes up and they put it off. And then they put it off again. And... I haven't found a statistic about the number of gym memberships that go unused but it apparently ranks as one of the top ten money drains.

It's easy to say that you need to force yourself to do things day after day, force yourself to think about doing them until you're doing them without thinking about them. It's easy to say this because talk is cheap. Action is not.

Random

Frustration Of My Own Making

20 February 2009 - 10:02am — Chris Ess

I've spent the last two days trying to recompile gcc on my G4 iBook. It hasn't been pleasant and it hasn't worked. And that might be because I didn't do enough research.

In the process of doing Project Euler problems, I reached one where I needed to solve a system of linear equations. For those of you who don't remember what this looks like, it's something like:
$4x+3y = 10$
$7x-2y = 3$

While this is a reasonably simple example and can be solved by hand, they can get significantly more difficult. The standard way for solving problems in this fashion involves using matrices. (If you took a linear algebra class, this should look familiar.)

Coding a naive way to do this is not difficult. Cramer's Rule provides a way to find each value by using the determinant of matrices. (Apparently LU decomposition is faster but it looks harder to implement. I'll go with naive first and then refactor later if I need to.) The determinant of arbitrary-size square matrices can be expressed through the Laplace expansion until eventually 2x2 (or, I suppose, 3x3) matrices are found that can have their determinant determined mathematically.

In consulting Skiena's The Algorithm Design Manual, I found references to LAPACK, a linear algebra package for FORTRAN. This is not useful to me since I'm using Ruby. But if such a package exists for FORTRAN, surely one exists for Ruby.

Linalg is a linear algebra package for Ruby. Or, more precisely, it's a Ruby wrapper around LAPACK. As a result, it relies on embedding a FORTRAN compiler into the package. And this is where the pain starts.

OS X comes with LAPACK already. However, it does not come with FORTRAN support. In order to get FORTRAN support, you need to install software or recompile gcc. Failing to do a proper search and not finding this resource, I decided to compile a new gcc.

gcc 4.3.3 relies on gmp and mpfr. gmp 4.2.1, which, if you don't have it installed, gcc tells you to get from ftp://gcc.gnu.org/pub/gcc/infrastructure/, does not work on OS X. It builds and installs fine and then yields an obscure linker bug when you try to build mpfr or any other software that tries to include gmp. After an hour of fighting with this, I found out that gmp 4.2.1 was not the newest version but that 4.2.4 was. I had no issues with gmp 4.2.4.

Then there has been little love compiling gcc. At some point, gcc creates a spec file which is then used to pass the option -macosx-version-min which causes the compiler to fail. Editing the spec file and removing that lets it continue on before the next pass with a recreated spec file. Fixing that seems to correct the issue again. And then, eventually, there's a point in the build where it just fails. However, this may have been left over from something else so I tore everything down and restarted the process.

It looks like the issue with the spec file could also be of my own making. If I understand this post correctly, the issue might be that I don't have a new enough version of the developer tools installed. This may be possible since I think the version I have is the one that came with OS X 10.4 (and is, therefore, at least three years old).

With the information I've found this morning, I wonder if I could restart the process and have it run smoother. (Although the installable gfortran may be the smoothest option.) I just wish I knew days ago what I know now.

Ruby
OS X

Excerpts From My To-do List

25 February 2009 - 1:35pm — Chris Ess

Like many sysadmins, I have a lot of things going on. This is an excerpt of some of the current entries and an explanation.

  • Look at planners.

    In Time Management for System Administrators, Thomas Limoncelli suggests getting some sort of personal assistant, either analog or digital. Since my current smartphone leaves a lot to be desired and I have an old-fashioned penchant for fountain pens, going the analog route seems ideal. So, to make an informed decision about what to get, I need to know what's available and that entails a trip to a local office store.

    I may use such a trip to look at furniture as well. I'm planning to work on an "office" in the spare bedroom to separate play from sleep. Having read about Mitch Haile's office, I am somewhat inspired. (Although proper furniture is expensive.) And, having just read this, a shredder may not be a bad idea either.

    The hard part about this is actually going out and doing it.

  • Look at shelving.

    As mentioned above, I want to work on assembling a "home office." One thing I want to avoid is having the computers on the floor since it's not good for them and it's not really good for me. I've also damaged cables because of where the computers are and their proximity to the chair. (Not "major" cables fortunately.)

    I don't need expensive shelving, just durable shelving. "Nice" is a bonus. Plastic is out due to static concerns. Lowe's Home Improvement has several options, like this one.

    Like with the office store above, the hard part is actually going out and doing it. I could probably even do them both in the same trip since there's a Staples near the local Lowe's. (Although I prefer Office Depot out of our local office stores.)

  • Install a personal wiki.

    At first, it sounds silly to install a wiki for use as what's little more than an online notepad. However, it seems like it would be a great way to write down things and flesh out ideas with little overhead. I could keep notes as documents on my laptop but that requires having access to the laptop. I'm fine with the requirement of needing to be online to modify it. I have a small Moleskine notebook in my coat pocket in case I need to make notes when I'm not near a computer. (I have also considered getting a portable voice recorder for taking notes as well.)

  • Play with RT.

    In Time Management for System Administrators, Limoncelli suggests using RT as a tracking system. While this won't work for anything on the immediate to-do list, it would help make sure that nothing falls through the cracks.

    I already have RT set up (although I'm not sure the email functionality is working correctly, I'll have to check that) but I haven't done a lot of playing with it yet. I expect that I will end up rereading RT Essentials.

  • Read the books I got this month.

    For some reason, February is usually a big book-buying month for me. Highlights include The Algorithm Design Manual, Code Complete, Programming Pearls, The Practice of System and Network Administration, and Pragmatic Thinking and Learning. This will probably keep me busy until, oh, May.

    There's other books I have which I'm sure I haven't read or don't remember reading. Most of them are still in boxes. I hope to unbox most of them when I'm done setting up the "office."

  • Write a Rails app.

    I actually have a specific Rails app in mind. have mentioned before that I like books. However, I've taken to buying the print book + PDF bundles when I by from The Pragmatic Programmers. I've been saved some by having a PDF of the book when it has not been available.

    Since I can't have all of my print books while traveling but I can have all of my PDF books, I want to have an application I can use to search the PDFs for given content. (For various reasons, it should only be accessible locally from the laptop and only run when I want it to run. However, this isn't an application issue as much as a deployment one.) Ferret, paired with either pdftotext or pdftohtml, should work for the search component. It should be reasonably easy to write. I just, you know, have to do it.

Random