You are here

Archive for No name

Changes Because of Piston 2.0

As mentioned elsewhere, I maintain the local copy of this site through a combination of subversion and Piston. Sometime in the past couple months, version 2.0.1 (and now version 2.0.2) of Piston was released and, when I updated my local Ruby gems, ended up upgrading.

Piston 2 allows for the ability to use Piston with Git as well as subversion. This requires significant changes to the backend. So in order to use Piston 2 with existing Piston-managed copies, you must first upgrade those copies to use Piston 2's new format. This can be done with piston upgrade.

Piston 1 stores all of its backend information as properties within subversion. Piston 2 instead saves it to a special file, called .piston.yml, since properties are not available with Git. To use this with a public site, access to .piston.yml should be blocked. This can be done with this directive:

RedirectMatch 404 /\\.piston.yml$

After doing all of this, I encountered a bug with Piston. Every time I tried to update a Piston-managed directory, I got an error like:

/usr/lib/ruby/gems/1.8/gems/piston-2.0.2/lib/piston/svn/revision.rb:30:in `check
out_to': Did not get the revision I wanted to checkout.  Subversion checked out
280, I wanted 280 (Piston::Svn::Revision::InvalidRevision)

280 is equal to 280, isn't it?

I'm not sure why this behavior would manifest. I did not see anything on it. I suspect it may be an issue with the upgrade process. A simple, hacky solution was to change line 29 from:

          elsif revision != $1.to_i then

to:

          elsif revision.to_i != $1.to_i then

(I haven't filed a bug report on this but I will shortly.)

After doing this, Piston ran normally as expected and I could install the pending updates for the Drupal modules.

Haskell, It Is

I've decided that I will start functional programming with Haskell. I've delved deep enough into the Learn You a Haskell for Great Good! tutorial to really turn back. In comparison, the available "starting" Erlang documentation seems daunting.

It also helps that Real World Haskell, published by O'Reilly, has gotten rave reviews and won the 2008 Jolt Product Excellence Award. (Why this isn't on O'Reilly's product page for the book, I don't know.) Remember what I wrote about books?

This is not to say I've written off the other languages I was looking at. Erlang, Scheme, and Scala are definitely leaders for the next language. In fact, before starting with Haskell, I want to take a short detour and read The Little Schemer first. I've heard good things about the book and since I'm about to delve into functional programming, I want to read it. The worst thing that can happen is it turns out to be a waste of time and I'm sure it won't be.

(Edit: I just noticed that the title of this article was incorrect. This has been corrected. Sorry for the issues.)

Whither Scala?

It's April and that means that I should look at the new programming language for the year soon. Thus far, my leading candidates for the next one were all functional languages (in particular, Erlang, Haskell, or Scheme). Then, yesterday, through Slashdot, I read this interview with the Twitter team discussing replacing some of their Ruby backend stuff with Scala.

I'd heard of Scala before. Some time ago I ran across Ricky Clarkson's post explaining what (0/:l)(_+_) means. (For those of you who don't want to read the post, the Ruby equivalent is something like l.inject( 0 ) { |x,y| x + y }.) A little poking around lead me to David Pollak's post comparing Ruby on Rails to his Scala-based Lift framework. (However, it's been over a year since then and I think that Rails has made some improvements but I have no hard data or anything really beyond my respect for the Rails developers since I think they're pretty smart people.)

I have been going through the online tour of Scala periodically and some of the features look interesting. The major issues I have currently are the use of the JVM and the typing overhead of static typing but both are minor. It definitely has allure.

As I think about it more, I am not sure that Scala is the correct way to approach functional programming for the first time. In his comparison of Scala and Erlang, Yariv Sadan calls Scala "an OO/FP hybrid." This certainly seems to be true. And while being a hybrid is not necessarily a bad thing, it may not be conducive to properly learning functional programming. It's like learning to swim for the first time. If you're in the shallow area of the pool, learning to properly swim isn't that big a deal because, if something goes wrong, you can find the bottom of the pool and stand up. If you're in the deep end of the pool, you'd better know how to swim or find a way to get out of the deep end real fast.

The proper thing to do then might be to learn a proper functional language (Erlang, Haskell, and Scheme all have their fair share of proponents) and use those in their own right for a while. And then, next year, having some of that understanding and practice, come back and look at Scala and see how to merge OO with FP using Scala.

Why I'm Moving Away From Perl

When doing system scripting, I historically tend to settle on Perl. This is a habit I am trying to break.

Perl is quick and dirty and gets the job done. And the scripts I've written in Perl certainly look like it. I looked at a Perl script I wrote about six years ago and... I have no idea what it's doing! I'm sure I could figure it out if I spent a few minutes going through it (including blank lines, it's only 125 lines long) but that's beyond the point. I am reminded of this joke comparing Perl and Python.

I have some Python scripts already in use. Perl's object model is painful to me and I have a hard time making use of it. So where I've decided to use objects because it makes more sense that way, I have used Python. And I find that the scripts using Python have a little more readability when read in the future. (To verify this, I looked at a script I wrote over seven years ago.)

The vast amount of existing scripts in Perl require me to continue to use it in the near term. However, as I touch the scripts less and less, the less I remember about them and, therefore, the higher the cost if I need to make changes to them for any reason. And since I would like to minimize the amount of time spent trying to reunderstand code, I think moving away from Perl makes the most sense.

What I haven't decided on is what language to use in the future. This will require further testing and gaining more experience with other languages in doing the sort of tasks I use Perl for. However, I will eventually have that experience so Perl's days are numbered.

Wikis, ./configure, and make

When installing packages from source on *nix servers, I find I need to compile the software identically across several machines. (I do realize that this would be easier if I built a single package and then installed that using the OS/distribution package management tools but that's for another day.) Or sometimes I need to upgrade a package and keep the configuration information the same.

On my personal webserver (which runs this site), I have a directory that contains scripts that include the ./configure command (or the equivalent for the package) and the options for that command. Whenever I need to rebuild a package that has such a script, I just need to run the script.

However, there are some packages that lack such scripts. In these cases, I have to go to the old source directory, check config.log to find how I built it last and then use the same options in the new directory. (Or the same directory if I am reconfiguring the same version of the package.) I find that due to a feature of config.log and either screen or my SSH client that I have to retype parts of the ./configure command-line because it has wrapped around and the wrapping isn't being honored.

The latter is clearly non-optimal. The former is better but is limited to a single machine. If I need to build a package in a like manner on a different machine, I either have to copy the script or recreate it on the new one. Either way, this process is somewhat cumbersome.

An improvement I am trying is documenting the build process used for all software on a wiki. This provides a central (and version controlled) repository for the information that I can refer to independently of the SSH session. It does require a browser but this is not an issue in today's world of large screens and the movement towards using multiple monitors. (If screen real-estate is at a premium or you're not at a workstation, most wikis render well in lynx. If using ikiwiki, you could even check out the repository and view it with less.) Also, if multiple machines have the same software installed but require slightly different configurations, you can make the note in the wiki entry so you can easily see the differences. Further, since wikis implement revisions, you can see how the options have changed over time.

The challenge is making sure that all packages get documented correctly. However, once in the habit of documenting the process, it should become easier to make sure that future packages are documented as well.

Implementing A Distributed Wiki

In my last post, I mentioned wanting to set up a personal wiki. I thought about it more this morning and realized a standard, centralized wiki would not work as well as I had originally thought. In order to properly use a wiki, I need to have access to it offline on my laptop.

Doing a Google search for "distributed wiki" returned this post which mentioned ikiwiki. ikiwiki can use a version control system as its backend for articles. Using its support for git provides for a distributed wiki (in the same sense of "distributed" as git is a "distributed" version control system). There are even instructions on how to do this.

I have ikiwiki set up on the webserver now. I encountered some issues with the web update functionality because I do not allow setuid scripts to run on the partition with the websites. This has resulted in some non-optimal permissions but I hope to fix this in the near future. (Or, at the least, when I rebuild my webserver.)

The one thing I don't like about ikiwiki is needing to rerun the setup script every time I want to change something. However, this shouldn't be a problem once I'm done tinkering with the configuration. I suppose I'm just spoiled from using a lot of PHP web applications (like Drupal and phpBB), and perhaps interpreted languages in general, that having to run a command to "make" the application seems cumbersome.

I'm still working out the logistics of the laptop-side of this. I'm tempted to run the laptop's copy of the wiki repository on a USB flash drive so that way I can even access the files on other machines entirely. (Running git might be hard but text editing should still work.) The issues with this are finding a format that all OS X, Windows, and Linux like that is not FAT32. With the appropriate software, ext3fs may be the winner but this is another topic for another day.

Edit, 03 March 2009: After some thought, I am concerned that the title is misleading. So if you've come here looking for quick instructions on how to set up a distributed wiki:

  1. Download ikiwiki.
  2. Install ikiwiki.
  3. Setup ikiwiki.
  4. Set up a git repository with ikiwiki-makerepo. (There are directions on how to do this near the end of the "by hand" setup instructions.)
  5. Configure ikiwiki to use the git repository.
  6. Test ikiwiki.
  7. Repeat the above for all other machines you may want to run the wiki on. Note that there may be special configuration needed on machines that may be offline, e.g. laptops.
  8. Enjoy your new wiki.

Excerpts From My To-do List

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.

Frustration Of My Own Making

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.

It's Harder Than It Looks

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.

How To Offer Poor Customer Service

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.)

Pages