8th Light Book Club – 1 paper down, 9 to go

This week we discussed On the criteria to be used in decomposing systems into modules. A lot of the talk centered around the age of the paper and how different it would be to work in those times. I’m betting the people who learned to program in those times have unique insight to computers that I’ve probably missed out on with my fancy IDE’s and high-level langauges.

Another topic someone brought up was that this should be common sense to a competent developer. I agree completely and I hope people won’t brush off the significance of the paper just because it can seem so simple. It’s the foundations that are so vital and can really bite us if we brush them aside. I’m really looking forward to next week’s topic, A Note On Distributed Computing. Everyone seemed really enthusiastic and I hope the momentum keeps on!

Lessons learned while pairing

Today I spent most of the day setting up a new client project in Rails and beginning to write the first Cucumber specs. The project is fairly trivial, but it is just enough to challenge me and keep me busy for the time we estimated for it. The estimation was an interesting exercise in being honest with your abilities yet not letting yourself off the hook with overestimating. Since this did have to get OK’d by a client for the time I estimated, I wanted it to be competitive but realistic. It’s going to involve some new stuff like using ActiveMerchant to hookup with PayPal and some basic authentication. I’ve already done the legwork prior to starting up the project to get familiar with the basics so I’m fairly confident with the estimates I gave for those parts.

I did get a chance to pair on it with Jim today and it was a great experience. I REALLY love pair programming and it’s one of the major reasons I came to the shop. We don’t pair all the time, but I trust in their wisdom to decide when it’s possible and beneficial to do so. I learned a few new techniques and I’d like to think I showed him a thing or two that I had discovered (for better or worse!).

I think I’m doing a good job of driving the tests with Cucumber and RSpec, and that testing brought up a good point. When letting your tests drive the code, “Do the simplest thing, not the stupidest thing”. I was writing specs and as I made them pass, I’d check my progress on my Cucumber features. I got my step to pass and I was continuing on to the next when Jim stopped me to ask why I hadn’t filled out some behavior. I said something like “I don’t need that to make my feature pass, I’m just letting my tests drive the code.” He let me know that that’s a good thing, but I knew that this behavior really was needed and writing a feature for it would probably have been too granular for that level of testing. There’s nothing wrong with closing up those gaps in your code, but you still need to test it with something at the unit level! It was another good lesson in a long line of “beyond the basics” testing. It’s not a black and white world and having that test-sense is another tool that every craftsman needs and I’m working on honing.

REST, Ajax, and other buzz words

On Tuesday, I was given the assignment to create a very basic Rails app to manage lists of items. It’s a textbook CRUD application, exactly what Rails should be great at. It also seemed like it would be a great chance to learn how to leverage a REST architecture in Rails.

After a few days, I’d have to say I am liking how little code needs to be written to get stuff done. It’s also nice to have a convention for laying out your API. I’m not the greatest at designing API’s right now, so anything that helps me in that department is welcome. It’s also nice because any time I look in a controller, I know where the behavior I am looking for is always in the same spot. I’ve heard that it gets abused in some situations by people trying to force a REST architecture on a domain that doesn’t fit. Knowing when and where to implement a pattern or convention is a skill that comes with a lot of experience and it doesn’t hurt to have a pair to keep you in check.

Today I got the basic infrastructure done and Jim asked me to use Ajax on the page to get rid of the noticeable redirects that were happening. I understand the basic premise about Ajax but I haven’t implemented it on my own. I started to extact some partials from the view and tried to hook it up with a link_to_remote but it didn’t go smoothly. I’ve decided to purchase Ajax with Prototype.js from PeepCode and give it a watch tonight and tomorrow morning to help give me a lift. I’ve watched a few videos from PeepCode and they are always great quality. I’m aiming to get the basic Ajax done tomorrow and then Jim said he wanted to do some pairing to show me some drag-and-drop effects which I’m really looking forward to.

8th Light Book Club – Programming Clojure – Week 3

After this week, we’ve decided to switch to reading papers from Michael Feather’s 10 Papers Every Programmer Should Read (At Least Twice). We are going to start with the first on the list, On the criteria to be used in decomposing systems into modules – David Parnas.

Here are the minutes for this week’s meeting:

12:42 PM Start
http://clojure.blip.tv/ screencasts
Micah begins presenting his bowling solution
(Was checking out code and not writing down notes about discussion, sorry!)

12:54 PM
Micah ends presentation
Comments on the size of Java solution being about 5x larger than Clojure solution
Colin begins presentation
Issues with try/catch
Placing functions inside of functions
Layout of code
Encapsulation

1:18 PM
Colin’s presentation ends

1:20 PM
Discussion about how we can stimulate participation, most polled indicate time is a factor.

1:30 PM Ended

People problems != technology problems

