Constant improvement does not require judgmental reflection

June 9, 2009 at 6:49 pm (Scala, Week 12) (, , , , )

I spent much of the morning wrapping tests around the state machine code I’d written last week and over the weekend. Obviously, this isn’t the ideal way to write tests. I want to be a programmer who does TDD all the time, but I wasn’t that programmer on parts of this project. In the sections of the application where I’d done similar things before (the board and the players, for instance), I had no problem incrementally describing the functionality in specs and implementing it. But as I wrote my first state machine code and experimented with a new interface to Swing, I found myself implementing more and testing less.

As I gain experience and learn from colleagues through pair programming, I imagine that my discipline and abilities with regard to TDD will continue to improve as they have in the past few months. In the time being, I’m proud of the amount of code I’ve been able to delete as I write tests and discover the functionality that is really necessary. There is plenty left to do, but my Scala code is much simpler and easier to modify than the Java version of Tic-Tac-Toe, even though the language is still pretty unfamiliar, and the documentation sparser than Java’s.

I was complaining to Doug late this afternoon about the variations in GUI frameworks that make it difficult to get started in a new one, and I realized that what I really want is to know Swing and Limelight as well as I know XHTML/CSS. Again, I think this is a case of frustration based on lack of experience: once I have years of day-to-day Swing experience under my belt, that will feel great, too. I’m slowly learning to reflect on my coding in a less judgmental way. Bruce Eckel’s recent blog post, “A Career in Computing”, advises “There is no right answer … and always a better way. Show and discuss your code, without emotional attachment. You are not your code.” This gels with my experience in music, where I find it very easy to beat myself up mentally for mistakes that I’m not yet skilled enough to avoid. My goal here is not to feel good about bad code, it’s to learn from my mistakes and engrain a healthy state of mind when coding. If I’m frustrated when coding, I’m teaching myself (unconsiously, of course) that it’s the correct way to feel when coding, and inevitably I’m going to make less progress.

Permalink Leave a Comment

Programming parallels with trumpet playing

May 18, 2009 at 7:41 pm (Ruby, Week 9) (, , , , )

Throughout the day, Micah and I did some ping-pong TDD development in Ruby, getting a good bit of the way through the feature we’re working on. There are still some things to do on this, and I’m going to need to get quicker at changing contexts within the application. It’s not trivial – most Rails apps I’ve worked on have been basically CRUD applications, so this is definitely the most complex (and interesting) project I’ve worked on. The code is very clean, but there were some requirements that increased the complexity a good bit (involving AJAX where we might ordinarily use a simpler 2-way communication method). I’m sure things will get easier as I get more exposure to the project.

With a big project like this, I’m seeing a convincing parallel between my programming life and my trumpet-playing life. As a working trumpet player, I often needed to perform music that seemed too hard for me. In high-pressure situations like these, I just had find a way to make it happen. I would practice and do my best, and in the end I often just had to accept the fact that I couldn’t play it as well as I imagined it could be played by my favorite trumpeters. I feel kind of like that on this project – Micah is of course very comfortable on the project, partly because he’s been on it longer, but mostly because he’s a great programmer. The big plus here is that because we’re pairing most of the time, I don’t have to settle for a subpar performance. The aspects where my junior-ness really shows are the length of time it takes me to figure out how to write the next test or to make it pass, and the number of times I have to ask Micah for explanations and/or confirmation. The end result is still good code, Micah’s making sure of that; it’s just slower going for now.

Just like with trumpet playing, I know things are going to get easier as I get better. How do I make that happen? I’ve improved a lot since I arrived in Libertyville, so my plan is partly to continue on the path I’m on: listening, watching, practicing, and performing (just as I’d do with trumpet). As a trumpet player, there are 2 basic ways I get to the point where I can play a piece beautifully: practicing fundamental skills, and practicing parts of the difficult piece at a slower tempo or lower register. I have the luxury right now of being a little slow, but it needs to be faster. I’m not panicking or pushing myself to go faster than I’m able to do well, but I’m going to start digging into the parts of this project that are difficult for me, in order to get more comfortable, so that I can get faster at thinking through things.

Permalink Leave a Comment

Using Javascript to order the client around

