Robert W. Rose

I should have known better.  Having never used audible before, when they had a free trial running a while ago I thought I would give it a shot.  Turns out they didn't have much in their catalog I wanted to listen to so I cancelled after an hour.

The NY Times has article up today titled, "Why Science Majors Change Their Minds (It's Just So Darn Hard)" that explores the reasons behind why an estimated 40% of science and engineering students change majors, or fail to complete their degrees.  Summary: classes can be difficult, boring, and feel irrelevant.

I can't say I disagree.  From my own experience as an undergrad, there were plenty of courses I took that were either excruciatingly difficult, mind-numbingly boring, felt completely useless, or some combination of all three.

In my first few years as an undergrad I had a bad attitude about school, and my grades reflected it.  In my case changing majors wasn't an option, I guess I was fortunate because I knew that whatever I ended up doing post-college (with or without a degree) it would have something to do with computers, so I never considered it.  But there were many occasions were I considered dropping out or "taking some time off."  It was the beginning of the dot-com boom, and a few of my friends had already given up on school for Silicon Valley, Redmond, or their own startups.

I got lucky when I landed an internship at a local software shop.  It was my first exposure to a large group of professional engineers, doing professional engineering in a professional engineering environment.  As a programmer, I learned that "raw skill" certainly matters, but it only gets you so far.  Yes, there are fundamental theories and surveys of techniques that you're forced to learn in college that you could pick up on your own, but what I observed was that these people thought differently than I did.  They had a way of approaching problems that was methodical, structured, and practiced.  I'm not talking about software engineering processes or anything like that--their brains functioned in a way that mine did not.

And that was the turning point.  I realized that college was not about being able to solve triple integrals or Laplace transformations, it was about training your brain to solve complex problems.  To rewire your neurons to study problems in an ordered manner.  When I began to approach my classes this way, it got easier.  I started putting in the hours, and my grades improved.

Not everyone is fortunate enough to have a good internship experience, or see their profession that they are studying for up close before they graduate.  These slots are competitive and space is limited.  To the article I referenced above, I would challenge industry to create more internships.

To students that are struggling through their first few years as an engineering undergrad: it gets better, trust me.  Courses become more relevant in your junior and senior years.  But also remember there's nothing stopping you from reading ahead or practicing your trade in advance of these courses.  Find people to collaborate with, or stay up late working on your own projects. (You can sleep when you graduate).  Stick it out. Engineering is very rewarding.

Water: 6oz
Time: 5 min
Milk: 2oz

Verdict: Smooth, fresh, pleasant. Slightly woody aftertaste.  Takes milk exceptionally well.

I made some ribs tonight.  Took about 3 hours to make and about 3 minutes to eat.

Preheat oven to 325F.

Dry rub:

* 1 part salt
* 1 part pepper
* 2 parts smoked paprika
* dash cayenne pepper (to taste)

Combine dry rub ingredients.  Remove membrane from ribs.  On a piece of aluminum foil, rub dry rub into the ribs.  Start with about 2 tbsp of dry rub per rack, but don't leave too much excess in the foil (or the corners of the ribs will end up too salty).  Splash about 1 tsp of concentrated liquid smoke onto each side of the ribs.  Wrap ribs in two layers of aluminum foil as tight as you can get them without tearing.

Bake in oven on a baking pan for 1.5 hours at 325F membrane side up.  Flip over, then bake for another 1.5 hours at 300F with membrane side down.

BBQ sauce:

* 1 part salt
* 1 part pepper
* 2 parts brown sugar
* 8 parts ketchup
* 4 parts apple cider vinegar
* big splash worcestershire sauce
* light splash concentrated liquid smoke

Combine BBQ sauce ingredients.  Remove ribs from oven.  Carefully open up ribs and lay them on one layer of aluminum foil membrane side down (discarding one layer of foil).  Be mindful of the hot steam that will escape when you open the foil.  Cover topside of ribs with BBQ sauce, about 3 tbsp per rack.