I read a blog post today by Michael Feathers titled Ending the Era of Patronizing Language Design. Reading the article struck a chord since I have had this discussion before at a previous employer. While discussing dynamic languages, there were objections to how things could be unpredictable in dynamic languages. They were scared of the mess that could be made. Another discussion we had was related to locking of files in a version control system. The arguments were very similar to the dynamic language arguments. They were worried that people would have too many issues merging their code or not checking in for long periods of time.

It didn’t take long to realize that what they really saying is “We don’t trust our programmers to be responsible enough to use such powerful tools”. This was a problem with people, not technology. Why is the opinion of our community so low? I certainly don’t think it is because we aren’t smart enough to use these tools wisely. Maybe it’s related to the abysmal quality of software “releases” that so many of us have seen happen. What causes these bad releases? Is it the customers who ask too much? Is it managers who put the pressure on us to work overtime to get these features released that were promised? In the end, everyone plays a part. But the part that you can control is how you respond to this pressure. I’ve seen many developers just shrug their shoulders and take the load, knowing it won’t be completed or at least completed correctly. The excuse I hear is generally along the lines of “What can I do? It’s out of my hands.”

You can do something about it, but it’s not easy. To the developer who is already drowning in deadlines and oversold features, you are going to have to make your stand in two places. You will need to push back against the people handing down the requirements. If you think they are giving you too much, let them know. You are not being lazy, you are being honest. Honesty doesn’t always win you fans, but I like this quote by 311: “Sometimes the things you are scorned for, you should be adored for.” This isn’t likely to produce quick results and it might not produce any results other than you getting on the bad side of your managers. If this puts you in hostile territory, perhaps it’s time to reconsider your employment if possible.

The other battle will be waged in your personal time. Yes, I’m talking about that tiny fragment of time you have left after your soul-crushing job. If you want to reduce your load at work, you will have to get better at producing quality code in your own time. Work is no place to sharpen your skills. That’s not to say you can’t learn something at work, but if you are already in this situation your work day is probably comprised of desperately applying every trick you know to get by. During your own time, you need to read blogs, follow interesting people on Twitter, see what people who (seem) to have their job in control are doing to manage that stress. Your situation isn’t special, many people have tackled this hurdle before. Learn from their mistakes!

I know this can sound like someone preaching the impossible, but extreme situations call for extreme measures. I took the easy way out and went to a company that valued releasing quality software while giving their employees a good work/life balance. If you think you can change your situation by changing your environment for the better, I wish you good luck and I hope you keep your sanity.

A light bulb in the darkness

I’m not going to write about my day too much since once again it wasn’t as productive as I wanted. In the evening once I got home I decided to give myself a break and watch one of Jeremy Miller’s talks at NDC 2009. I’ve always enjoyed listening to him on podcasts when he was a guest and CodeBetter was a big influence on me wanting to step-up my developer game. I’m not sure if it was the break from working on my project, some inspiration from his talk, or my mind misfiring because I was tired, but around 10 PM I started to see clearly what I needed to do. Everywhere I looked in my Java, I was seeing my code being too nosy about it’s dependencies business. Jim and I had discussed Tell Don’t Ask before, but I was having a hard time seeing it. Tonight, I think I’ve made my first steps towards understanding it. And with that off my chest, I need to go to sleep so I can actually make it in tomorrow. I REALLY want to keep coding, but I’ll just have to take my chances and sleep. I really hope that this flash of inspiration isn’t gone come 9 AM.

New tricks, manual refactorings, and sharing the knowledge.

Today I didn’t hit my goal that I stated during my stand-up with Jim, and that is always a bummer. I did learn to use a few new tricks including the ternary operator in Ruby and the value ||= value_to_assign_if_nil idiom. I was actually playing with them in this method.

Why did I go with the ternary operator instead of ||= The first one I wrote was the ternary but I really didn’t like having the two ?’s so close to each other. It just really didn’t seem to read well. Then I wrote the other line and I really liked how clear it looked. But then I realized that I was doing an assignment for no reason. It produced the same results (my tests reinforced that), but it just didn’t feel right. So ternary it was. I’m not exactly sure what the bigger lesson here is, but even I know that assigning something and never using it is just silly.

I also learned that having a refactoring IDE like IntelliJ is great, but you actually need to know how to manually perform the refactors sometimes. My situation today was extracting a class in Ruby. Needless to say, it took much longer than it should have and I was not green for awhile. That is a good sign that you took a wrong turn somewhere.

I’ve also began to mentor a friend of mine who is learning to program. I take great satisfaction in helping others and it’s a nice feeling to be able to pass on some of my knowledge. I imagine that this is how the craftsmen feel when they help us over a hurdle or show us something new and cool. I also was able to help one of our interns find a bug where they were setting a reference to an array instead of creating a copy of it. I’ve chased my tail on that a few times so I was pretty quick to realize the issue but we still had to track down where the culprit was. The satisfaction of helping someone else instead of constantly needing help was great. There is always something you can teach someone and there is always something you can be taught.

