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.

Advertisements

Permalink 1 Comment

Week 2, Thursday

April 2, 2009 at 6:49 pm (Java, Week 2) (, , , , , , , )

Software design was my main focus today – I spent some time creating an updated UML class diagram of my Tic-Tac-Toe game. By creating a Swing-based GUI for the game, I had been forced to make some abstractions in the View/Controller area, and a lot of SOLID principle violations got fixed in that process. However, once I had drawn the UML up on the whiteboard, I saw several things that I knew Micah would point out, so I spent some time cleaning up before I had him look at it.

For instance, my ConsoleView and SwingView classes had dependencies on my PlayerFactory implementation, which was a violation of the Dependency Inversion Principle (DIP). Now, just to be clear, especially for those who haven’t already read Uncle Bob’s (Robert C. Martin’s) books and articles, programmers don’t follow these principles just because they exist – there are clear reasons to adhere in specific situations (and I think by extension, in general wherever possible). My problem here was that if I want to write a new PlayerFactory, which creates Players that have faster algorithms or which pick moves randomly, then I’ll be stuck in the situation of having to go down into all the views and change code there.

I’ll be a bit more specific to make this clearer. My PlayerFactory implementation had an enum full of things like Computer_V_Human, Human_V_Human, etc., to which the views had to have access in order to parse the names and display the game type choices to the console or GUI. So then I couldn’t change a field in PlayerFactory without needing to verify that it’s OK with the view. But PlayerFactory shouldn’t have to worry about that! I refactored PlayerFactory and the Views, adding a method gameTypeToString() on PlayerFactory, so that now the Views are telling the PlayerFactory to do something, rather than pulling out and parsing enum members, which felt kind of magical (in a bad way). At any rate, the final step was to extract an interface out of my implementation of the PlayerFactory, so that now the Views could just refer to the interface and not the implementation. The Dependency Inversion Principle says you depend on abstractions, not implementations or details. Especially when you have an idea that those details are going to change…

Which brings me to my next big assignment: I still have a significant number of DIP violations with dependencies on my Board class, which means that it will be hard to change it (it’s rigid) and I’ll break a lot of stuff when I do change it (it’s fragile). So what part of the application would you guess that Micah wants me to change? Indeed, now I need to create the option and implementation to play 3-dimensional Tic-Tac-Toe. There are 2 things I foresee happening: (1) lots of pain when changing the Board, and (2) lots of changes in other places. I know the minimax algorithm in particular is going to take a lot longer to run – I’m going to be traversing a tree with a LOT more levels: 27 vs. 9. That might not sound like a lot, but the number of nodes grows exponentially. There are 2^9 (512) nodes right now at the start of the game, but now there will be 2^27 (134,217,728) – OUCH! I may be off by one on those exponents, but you can see the problem… And I can see that I’m going to need to use some of the speed strategies that I read about when I was researching the minimax algorithm.

Permalink Leave a Comment

Week 2, Wednesday

April 1, 2009 at 10:10 pm (System Administration, Week 2) (, , , , )

Last things first: I had some delicious Chicago-style pizza this evening, my first since moving to Illinois. I won’t name names, but it was at a well-known place, highly recommended by some friends back in Georgia. I got some hot tips at work this afternoon about some other places that are supposed to be better, so I’ll be excited to try those once my wife and I finish all of our leftovers!

OK, on to the fun stuff. Eric and I worked on some more stories for the project we’re on. I actually had a decent amount to contribute today, because we did a lot of deployment-related stuff: SSL, payment gateways, Apache/Passenger configuration, and generally setting up a new Ubuntu slice to run Rails. My last job involved a lot of this kind of thing, so I was relatively comfortable, especially compared to yesterday’s mostly RSpec/Cucumber work. I had forgotten a lot of things, though, especially regarding Apache setup. We were both talking today about how we needed to go home and experiment with different Apache config commands to get more familiar. The big stumpers were VirtualHost, NameVirtualHost, and a lot of the mod_rewrite syntax (RewriteCond, RewriteRule, etc.) – nothing a few hours of thought and Q&A with Google couldn’t solve for us today, though.

It was nice having more to contribute, but at the same time it was frustrating when I couldn’t remember the syntax for things I know I’ve done before. It sure is a lot easier to copy a file from another project and replace a few lines than it is to recreate it one from scratch – but I’ve been interested in system administration stuff for awhile, so it’s good for me to know and practice.

My wife’s mother is in real estate – meaning she fixes up and sells or rents houses. For awhile starting out, there were certain things she didn’t know how to do, like laying bricks for a fireplace. So she hired some guys to come out and do the job, but she stood there with them and watched them do the job, asking questions and absorbing the information until she knew how to do it. When she needed a brick fence later on, she layed the bricks herself (and saved a lot of money, of course). This strikes me as a great model for software developers who work alone or on small teams with skill holes. Just hire somebody to come in and do the job, but learn from them. Chances are you won’t be as good as them at it when they leave, but you’ll be a heck of a lot better than you were before.