Place ribs back into oven and broil on top rack of oven for 2-3 minutes, or until sauce on the top begins to caramelize.  Remove from foil and serve.

I gotta give props to Cheater BBQ for inspiration on this one.  Their indoor rib recipe is great, but I think mine is better. :-)

I just got a NS-K330 NAS off Deal Extreme, it's a super cheap-o 3W network attached storage device.  Just add a USB powered HD and you're ready to go.

The operating system that it comes installed with doesn't do very much, so the good hackers over at SnakeOS have made a simple BusyBox-based distribution that you can use to replace it.  In 3 minutes you've got an embedded Linux server running ssh/sftp, ftp, samba, http.  Did I mention it only draws 3W?

Once I got SnakeOS installed I was disappointed to discover the embedded web server doesn't support directory listings.  It does however support CGI scripting.  It took me a few minutes to put this together, but here are two scripts you can install in your web server /cgi-bin directory to enable directory browsing and automatic generation of m3u files for your mp3 collection:

#!/bin/sh
# Generates a directory listing, links directory to m3u generator

echo "Content-type: text/html"
echo ""

QUERY=`echo ${QUERY_STRING} \
  | sed -r 's/%20/ /g' \
  | sed -r "s/%27/'/" \
  | sed -r 's/^\///'`

echo "<h2><a href=\"/cgi-bin/m3u?$QUERY\">/$QUERY</a></h2>"

ls -l "../$QUERY" | grep ^d \
  | awk '{$1=$2=$3=$4=$5=$6=$7=$8=""; print $0}' \
  | sed -r 's/^[ ]+//' \
  | sed -r "s/^(.*)$/<a href=\"?$QUERY\/\1\">\1<\/a><br>/"
 
 
ls -l "../$QUERY" | grep -v ^d \
  | awk '{$1=$2=$3=$4=$5=$6=$7=$8=""; print $0}' \
  | sed -r 's/^[ ]+//' \
  | awk "{printf(\"<a href=\\\"/$QUERY/%s\\\">%s<br>\", \$0, \$0);}" 

#!/bin/sh
# Generates m3u from query parameter

echo "Content-type: audio/mpegurl"
echo ""

QUERY=`echo ${QUERY_STRING} \
  | sed -r 's/%20/ /g' \
  | sed -r "s/%27/'/g" \
  | sed -r 's/^\///'`

find "../$QUERY" -name *.mp3 \
  | sed -r 's/\.\./http:\/\/192.168.0.11:8080/' \                                  
  | sed -r 's/ /%20/g'

Not the cleanest of scripts, but it gets it done.  BusyBox doesn't have a complete "find" implementation so this kinda limited what I could do.

As I'm writing this it does not appear this system is the most robust of web servers... Both WinAMP and Windows Media Player are seizing up part way through songs and reporting network errors. Hmm. I guess for $40 I can't complain.

I've been spending some time with Renoise recently, and this LADSPA plugin called Autotalent that acts as an auto-tuner / real-time pitch corrector.  For a while I was playing around with it using pre-recorded samples, but the other night I thought it would be fun to try it out live.

Unfortunately I couldn't get my motherboard to work with any of my (analog) microphones, so I pulled out an old Logitech USB microphone I had for my Playstation 2.  Linux recognized it, and I was able to record, but then I discovered that Renoise has an unusual shortcoming: it does not support monaural input sources.  Well, this is Linux.. there must be a way to make this work, right?

Sure enough, there is!  I dunno if this was the smartest way to get it working, but I got Renoise to recognize the mic as a stereo microphone if I configured a virtual pcm device in in ALSA, ran a Jack server with this virtual pcm as the capture device, and then reconfigured Renoise to use Jack instead of ALSA.  The latency was noticeable, but still good enough to allow me to do my own T-Pain and Wallpaper renditions.

