The Artima Developer Community
Sponsored Link

Ruby Buzz Forum
My Apprenticeship - Wednesday, July 21, 2004

0 replies.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a flat view of this topic  Flat View
Previous Topic   Next Topic
Threaded View: This topic has 0 replies on 1 page
Jake Scruggs

Posts: 336
Nickname: aurorae314
Registered: Feb, 2008

Jake Scruggs is a developer at ThoughtWorks
My Apprenticeship - Wednesday, July 21, 2004 Posted: Jul 21, 2009 9:48 PM
Reply to this message Reply

This post originated from an RSS feed registered with Ruby Buzz by Jake Scruggs.
Original Post: My Apprenticeship - Wednesday, July 21, 2004
Feed Title: Jake Scruggs
Feed URL: http://jakescruggs.blogspot.com/feeds/posts/default
Feed Description: Ruby, Rails, Metrics, Testing, and pursuit of clean code.
Latest Ruby Buzz Posts
Latest Ruby Buzz Posts by Jake Scruggs
Latest Posts From Jake Scruggs

This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.

Wednesday 7-21-04

Our payroll UML diagram (from yesterday) had some needless complexity but, other than that, it was fine. Well, mostly fine.

Lots more patterns today. Many of the patterns boil down to the server-client relationship. Let's say you have a laser scanner object that can scan a bar code and identify a product. There's also going to be a sale object which gets a message from the scanner and then does some sort of sale stuff. Well now the scanner has to have code that knows about the sale and the sale might even have code that depends on the scanner. This system is now tightly coupled. But if you stick and interface between them, you can have them both know about the interface and not each other. Therefore swapping out the scanner for another one doesn't affect the sale code. And changes to the sale don't affect the scanner object. Patterns can be way oversimplified as the proper placement of interfaces. Too many and you've got needless complexity. Too few and the code is tightly coupled and hard to maintain. All these patterns have trade-offs so the big deal is not just knowing how to use them, but being able to figure out if they're necessary/will help your project.

My project for the afternoon was, of course, banging my head against the Linux box. Apache keeps insisting that I don't have permission to run the install.php program, but everybody has permission to use it. Hmm. At least Micah had some trouble when he tried to figure it out. I'm always a wee bit worried that the thing that's been bugging me for days is only 30 seconds worth of work for a pro. So I went back to prowling through the httpd.conf file (a set-up file for the apache file server) for things to change or adjust. The day ended with Micah and me pretty stumped.

The big message I took away from Object Mentor that summer was that although patterns are cool and can help a lot, they add complexity. It's a complexity/coupling trade-off. A message that has stayed with me. Just today I was looking at some code that could have been refactored to be more DRY, but way less intentional and I had to make a call as to wether the project would be better served by adhering to one principle or another. That's the thing about writing code that is meant to be understood by humans: The hard part is not learning the language, patterns, or principles, but knowing when to use them and where.

Read: My Apprenticeship - Wednesday, July 21, 2004


Topic: My Apprenticeship - Tuesday, July 20, 2004 Previous Topic   Next Topic Topic: Efficient low-level VMs implemented in high-level languages

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use