No Open Blockers

I made a lot of changes to the code base to support the last few projects of the semester. I figured now that school is out for the summer it’d be a good idea to post a build with what CodeTurtle ended up being after a semester of usage (seven projects in total).

Before I go on, I want to welcome Scott and Emily to the project. Scott was a contributor on this release, fixing some critical issues when running on Windows and providing the very cool printing support (a feature that coincided with me running out of paper at home and thus failing to print out the last project of the semester anyway). Emily is just starting out and we’re deciding on where she is going to focus her efforts. I’m psyched to be able to work with them and appreciate the support.

A big improvement with this release is that I finally had the discipline to sit down and begin to write some documentation. I ripped out the hardcoded HTML file from CodeTurtle and began work on a wiki specifically for the project:

http://codeturtle.noopenblockers.com

It’s a work in progress. What a loaded statement, it’s always going to be a work in progress. That’s one of the appeals of using a wiki, you get to use the excuse that “I’ll add that to the wiki soon” since all of the information is stored online.

The wiki has a mixed audience. I’m trying to jump to the quick parts of how to download and run since that’s what most people will be interested in. But I’m also catering to my students who want to contribute (as well as some, um, academics that haven’t actually worked on a real software project and sadly don’t know how to use these things). So I took some extra steps to explain concepts such as source control systems and build systems. This will pay off anyway, since I do a lecture on these things in class but never had a central reference location I could point them to. It’s also got my first feeble attempts at a logo (I’m thinking of blogging on its creation process in the future). My lack of creative skills is astounding.

Along the same lines, since there has been a growing interest lately, I took a number of steps taken to help introduce new users. I flushed out the sample project a bit more to make for a better demo. On the first run, there is a guided setup that will help the user set up the compiler used in the grading process and automatically configuring the sample project. I don’t know why, but I find writing that sort of thing to be a lot of fun.

As usual, the latest release can be found at the SourceForge site: https://sourceforge.net/projects/codeturtle/.

I’m actually including the release notes in this post since there was some pretty cool shit done since 0.3.

New and Cool Stuff

• Added current project printing support (courtesy of Scott).
• Added progress bar to indicate the work done towards creating a gradebook (compiling submissions, grading, etc.).
• Added toolbar to UI to support quick access to common functions.
• Added user preferences support.
• Changed handling of command line options. If any of the gradebook options are specified, the create gradebook dialog will automatically be displayed and prepopulated with the command line values.
  • The “-c” option has been renamed to “-g” to reflect the change in terminology from “project checker” to “project grader”.
  • The “-c” option now clears the Java preferences node for CodeTurtle.
  • The command line options can be displayed by passing the “-?” flag.
  • The “–sample” option will populate the gradebook creation dialog with the included sample project
• Better flushed out sample project, including cleaning up their representation in the source control system and adding build scripts to set up their state.
• Added “first run” feature that will perform installation and sample steps to ease new users into configuration and using CodeTurtle.
• Bug fixes (hopefully more fixed than new ones introduced).

Ahhh… laziness. It was becoming too hard to rotate my chair the 10 degrees to turn and use my laptop keyboard and mouse. In the past I have used Synergy to share a single keyboard/mouse across multiple computers. Rather than requiring a hardware switch like a KVM, it lets you treat multiple computers as if they were the same desktop. In other words, I can literally use a single mouse to slide the cursor across multiple machines, treating them almost as if it was just a multiple screen display. You can even copy and paste across multiple computers.

So in the above picture, the keyboard and mouse on the tray is being used to control both the desktop and the laptop at the same time. When I slide the cursor off the left of the center monitor, it starts moving the cursor on my laptop. Win.

Here’s a quick overview of the steps to connect my desktop (guardian) as the host (in other words, the keyboard and mouse are connected to it directly) with my laptop (jdob-lt).

1.) Install synergy on both machines. Back when I first used this a few years (and jobs) ago, it was a bit of a pain in the ass to install. Life is a lot easier now since it’s included in the Fedora repositories.

yum -y install synergy

2.) Write the configuration file on the host machine. I’m normally a big fan of text-based configurations, but in this case I think a graphical configuration would make life a lot simpler. The configuration file can be put anywhere, so for consistency I put mine in /etc (make sure it’s readable by whatever user will be running the server daemon).