May 17, 2009 at 10:00 pm (Java, Javascript, Ruby, Week 8) (, , , , , , )

Micah and I spent most of Friday working on a lightweight messaging system that’s going to allow us to push messages from server to client, even though the client is basically a web browser. Since HTTP is basically stateless, we’re doing it with AJAX requests (Javascript, with some help from JQuery). And in order to keep it really simple and flexible on the client side, we’re developing something like a message queue on the server, which builds up Javascript for the client to execute whenever it’s ready (this way the server keeps track of time-sensitive issues, and the client doesn’t really have to hammer the server to stay updated). It’s a pretty cool idea that Micah had; he likens it to us putting food on a plate (at the server), and when the client’s hungry, he comes along and takes the food that’s there and eats it (executes it in the browser). We’re using the command pattern to fill up the plate of Javascript.

The lunch & learn was a bit more technical this week (after last week’s great Star Trek excursion), but still great fun. Doug presented a prepared code kata: TDD factorials in C++. I had already seen a little of CppUTest from pairing with Doug earlier in the month, but he went a little more in depth explaining the syntax, which we had just kind of touched on before. He’s teaching a TDD class this week, which I’m sure will be awesome for anyone lucky enough to attend.

Eric Meyer presented the development of a story using acceptance test driven development (ATDD) with Cucumber. He and I had worked with it a good bit while developing our Rails app (which by the way has been live for awhile now): a job board for software craftsmen, so I knew the syntax and structure already. Eric used a great technique to get the story done quickly and correctly while doing a good bit of live coding as well: git tags. He had about 8 steps to the development of the story that he had practiced, and each one was tagged, so that he was free to code in a normal way and know that we could fast-forward to the next step at any point. I’d like to learn more about version control (both Subversion and Git), but it’ll just have to go in the bucket of stuff to learn with everything else!

In less technical news, I finally got a Cubs hat. Look out Chicago, now you might have to hear me say “Y’all” before you know I’m not from around here.

Permalink Leave a Comment

Some Limelight refactoring and Java learning

May 10, 2009 at 10:33 pm (Java, Limelight, Week 7) (, , , , )

Micah and I paired most of the day on Friday on adding a kiosk mode to Limelight. Since the codebase is a mix of Java and Ruby, we were moving back and forth between the two languages (and JUnit/RSpec), but our changes were mostly in Java. There weren’t really too many big surprises along the way, and we worked incrementally enough that, in most cases, I was able to figure out what kind of tests to write. Of course, I did get stumped a few times, but rather than just write the tests himself (which I know he could’ve done in a few seconds), Micah helped me to see the bigger picture of what exactly we were trying to test, and the tests themselves came soon enough after that.

Our Friday Lunch & Learn went in a very different direction than usual – we took a little field trip out to the movie theater and caught the new Star Trek movie. Good stuff; I recommend it!

This weekend, I’ve been finishing up reading the book I’m reviewing, and I’m really enjoying that. It’ll be a good read when it’s done, and it’s already really interesting and helpful (it’s on agile coaching). The other book I’m working on is Thinking in Java by Bruce Eckel. I’ve been pecking at Java since I arrived in March, but I feel like I’d be much better off armed with a more solid understanding of the language, like I have with Ruby. This book is great. I have it checked out from the library right now, but I may actually still end up buying it just because it clarifies so many things. One particular thing I loved when reading this morning Eckel’s coverage of polymorphism, edge cases where you might expect late binding but don’t get it, and the fact that you shouldn’t encounter these edge cases often because there are better ways to design your code. I’m reading in this book a lot of the same OO design principles I read and hear about everywhere else, but with different words, which kind of hammers it home even more.

I watched Uncle Bob’s RailsConf keynote and enjoyed it. I know that a few have pooh-poohed the talk (though many more loved it), and I do agree that the tongue-in-cheek testosterone / estrogen metaphor is outdated, but who can disagree with the crux of his argument? We should drive development with tests, have some humility, and take on tough problems like legacy codebases. Being a professional means different things to different people (one of Uncle Bob’s descriptions), but to most it means you’re good at what you do and that you’re serious about being good (but not necessarily serious about yourself and wearing a 3-piece suit all the time; that’s an entirely different meaning).