TDD alone is not enough

Per yesterday’s post, I spent my day writing a text UI in Ruby to access my Java code. Instead of letting my existing Java API drive the design of my Ruby code, I mocked out the Java side completely and simply wrote the code to express the interface I wanted. I only concerned myself with the behavior that my UI needed such as sending player names for internal record keeping, getting the board for display purposes, sending the move to make, checking for a win or tie, and getting the results to display. That’s all any client of my Java code would ever need to play a game. Each one of those items is usually no more than a single method, and as a result my programmatic interface is straight forward and clean.

Now the big task lays ahead. It’s time to refactor my Java code to work well with the interface that the client has specified. This type of outside-in development is not something that I just discovered, but for some reason in my Rails app I was having problems expressing this correctly. I think it had a lot to do with my unfamiliarity with Rails and tackling two problems at once is usually not a good idea.

It also helped to reinforce that doing TDD alone is not enough. TDD can help you create a cleaner design, but it is no guarantee. You still need design-sense to know how to structure your application beyond the basic decoupling benefits of TDD.

One of the major problems my code had was that any UI that used it was not in control of the game flow. I got it in my head that this is a game and it needs a game loop. But why does Tic-Tac-Toe need a game loop? It’s just move until the game is over. I believe when Jim first told me to add Swing as a UI option, he had identified this dependency and was trying to get me to break it. What did I do? I created some poorly implemented method of having my game poll the UI in it’s loop. What I should have done is what I’m doing now. Let the UI dictate the game flow by sending commands to the game. My game should only care about keeping itself in a valid state. As long as it performs that task, the client is free to implement the flow however it wants. In my text UI, it is using a loop. In my Swing code, it should use events. In Rails, it’s going to receive a request over the web and then manipulate it’s model. My game code shouldn’t care about these details. All it needs to know is that when I tell it to place a marker in the top left corner, it should make sure it’s valid and then manipulate it’s state.

This day has been a pretty big eye opener for me. Will I make this mistake again? I surely will. But next time I hope that as soon as I start feeling this resistance to change, I can identify it and rip it out.

8th Light Book Club – Programming Clojure – Week 2

Today was the 2nd official meeting of the 8th Light Book Club. We are reading “Programming Clojure” by Stuart Halloway.

I’ve never been the secretary of any club, and I didn’t research what the standard is for recording minutes. I am open to any suggestions! So here it is, shooting from the hip:

1:05 PM Start
Macros
Metaprogramming
Symbols
Keywords
Simplicity of the language
Lists
Special forms
IDE’s for Clojure (IntelliJ plugin, TextMate bundle)

1:15 PM
Sequences
Exercises in book
Learning/refreshing functional programming
Clojure mailing list
Corey Haines, Stuart Halloway, Relevance
Clojure in the wild
Chicago On Clojure

1:25 PM
Metadata
Design by contract
Whitespace
When and when-not macros
Tail-recursion and recur
Calling Java

1:35 PM
Calling static methods in Java

1:38 PM
Last call
Project for next time: Bowling Game Kata

1:40 End

Great meeting everyone!

Taking a step back

Sometimes when you try to take on too much, frustration can really get you down. I found myself facing this issue with my JRuby on Rails project. I have followed a couple of Rails tutorials and I understand the basic concept of the MVC pattern, but I definitely qualify as a rails noob. Most of the Rails tutorials I have checked out seem to tackle a project that fits nicely into the Rails conventions. Usually this means they are heavy on CRUD and focus on using REST conventions to handle a lot of the work for you. This is great for getting your feet wet and I always recommend these tutorials to people who are interested in checking out Rails. I’d say the problem with most tutorials though is that there is a huge leap from the entry-level app to the one you really wanted to create when you learned Rails. I’m betting a lot of aspiring developers hit this barrier and give up, which really stinks!

So what do we do? We need to step back and realize that success is built on many small victories. Instead of trying to tackle all those features you wanted in your “killer” app, select one and try to implement it in a smaller, isolated environment. Make it into a kata that you practice each day until you are comfortable and then move on to the next feature. Once you are competent with the individual pieces, start to practice their interactions. There’s a reason that many people like to work in short, iterative development cycles. It gets you something that functions quickly and that helps to boost confidence. Confidence (not arrogance!) is one of the greatest tools a programmer can have. I know my confidence can certainly be lacking, and it gets smacked around really hard when I get too big for my britches.

To this end, I’ve reduced the scope on my JRuby adventure to a plain console app. Why? Because I was trying to fight a war on two-fronts: cleaning up the interface of my Java code so that it can be used as a library and learning Rails beyond CRUD. I haven’t given up on Rails all together though! I’m going to take my own advice and go back to the simple stuff until it is internalized and I don’t struggle with the basics. It’s better to have progress in small steps than to take a great leap and fall. Then again, you can learn a lot about humility from falling every once in awhile.