About seven years ago, I worked on a project called Keryx. I wanted to install new software on my Ubuntu computers in rural Tennessee, and resolving dependencies by hand was not cutting it. So I joined Chris Oliver to write something to make the job easier.

Then I took a break from development. Long story short, I learned way too much about trees, went to college, and then got a job.

Now I have some free time. I’ve got great internet connectivity, but tens of thousands of downloads prove Keryx is still relevant. So I refactored the code and issued a new release today.

What’s new?

Most of the work was refactoring. While Chris is a heck of a coder, seven years ago neither of us followed all best practices.

We had worked on a 1.0 branch, but I chose to throw back to 0.92 for my refactoring efforts. Why? Nostalgia, probably. I’m also pretty certain Keryx 0.92.4 did a pretty good job. I don’t remember much about 1.0. And I like refactoring. It’s fun.

So what did I actually do?

  1. Tried to get the code in line with PEP 8, Python’s style guide
  2. Removed non-critical features, cutting the lines of code 10% from 2865 to 2555
  3. Switched from py2exe to pyinstaller for builds
  4. Started documenting with Sphinx
  5. Cut project load time ~85% (at least on my machine)

In short, I had fun.

0.92.5 is not a polished release. It’s simply functional. I feared that if I waited till things seemed nearly-perfect, I’d never release at all. So give it a try, report the bugs, and I’ll try to issue bugfix releases as often as possible.

What’s next?

I’m going to strip out the GUI, implement a CLI, and then build up a new GUI. I think that promotes good development practices, and helps me understand all the magical things that Chris originally implemented.

I’ll build a better standalone APT emulator which could be used in other projects. That was originally a goal of the 1.0 series.

And hopefully I’ll build a new website, because this project is all about accessibility. Unfortunately, for the moment, it’s also about convenience for me. So it might be a while before that happens.

Maybe I should have a philosophy on How to do Phone Interviews. You know, some Do/Don’t list which is guaranteed to land me my post-college dream job. But I don’t have such a list.

Instead, my anti-philosophy is to treat the interview as if I am already working with the interviewer.

After all, aren’t I? A phone interview is just a discussion between two professionals, helping decide whether one should join the other as a colleague at their organization.

So before an interview, I make a cup of coffee, grab a pen and pad, and sit down at my desk ready simply to have a collegial discussion.

And I try to learn. Not something dull which won’t be useful to me in two months, like what’s precisely the best answer to some boilerplate interview question. But interesting things.

Last week during one interview I learned about startup accelerators in Pittsburgh. In another, I picked up an entertaining description of the C# programming language. I had fun and educational conversations with several interesting professionals. And if they’re interesting, shouldn’t they be great coworkers?

I believe an interview is best if all parties to the conversation almost forget that it’s an interview. Perhaps it’s a skill I carried over from my days as a college policy debater – the best speeches and cross-examinations feel like conversations with the judge, not speeches or cross-examinations.

Maybe my way of interviewing is a little too chipper or happy-go-lucky. But so what? I look forward to being part of a company culture that appreciates genuineness. I really believe “being real” is a crucial part of getting work done.