Posts Tagged Random Thoughts

HP48G Emulator for OSX

When I was in high school I had a HP48GX calculator.  I cherished that calculator.  I wrote programs for it.  I shared those programs with a couple fellow nerds at school via the IrDA transport.  I sent away for programs that arrived by mail on a floppy disk, which I downloaded to the calculator via a serial connection.

I’ve heard veteran engineers reminisce about old machines like the PDP-11.  The HP48G was my PDP-11.

From time to time I get nostalgic about that calculator, and I search for an emulator.  I’m not sure why.

I just did one of those searches and was delighted to find an emulator with a codebase updated as recently as last month!  If you download the app and then load the JEMAC.KML file you’re presented with a full color, functional HP48GX!  The memories are thick.

Leave a Comment

Hari Balakrishnan on Congestion Control

I was fortunate enough to work in Hari Balakrishnan’s group when I was working toward a PhD at MIT (I never finished it — I’m ABD).  Anybody who’s ever worked with Hari will confirm that he’s brilliant.  Fine, he’s a Professor at MIT.  Big surprise.  (Fact is, even in that crowd, he excels).

What’s cool is anybody can learn from him.  Today I watched a video of him lecturing on congestion control, an area that he’s both a pioneer and an expert.  It’s a brilliant lecture.  It’s not punctuated by “ummms” and “so yeahs.”  It’s crisp and crystal clear.  He not only explains the core concepts, but he also hints at open problems.  I highly recommend checking out the lecture.

Comments (1)

Climbing Two Fourteeners in Colorado

Yesterday I hiked to the 14,271 foot peak of Mt Quandary.  Quandary Peak was my second fourteener.  A couple months ago, on July 4th, I summited Gray’s Peak.

Hiking reference guides declare that both hikes are easy by fourteener standards.  The key phrase there is “fourteener standards,” because they’re difficult.  Granted, I did both hikes just one day after flying in from New York, so I wasn’t acclimated to the altitude.  Even so, with a pack on your back and loose rocks under your feet, it’s always tough going past 13,000 feet.

Catching my breath on Mt Quandary's peak

Catching my breath on Mt Quandary's peak

The hike provides a lot of metaphors for business and software development.

  1. Ultimately, you only reach the top by repeatedly putting one foot in front of the other.  To ensure success, break down the journey into a series of short term, easy to attain goals.  That’s how you get things done.
  2. Experience helps.  On my first climb, even though I had read some trip reports, I was surprised at how difficult it was to keep moving in high altitudes.  I had to take breaks every 10 feet.  I wondered if the summit was worth the effort.  On the second hike, I expected to go slow, and I knew the summit was an ample reward.
  3. Although the ascent and summit contain all the glory, the descent is both more difficult and equally important.  It’s exhilarating to release a new product or major feature, but you have to be prepared to maintain it and complete the life cycle.
  4. If you need to remember part of your journey, then you have to document it.  On both descents there were several points where I had egregious recall of key landmarks.  For example, I’d think “wow, I really thought the tree line was much closer to this big white rock.  I can’t even see the tree line from here!”  Fortunately trails were well marked, so this wasn’t a danger.  In business, you must document key problems and decisions.  Otherwise your mind will surely blur them out over time.  If the trail isn’t well marked, you’ll get lost.
  5. You can find excitement in every stage in the journey, from shopping for supplies, to standing at the peak, to tasting a celebratory beer.

Comments (1)

Analysis of Google Code Jam Qualifier Results

I wrote a quick Python script to pull down all of the results from the qualifying rounds of Google Code Jam from 2008 and 2009.  I have put the rank and time of each submitted solution for all participants in these two Google Spreadsheets:

I also put a collection of summary statistics in this Google Spreadsheet.

Here are some conclusions drawn from these data:

  1. The number of participants increased by 1,449 people in 2009, a 20% increase.
  2. There were 2,572 people who participated both years.  This means 36% of the 2008 participants came back for more.
  3. The 2008 Qualifier had more difficult problems.  After normalizing the point totals (2008 had a max total of 75 points but 2009 had a max of 99 points), the average score was 15% higher in 2009.
  4. Problem C in 2008 was extremely hard.  Only 14% of the participants solved Problem C with the small data set, and only 9% solved Problem C with the large data set.
  5. The large data set for Problem C in 2009 was hard for many people.  Only 36% of people solved it.  Furthermore, of the people who solved the small data set, only 57% of those were able to solve the large data set.
  6. People worked roughly the same amount of time both years.  The 2009 times are all slightly larger, but the round was also extended by 2 hours because of technical problems early in the round.
  7. On average, for each participant, there is about a 3.5 hour gap between the submission time of the first solution and the submission time of the last solution.  Of course some people (like me) probably choose to tackle the problems whenever they found free moments during their day.

If people are interested, I’ll post my code and all the data somewhere.

Leave a Comment

Acknowledgements to Bernie Madoff

Last night I started reading Trading and Exchanges: Market Microstructure for Practitioners, by Larry Harris.  I was surprised to see Bernie Madoff mentioned in the book’s acknowledgments.  Dr. Harris thanks both Bernie and Peter for “their early support” that allowed him to “take time off from my teaching to start this project.”

Curious, I searched Google Books for books published before 2007 that mention the great ponz.  The search yields a number of results — pretty amusing.

Leave a Comment

Navigating New York’s Attitude toward Technologists

I just read Zed Shaw’s post where he announces that he found a job in San Francisco.  Congratulations to him.  In his post, I appreciated his concluding comparison of how companies in New York and San Fran perceive and approach technologists.  Zed says:

NYC prospects were looking for a badass/ninja/rockstar beta-male “techie” employee to make them rich creating lame applications for giant Finance/Fashion/Marketing companies.  SF prospects were looking for a partner to get rich with them creating great products for customers.

To a large extent, I agree.  New York is filled with companies that have non-technical core competencies.  These businesses treat technology as a necessary cost.  When they search for a rockstar ninja, their goal is to minimize cost.  The thinking is “that last tech we had was too slow and too sloppy, and his mistakes cost us money.  We need a superstar tech guy to come in here and do things right (not screw up).”

The dynamic is top-down.  The business wants a super star who will take orders and work efficiently.  On the whole, this makes perfect sense.  As Judge Smails says, “the world needs ditch diggers, too.”

This system fails for superstar techies like Zed Shaw.  This class of techies are often prima donna’s in the same vein as star wide receivers in the NFL.  Instead of taking orders, they want to provide advice.  Instead minimizing cost, they want to generate value.  Indeed, they want to be partners, not employees.  (Even if the company pays well, as many New York firms do).

San Francisco, on the other hand, is a town filled with ninjas looking to band together.  Each one is a Steve Jobs looking for a Steve Wozniak to join them in the garage.  This is a natural and attractive situation, as evidenced by Zed’s move from his beloved LES.

New Yorkers do have hope.  The key is to pursue and promote every opportunity to increase revenue instead of decreasing costs.  When you see this opportunities, you need to explicitly point them out.  Then, if you’re given the green light, work extra hard to execute.  If you score a couple wins, then you can take a partnership role (even in New York).

Comments (1)

I don’t use debuggers

I just read this post, which says “Just about every developer uses a debugger, at least occasionally.”  I don’t know if I’m inadequate or working on a peculiar class of problems, but I haven’t used a debugger in roughly 10 years.

I have used a debugger twice.  Once I was chasing down a bug in a boutique embedded systems compiler.  The compiler had a bug, and staring at the C code didn’t cut it.  I also used the Perl debugger while writing my MS thesis (back when I wrote oodles of Perl code).  I used it because a friend showed it to me, and it seemed cool.

My primary debugging technique is code examination.  I simply look carefully at my code and think about it.  I also write unit tests.

I’m not fundementally opposed to debuggers.  It’s just that I haven’t used one in the past 10 years.

Leave a Comment

Scatter Map of Madoff’s Victims

When I learned that the court had made a list of Madoff’s victims available, I immediately wanted to graph it.  I first forwarded the PDF one of my best friends.  Within a couple hours he had converted it to text, which he streamed through Yahoo Pipes to generate KML suitable for viewing with Google Maps.  The pipes filtered out duplicates, did address discovery and geolocation.  Unfortunately, Google Maps can’t display more than 80 markers at once, which is far less than the thousands of people whom Madoff ripped off.  He eventually did pull off a single view visualization, but it ran like a dog.

So last night I took a different approach.  I extracted out all of the zip codes from the list.  (Ignoring all of the international investors robbed by Madoff.)  Then I used http://geocoder.us to map each zip code to a latitude and longitude.  Next I wrote a short script in NodeBox to draw a projection of the zip codes on a canvas.  Each point is color coded to indicate the number of times that zip code occurs in the court document.  I was helped a lot by code and ideas in Ben Fry’s Visualizing Data book, which I have access to via Safari Bookshelf.  In particular, I stole his function for projecting out the latitude and longitude numbers.

Here are the resulting images.  The perfectionist in me would love to tinker with this for hours.

scatter map of Madoff's victims in the NYC Metro area

scatter map of Madoff's victims in the NYC Metro area

scatter map of Madoff's victims in NYC Metro area

scatter map of Madoff's victims in NYC Metro area

scatter map of Madoff's victims in New England

scatter map of Madoff's victims in New England

scatter map of Madoff's victims in Florida

scatter map of Madoff's victims in Florida

Comments (6)

Researching Ant Colonies

Last night I watched Dr. Deborah Gordon’s tech talk about How Ant Colonies Get Things Done.  She’s been studying a collection of ant colonies in New Mexico for the past 25 years.  That impressive feat of longevity was my biggest takeaway from the talk.  25 years devoted to ants.

As a kid growing up in Illinois, I toyed with ants.  I mixed ants from different colonies.  I figured out that you could confuse an ant by erasing its scent trail.  I sprayed ants with paint.  I roasted ants by focusing sunlight with a magnifying glass.  I slowed ants by putting them in the fridge.  I had a couple ant farms.  I submerged ants under water.  I dug up colonies outside.

I see Deborah taking that childish curiosity to a professional level.  As a computer scientist who also first played with computers at an early age, I find her longevity inspirational.

I’ve also been thinking about how her results might be applied to distributed computing problems.  Ant colonies are extremely fault tolorant and highly decentralized.  When I design distributed systems I’ll be sure to think about how ant colonies might apply.  And if I get tired, I’ll think about how Deborah Gordon keeps on keepin on.

Leave a Comment

Blurry image on nytimes.com

For a while now, nytimes.com has linked to their headline opinion piece with a blurry image.  For whatever reason, it seems their designers simply magnify a screen capture of a their standard small font.  The grainy result is unsettling because it’s sandwiched between normal, smooth images.  I wonder why they do this, and I wonder if this bothers anybody else.

blurry image on nytimes.com

Here is a screen capture taken within Firefox on my MacBook Pro.

Leave a Comment

Older Posts »
Follow

Get every new post delivered to your Inbox.