Here's how it's done:

$ arecord --list-devices
card 2: Microphone [Logitech USB Microphone], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0


$ cat /etc/asound.conf
pcm.stereo_capture
{
    type route
    slave.pcm hw:2
    slave.channels 1
    ttable.0.0    1
    ttable.1.0    1
}

$ sudo jackd -d alsa -P hw:0,0 -C stereo_capture

FusionGarage is trying to make a comeback after their JooJoo debacle, it's called GridOS.  They have a few videos of it in use on their website.

When I used to work in games people would say to me, "hey I have this great idea for a game..." and then I'd have to gently explain that either the idea had already been tried or probably wouldn't be fun for xyz reasons.  Or I would just smile and nod.  Watching the GridOS videos they have on their website brought that feeling back.  I cringed watching them.  I imagined this dude telling some poor programmer, "hey I have this great idea for a user interface..."

"The desktop should never end! It should just go on and on..." Great idea, genius.  So you want people to get lost finding their apps?  Or worse, lose their apps?

"Oh well then we'll have this map in the top corner so you don't get lost!"  How about you just don't let people get lost in the first place.  Confine the apps to as small an area as possible.

"Grids are cool! Everything should be in a grid with massive blocks of dead space between groups."  So, you want people to get tired of scrolling?  You want to not use the available screen real estate to convey useful information?

"There should be this gadget for your left thumb that acts like a jog dial, and have scroll momentum and do this neat little shaking of the items attached to the wheel!"  So you want to violate your grid design and rigid fade-in/fade-out visual semantics for this one different UI element. O.. K.. And you also want things to not actually be visible until they stop shaking / stabilize?  And you want this under the user's thumb, so they can't actually see what they're controlling? Right.

"But the right thumb should be like a context menu, and have this grid pop-out with context sensitive options, (and all the options should be on the same background with single-color icons)."  Is there any rhyme or reason to how these icons are arranged?  "Sure! Arrange them based on the distance your thumb has to travel, so commonly used items are closed to the edge.. you know, like Dvorák and stuff."  Alright, I guess people will have a hard time finding where things are the first time, but maybe they'll develop a muscle memory for where things are.  Oh wait. This is a tablet.  There is no physical feedback mechanism.  They'll have to use visual feedback and get lost every time.

"We'll have the coolest UI for playing music!"  Uhh, yea, isn't that kind-of a solved problem?  Plus, you don't really need much of a UI for listening to music on a portable device.  Unless you're developing a great UI for managing music--and sync'ing that management with wherever your music library is stored--then you might be onto something.  But I suspect you're not.

Too harsh?

I find it frustrating that there is no requirement to inform the customer of the country of origin of a product when it is purchased online. I often times have no idea what country something was made in until it arrives at my doorstep and I open the box.

According to the Customs and Border Protection document "Marking of Country of Origin on U.S. Imports" the purpose of this marking is:

To inform the ultimate purchaser in the United States of the country in which the imported article was made... The ultimate purchaser is generally the last person in the United States who will receive the article in the form in which it was imported.

When you buy something from an online retailer you don't get to see this marking until you've already made the purchase.

The intent of this law is not being met.

Secrets of Success (Radiolab)

"If you look at any cognitively complex discipline... in order to be good, you must practice at least 10,000 hours."

Agree.

A new paper I co-authored with a few of my colleagues is scheduled to appear at SIGLP* 2011:

Abstract: The Mythical Beer Month is a software project management method that builds on the close relationship between software engineers and their beer. The method exploits properties of Booze Law to maximize the effectiveness of software developers by carefully rationing them beer.  Software developers are placed into a matrix organization according to their individual Ballmer Peak and rewarded with beer during and immediately following accomplishment of a milestone.  In this paper we present the Mythical Beer Month method, a summary of projects that have implemented the method, and finally some criticisms of the method.

(ACM Special Interest Group on Lazy Programming)