Red Squirrel Reflections
Dave Hoover explores the psychology of software development
Fri, 03 Oct 2008Obie's Me Meme post...
Go ahead and follow these instructions if you're into silly memes...
Wed, 23 Apr 2008Paul Graham's Be Good. I found this little tidbit of wisdom echoed the words of Jerry Weinberg'a Secrets of Consulting...
Being good is a particularly useful strategy for making decisions in complex situations because it's stateless. It's like telling the truth. The trouble with lying is that you have to remember everything you've said in the past to make sure you don't contradict yourself. If you tell the truth you don't have to remember anything, and that's a really useful property in domains where things happen fast. --Paul Graham
One of the great advantages of not lying to your clients is that you generally don't have to remember what you said. --Jerry Weinberg
Mon, 16 Apr 2007Ryan says:
Frameworks don't solve scalability problems, design solves scalability problems.I agree. Using a tool that gets out of your way (like ActiveRecord) gives you the power to design your own solutions with minimal accidental complexity.
Fri, 09 Mar 2007Tyler's first attempt at instructing our Rails TDD Boot Camp. It has been humbling to watch Tyler pick up the course that I helped develop last year, make it RESTful and 1.2-friendly, and then deliver it with confidence. Unlike me, who was always on the edge of collapse after day 4 of the course, Tyler was itching for more. I believe this officially confirms that Tyler is an extrovert. You can read his latest blog post for his reflections on the experience.
Wed, 20 Dec 2006known as "languages of the gods". Giles shares some excellent stories and rants along the way...
If there's anything godlike about using Lisp or Smalltalk when the rest of the world is on Java and C#, it isn't the skill level required. It's the balls. Standing up to the rest of the world and telling them, "your technology decisions are bad and I'm going to use a language that doesn't suck" is a very unusual move.via reddit
Mon, 11 Dec 2006Kevin Barnes is becoming one of my favorite bloggers. Today he posted a little gem about dogmatic YAGNI.
My point is that sometimes you are going to need it and you know you are going to need it. The secret is to use some balance and not just shut off your brain.This took me back to what agilists were saying in 2001...
No process is foolproof enough, or complete enough, for users of that process to turn off their brains.I believe this quote was from a paper from some of the guys from RoleModel but I can't find the PDF.
Fri, 08 Dec 2006the freedom that monkeypatching provides, it's not until I taught the concept to a room of Ruby newbies that I appreciated how dangerous it could be in a team environment, particularly on a team with more than one Ruby newbie. Obie is teaching our Rails course at Cisco this week where it sounds like he had a similar experience. Tim Kuntz has written a nice series of blog posts on introductory ActiveRecord: intro, impl-1, impl-2, conventions.
Mon, 04 Dec 2006Aslak has been doing some cool work with RSpec and Watir. Most recently, he's added automated screen capture on failing Watir tests to his bag of tricks ... and he's not just using plain 'ol Watir, he's using SafariWatir too. :-)
Fri, 10 Nov 2006heading to sunny Columbus in February to speak at erubycon, a conference focused on Ruby in the Enterprise put on by the artisans at EdgeCase. I'm honored to share the same web page with the other erubycon speakers: Bruce, Stuart, Justin, and Neal.
Mon, 16 Oct 2006Kevin Barnes posted an insightful piece on Knowing, Doing, Learning in the context of web framework development. A quote that fits into Expose Your Ignorance...
"...the difference between an expert and a student is that an expert hasn't yet learned how much he doesn't know."via Obie
Mon, 09 Oct 2006Richard A. O'Keefe responded to a question of language marketablitiy with an fascinating post to the mercury-users mailing list.
Why would anyone choose an unhyped language like Mercury over a widely hyped language like Java unless they were interested in finding out what can be accomplished by doing things DIFFERENTLY?via reddit.
After four years of yearning to feel the difference that Ruby can make, and finally feeling the difference in the past year in my full-time work, it's exciting to have the luxury of looking beyond Ruby for this DIFFERENT-ness that Richard is talking about. Smalltalk and Scheme are two of the languages I yearn to learn now.
Tue, 22 Aug 2006George provided an insightful post on Java and the trend toward dynamic languages:
I'd like to see focus shifted to the core characteristics of Java that made it such an interesting prospect at first, and these, in my opinion, boil down to good software design, powered by fundamental OO principles, not bells and whistles like Continuations, which, according to the Ruby FAQ, can be used to implement complex control structures, but are typically more useful as ways of confusing people.
Tue, 11 Jul 2006Yukihiro Matsumoto: I work very eagerly to be lazy.
Sun, 11 Jun 2006Tim Kuntz is one of my teammates at my current client. He also just started as the first Ruby guide for About.com. (Coincidentally, About.com was my first venture into technology: I was the Teen Advice guide in 1999. I'm using the term "technology" loosely. I learned HTML, which for a child and family therapist feels like putting a man on the moon.) Anyway, Tim is focusing on helping Ruby newbies get up to speed, so if you're interested in Ruby but haven't taken the plunge yet, have a look at Tim's articles (rss).
Thu, 01 Jun 2006Dan shared an important experience from Expo-C in which he debated Haskell creator Erik Meijer on the XP philosophy of Doing the Simplest Thing That Could Possibly Work. To me, the best part about Dan's story is the realization that our experiences as programmers (and as humans) so powerfully shape the way we approach our work. This explains why a language designer and a custom software consulant would have conflicting software design approaches, and yet both are "correct" in a specific context. We must be attentive our context, particularly when we change working environments. The programmer who thoughtlessly applies a single approach in every context is headed for trouble. Thoughtful programmers consider variables such as the Change Event Horizon when applying the rules they have developed previously:
"So now we had a working definition of 'too simple'. It can be defined as any decision that doesn't consider the scale of the change event horizon. As an agile developer, one of my objectives is to create as small a change event horizon as I can, through the medium of continuous integration, automated testing and regular user feedback."
Wed, 31 May 2006Shaun Inman wrote a concise, thoughtful piece on Responsible Ajax. It was one of those "Why couldn't I have said it like that?" blog posts that are perfectly timed with what I'm presently focused on. I think that's called synchronicity. A few nuggets of wisdom:
"XHR doesn't break the back button, misunderstanding user expectation does." "If refreshing a page immediately after that page has been updated by remote scripting results in an essentially identical page then you're doing okay. If not, head back to the drawing board."
Wed, 24 May 2006Jay Fields provided an informative post on delegation in Ruby (via Forwardable) that was insanely relevant to some questions I recently fielded from some of my teammates who are learning Ruby. Thanks for posting it Jay. It's been fun to watch Ruby creep into the collective consciousness of unexpecting Java developers over the past year. Although we're mostly a Java shop at my current client, our chief architect has just started as the new Ruby Guide at About.com and yet another guy named David is playing with JRuby.
Fri, 05 May 2006Tyler Jennings has written up a useful unit testing strategy (particularly for legacy code).
Motivation: An Object you need to test is constructing another complex object internally which you cannot access and this object is passed to a collaborator you can replace with a mock.
Mon, 06 Mar 2006David (I'm not going to refer to him by his initials since they were mine first) poked fun at how insanely repetitive Java code can be with type declarations, variable names, casting, and getters all repeating the same phrase. You know, like UploadedFile uploadedFile = (UploadedFile) fileUpload1.getUploadedFile(); My colleague Greg Luck shot back with the standard "Java IDEs rule and Ruby needs one". Greg showed how he could use IDEA to produce 77 characters of code in 21 keystrokes. That's great and I use those same keystrokes nearly every day that I write Java code (which is starting to become slightly less frequent). But imagine you're coming at Java and Ruby as a newbie (I think from that perspective a lot these days). It's great to know that I could write Java that quickly, but first I'm going to have to internalize all of those proprietary keystroke combinations. I think I'd rather just type file = file_upload.file in 23 keystrokes and move on. Even if you have internalized the powerful IDEA shortcuts, there is a (diminishing but everpresent) psychological cost in having to translate what you want to say through a tool that says it for you as opposed to just saying it yourself. As I said a while back, I agree that Java IDEs do rule and I also agree that Ruby would benefit from a high powered IDE like IDEA. But I also agree to some extent with Dave Thomas that Java needs an IDE because it is so verbose, while Ruby doesn't because one can do so much with so little. That said, automated refactoring support is something that I need in any language I work in because I never get things right the first time. For instance, I went through some severe pain this weekend when I renamed one of my core Rails models. I'm still waiting and hoping for a Ruby refactoring browser, and until then I'd still rather type p-u-t-s-<space>-"-f-o-o-" than p-s-v-m-<tab>-s-o-u-t-<tab>-f-o-o because I'd rather write in Ruby than tell IDEA how to generate Java.
Tue, 24 Jan 2006Chris McMahon has asked me to co-teach the STAREAST 2006 Scripting for Testers workshop (provided we get enough people for 2 instructors). If you are interested in improving your Ruby-for-testing skills, consider attending.
Thu, 15 Dec 2005The Ajaxians posted Romain Guy's cool Crystal CD case effect. Consider taking advantage of canvas and Ajax for real-time graphical data presentation. They're an awesome combination.
Fri, 04 Nov 2005Stefano wrote up a nice post about the significance of Firefox supporting the <canvas> tag in 1.5...
Can a little <canvas> tag kill Longhorn? of course not. But this little new HTML tag is a sign that the ecosystem is now moving and that somebody with a 5% market sees enough value in this movement that can boldly scream "screw you" jumping on the Darwin bandwagon. Thank you, little <canvas> tag, you'll be teaching a lot of lessons to a lot of people and you'll be making my rich-webapp-developer life easier.via Obie
Thu, 27 Oct 2005Amit blogs about attaining mastery:
"...what many people claim is master-level of competence, is really not quite the truth. If someone who is supposed to be a master programmer doesn't understand computer science internals, then he or she is really not all that masterful."For all of us non-CS-majors out there, I think this is good food for thought. We should not forget to dig deep where approrpriate.
Wed, 31 Aug 2005Ravi has blogged on Book Chain, a pattern that is an instance of our (in progress) Construct Your Curriculum apprenticeship pattern. Ravi's pattern parallels Joshua Kerievsky's Study Sequence pattern in his Knowledge Hydrant [PDF] pattern language. As someone who has learned a ton from books, I think these patterns are important for apprentices to be familiar with.
Thu, 07 Jul 2005Dave blogs about specifying behavior rather than testing units...
"When you realize that it's all about specifying behaviour and not writing tests, your point of view shifts. Suddenly the idea of having a Test class for each of your production classes is rediculously limiting. And the thought of testing each of your methods with its own test method (in a 1-1 relationship) will have you rolling on the floor laughing."
Thu, 16 Jun 2005Micah Martin, son of Uncle Bob (does that make Micah a cousin?) has posted two interesting blog entries. One of them answers a few questions I asked Micah, and one is a tale of two apprentices. Pam Rostal contacted me to let me know that she is part of a community working on pedagogical apprenticeship patterns and androgogical approaches to learning in agile software development teams (wiki). This stuff excites me because it appears to be synergetic with what I'm working on. While our apprenticeship patterns are written to apprentices, Pam's work looks like it's aimed at educators and masters. To see software craftsmanship being pushed from multiple levels is encouraging!
Thu, 09 Jun 2005some lessons she's learned during her time as a software developer. It's reassuring to see some of the common patterns of successful apprenticeships echoed in Liz's story. I particularly resonated with her lesson about reading lists and her love for books (hello Bookshelved).
Also, I just pushed out another pattern: Nurture Your Passion. I would love to get some feedback on it (use the comment form).
Fri, 29 Apr 2005Pat posted a gem from the Domain-Driven Design yahoo group. Ralph's advice ties directly into Find Your Master and Your First Language, two of the apprenticeship patterns I'm fiddling with.
My favorite nugget of wisdom from Ralph...
"By far the best way to learn a language is to work with an expert in it. You should pick a language based on people who you know. One expert is all it takes, but you need one."This alters my direction on the Your First Language pattern. I had been wanting to advocate starting with dynamic languages because they help tie into the Short Feedback Loops pattern. Ralph's advice helps me see that the attributes of a language are not the only way to shorten feedback loops.
The availability of the feedback of a nearby language expert should be a major factor when selecting Your First Language.