The following is my configuration file with comments where applicable. Keep in mind my comments are mostly my interpretation of what I’ve pieced together, so if there’s any source of confusion, RTFM.

# Declares the machines that will be connected.
# I used the hostnames of the machines, but there
# may be another means for identification.
section: screens
guardian:
jdob-lt:
end
 
# Describes the orientation of the screens in
# relation to each other. Read as "guardian has
# jdob-lt to the left" and "jdob-lt has guardian to its
# right". Yes, both directions need to be specified.
section: links
guardian:
left = jdob-lt
jdob-lt:
right = guardian
end
 
# I haven't played with this much, but this prevents
# the screen savers from syncing up.
section: options
screenSaverSync = false
end

3.) Start the server daemon. There are two binaries that come with the synergy package, one for the server (synergys) and one for the client (synergyc). Starting the server daemon is as simple as running the server binary and specifying the configuration file.

synergys --config /etc/synergy.conf

Additionally, the -f flag can be passed to the executable to cause it to run in the foreground. This is useful in debugging while you’re getting things set up. For instance, you’ll see messages such as:

DEBUG: CClientProxy1_0.cpp,404: received client "jdob-lt" info shape=0,0 1680x1050
NOTE: CServer.cpp,278: client "jdob-lt" has connected
INFO: CServer.cpp,447: switch from "guardian" to "jdob-lt" at 1679,521
INFO: CScreen.cpp,116: leaving screen
...
INFO: CServer.cpp,1440: screen "guardian" updated clipboard 1
DEBUG: CClientProxy1_0.cpp,278: send clipboard 1 to "jdob-lt" size=119
INFO: CServer.cpp,447: switch from "jdob-lt" to "guardian" at 42,761
INFO: CScreen.cpp,98: entering screen

One last server note, you’ll have to open up port 24800 if you use the synergy default.

4.) Start the client. Similar to the server executable, -f can be passed to keep the process in the foreground and view logging information. When starting the client, simply specify the location of the host (in this case, I have /etc/hosts configured to resolve “guardian” to its static IP).

synergyc guardian

If it connected correctly, you should see logging on the server similar to what’s posted above. A little more apparent is to simply try to slide the cursor from one screen across to a screen on the other computer. If it works, then you’re running.

5.) Sit back and admire the leetness.

The one thing I haven’t bothered with yet is setting this up to automatically run. It’s probably not much to set up some simple init.d scripts (I believe the client will auto-retry by itself in the cases it starts up before the server), I just haven’t taken the time to try yet.

Oh, and for the unenlightened, it runs on Windows too. And yes, you can connect Windows to Linux through synergy. Awesome.

I turned 30 a few weeks ago. Ok, so it’s probably time I learned how to ride a bike.

The actual learning process itself was pretty uneventful. My wife and I went up to the parking lot of the community pool, I got on her bike, and just went. No catastrophic falls, no accidentally riding into oncoming traffic. Twenty minutes later we were at Dick’s buying me my own shiny bike.

I became addicted. I’ve gone riding every day since then, even if it was just 30 minutes at lunch. I’m happy to report that I haven’t fallen yet. Though after that much riding that quickly, I have to admit that my ass is killing me.

That isn’t to say it’s been without incident. My wife and I have been taking the baby for rides after work (she has a baby seat on her bike, I’m not daring enough to risk Leanne’s well being, just my own). Every time we go, I insist we leave the front door unlocked. That’s in addition to my wife leaving the garage door unlocked when she closes it. Call me paranoid.

Call me unlucky too. The one time I forget to leave the front door unlocked is the one time I accidentally locked the garage door when I closed it. Seven years of instinct in simultaneously closing and locking the door kicked in before I realized it. Half a second after I heard the click I realized what had happened. Then I cursed. Loudly.

It gets worse. Here we find the family locked out of the house, yet I could see the spare key. It was in the little box attached to our front door for when realtors come to show the house. There it hung a mere 4 inches below the lock itself, mocking me.

I thought back to a month ago when we put the house on the market. The realtor gave us an option…

“Do you guys want the fancy digital one that only realtors can unlock or a combination one that you guys could unlock as well?”

The geek in me smelled technology.

“We’ll take the digital one. We’ve been here seven years and haven’t locked ourselves out yet, why the hell would we need the combo lock?”