Well-tested code means you don’t have to be afraid of change. I worked on a larger project on my last job that took forever to change, because there were virtually no tests. Any change I made to the code (and on any big project, there are plenty of changes) meant I risked breakage. Luckily, the code wasn’t hammered by users or mission-critical, but it is so embarrassing to have bugs in your code, especially when they’re discovered by the client. If I had the skills at the time to get more of that project under test (and I have a good idea of what to do thanks to my apprenticeship experience so far, along with Michael Feathers’ book), things would have gone differently. Changes might not have been that much easier just because of the tests (there are also OO design issues to consider), but they would have been verifiable. I would have known when I had it right.

Permalink Leave a Comment

Back and ready for action: reading and writing

May 4, 2009 at 9:40 pm (Limelight, Reading, Week 7) (, , , , , , , )

Well, I’ve played my last trumpet gig on the books for the time being. Took a trip down to South Carolina over the weekend to play a wedding ceremony and visit my mom. It was a good trip, and I actually got a decent amount of work done, believe it or not. The Limelight GUI that talks to my Java Tic-Tac-Toe code is finally in a completed state! I showed it to Micah this morning, and he didn’t have much to say at first besides that it worked pretty smoothly (he also noticed that I’d put in artificial sleeps to make the Computer vs. Computer game look more interesting). We spent a bit of time looking at some problems I was having with a refactoring in a Props file, but didn’t make much headway.

Most of the other work I did over the long weekend was reading – I’m really enjoying Michael Feathers’ Working Effectively with Legacy Code. I’ve noticed that most TDD resources I’ve read so far have dealt with simple, granular situations, where the design is perfect. But when I go to write tests for my code, I find that things are much more complicated. This tells me that at least one of two things are happening:

  1. Most textbook examples are simpler than real life situations
  2. My design isn’t clean enough

My estimation is that both are the case, but at any rate, I’m getting more and more motivated to write tests, even when it seems like it might be difficult. Particularly, the ideas of “sensing” and “separating” are helping me to crystallize what exactly I’m trying to accomplish when I write tests. The idea is that if I have an implementation method that needs to set a variable, I need to write a test that somehow senses the change in that variable based on the use of that method. It’s a simple idea, but there are a lot of ways that legacy code can make this difficult.

My next assignment was to pretend I was a writer (gasp!) and write a review of Limelight, as though it was for a magazine or something. I found myself drifting into tutorial mode for a paragraph or two, but eventually made my way toward an opinion on the framework. Basically, I think it’s great. There are a few strange behaviors here and there, and some features I’d like to see added, but it’s pretty cool to have a desktop application framework where you only need to write Ruby. Now, I must be completely forthcoming and admit that I’ve never tried any other Ruby GUI frameworks like Shoes, RubyCocoa, or wxRuby. In taking a cursory glance at Shoes (by everyone’s favorite Ruby mad scientist, _why), it looks interesting and feature-packed, but I’d like to see bigger examples, with the same separation of concerns that Limelight boasts. I’d also be surprised if interfacing with Java code was easy, or even possible, since Shoes doesn’t use the JVM.

Whew, I think I’ve written about all the prose I can write in a day; think I’ll spend the rest of the evening working some more SICP exercises. I watched another lecture over the weekend and finally started to look at the book and its exercises. It’s definitely forcing me to think in a very different way than I’m used to – I think this is exactly what Dave Thomas and Andy Hunt had in mind in The Pragmatic Programmer with their suggestion to learn a new language every year. At this point, I’m trying to learn several this half of the year, but since I’d at least written some cursory Java and Javascript code, I think I’m OK for now. I do worry sometimes about stretching myself too thin and becoming a jack of all trades, master of none, but as long as I can keep improving on all the fronts I’m aware of, I think I’m in good shape.

Permalink 1 Comment

Week 3, Monday

April 6, 2009 at 6:31 pm (Ruby, Week 3) (, , )

Yuck. A cold going around the office finally got to me over the weekend, and I’m still way under full speed in my cognitive capacity. Hopefully I can kick it in the next day or so, because I was pretty useless today.

