Slicing & dicing, and Chicago Code Camp!

May 31, 2009 at 1:55 pm (Ruby, Scheme, Watching, Week 10) (, , , , , , , )

Friday I spent the morning with Eric Meyer working on the same Rails app Jim and I had been working on last week. We got two bugs knocked out pretty quickly, and we also did some planning for a database refactoring (not as big of a deal as it sounds like, as the system isn’t in production yet). Eric’s laptop was having some boot problems, so we used mine; hopefully his Time Machine backup worked over the weekend – there aren’t many things more frustrating than not being able to boot. In the afternoon I chopped up a new website that should launch on Monday, showing Paul some tricks with the Slice tool in Photoshop along the way. I feel like I’m pretty efficient slicing up a PSD into XHTML/CSS – hopefully before too long I’ll feel that way in the code world!

Saturday was Chicago Code Camp, and it was awesome. The first session I went to was “Trends in Continuous Integration and Software Delivery” with Sean Blanton of OpenMake software. He went through the major features of a continuous integration system, and while we’ve got one in place for a couple of websites I work on (cc.rb), there was a lot of information there. I never realized how many different systems were out there. I was impressed with the fact that Sean wasn’t just pimping his products (Mojo and Meister) – it really seemed like a pretty fair assessment of the different systems. There were a couple of slides on Git, actually, which talked about how powerful it was, but that it might be hard for novices to get into. I thought that was odd at first, but as people asked questions I realized that Subversion and other systems have lots of GUI implementations that integrate tightly with OS’es, and Git doesn’t have so many yet. Maybe that’s a good project for someone…

Then I made the tough choice to miss Eric Smith and Eric Meyer’s talk on “TDD for the IPhone,” in order to attend Dean Wampler’s talk on “Better Ruby through Functional Programming.” Sorry, guys! I figured that since I’m working on a presentation involving functional programming, and I mostly use Ruby during work hours, I’d learn a lot there. And I did! I have a much better grasp of what functional programming is now, and how to apply that to Ruby (it can be done without too much hassle, actually). There was one particularly interesting point where Dean posited that we’d see programming (and concurrent programming in particular) become more functional on a small scale, but still object-oriented on a macro level.

Micah’s talk on Limelight (“Develop your Graphical User Interfaces (GUIs) faster than ever, with a thorough suite of unit tests to boot.”) was great, but it was tough because the 8th Lighters were the only Rubyists in the audience (I think), and there were only a few Agile/TDD practitioners. But there was a powerful point about what to do when something is hard to test: rewrite it so that it’s easy to test. And that’s just what Micah did with Limelight – which is indeed easy to test, once you know what you’re doing.

Next, I went to Dean’s other talk, “The Seductions of Scala,” and missed Jim’s “TDD and JavaScript” talk. Sorry, Jim! I had seen a version of Jim’s talk on Friday during the Lunch & Learn, and it was awesome. I’d of course heard about Scala because of the big Rails/Scala/Twitter debacle awhile back, so I was interested in what a language looks like that’s built with concurrency in mind. The language runs on the JVM, so like JRuby, it’s easy to interface with existing Java code. There is some strange-looking syntax to get used to, but it seems interesting, and it sounds like it’s gaining traction on production systems. I had thought the next language I took a look at would be Clojure, since it’s a Lisp dialect with concurrency in mind, and I’ve been studying Scheme, but now I’m thinking I may look into Scala. Or maybe learn JavaScript right. We’ll see. Incidentally, Dean’s new book, Programming Scala is available online in draft form as a preview – it looks great!

Micah’s last talk on “Ruby Kata and Sparring” was great. I’d seen forms of it before: the Langston’s Ant Kata and RubyConf 2008. There’s some kind of magical stuff in this version of the kata (instance_eval), but it’s extremely elegant once you understand the algorithm. I really like the notion of practice as important in software development; Paul was talking about this earlier in the day as well. I’m going to try to do the same kata 3 times a week for a few weeks and see if I see any benefits. I know from trumpet playing that even playing ridiculously easy exercises on a regular basis, with strict attention to form, can yield great benefits.


Permalink 2 Comments

Week 2, Friday

April 3, 2009 at 8:09 pm (Java, System Administration, Week 2) (, , , , , , )

Time is flying a lot faster now. Today I looked at some new technologies (new to me, anyway): Ant and the KML API for Google Maps.

For Rubyists out there, Ant is analogous to Rake, but in the Java world (and Make for C/C++/others). It’s kind of an automated build tool, so that you can avoid duplicating labor each time you want to build a project and run the test suite (or any number of other things). Micah wanted me to build an Ant task that would run all of my tests. So I checked out the Ant manual, but it wasn’t much help at all to me until I’d seen and worked my way through a concrete example. It’s pretty nifty – until now, as far as I knew, I’d have to either let IntelliJ run the tests for me or go through each test class manually running the JUnit tests.

I also had to fix my directory structure to make it more idiomatic for a Java project. Previously I just had my src directory with all my *.java files under version control, but it turned out that what I really needed was to go up a directory and have the main project under version control (Git). This presented a problem for me in that if I just moved my .git directory up to the main project directory, it would appear to Git that I’d deleted and re-added a bunch of files, which would mean that every file’s history would begin again, and I’d lose the ability to see small changes from the previous commit to the next one (just for a certain commit, but still, I didn’t like it). Here’s the workflow I used to move Git’s notion of the structure up a directory, in case anybody else runs into the same issue:

  1. mkdir src/src
    because I knew I was going to need to see the current source files in an src directory, but it needed to be relative to the current Git location, src
  2. git mv src/*.java src/src
    here’s where I’m telling Git to rename the files – the key action that allowed me to preserve history on the same file
  3. mv src/src src_new
    moving the actual source files up to a new folder in the root (which is going to be src eventually, but since “src” is taken for now…
  4. mv src/.git .
    one of the many cool things about Git is that ALL of the versioning information is contained in a single directory – no .svn directories littering the project and making change like this difficult
  5. mv src src_old
    making way for the new src directory
  6. mv src_new src
    in place the way we need it
  7. git status
    checking to make sure things look good, with files being renamed instead of added and deleted)

Pretty simple, considering my initial worries. Thanks, Git!

My time with KML so far has been pretty educational, but I haven’t actually gotten anything done yet, I’ve just been investigating options. I’m working on a problem where I have points on a map with identical latitudes and longitudes, and I need to tell Google Maps to display them as separate points somehow. I’ve found a way to make Google Earth do it fine, but Google Maps is a different story.

Another task I’ve got before I get going on 3-D Tic-Tac-Toe is to split my 2-D version into packages. So I’m going to bone up on the package principles this weekend. I have a tentative separation already (there was some Git love that needed to happen there, too, when I moved files around), but I know have some Common Closure Principle violations I need to take care of before daring to show it to Micah.

Permalink 1 Comment