Friday, June 29, 2012

Another shell script to share

At home I get a lot of use out of the tree command line utility. It gives me a quick and easy way to look at a nested directory structure without having to leave the command line. The computers at work don't have the tree utility, and every so often I really miss it.

So, I wrote my own.

Here's a bash script that is a simplified version of the tree utility.

#!/bin/bash

tree() {
    local prefix=$1
    local dir=$2
    local count=`ls -l $dir | wc -l`
 
    if [[ $count -eq 0 ]]
    then
        return
    fi
 
    local i=1
    local bar="|"
    local nextPrefix="|   "
 
    for file in "$dir"/*
    do
        i=$(($i + 1))
        if [[ $i -eq $count ]]
        then
            bar="\`"
            nextPrefix="    "
        fi
        filename=$(basename $file)
        echo "$prefix$bar---$filename"
        if [[ -d $file ]]
        then
            tree "$prefix$nextPrefix" $file
        fi
    done
}


if [[ -z $1 ]]
then
    dir=`pwd`
else
    dir=$1
fi

if [[ ! -e $dir ]]
then
    echo "Directory $dir does not exist"
    exit 1
elif [[ ! -d $dir ]]
then
    echo "$dir is not a directory"
    exit 2
fi

basename $dir
tree "" $dir

Wednesday, March 28, 2012

Back to school

I've started taking classes as part of the Embedded Systems Engineering certificate offered through UC Irvine Extension. Just last week I finished up my first course in the certificate program. It was the requisite software engineering course that I imagine every such program has. Overall, the course was fairly dull, and I can't say I got much out of it.

The deliverables for the course consisted of a five question multiple choice quiz every week, and four larger assignments. Two of these assignments were research papers, which were little more than book reports based on our assigned reading. The other two assignments were demonstrations of the Hatley-Pirbhai Methodology (HPM). HPM is mostly just a repackaged waterfall workflow, but with a requirements document following a specific structure. None of these were particularly interesting, challenging or fun.

Although the course was rather disappointing on the whole, I can't say I got nothing out of it. Much of the required reading had very little to do with software engineering and instead was more a survey of common hardware found in embedded systems. Not having an extensive background in hardware, there was a lot of new information for me. I now have a much better appreciation for things like system bus protocols, and the details of how DMA works. This was also my first exposure to a digital signal processor architecture, when previously I only was familiar with MIPS and x86 type instruction sets.

Unfortunately, I only got to read about all this, and not actually get my hands dirty, but that's going to change. My second class* starts up this week, which is an intro to embedded programming, and my dev board just arrived in the mail. I haven't had a chance to play with it very much, but I can already tell this class is going to be much better than the last. The AVR board we are using has fun blinky LEDs, but sadly no piezo buzzer to annoy the roommates with.

* You may think it's odd to have the first class in a curriculum to be software engineering, and you would be right. My "first" and "second" classes should have been reversed in order. I ended up taking them out of order because I started the program at an odd time with regards to class schedules. In the end, I think this will turn out for the best. I have accidentally eaten my vegetables first, which means now there's nothing left for me but dessert.

Monday, December 12, 2011

Free Chromebook

I'm on a plane at the moment, flying to Chicago. It turns out, Google is promoting its Chromebooks by offering them free for the duration of your flight. You give them your name, email address and swipe a credit card, and you get free use of a Chromebook and on board wi-fi. This is great for two reasons. First, I can entertain myself with cat pictures and rage comics for the three hours it will take me to get to Chicago. Second, I get to play around with a Chromebook.

I've only been using it for about a half an hour, but already I can say I would not buy one of these. The main reason is that it is just not the right device for me. I mean, it's basically a computer that can only run Chrome. Don't get me wrong, Chrome is a great browser, but I just need my computers to be able to do more than that.

I do understand the use case for a computer like this. Let's say you run something like a large customer support call center. The software needs for your call center could easily be filled by web applications. With something like a Chromebook, if a computer craps out on you, IT can just grab another Chromebook off a shelf and your employee can get back to taking calls.

Unfortunately, even if I were in a position where a computer like this were to be useful, I still wouldn't buy a Chromebook. The experience of trying to write this blog post has been little short of infuriating. The hardware simply does not work well, at all. The keyboard regularly registers double key presses, resuultiing in worrds like thesee. The touch pad is not much better. It will often not register your finger movements at all. I suppose it's possible that these computers have seen a lot of miles, and a lot of different people have used them, but it just makes me wonder how long it would be before my own use would result in similar behavior.

One thing this experience has shown me is the appeal of a netbook. I brought my laptop with me on this trip, and I can see where my laptop would just be too big to comfortably use on a plane. It is also quite heavy compared to this. If I were to travel more, I think something like an Eee PC would be a worthwhile investment. But that will have to wait. I think my next purchase is going to be an Android tablet of some flavor so I can read on the train during my morning and evening commute.

Update: I'm waiting for my plane back to San Francisco, and they have the free Chrommebooks again. I'm just writing to confirmm that this CChromebook has the samme problems that the last one had. Ick. Oh, well. The frustration is worth the free wifi.

Friday, October 28, 2011

Damn it, I'm actually going to do it this time

I have dipped my toe in the water of Linux From Scratch (LFS) a couple times before, but I never followed through with it. Well, I'm making another go at it, but this time I intend to follow through. I'm applying to grad schools to study operating systems, and I'm recently unemployed which gives me plenty of free time. I also have two computers to work with, which means I can screw up my LFS system without having to worry about losing important data or access to a computer.

I'm in the middle of step one at the moment. I'm formatting the disks on my tower. I will install Ubuntu 10.04 on the smaller of the two disks, and the larger disk will be where I will build my LFS system.

Saturday, October 8, 2011

pH-kraut

Do you remember using purple cabbage as a pH indicator in grade school science class? I decided to combine that with my hobby of pickling.

As sauerkraut ferments it becomes more acidic, and since purple cabbage is a pH indicator, the sauerkraut should change color. I shredded a head of purple cabbage, mixed it with salt and thyme (yum!) and packed it into a plastic container. I took a picture every evening when I got home from work to see how it had changed.

I had hoped to post the whole series of photos here, but the sauerkraut didn't act as I had expected. The change was dramatic, but it happened too quickly for the series of photos to be of any use. The appearance of the sauerkraut did not change at all, until day 3 when it changed drastically. After that its appearance did not change again.


I will try this experiment again, but will have to change how I photograph the sauerkraut. I plan to set up a camera on a tripod taking pictures several times a minute so I can stitch them together into a time lapse video. Hopefully that will catch the dramatic change in detail, as well as some of the more subtle action like formation of bubbles.

And since I'm already pulling stuff off my camera, here's some dude rocking out on an old busted spinet piano at the MacArthur BART station.


Tuesday, September 13, 2011

Grails events

I couldn't find a complete list of Grails events, so I've tried to compile one. Using various text processing tools, I chewed through all of the Grails scripts in my Grails 1.3.7 installation, and here's what I came up with.
  • AppCfgEnd
  • AppCfgStart
  • AppLoadEnd
  • AppLoadStart
  • CreatedArtefact
  • CreatedFile
  • CreateWarEnd
  • CreateWarStart
  • DocEnd
  • DocSkip
  • DocStart
  • Exiting
  • GenerateControllerEnd
  • GenerateViewsEnd
  • InstallPluginStart
  • IntegrateWithInit
  • PackagePluginEnd
  • PackagePluginStart
  • PackagingEnd
  • PluginLoadEnd
  • PluginLoadStart
  • PluginUninstalled
  • SetClasspath
  • StatsStart
  • StatusError
  • StatusFinal
  • StatusUpdate
  • TestCompileEnd
  • TestCompileStart
  • TestPhaseEnd
  • TestPhasesEnd
  • TestPhasesStart
  • TestPhaseStart
  • TestProduceReports
  • TestSuiteEnd
  • TestSuiteStart
  • WebXmlEnd
  • WebXmlStart
I don't know what all of them do, but it should be easy enough to guess from the name.

Git and empty directories

One minor annoyance I have with Git is that it cannot track empty directories. This is especially annoying if you are working with an application framework, which creates an intricate structure of empty directories.

A common work-around you will see is to create an empty .gitignore file in each empty directory. It's not a very elegant solution, but it gets the job done. The trick is making sure you actually find every empty directory. So, I wrote a simple bash script, gitify.sh, to do it for you.
#!/bin/bash


gitify() {
    if [[ -z $(ls -1A "$1") ]]
    then
        touch "$1/.gitignore"
    else
        for file in "$1"/*
        do
            if [ -d "$file" ]
            then
                gitify "$file"
            fi
        done
    fi
}


rootdir=$(readlink -f .)


gitify $rootdir
Just navigate to the root directory of your Git project, and run the script. It will descend from the working directory into all subdirectories and drop a zero byte .gitignore file in any empty directory it finds. Just git-add all the newly created files and check them in to your repository.

I'm posting this not so much for the benefit of others as for myself. This is probably the fifth time I've written this script, because I keep losing it or deleting it. Maybe now that it's posted on the internet I won't lose it so easily.