Eric and I had our second iteration meeting with Micah for our Rails project, and that went pretty well, aside from one bug that got uncovered at the meeting. We made a lot of progress this past week and actually hit our estimates, which we were both happy about. We got a new set of stories estimated and assigned for this iteration, and we wrote a decent amount of code today, finishing one small story and getting most of the way through another.

Mocks and stubs still slow me down when reading code, but I’m getting faster at comprehending them and seeing when they’ll be necessary. My biggest challenge, though, is figuring out what to test next. It’s relatively easy to write tests in Cucumber, because those scenarios basically line up with what the user would do in the browser, but RSpec is so much more granular that I sometimes get overwhelmed and have to really spell out for myself what it is that I’m trying to do.

OK, this’ll have to do for tonight, because I need to get well and be at 100% mentally! The big takeaway for me from today was more experience with RSpec and TDD – the more I see it and do it, the easier it’ll get.

Permalink Leave a Comment

Week 1, Weekend

March 29, 2009 at 9:03 pm (Java, Week 1) (, , , )

I spent a lot of time this weekend trying to wrap my head around Java/Swing listeners and how to do TDD with this setup. Eventually I backed up a bit and dug into some more basic Java knowledge – reading from Learning Java by Patrick Niemeyer and Jonathan Knudsen. I just was a little overwhelmed with all I need to learn, and I wanted to focus things a bit more. And it turns out, after spending a good portion of the weekend looking at event listener code, I have a lot better grasp of it now. I was able to delete big chunks of my old GUI code and simplify some things. There are still LOTS of things I need to learn about testing this stuff; I think I might’ve painted myself into a corner with my console-based presenter, so that testing is difficult. Maybe there’s a way around it I’m not seeing, though. Basically, I have the core logic sending a request to a controller (for a move, the game type, or playing again), and the controller listening to the view layer for the answer. Right now there’s a lot of state-saving variables (boolean waitingForInput, stuff like that) that I know there has to be a way around.

At any rate, I’m going to spend some more time with the Java book over the coming week, so that I can get a better handle on things. I’ve been a bit spoiled in that I’ve worked with Ruby for the past couple of years, and have had all that time to absorb and read about the language. So much to learn! It’s so motivating when I come into work and literally everyone else knows so much more than I do (and are more disciplined). The advice that I’ve read from Chad Fowler (My Job Went to India) and many others to “Be the Worst” is really paying off.

I also realized that I never blogged about our Friday Lunch & Learn session – we had a Randori session, where we worked in five-minute pair programming sessions to build a small app. It was humbling to get back into Ruby, which I felt great about two weeks ago, and forget the syntax to set an instance variable in front of everybody (I was being Java-y). But it was excellent to see everybody in action and to hear people’s thought processes as we started the app, when the design was so sparse.

Permalink Leave a Comment

Week 1, Friday

March 27, 2009 at 5:28 pm (Java, Week 1) (, , , , , )

I spent some time last night experimenting with Swing and was able to get the Tic-Tac-Toe grid set up, with some listeners on the squares. Then this morning I wired up the GUI to my existing Java Code. I only had to make one major change, which was getting rid of the Dependency Inversion Principle violation I had in my display code. I just turned that into an abstract class and moved the existing, console-based code into a subclass, and then also derived a GUI display class from the abstract class.

That part was simple, but I really did a lot of monkey-hacking today to get the GUI working properly together with the existing game code. I think part of the problem was that I never really stopped the “spiking” I did last night to learn how to use Swing a little bit. I just kept right on trucking (in implementation code, without tests) until I had a working game. So I need to go back and retrofit some tests to most of the code I’ve written today, which I’m sure will mean rewriting some things. My mom got me Michael Feathers’ Working Effectively With Legacy Code for my birthday, so I may dig into that some to give me some ideas. My understanding is that the book describes legacy code as any code not under test, so I wrote a bunch of legacy code today [frown].

On a brighter note, I’m going to be working with one of the craftsmen on an internal project, most likely using Rails, so at least I’ll be familiar with the language for this one. I’m glad I’ll have a compelling reason to learn RSpec, and probably Cucumber and Selenium as well. These are the kinds of things that motivated me to want to work at 8th Light in the first place. As I told one of the craftsmen when I interviewed, it seems like all of the big names in the Ruby world use TDD/BDD, so I really was looking forward to writing code that way.