I know some companies can afford to have distinctions between/among system admins, database admins, and developers, but I think with software craftsmanship, and smaller teams in general, it’s important for the tech people to be able to get everything done, top to bottom. And for me personally, I love the idea of having the necessary knowledge and skill to produce a great product alone or with a pair.

I can see why people say that demonstrating a task or skill for someone is a great way to learn it, because I’m motivated to get more solid with my sysadmin knowledge, even though I felt like it was almost good enough today. It’s just a matter of prioritizing at this point. My stack of books to read is getting taller and taller, but I can only learn so much at once!

Permalink Leave a Comment

Week 2, Tuesday

March 31, 2009 at 6:57 pm (Ruby, Week 2) (, , , , , )

Today was my first day of really serious pair programming: Eric Meyer and I worked on a Rails application, learning Cucumber together along the way. Some of the most interesting things I’d read about pairing really proved true for me today: it was more fun than developing alone, it made me concentrate more and think through decisions better than I would alone, and it definitely gave us a better result than I’d get alone (I can’t speak for Eric!).

Cucumber is a great acceptance testing framework. The idea is, you write the tests in plain text, then wire them up using regular expressions to Webrat, Selenium, Watir, Mechanize, etc. There is a little more structure than that, but your best guess is to jump right in and try it out. Even if you’re not doing unit tests, these can really prove that a given feature works, and it only takes an hour or so to really get the hang of it. Cucumber even generates regexes for you to copy and paste, based on your Givens, Whens, and Thens. If you’re interested in learning Cucumber, check out Ryan Bates’ Railscast on Cucumber. It’s really clear and you don’t need to be experienced with testing to understand it (and it’s brand new – just came out yesterday). I’d definitely start here if you’re doing Rails work and are interested in getting into testing. And if you’re doing Rails work and NOT interested in getting into testing… Well, I’d still start here.

It’s nice to be doing Ruby again, where I have a lot more experience, but I quickly realized that the way I did Rails isn’t anything like the way 8th Light does Rails. Basically everything gets unit tested, including views. One result is that I’m very confident about the solidity of this application after running all of the specs, but another equally important one is that when things need to change, we find out very quickly when things get broken, and we know when everything is fixed. So we don’t waste time click-testing through sample user workflows as each change gets made, but we still know we’re OK.

I had to stop our coding process several times to ask questions and sometimes just look at the code for another minute or so to absorb the reasons for testing decisions. Mocks and stubs are looking more normal, and I’m even starting to notice ahead of time when one will be needed. I still struggle with starting out on a testing path, and I’m sure it’ll stay that way for awhile, but I know I’ll progress with time and experience.

Permalink Leave a Comment

Week 2, Monday

March 30, 2009 at 6:57 pm (Java, Week 2) (, , , , , , )

I feel like I’m getting close to completing the Tic-Tac-Toe game in Java. The functionality is there for Swing GUI and console modes, but I have a lot more to learn about GUI testing (simulating mousePressed and actionPerformed events) and testing threads (turns out I need to USE threads to test threads – duh).

But I’m feeling much more comfortable in Java. At Micah’s suggestion today, I took a lot of GUI-specific code (JLabel, JButton, etc.) out of my controller class and moved it into the view. This made a lot of sense since the implementation of the view should be easily swappable, without the controller worrying about it. I also refactored my old ConsoleDisplay class out to be more in line with my GUI code, so that both the console code and GUI code are just views, using the SAME controller/presenter. This was kind of a pain in that I had to add threading in the console code so that the GUI controller worked for it as well, but the big win here is that I can swap out views super-easily. It probably would have taken me another whole weekend without Micah’s help today, though.

We had an internal stand-up meeting, where everybody briefly talked about their current projects, side projects, learning experiences, blogs, kata, etc. It was short and to the point, but I think it’s a great idea for a team’s camaraderie – especially since two of the team members work at a client site. Paul just came out with a great blog post titled Material Consciousness in Software that’s well worth your time, and both Erics have blog posts in the works. Stay tuned!

Speaking of the culture here at 8th Light, I noticed very early on that everyone, without exception, shakes hands with everyone else as they arrive at work, and as they leave. It seemed very formal and quirky at first, but it’s really growing on me. So often, people show up to work with their team and barely grunt a “Morning” before diving into code. I definitely was guilty of that at my old job, and it seems like this is a good way to reinforce the team’s communication. Now that I write this down, it sounds like marketing mumbo-jumbo, but it’s a fact. I don’t know whether this is something that’s grown organically here or if the guys formulated the idea before its execution (or somewhere in between), but shaking hands feels like it solidifies a relationship each time, and at the same time heightens the importance of what you’re about to do (or have just done): software craftsmanship.

Permalink Leave a Comment