The Avid Apprentice

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

leave a comment »

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!

Written by Caleb

July 22, 2009 at 9:51 PM

Lessons learned while pairing

leave a comment »

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.

Written by Caleb

July 20, 2009 at 8:43 PM

REST, Ajax, and other buzz words

leave a comment »

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.

Written by Caleb

July 15, 2009 at 10:48 PM

8th Light Book Club – Programming Clojure – Week 3

leave a comment »

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 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

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

Written by Caleb

July 14, 2009 at 11:40 PM

People problems != technology problems

with one comment

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.

Written by Caleb

July 13, 2009 at 10:12 PM

Posted in Rant

Tagged with ,

A light bulb in the darkness

leave a comment »

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.

Written by Caleb

July 10, 2009 at 12:25 AM

New tricks, manual refactorings, and sharing the knowledge.

with one comment

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.

Written by Caleb

July 8, 2009 at 9:36 PM