This is a somewhat less exciting project and announcement, but I put together a utility that helps translate Foxpro DBF to SQLite. In case you don’t recognize the word Foxpro, it’s a Microsoft DBMS whose final version was released over five years ago (and whose heyday was nearly two decades ago). WomensTrust has a database that I’ll be getting a hold of soon, and I wanted to actually be able to use modern tools to work with the data instead of having it trapped in a sunsetted technology. I tested it on a sample database, and it works fine, if a bit messily. It’s directly reading and processing the data in the DBF tables. It tried to preserve the format and structure of the tables, but it’s not perfect.

I haven’t tested the script with any other dialects of SQL, but since I’m just gluing together a Python dbf library and SQLAlchemy, it should require minimal effort to adapt it (though once you’ve translated DBF to SQLite, there are far better tools available for getting it into other dialects of SQL). The code is here.

As mentioned in my last post, while working on a lambda calculus interpreter, I encountered an issue where I wanted to skip ahead in a for loop, but found that I couldn’t. Although I initially put it aside, when I was getting a code review on the interpreter from Tom, I remembered the issue again and did some further investigation on the topic.

For the past week, I’ve been working on a lambda calculus interpreter (Github) in order to try to better understand the concepts in lambda calculus. It’s been a great experience, especially since I’ve been coding it in Python. Normally, if I were writing the interpreter in a language like SML or Haskell, I would rely heavily on pattern-matching.

Using pattern-matching is a pretty natural fit for creating an interpreter, given the operations involved in lexing, parsing, and reduction/evaluation — specifically, handling a particular encountered block depending on the token or keyword/structure encountered.

I only started this log last week, but figured it would be helpful to start tracking more of what I do at Hacker School, apart from my bigger projects. As a side benefit, it might give some of the people who have asked me what I’m doing at Hacker School some insight into what a typical day might be like — though do keep in mind I’ve likely not captured literally every single thing and this particular week was more chaotic and scattered than average.

This is more of an experimental idea right now, but if it works out well, I’ll try to post these at the end of each week.

As part of my Hacker School application, I wrote a simple Tic-Tac-Toe application for my “program written from scratch.” My choice was driven primarily by the fact that the application itself suggested a Tic-Tac-Toe application. As such, I expected many other people would write Tic-Tac-Toe (I was very right in this regard) and wanted to do something unique. My original ambitious plan was to write an AI for it. Unfortunately, I had to quickly abandon this plan, since I realized 1) I had no idea how I would go about creating one, and 2) I didn’t have enough time to figure it out before the application was due. As such, I had to settle for infinitely expandable Tic-Tac-Toe (theoretically anyway — at greater than 15 x 15, it becomes quite visually ugly).

Now that I do have the time, I definitely wanted to tackle writing an AI for Tic-Tac-Toe. However, I didn’t want to just find and apply an algorithm. I wanted to have the full challenge and experience of working through how one would create an AI.

Last week, while working on my simple text editor, I chatted with fellow Hacker Schoolers about what was actually being used in the industry nowadays for GUIs. The answer I most commonly heard was that the tech world had largely moved on to web (and mobile) apps. No one who I spoke to actually worked on desktop applications. The insight here is quite fascinating to me.

Developers and users are a chicken-and-egg problem. To get developers to work on a platform, you need users. To have users, you need a strong developer base that creates appealing and useful apps. It’s a small sample set, but the lopsided nature of the sentiments suggest to me that either developers have a stronger lean towards web than users or the companies that work in web are much more interesting/appealing to the strong programmers that Hacker School selects for and attracts. Again, it’s too small a sample set to draw sweeping conclusions, but it is an interesting data point. Nevertheless, these conversations helped point me to my next project: a web app.

I have a lot of project ideas that I want to play around with during Hacker School. However, my primary goal — the thread that ties all of these disparate ideas together — is to tackle areas of programming that I have never encountered. If an area of programming is “magical” to me, I want to dispel that magic.

First up on that list of “magical” topics is graphical user interfaces (GUIs). I remember trying to experiment with GUIs in a group project during high school Java using Swing and AWT. I also remember quitting out of disgust after only a brief foray into their APIs, leaving one of my poor teammates the painful task of programming our project’s GUI, while I worked on fun game logic. Since that brief attempt, I have never attempted to play around with GUIs ever again, so I have remained mystified as to how I would actually go about creating them. So, after nearly a decade, I’ve decided to try my hand at it again.

Hacker School has finally begun! The past few days have been a whirlwind of activity. Last week, I finished my last day at work, Liz and I packed up our apartment and got it loaded on a truck for California, loaded the rest of our stuff into the car, moved to NYC, and made an extremely difficult decision which coast we wanted to be on (Liz for her engineering/design programs, and me for business school).

It’s been exhausting, mentally and physically, and I haven’t had much sleep at all. The exit schedule will be just as crazy. Just like how I left work and hit the ground running in NYC for Hacker School, I’m going to have to leave Hacker School a week early on Friday and start business school at Berkeley on Monday.

Ah well, I knew what I signed up for, and I wouldn’t miss this opportunity for a piddling few months of “break.” This will be my break. I’m exhilarated to spend three months becoming a better programmer, surrounded by people trying to do the same thing. Hearing about what some of my batch-mates do and plan to do when I met them this morning was great. There’s a lot of experienced programmers here that I look forward to working with and learning from. Here’s to never graduating!

I’ve been “barefoot running” now for about a year at this point. Overall, I think the results have been better than expected — though my original expectations were pretty low.

While some people get into barefoot running because they’ve read about the Tarahumara, decided it’s the secret behind African Olympic success in running, or heard some interesting biomechanical or evolutionary argument, I admit that I primarily got into it because the shoes are more compact and easier to carry in my work bag (my company has a gym). Given that benefit, I decided I’d just hope that some of the other touted benefits were true.

My Vibram Fivefingers. These squish a lot better than running shoes.

Liz and I were recently up in Philly when I got an idea for a prank that I’m a couple years too old for at this point. Liz got into UPenn’s Integrated Product Design master’s program last week, so we were visiting the city and school to get a sense of whether or not she’d like the program.

At one point, going around the city, we saw this statue very prominently stationed at an intersection.

Deep thought.