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

Photoshop, Radiant, and threads

May 28, 2009 at 6:59 pm (Graphic Design, Week 10) (, , , )

I polished off the old Photoshop skills today to put together a design for an upcoming event web site. Things came back to me relatively quickly, but it’s still an amazing program that I’ll probably never master. The CS 3 version of Photoshop, incidentally, gives you the ability to select multiple layers in the Layers palette. I’m pretty pleased with the way the design is coming together so far; it’s almost done; I’m just waiting on a logo to finalize the look for the header. I ended up using a lot of shapes and the Direct Selection tool to modify them when the shapes needed to change. It seems like the Agile way to design: change becomes very easy, compared to just painting and filling selections.

Caleb and I are going to be working on the site together, and we’re pretty sure we’re going to use Radiant for the site. Radiant is a CMS (content management system), using Rails. It’s installed as a gem, which makes things very easy and makes our work mostly configuration rather than re-inventing the wheel by coding up an admin section. We don’t need anything too complicated, just some image uploads and static information. We took some time this morning checking out Radiant’s extension system to make sure it’s going to be customizable enough, and I was really pleased to see how easy it was. I’m looking at Keith Bingman’s paperclipped extension, which is based on Thoughtbot’s excellent Rails plugin: Paperclip.

I’m also working through Uncle Bob’s The Craftsman articles (click “Craftsmen” on the link to get to the articles), which I’d started a month or two ago, but fizzled out on. Justin Martin’s apprenticeship blog reminded me to get going on them again, and I’m thinking a lot more about concurrency. Threads have seemed fairly magical when I’ve used them (and seen Micah use them) so far, so I definitely need to do more reading and practice with them.

Permalink Leave a Comment

RSpec getting easier on new project

May 26, 2009 at 9:44 pm (Ruby, Week 10) (, , , )

I hopped on a new project today with Jim and Paul (both Erics are also on the project, but weren’t in the office today). It’s a Rails application, and I was making some changes and bug fixes. I ended up having lots of questions for both of the guys as I got acquainted with the application; some of those are going to go away as I learn the codebase. The end of the first iteration is tomorrow, so I’m trying to work quickly to patch up these bugs, but at the same time I’m keeping a high standard of quality. It was a little stressful, but that’s probably mostly because I had a little too much caffeine – nobody’s putting pressure on me to hurry up yet!

It was great taking responsibility for a small piece Rails code (test-driving it, of course) and improving it. As I’ve said before, I generally feel very comfortable working with Rails and HTML/CSS, so I appreciate the chance to give back to the team, even though the other guys are probably still faster on the Rails test-writing.

RSpec isn’t feeling foreign at all anymore. At this point, I think I have a decent intuition for when to mock, when to stub, and the general syntax, but my vocabulary needs much improvement. I spent some time with the RSpec documentation looking for matchers, but I didn’t always know where to look to find what I wanted (especially in view and controller tests). So I’m planning to bone up a bit on objects like response and template (looks like the RSpec wiki on GitHub is a great source of information).

Tonight Software Craftsmanship group meeting was awesome. Doug kicked things off by talking about a bit of the history behind the software craftsmanship manifesto, and his thoughts on gaining consensus and what makes someone an authority. The main takeaway, for me (in addition to the contextual history of the manifesto), was that apprenticeship is the path to finding your personal authority. When you’re an apprentice to someone, you’re making that person an authority in your field of apprenticeship.

Then Jake Scruggs and Jim talked about their experiences during the software craftsmanship swap (which they’ve also both blogged about). It was mostly a question-and-answer session, but both of the guys were really interesting and engaging speakers. I’m excited about the next swap; it seems to me that it’s energized both teams into improvement.

Permalink Leave a Comment

Week 5, Monday

April 20, 2009 at 9:37 pm (Ruby, Week 5) (, , )