I took my first crack at estimating (our initial iteration meeting for the project was today), and only time will tell if I was being too optimistic or not. I certainly don’t think we’ll have too little to do, but as I said in a previous post, I think I’ll get better at estimating as I do it more often and measure actual velocity (stories completed per iteration) against estimates.

Since it’s the end of my first week here, I’ll just close with a general thought on TDD: it isn’t faster to write your first few lines of code in a new project. But if you have tests for those lines, then you know they work. The tests allow you to forget about them, and still be able to change other parts of the eventual system without fear of breaking old stuff. Because it’s got a test suite that you run and see that of the system’s requirements that you have encoded in tests, you’re passing. I’m looking forward to making this a habit and really having TDD become my default coding behavior.

Permalink 6 Comments

Week 1, Tuesday

March 24, 2009 at 8:05 pm (Java, Week 1) (, , , , , , )

Okay, so today was harder. I had a flurry of discoveries this morning as I got my questions answered from some work I did last night on the Tic-Tac-Toe game, and then I hit a big roadblock this afternoon. Lesson learned: interrupt when necessary and get questions answered rather than stalling on my own if I’m really stuck.

My problem this afternoon was the Minimax algorithm. I’d looked at it briefly before, after I had finished the Ruby version of the game, but didn’t understand it and gave up. Since the algorithm is part of this assignment, I buckled down and read several descriptions of the algorithm that I found on Google. I thought I understood the mechanics of the algorithm, decision tree and all, but two things were eluding me: the implementation of the decision tree and the computation of the value of a given board position. Eventually I got close (basically translating the pseudocode to Java and Tic-Tac-Toe), but I really did need Micah to help me think through my implementation line by line in order to see a big mistake I was making with recursion. It’s not there yet, but I think it’s close.

Which leads me to the other (maybe bigger) afternoon problem: in my efforts to understand and implement the algorithm, I had neglected TDD and avoided writing tests. Because it was hard => because I’m not good enough at it yet. Well, Micah’s given me some ideas to begin with: sending in board positions where there is a definite best move, and testing that the algorithm spits out the right one, along with some other lower-level things. He did say it’s hard to test, so that makes me feel a little better, but I have to get to the point where I’m not intimidated by TDD. I caught myself jumping ahead to the implementation several times today (and once in front of Micah IN THE TEST CODE – whoops!).

On to the more complete wins of the day, from the morning: I came in with a couple of questions about how to test specific points in the project. Let’s say I have Game, Player, and Board classes. Now, I needed to test that when I told a Player to make a move, the Player would pick a move, and then populate the Board with that move. I was struggling to find a way to verify that the Player had told the Board to populate. It turned out that I just needed a mock Board object. I had an inkling that this is something mocks would be good for, because I remembered a bit of RSpec (ONLY a bit) where an object might have “should_receive(:populate)” to do something similar. I was really glad to come across this problem, because nearly every time I’d read about mocks and stubs in the past I’d come away feeling dumb and defeated. This was simple, though: I just derived a MockBoard class from Board, added a field on the class (private boolean populateCalled = false;), and overrode the populate() method, setting populateCalled = true inside it (and calling super.populate() when I needed the real behavior later).

I’m still incredibly slow in IntelliJ, so I was happy to pick up a few IDEAs about it today. Get it? Get it? I know, I’m incorrigible… Shift-F6 is the Rename refactoring. Wow, is that going to save a lot of time! I think you have to be hovering on the declaration, but the program goes through and changes the name of that method/field/variable/class, in a pretty smart way.

The biggest IntelliJ thing I’m excited to know about is Live Templates, which right now seems exactly like TextMate snippets. Micah wrote me a quick one that does the skeleton of a JUnit test on a tab-complete of “test”, and I can see how this is going to come in handy. I always liked scripting up and using snippets to blast out often-used ERB template things for Rails, and I’m definitely going to start paying more attention to the things that I end up typing over and over so that I can give those to IntelliJ to do.

Permalink 3 Comments