In addition to my keys, I also left my cell phone inside. So on top of everything else, I had to suffer the indignity of asking a neighbor to borrow his phone so I could call our realtor to come let me in. To make sure I fully paint the picture of how big of a douche I looked like, realize I was wearing one of those stupid looking bike helmets at the time.

So one 45 minute bike ride later, our realtor showed up to let us back into our own house. Any longer and I was about to carry out my carefully devised yet extraordinarily stupid plan to scale the outside deck to the second floor screen door into the kitchen which, by our estimates, had about a 66% chance that we left it unlocked.

Getting back to the actual bike riding, the timing of my new found skill is great. I was running out of new options for cardio at the gym. We had been looking for something to do outdoors as a family. And I had been looking into possible Python projects for the summer, and I already know of a really cool combination of the two.

So what did I learn from this whole experience? Apparently not much, since I once again declined when the realtor offered to swap out the digital key holder for the combination one (I don’t think she wanted to be called out here again the next time we do this). Mmm… the sweet smell of digital technology on my front door…

1
2
3
4
5
6
7
8
9

try {
    String line = input.readLine();
    while (line != null) {
        line = input.readLine();
    }
}
catch (IOException ioe) {
    logger.debug("IOException...really need better handling here");
}

Everyone, at one point or another, is guilty for just swallowing an exception. Java tends to be a bit trigger happy with its checked exceptions (especially in the IO packages), so it’s inevitable to be in a position of having to deal with an exception that admittedly will probably not happen while trying to get something else accomplished.

The nice part is that I’m cleaning this up and actually providing the better handling. The cool part is that I’m using code I wrote for CodeTurtle to do it.

When I started this site, it was meant as a trial of using a blog to communicate with my students. Around the same time I had been trying to maintain a separate work blog. That was too much to handle and I think there is a cross over audience between them, so the two kinda merged into one. This site won since I’m hosting it on my web server and not surprisingly, having full access to the server is better than limited access.

The whole idea of “Professor Jay’s Notebook” was partially due to the school focus and partially due to the fact that I wanted to use a really sweet notebook-style theme I found. However, I have a short attention span and tend to change the theme every 6 months or so. And to be honest, I was getting kind of tired of the whole “Professor Jay” moniker.

So, I’ve been slowly migrating this site over to a new domain: noopenblockers.com. I set up automatic redirects so notebook.novasurv.com will still work, just automatically kick you over to here. I’ll leave it that way for a while, but to anyone using the RSS feed, be sure to update the link.

Why No Open Blockers? It came from a previous project as we were trying to ship the 2.0 release. We had progressed past the stage of “It actually compiled? Ship it.” to having a list of prioritized bugs. The next stage of just wanting to be done had migrated to “No open blockers? Ship it.” (where blocker was our highest priority for bugs). I liked the phrase and ran with it.

I’ve been reading Dreaming in Code for the past week. I forget where I first heard of it, but after a recommendation from a coworker on the Spacewalk team (thanks Partha) I finally followed through with checking it out.

The subtitle does a good job of explaining the book’s purpose: “Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software”. I hesitate to call it a case study in software projects because I don’t think it does justice to the book’s relaxed, conversational style. Rather than reading like a formal study, it’s the story of the development of Chandler an open source personal information manager with high goals. Rosenberg also provides a ton of related information to help frame the choices the Chandler team had to make, which increases the book’s audience significantly to include non-professionals.

I wish I was in a position to assign required reading for CSC majors. I’m not sure what class this would fall under (the most likely candidate is Software Engineering). Even then, the bigger challenge is convincing students of the value.

In short, anyone considering a career in programming needs to read this book. It provides an incredibly good insight into what it’s like to work on an actual project, an insight that students normally only get with experience after they’d graduated. Like I said, it’s presented more as a story of what happened rather than a technical manual, so it’s not painful to read.

But I cannot stress enough how much I would have appreciated such a detailed look into a real software project before I started on my career. Software Engineering text books describe what to do “by the book”. This book shows you a more realistic view of how those theories and practices can (and often do) go wrong.

Of course I bought her a Mario. A Donkey Kong too.

Sorry for the quality, my wife’s phone is such crap that it might as well be a banana.

She apparently spent the day carrying him around and hugging him (I was at school at the time). And when I take her to GameStop, she runs to the Mario games yelling his name.

Hell. Yeah.