Archive for No name

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.

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.

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.

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.