Long day today: we closed out basically all of the outstanding bugs in our Rails application, and we’re going to be launching publicly soon. There are a few styling and wording tweaks left, but the actual bugs and other big things are all done. I ran across a problem with RESTful routing in Rails that somehow I hadn’t encountered before. I know that on an edit form, you generally need something along the lines of :html => { :method => :put } since browsers don’t really do PUT requests, at least not yet (it inserts a hidden _method input with value “put”). This was working great to direct the form submittal to the :update action, but we also had an observe_field that needed to submit to a different action (for a live-preview AJAX request). It turned out that the observe_field was trying to submit to the :update action as well. I have a feeling there’s a “Rails way” around this dilemma, but I ended up just changing the :update action to be a straight POST request (no PUT), adding a :member => {:update => :post} route to handle it, and things are going swimmingly now.

Paul and I stuck around late to do some styling tweaks, and I think we’ve got something presentable, though there are still some improvements to be made. Launching early and often is exciting: we’ve gotten so much done in just three weeks on this project!

Micah and I had a one-month retrospective on my apprenticeship, covering the things that were going well, the things that weren’t going as well, and the things that should change. We think that in general, things are going very well. I mentioned that while I’ve come a long way with TDD and RSpec, that part of my programming is definitely weak. It kind of ends up falling into the “good” column, since I’ve progressed so much, but I have a long way to go to make it as strong of a habit as the other 8th Lighters. It sounds like there’s another, tougher project on the horizon once I finish Tic-Tac-Toe. Micah says the big things left for my Tic-Tac-Toe game are caching of the board scores (my HashTable) and then a code review with him. I’m pretty confident in my ability to get the HashTable working properly, but I know that the code review is going to show me some weak spots. I’m definitely going to need to take a few passes through the codebase to refactor and add tests where I can. I feel certain that I’m going to spot a lot of bad things, since I started this project three weeks ago, and I’ve come so far since then. It makes me a little apprehensive, but I have to remember this talk from David Heinemeier-Hansson. Key thoughts: “The software doesn’t change… you got smarter… you learned more… When that tomato went from great to rotten, that was a process in you, where you improved.” Inspiring and happy thoughts.

Permalink Leave a Comment

Week 4, Friday

April 17, 2009 at 7:47 pm (Ruby, Week 4) (, , , )

Jake Scruggs and I started the day out by changing the feature I did yesterday so that emails would only be sent for 500 errors, not 404’s. This way people’s inboxes won’t be clogged with notifications when any old bot hits the wrong URL – or tries to hack it! It’s a good fix to begin with, but Jake also helped me to think through a refactoring that really cleaned things up. I was overriding the rescue_action_in_public method from the exception_notification plugin, and now that we needed it to act almost like the default, we had almost an exact copy of that method from the plugin. There’s an if-else statement that separates 404 errors from others, and the plugin, by default, calls its render_404 method and render_500 method, respectively. The obvious solution (well, obvious after the fact, anyway), was to instead override render_404 and render_500 to simply call our new method, render_error (which uses the Rails layout code to keep some consistency across the site). Much nicer, much cleaner. Thanks, Jake!

Eric and I finally got our continuous integration server up and running for the site, which was kind of an adventure. Note to self: use rake features, not cucumber features -n. CruiseControl.rb interprets the rake tasks better than command line output – or at least the setup is more intuitive that way. CruiseControl.rb, by the way, is pretty awesome: it’s a Rails app that monitors your Subversion repository and runs scripts of your choice, emailing build failures as desired. I can imagine a similar setup using Ant tasks for Java, and it looks like there’s a Cruise Control for that, too.

Eric and I started a small bug list as well, and knocked out several of those before we finished for the day (several styling things, and one or two things we didn’t consider when building stories). I’m definitely feeling much more comfortable in RSpec now: I wrote some helper tests after everyone else left for the day, and I knew exactly what I needed to do, in a strict TDD/BDD manner. I went pretty slowly, and because of my tests, and our already extensive unit and integration test suite, I’m pretty confident of the correctness of my implementation code (of course, I also checked manually to make sure I didn’t do anything stupid that I forgot to test). It’s nice not to feel overwhelmed by RSpec anymore. I still want to get the new RSpec book, but I’m feeling less and less that I absolutely MUST read it as I learn more on the job.

Permalink Leave a 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 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