Trying to convert my database of readings into an import file for Goodreads. The formatting for the CSV file is giving me trouble. I look at their documentation and sample, to figure out what columns to output, but is seems a little incomplete. I end up having to write review material in one sample book and looking at the Goodreads export file to reverse-engineer what other columns there might be.
At first, I considered writing it in Groovy, but my wiki-like logic is all in Perl. My Perl is rusty. Very rusty.
Dropped off my Alienware PC at the recycling center. :-(
Writing some serious CSS to make dialog bubbles. Rounded-corner boxes and custom images for the bubble's tail, complete with to-the-pixel adjustments to tie them together seamlessly. I've been wanting for a long time to do this kind of fancy layout, but I could never get the time, somehow.
Decided to go PC-less. I picked up my broken Alienware PC from the repair shop. I didn't call ahead and the PC was still in pieces: heatsink, CPU, DIMMs. No matter. I got a KWI-S2 SATA-to-USB converter so I can connect my two hard drives to my Mac to get the files back. Best $17 ever.
Got a call from the repair shop. THe motherboard is fried. They don't have a replacement that will fit my CPU, so I need to build a new machine. $100 plus parts. I found a replacement motherboard on the internet for around $200, but the sellers are few and are unknown to me, with mixed ratings. I'm starting to consider getting rid of my PC altogether. We use the Macs almost exclusively nowadays anyway.
Still haven't heard back from the local at-home repair crew. I dropped off my Alienware PC at the repair shop. They want $70 to diagnose the problem.
Wrote my first non-toy bit of jQuery for work. It's a small voting exercise, making AJAX calls to the back-end and changing CSS classes and counters to reflect the latest votes.
Emailed a local PC repair outfit to see if they can make a house call.
My Alienware PC is making a weird two-tone siren sound and won't start anymore.
Getting a little more familiar with jQuery and some JavaScript. I have solid backend skills, and my HTML is pretty good. I can do some straightforward CSS but my JavaScript is still my weak point. I just hate having to write and maintain multiple versions of the same code for different platforms. In all my current languages (Java, Ruby, etc.), the code is the same on all platforms. With JavaScript's uneven support in various browsers, it's hard to do something non-trivial that will work cleanly across all browsers. This has been a real demotivator for me trying to learn this stuff so far.
Moved some of my local tinkering projects to github.
And only after I had uploaded them did I realize that the build.xml file in
each project contained my account password. Drats! I had to go and change it
super quickly.
Started new job at INSIDR. ShopWell is owned in part by Social Ventur.es. They brought be on board their new venture INSIDR because of my Grails knowledge and overall engineering skills.
Setup my profile at about.me. A friend showed it to me back in October and it's taken this long for me to get an invite to their invitation-only beta. Well, actually, I received the invite over two weeks ago but only acted on it now.
Last day at ShopWell.
So far, I've been managing the files for my website by hand, with only Emacs to edit the files. Aside from CSS, each file contains everything it needs. One upside is that I can open them locally with a browser. The downside is that there is a fair bit of code duplication between the files.
I started to partition things a bit more. I host my site on Dreamhost, which
runs Apache and supports server-side includes. I extracted some of the common
navigation into partials. I also extracted the Google Analytics tracking code
to its own .js file. I know this defeats the purpose of Google's Asynchronous
Snippet, which is to not delay the loading of the page by including other
scripts synchronously. But if it's the only one being loaded, the delays are
barely noticeable. I timed it using Chrome's developer tools and the time to
load a typical page went from just under 100ms to about 170ms. A large increase
but still fast enough.
Found some more free fonts, Fontin and Fontin Sans, that include bold and italics. Fontin Sans even has bold-italics. Both also include small caps variations, but for some reason I couldn't get that part to work. But I used the others successfully on my book blogs and on my home page.
A friend of mine is participating in 24 Hour Comics Day, trying to write a 24-page comic book in 24 hours. Comic writer Erik Larsen gave the participants the following piece of advice:
Don't try to make it beautiful--try to make it finished.
Don't do unnecessary drawing--don't do thumbnails--don't do character design--do minimal pencils and plow through it.
Your primary goal is to get done. Make it bare bones--do rough outlines--and plan to render and sweeten it AFTER you have 24-pages finished in some form. If you run out of time because you decided to make every page awesome--you've failed. It's okay to do shitty work. People expect them to be shitty--they always look pretty sloppy--the bigger shame is failing to finish. So plan on doing 24-rough, barebones pages. Anything more is gravy. I suggest that you work on it all as one piece--don't tackle it page by page or it'll deteriorate as you go--don't stop for anything--if a panel is giving you grief--move on and come back to it--keep your hands moving at all times.
Use tools that allow you to work fast. You may think using a proper dip pen and brush would be fine but you'll lose a lot of time dipping--you're better off using markers (I used a Pentel Rolling Writer and a Sharpie to fill in blacks--the originals are pretty ugly 15-years later but what the hell).
Now, this advice is for a very specific task: writing a 24-page comic in 24 hours. I suspect that it might be slightly different when working on a masterpiece. But the general idea of going for breadth before depth is still a good idea to keep you on track and make sure you produce some value before you try to maximize that value.
This is eerily similar to a piece of advice in software development regarding premature optimization:
Make it run. Make it right. Make it fast.
That is, get something running first, however ugly it might be. Once you have that first step, you can go back over it to clean it up and design it a little better. Only then should you consider optimizations to make it run faster, with performance metrics to justify the need to optimization and to tell you when you've done enough. I even found a fourth part on the web: Make it small.
Test-Driven Development applies the same principle: write a test that breaks, then writes the simplest code to make the test pass. That's making it run. After that, you have to immediately refactor the code mercilessly. Make the intent clear, remove duplication, all the various ways you can make it right. All the tests written so far make up a safety harness that allows you to refactor without breaking anything. If you want to optimize the code afterwards, you need metrics to drive it and the tests again guard you against breaking something.
The first part, making it run, is similar Larsen's advice. At that stage, do not focus on esthetic concerns. It is fast and furious. And while you can get a lot done this way, it is short-lived. Larsen's comics are pretty ugly 15 years later. Code that's quickly hacked together is hard to maintain and increasingly difficult to extend.
The second part, making it right, is there to ensure longevity of the work. This is where you clean it up so it will last a long time. This is where you make the code easy to maintain and extend. This is where attention to detail is really important, where craftsmanship really shows. It is also the part that is hardest to convey to the uninitiated. Especially in software, the code where Engineering spends all of its time is hidden from the Product Development stakeholders. If you only show them outputs from making it run, they might not understand why you cannot do everything at that speed. But that code rots pretty fast. Time and time again I've seen projects grind to a halt under the weight of their technical debt. Making it run is incurring the debt but making it right is managing it. You don't have to pay the entire balance everytime, but you cannot ignore it for too long either. If you want the product owners to stay happy for the long run, don't skimp on making it right.
I found a few places when I could try web fonts on the site, starting with this blog's dates.
I played a bit with downloadable fonts using the @font-face support in CSS.
I got some free fonts from
exljbris Font Foundry and tried them on
my reading list. The free fonts don't come with italics and bold versions. I
use italics for quotations and I sometimes use bold for emphasis. All that goes
away if I limit myself to these free fonts. (And no, I'm not going to start
paying for fonts for personal use on my personal website.) Fertigo Pro looks
nice, if it weren't for the lack of styling.
Kent Beck tweeted:
KentBeck
trying out the Anonymous Pro font for source code:
http://www.ms-studio.com/FontSales/anonymouspro.html
clear and readable
I've been interested in fonts lately. At work, we started using Museo for the website. It got me thinking that I could spruce up this blog (and my reading reviews) with some clever use of fonts.
I try not to customize my environment too much anymore, because then it gets strange when I have to work on a non-customized machine. Managing long lists of fonts has always been problematic. It's even worse on the web since you cannot assume what's gonna be available in the user's browser. That's why so far, I've been relying solely on the lowest possible common denominator when doing web work, which means the generic font families in CSS.
But now, there are all kinds of web fonts becoming available. Browsers can download them from the web as needed and use them to render text. This opens up a whole new world of possibilities. Now, the problem becomes choosing the best font among the thousands that are available. And making sure that the terms of usage let me use them for free.
For now, I'm experimenting with a simple "font-family: cursive" until I can
find time for more exploration. I also installed Anonymous Pro in my IDE to try
it out. So far, it looks a little clearer than the default monospaced. Other
fixed-width alternatives looked good too but the code highlighting was not as
effective. This new font looks well calibrated.
Interesting links regarding fonts on the web:
I went to lunch at Google today. A friend of mine is leaving Google and he invited me over to catch up. It was a little strange to set foot in the place after ten months. Thank goodness, it is still Nerd Mecca. I saw a few familiar faces around the cafeteria. One guy hadn't even realized I was gone.
I worked through the turorial for Hadoop. I had to turn on remote login on my MacBook Pro to get the pseudo-distributed mode running. It was really cool to see MapReduce running.
I got an Amazon Web Services account when I read about Amazon Elastic MapReduce. It is an on-demand Hadoop cluster for running MapReduce jobs. Cool! You pay only for what you use, by the hour. Unfortunately, there is no way for developers to run small jobs on it for free either to get more familiar with the technology or developing a new job. The minimum cost appears to be $0.10, but these can accumulate quickly. And while you can do test runs on your local machine, it doesn't take into account all the other provisioning that you might need to do to run on the Elastic MapReduce. Amazon's pricing information hints at separate EC2 and S3 charges, so there might be more to running a Hadoop job on Amazon.
Refresher look at the Hadoop project. I see a number of sub-projects that look a lot like the parts of Google's MapReduce stack.
| Hadoop | ||
|---|---|---|
| HBase | => | Bigtable |
| HDFS | => | GFS |
| Hive | => | ??? |
| Pig | => | Sawzall |
When I saw the brief description of Pig on the Hadoop home page, I immediately thought of Google's Sawzall language which you can describe as scripting for MapReduce. Sawzall is extremely powerfull. You can express fairly involved analysis logic in very few lines of code. I was hoping for something as powerful in Pig, but the sample code seems a lot more verbose (and obtuse) than Sawzall.
Also, Hive reminded me of Google's cluster for running Sawzall scripts on log data. But Hive looks to be applicable beyond just log processing.
I was pleased to see that Hadoop claims great support for the Amazon EC2 and S3 stack. That could come in handy if we ever start to use it at ShopWell.
Funny exchange on Twitter between two of my favorite software people:
KentBeck
.@cirillof sciosciamento is just such an awesome concept that it stuck.
it also says a lot about italian culture that there's a word for it.
10:27 AM May 26th
martinfowler
@KentBeck ok - you've got me interested. So what does it mean (in 140 chars ;-)
10:39 AM May 26th
KentBeck
.@martinfowler ian italian, but i understand sciosciamento to mean
the feeling of wind in your hair as you drive a convertible in the sun
10:51 AM May 26th
martinfowler
@KentBeck ah yes that needs a word. And it seems fitting that it would be Italian.
10:57 AM May 26th
KentBeck
@martinfowler although for us it's more a term of nostaligia :-)
11:03 AM May 26th
martinfowler
@KentBeck you're lucky. I lost my hair before ever being in a convertible.
11:05 AM May 26th
Later, @cirillof offered some more explanation. He is Francesco Cirillo, the originator of the Pomodoro technique.
cirillof
#sciosciamento is a mood. you're sitting still and let the wind caress you.
and the wind embraces you. it is better not to move...
1:43 AM May 27th
cirillof
...otherwise the wind would go elsewhere... #sciosciamento is a Neapolitan
philosophical practice. you have to practice a lot to be a master
1:47 AM May 27th
The whole thing reminds me of some of the banter between two of my favorite science-fiction authors: Arthur C. Clarke and Isaac Asimov.
Martin Fowler was in town for a "ThoughtWorks' Technologist Forum". It was a free event hosted by ThoughtWorks, I just had to attend.
I got there early, hoping to meet some familiar faces. I worked with ThoughtWorkers at Google and there's a Google office nearby, maybe someone would be there too. I met Jonny Leroy, a ThoughtWorker who was an agile coach with me at Google and I got to show him ShopWell and we got to catch up a bit. I immediately recognized him and remembered what we had worked on together, but I drew a blank with regard to his name. I remembered the guy but couldn't recall the name. I had to surrepticiously grep through my notes from back then, which I had on my laptop, to get at this missing piece.
Back to Martin Fowler. The talk had three parts: continuous integration and deployment, selected questions fielded by the audience, and domain specific languages, his latest thing.
The first part started about continuous integration and how it helps reduce painful integrations. "If it hurts, do it more often," as they say. This part was probably aimed at laggards who still don't get continuous integration. Fowler mentioned the book Continuous Integration, part of his Signature Series at Addison Wesley. It is a good book if you're not technical and want to learn about software practices, but any developer worth a dime needs only one figure out of that book. The talk got more interesting when he moved past this into "continuous delivery" territory. He talked about build pipelines and introduced terminology to help communication about the various stages (commit, acceptance, performance, deploy) and the degrees of automation required by each. There is a new book in the works, Continuous Delivery, due out later this year.
For the second part of the evening, Fowler answered some questions that had been submitted by attendees when they registered for the talk. I was happy that he had picked my question, whether it is better to hire people already familiar with your platform or to hire talented individuals who will learn it as they go. I stole it from one of the presentations at Startup Lessons Learned. His take on it is to hire candidates with solid design skills, they will thrive in any environment. It helps to have one platform expert on hard to answer questions. Jonny also told me about ThoughtWorks' system of T's: broad skill sets with one or two deep areas of knowledge. Just make sure the T's on your team don't all line up exactly, so you have appropriate coverage. Other questions dealt with how to write stories (strict templates are for process weennies), planning defect fixes (beware of broken windows), and active objects (use lazy loading at first and optimize only as needed).
The last part was about domain specific languages (DSLs). Fowler has been
blogging and tweeting about this for the past couple years, so it was expected.
He has a book coming out on the topic,
Domain Specific Languages.
He talked about the Unix tradition of creating a new language and writing a
parser for it, using yacc or YAML, what he calls external DSLs. He
compared to the Lisp tradition of writing languages as flavors of Lisp and
running them using the Lisp environment, a tradition that has been picked up by
the Ruby community. He calls these internal DSLs or embedded DSLs since
they live inside a host language.
The evening concluded with some mild Q&A.
After the talk, I got Martin to sign my copy of Planning Extreme Programming, which was already signed by co-author Kent Beck. Afterwards, he came to say hi to Jonny, at which point Jonny introduced me to Martin Fowler. I've been introduced now, I'm no longer just a nerd in line after a talk. :-)
Unrelated to this, but today I came upon a great talk by Steve Freeman (of jMock fame). It is about writing good tests that are easy to maintain, as opposed to record-replay types that are very brittle. It covers material in his new book: Growing Object-Oriented Software, Guided by Tests.
Today, at ShopWell, we released the code from our latest sprint. This release is very personal to me because of the new ingredient highlighting feature.
A few sprints ago, we built the grade explanation feature that shows some of the good and not-so-good things about each product. At the time, I came up with the idea to highlight the elements of the page that relate to these judgments. I pitched it to the product manager, discussed it with the graphic designer and front-end developer, but there was no room in the schedule at the time. Until now. We collaborated really well to make it happen. The graphic designer, @k4rl, made it look so much better than what I had pictured in my mind. The front-end developer @mepetestuart, used his JavaScript magic to make it super dynamic. I coded all the back-end work to figure out what needed to be highlighted and whether it was good or bad. It all came together beautifully and I hope you enjoy it too.
Go look up products on ShopWell and hover above some of the characteristics it lists for them.
Kent Beck tweeted:
KentBeck
my #sllconf talk was widely misinterpreted.
presentation: http://www.slideshare.net/KentBeck/to-agility-and-beyond
video: http://www.justin.tv/startuplessonslearned/b/262656520
After watching the video, I understand better what he meant. He is taking a wider view of software development, especially in the context of a startup. Tying in to the other talks at the conference, startups are where we search for working business models. We have to maximize learning, sometimes at the expense of perfect engineering. But we cannot sacrifice engineering so much that it jeopardizes future learning. We have to still do enough engineering, but not more. This is not a carte blanche for hacking, merely an reminder not to lose sight of the real goal.
See also Steve Freeman's review.
I watched Startup Lessons Learned through their live broadcast. Here are my takeaways from the sessions I watched.
Kent Beck: His beliefs in keeping the code clean at all times are eroding. In a startup context, you want to keep the code clean enough that it doesn't slow you down but you don't want to waste time making things perfect.
Ash Maurya: Continuous deployment is the new cool thing. They deploy code in small chunks as soon as it is passes the tests. They deploy all the code for a feature over time. Code deployment is automated, but feature deployment is still managed. I suppose they have a large switchboard somewhere that says which features are turned on for which class of users.
Farb Nivi: At Grockit, they use Pivotal Tracker to manage their stories. They try to keep them as narratives of what the user does and not as dry specifications for the engineers. They hire smart developers regardless of which language they know and expect to pick up Grockit's language and idiosyncrasies as part of ramping up. Interviews consist of pairing for a day. Farb was using Prezi for his presentation, which was very cool (except it was hard to read the text on the broadcast).
IMVU: They push code multiple times a day, which can be a difficult adjustment for new hires that come from large institutions that used to push code only once a year. Things that are "everybody's job" quickly become "nobody's job", so it's good to make sure each task has a champion. They do post mortems all the time and don't punish failure, assuming you learned something, at least.
Dave McClure: He led a panel discussion on the role of design. You should try to get an emotional response from the user. Have them either love it or hate it, stay away from the middle of mediocrity. If someone hates your product, that gives you a concrete actionable item. He pointed to Kathy Sierra and her blog Creating Passional Users, it shows good use of simple graphics to carry a point across. A panelist brought up that agile is well entrenched in the world of coding now, but waterfall is still strong in the world of design.
Randy Komisar: There was a nice interview with Randy Komisar, a VC with Kleiner Perkins, where he talked about his latest book, Getting to Plan B, about a company's ability to pivot, or realize what they are currently doing is not going to lead to success and they need to start going in a new direction. He mentioned working with Pinger, the VP Eng there is a very good friend of mine so there was a nice personal connection there. Successful companies pivot many, many times. You could say they never really stop pivoting.
Aardvark: They did a lot of "Wizard of Oz testing", where a live operator is pretending to be the software, before they wrote their first code. It allowed them to test lots of ideas quickly before making an investment in code. They were eventually acquired by Google.
Flowtown: A startup is a sinking ship from day 1. You will have to make hard decision and you will piss off users. Get used to it and grow a thicker skin. You shouldn't be afraid to anger your first few users if it lets you learn how to satisfy all the ones that come after them. Prototype fast and furiously. Pivot hard and take no prisoners.
Steve Blank: This session is well worth watching, if you can find the video. He presented a model where a startup is meant to search for a business model that works as opposed to a large enterprise that is meant to execute a business model efficiently. Startups are small and nimble and staffed by entrepreneurs. Creativity is key to look for new models and try them out. Large entreprises have a model and they scale it up with professional management. There is a transition step in the middle where the founders usually depart or are thrown out. That's when you've found a working business model and you have to become less creative and more managed. Entrepreneurs constantly start new startups, they don't become captains of large industry.
Thanks to Troy Angrignon who posted detailed notes on Startup Lessons Learned in a public Google document.
Martin Fowler and Alistair Cockburn have posted their views on SEMAT. They are more eloquent than me, so go read their posts. I agree with them that SEMAT is a lost cause.
I started a page where I hope to illustrate why I like programming in Groovy.
Today, we launched ShopWell. I posted some pictures of the launch party on Picasa Web Albums.
Here is the patent that was awarded to Google for MapReduce.
Here is an article that discusses some of the ramifications of Google's patent for others who were inspired by MapReduce, including the Hadoop project.
A friend made me realize that I didn't mention leaving Google in this blog. I retro-actively corrected the mistake. By the way, I loooove my new job at ShopWell.
I don't have much time for Dependency Finder, though.
A really nice article on the origins of mock objects and jmock. It is really nice to see how the concepts evolved naturally from doing TDD, using dependency injection, and keeping the code clean.
Interesting overview of the Go language by my good friend Dave Astels. I like how it can deduce the type of things by itself in many cases. I also like its use of interfaces. It is still a little too low-level for me, though.
First day at ShopWell. It's an early startup, still in stealth mode, so I cannot say too much about what we're doing, yet. It's got to do with health and nutrition. We work with Groovy and Grails.
Last day at Google. After four years, it is time for me to seek greener pastures elsewhere. An old colleague from Vignette is now looking for developers for a new startup. Looks interesting.
Read a little bit about Groovy and Grails. From what little I saw, Grails has a lot in common with Ruby on Rails.
Looked into Hadoop, a Java implementation of MapReduce. I was able to run a simple example on one machine, straight out of the box. MapReduce is very cool technology.
Going through the Groovy tutorial. It is a
nice scripting language, a cool extension of Java. You can name closure
parameters, just like Ruby, but the closure can get a single default parameter
named it if you don't specify any parameters, an interesting shortcut.
A friend mentioned the Groovy language. It is a scripting language built on top of Java. It compiles to bytecode and runs on the JVM.
Videos on Groovy:
There are a few books on Groovy out there. I don't know which ones are worth it just yet.
Bumped into John Brewer in the train on the way home. I knew him from BayXP and also from when he worked at Google. It turns out he's been doing iPhone development and improv in the year since he left Google.
I signed the Manifesto for Software Craftsmanship. It is in the same spirit as the Agile Manifesto, which I also signed. It is a statement of values for professional software developers.
We had a visit from Donald Knuth at work. The title of the talk was "Faith and Science" and meant to give his perspective on the interplay of religion and science. I missed the beginning, but I have to admit the open questions portion I attended was pretty horrible. Attendees would ask some fundamental questions of reconciling elements of faith and science; Knuth would dance around the question nervously for multiple minutes before finally admitting that he didn't know. Now, don't get me wrong. I have great respect for a man who knows his limitations and admits he doesn't know something. But not after leading us on for five minutes.
He quickly introduced his Project 3:16, where he is studying a vertical slice of the Bible. Here, he is taking chapter 3, verse 16 of each book of the Bible and researching what commentators and theologians have written about it. He picked 3:16 because of John 3:16. So far, he's only done that one slice. It would be very interesting to see what shows up for other slices.
Aside from that, he had nothing original to say. When you're someone of this caliber and you have nothing to say, don't make a one hour lecture out of it.
The talk might make its way onto YouTube eventually.
I play sudoku online with Count to Nine. It turns out that one of the site's owner, Wayne Crosby, is a coworker of mine. I was playing a quick game during a game when he dropped by and asked me if I liked that site. He then mentioned that it was his site. I was pleasantly surprised.
It turns out the Guice people were already working on
something along the lines of the pattern
I documented yesterday. With my solution, you can repeat it over and over,
with different qualifiers, into an arbitrarily long chain. The @New
annotation that Guice is considering is a one-shot deal.
I added my tests to the write up. I wrote the code tests first, so I figured the write up should reflect that.
Wrote a full description of my 2-stage Guice provider pattern.
Stumbled upon a way to split the initialization of an object across multiple providers when doing dependency injection in Java with Guice. I will document it more fully on a separate page.
I wrote some sample code and gave JUnit 4.5 a try. In the past, I have always
been limited to JUnit 3 for one reason or another. But now, I got to write
some tests using annotations and the new assertThat() with Hamcrest matchers.
It was nice, except that I couldn't really inherit from MockObjectTestCase
anymore and I have to explicitly declare the jMock context in my tests.
Added an Atom feed for this Journal. It forced me to correct many errors in past entries, from well-formedness to proper escaping of control characters.
Played with RSpec today and wrote my first unit tests in Ruby. I even played with Spec::Mocks to do some mocking while I was at it.
Started learning about JavaScript today.
Started looking into Mockito. It is quite different from jMock or EasyMock. In Mockito, the default is to allow everything and not complain about anything. In jMock or EasyMock, the default is to allow nothing and complain about every interaction.
This has an impact when working with legacy code. When you write a test with Mockito, you create mocks and pass them to the SUT. Your test is green and you add focused verification to keep it green. When you write a test with jMock or EasyMock against legacy code, you create mocks and pass them to the SUT. Your test is now red and you add all kinds of expectations to cover all interactions and eventually make the test go green. So with Mockito, you start with something that works and refine it. With jMock and EasyMock, you start with something that is broken and repair it.
So it is a little easier to write the tests after the fact using Mockito. But once those tests are written, Mockito will not detect new interactions that happen on the mocks, whether they are wanted or not.
I wrote a more complete comparison of jMock and EasyMock. Someone also suggested I should include Mockito.
I looked for some corresponding features between jMock and EasyMock.
| Feature | jMock | EasyMock |
|---|---|---|
| Default return value |
one (myMock).getFoo()
|
n/a |
| Ignoring a method |
ignoring (myMock).someMethod()
|
expect(myMock.someMethod()).asStub()
|
| Intercept mocked method |
Action and CustomAction
|
IAnswer<T>
|
| Access arguments to mocked method |
invocation.parameterValues
|
EasyMock.getCurrentArguments()
|
It looks like everything I can do with jMock, I can do with EasyMock too.
All, that is, except returning innocuous values automatically. I'll need to
look into the andStub...() methods further.
Got into an argument of jMock versus EasyMock. I like jMock better. I find its syntax more expressive and it lets me do more things with less typing. I really like how it can return "innocuous values" by default. 0 for numbers, "" for Strings, ignored mocks for any class, etc. If I don't care about a given return value, I can let jMock handle it and not worry about it. It's really nice. I often hear from people who don't like jMock that they looked at it a long time ago and didn't like what they were seeing. Early versions of jMock had severe limitations, but jMock 2 is much, much better.
I wrote a Ruby script to parse some grep output to help me ascertain which is most popular at work. I essentially did this:
$ find . -name "*.java" -print | xargs grep -R -l org.easymock | wc -l
X
$ find . -name "*.java" -print | xargs grep -R -l org.jmock | wc -l
Y
And got that X was much larger than Y. Bummer. Then, I started thinking.
If I have one project using EasyMock with 1000 files and one project using
jMock with only 50 files, my grep output would make it look like EasyMock is
used 20:1 compared to jMock, whereas in fact, it's more like 1:1; one project
on one side, one project on the other side. So I wrote a quick Ruby script to
capture the projects instead of just files. By project, I mean the third word
in package names like com.<company>.<project>. I wrote my script
as:
$!/usr/bin/env ruby -w
projects = Hash.new(0)
ARGF.each do |line|
if (line =~ /src\/com\/\w+\/(\w+)\//)
projects[$1] += 1
end
end
projects.sort.each {|pair| puts "#{pair[0]} -> #{pair[1]}"}
I paired with Dave Astels to tap into his immense knowledge of Ruby. His style
is more in tune with functional programming than mine, but we ended up with
something that was both liked. I learned a bit about puts, he learned about
ARGF.
This script lets me see what the "projects" are and how many files are in each.
$ find . -name "*.java" -print | xargs grep -R -l org.easymock | collect_projects.rb | wc -l
X'
$ find . -name "*.java" -print | xargs grep -R -l org.jmock | collect_projects.rb | wc -l
Y'
This time, the ratio of X' to Y' is 4:1. A little better. At work, we still use EasyMock predominantly, but I can still make a case for using jMock. :-)
Which is what I did in the afternoon, as I was pairing with someone. I got
them to start using jMock to test some specific piece of behavior. As we went
along, we came upon a nasty situation: the class under test creates a structure
and then passes it to a collaborator that knows how to populate it. The
behavior we wanted to exercise then depends on the structure having been
properly populated. But we are mocking the collaborator! I can write an
expectation that the populate() method got called, but how can I have the
mock modify the structure that was passed in as one of the parameters? This is
how I learned about jMock's CustomAction and how to stub side-effects in my
expectations. It looks ugly, but it allowed us to write a test quickly instead
of having to embarking on a lengthy refactoring right on the spot. It was
kinda nice. I learned something today!
I wrote my first PyUnit tests today. I'm not in love with the Python syntax for running the tests or for importing classes. Or maybe there's just something I'm not getting.
I colleague pointed me to these great motivational posters that blend Demotivators and testing and Star Wars very nicely.
For my new language for 2008, I decided to learn Ruby. I finished reading the
first two parts of the
Pick Axe.
Last year, I learned Python and I stopped using Perl in order to force myself
to focus on Python. One thing I really missed from Perl are the command-line
switches -p, -n, and -i; I could use them for quick one-off operations on
files. In Python, I have to write a script for the simplest task. I'm glad to
report that Ruby also has -p, -n, and -i switches that behave exactly as
in Perl.
It's alive!
My Alienware computer is alive again!
I put in the new drive, but the computer wouldn't start. I needed to use the floppy drive in a pinch, so I decided to re-install Windows again so at least I could copy a file from my USB thumbdrive to a floppy. So I put the old hard-drive in and ran the Windows recovery CD. Somehow, that fixed the boot sequence and next thing I know the computer is booting from the image on the hard-disk. All the drivers are setup correctly. Oh joy! Now, I bought a 250GB hard-drive for nothing. Ah well, maybe I can find a way to make it work as a secondary drive or something.
All I have left to do is reinstall everything: games, apps, patches, data...
The new hard-drive has arrived. I ordered a WD2500JD and they sent me a
WD2500JS. Everything seems the same except it uses SATA II instead of plain
old SATA. Searching the web indicates that they should be compatible.
Ordered a replacement drive. I'm going for exact duplication of the hardware,
so I need a WD2500JD. After 2.5 years, they are getting hard to find.
Copied all remaining data to the external drive. Ran Alienware Respawn to ghost the machine, but it failed. When I reboot, I get a blue screen to flash for one moment and then it tries to reboot again. I guess the crash actually damaged the drive and some sectors are now bad. The Respawn tried to restore these sectors to what they had been but failed. It looks like I will have to reinstall Windows again and figure out all the drivers. One good thing: just before running Respawn, I got the sound card to work again.
Bought an external 500GB drive with USB 2.0 and FireWire. That should last me a while.
Borrowed a FireWire cable so I can copy data out of my Alienware onto my MacBook Pro. I needed MacDrive so Windows could write to the MacOS-formatted drive. It works pretty well, but it was slow work copying everything. And I ran out of space on my MacBook Pro; I only got to copy 75GB and I still have another 50GB to go.
I have an Alienware Respawn CD to set it all back the way it was when they shipped it to me. This will erase the harddrive, though. I need to copy all my important files out of there first. But it should solve all my driver issues.
Got a technician to come and install my new motherboard. When we booted up the machine, it flashed a blue screen and tried to reboot again. The technician thinks the crash corrupted the OS files and I will have to reinstall Windows. When I did, all the driver configuration was wrong. I can't get to 1600x1200 with 32-bit graphics, I can't get sound, and I can't get on the network. I have a CD with drivers, but it has drivers for all Alienware hardware and I can't figure out which ones are the ones I need.
New motherboard arrived.
New motherboard shipped.
I won the auction for my new motherboard.
My Alienware machine is dead. It won't start. I can't even get a hardware splash screen to show. I talked with a technician who said my motherboard is probably dead.
I bid on a new motherboard on eBay. It comes with a slightly better processor and 4GB of RAM. That would be a nice upgrade.
I just realized that I've been working with Alex Martelli, author of some of the most popular books on Python, for the past six months and I didn't even realize it. He wrote or co-wrote:
What a small world.
I volunteered to read Agile Software Development, 2nd Edition. I have only one week to read it and do a report. I had to stop by a booktore on my way home to buy a copy. I had read the first edition and done a presentation back when I was at Vignette, I should be able to reuse a lot of that material.
I attended a BayXP meeting with guest speaker Alistair Cockburn. It was hosted at Google. He covered many of the ideas in his latest book: Agile Software Development, 2nd Edition. His latest interests have taken him in an interesting direction: maybe the expression software engineering isn't so bad after all, as long as you adjust your definition of engineering.
He proposes that engineering has always been a collaborative game of invention and communication. It is only in the second half of the 20th Century that some started to think of it in terms of hard, empirical science. If you look at how engineers work from day to day, it looks very much like what we do with software: discuss, model, compare idea, make prototypes, iterate, etc.
Cockburn is working on a framework to help define software engineering. His framework is based on three legs:
The crafts are skills that all practicioners must learn and refine continuously. His list of crafts for software engineering includes:
He eschews words like requirements, UI, and testing because they carry too much baggage and it keeps people from looking beyond their preconceptions.
The game aspects means it's a team effort and there are many factors that come into consideration for every decision.
Finally, we can learn from lean manufacturing by replacing units of production by decisions and they optimizing the flow of decisions throughout the process.
Cockburn also brought up the latest acronym: XXD or "Dos Equis"-Driven
development. Just like TDD is not about testin, XXD is not about beer. Really,
the tests are eXecutable eXamples, hence the name. Funny.
Cockburn closed with some quotes from a NATO conference that was held in 1968 and was where they coined the tern "software engineering". He found it interesting that they recommended heavyweight procedures, but in practice they were doing things in a very agile way.
It's easy to take quotes out of context and spin them however you like. I would have liked a little more context about the NATO conference, who the participants were, who held what position, etc. I guess I'll have to find and read the transcript.
Met Guido Van Rossum's wife and son at the park. They are nice people. I was out playing with my kids when this lady saw my Google jacket. She was wearing the same. She mentioned that her husband worked at Google, "doing things with Python." When I mentioned that I was just learning Python myself, she said: "My husband wrote Python." I said: "Guido?" She answered yes and we had a good laugh.
Python won't let me write "i++". So far, the only explanation I could find
was that Guido didn't like the ++/-- operators. Lame. For a moment, I
thought I'd be stuck writing super-long "i = i + 1" until a friend pointed
out "i += 1" worked too. I guess this will have to do.
There is an FTP module in Python, but it looks pretty useless. It is little more than writing explicit commands to a socket and parsing the response yourself. I was hoping for a list or dir operation that would return a directory structure, but I guess I will have to keep on searching.
Got Python for my PCs from python.org.
I found some good candidates for books on Python:
Obviously, they modelled "Learning Python" and "Programming Python" on the very popular titles for Perl. But wheras "Programming Python" is much more popular than "Learning Perl", it appears to be the reverse with Python and "Learning Python" gets more stars on Amazon than "Programming Python". Curious.
There is also a pretty cool online tutorial.
New Year resolution: learn Python. We use a lot of Python at work to write scripts and small applications. Learning it will make me more efficient. If I write my own scripts in Python, someone else is more likely to be able to maintain them than if they were written in Perl.
So I am quitting Perl cold-turkey. From now on, I will use only Python for
scripting (besides Bash scripts). Quitting Perl will force me to go through
the effort of finding what I need from Python rather than falling back on Perl
out of expediency. So far, I have not found an equivalent to perl -p/-n to
quickly process a file. :-(
I borrowed some books from a colleague until I can get my own (his are a little out of date):
Latest chapter in my quest for a job title: Software Designer. I was looking at a job description from Québec, where you cannot call yourself an engineer unless you are a member of their professional organization. Since I got my degree in Computer Science and not in Engineering, I could not call myself a software engineer, but a software designer would work just fine.
Played with Selenium.
Looked at TestNG. Noticed how they use annotations to earmark the tests and fixture methods.
Took another at Junit 4.1. Played with it a bit in order
to try using annotations. It was not so easy since they actually removed many
of the familiar trappings of JUnit 3. Gone is the Swing TestRunner. All
that is left is the text runner and now it is called
org.junit.runner.JUnitCore. Go figure.
I remember being fairly disappointed that JUnit had gone the route of annotations. It makes life harder for tool makers. :-)
I used to keep my blog in a static HTML file and write it all by hand, markup and all. That was tedious.
Today, I wrote a CGI script in Perl to break it up into individual text files, one per day, and use my pseudo-wiki processor from Dependency Finder to generate the page dynamicaly. This way, when I want to add an entry, I simply add a text file with a much easier notation than fullblown HTML.
I assisted at a presentation by Ken Schwaber on Scrum and got a free copy of his book: Agile Project Management with Scrum. He is a very good speaker. He sounded very honest and he shared his experience freely. Later in the day, he had a more intimate session with the agile user group. The organizer had asked for questions ahead of time but Ken completely highjacked the meeting and took it where he wanted to take it. It was very intereting. He basically forced us to question why we care about agile processes and what our goals are and what are we doing to make track against them.
Finally launched Reporting for Google Base. On the UI, it's just three columns of numbers, but there was quite a bit of backend work to do. I got my name in the official Google Base blog!
A friend sent me these hilarious posters about eXtreme Programming.
I assisted at a presentation by Mike Cohn and got a free copy of his book: Agile Estimating and Planning. He has another book out on user stories that is well liked on Amazon. I'm thinking of getting it, but I might read this one first.
I finished reading an updated version of Martin Fowler's The New Methodology, his article on agile processes. In it, he talks about how they distinguish themselves by focusing on the iterative nature of development and being people-centric.
I have been thinking about this lately. To me, agile processes are first and foremost about feedback. They try to make you close the feedback loop and keep it real short, so you can get a lot of good information in a timely manner and better steer the project especially in the face of changing requirements.
A friend of mine keeps mixing methodologies and individual practices. He talks of the Test-Driven Development methodology or the Pair Programming methodology. I don't know that it's really worth my time to try to set him straight, that these are just practices in a larger context, not ends in and of themselves. For what he needs, his concerns are of a higher nature: get the software done and answer customer needs. His interests do not lie in knowing the finer details of this methodology versus that methodology. And it's OK. He focuses on figuring out what needs to be done and he can let the developers worry about the details of which methodology and which practices to put in place to do it.
I learned today, quite by accident, that John Vlissides passed away a few days ago. He was one of the "Gang of Four", the writers of Design Patterns. I was fortunate enough to meet him, once, at PLoP '96. He was on my workgroup and he was a very positive influence. He was very nice and he liked my paper a lot. :-)
I was presenting the patterns from my MSc work. The one about Remote Operation caught his eye and I remember him saying he wished he had had it when they were writing the Proxy pattern. I was quite awed that one of software's great would appreciate my work. During the workshop sessions, he was just one of us, looking at papers and commenting constructively on them. I fell very fortunate for these few moments spent in his company back then.
John Vlissides died on November 24, 2005, after a long fight with cancer. There is a memorial on Ward Cunningham's original Wiki.
Google Base was leaked today. Screenshots showed up on various blogs less than one hour after the site was briefly open to public access. It is quite a change to work for a company where everything is under a very powerful microscope.
Had a discussion at work about how comments lie and you shouldn't rely on them too much. Of course, eXtreme Programming advocates actually recommend you don't even bother with comments. My coworkers don't agree. And they wish all this nonsense would just end.
In my opinion, comments rely on human nature to stay current, which is highly unreliable. Eventually, as the team grows and the complexity increases and the release pressure builds, the effort required to maintain the comments exceeds their ROI. It in in the fundamental nature of comments to lie, no matter how hard you fight it. In the end, entropy will win.
My colleagues' counter-argument is that you don't really come upon such bad, lying comments all that often. And it is already hard enough to get programmers to write comments, we don't need to discourage them further. One could say that yes, it is hard, and they should be spending their energy writing code instead.
This discussion is far from over.
Looked into WebWork, a web application framework based on MVC-2. I've always been unclear about the distinction between MVC-1 and MVC-2, but reading through it finally drove the point home. In MVC-1, the navigation between controllers and views is embedded in the JSPs (views) themselves. In MVC-2, the navigation is encapsulated in a central dispatcher and usually driven declaratively by a configuration file. WebWork also uses an Inversion of Control framework to inject dependencies into components that make up the MVC-2 structure.
I have been considering for some time to redo the Dependency Finder web app with some kind of MVC structure. Right now, all the logic is embedded into the JSPs themselves as large scriplets. While this is not maintainable on large scale project, in the case of Dependency Finder it kept things simple and kept the size of the WAR file down. At one point, I thought of using Struts, but the libraries it requires were too big and I didn't want to ship them with Dependency Finder. I'll have to see if it's the same for WebWork.
It feels nice to learn something new and on the cutting edge. It had been a while.
I realized I'm working with the author of JsUnit, Edward Hieatt. He leads a small group that does eXtreme Programming and it is quite refreshing to have somebody else push for XP practices, for a change. He and the rest of his group are pretty smart and it is a joy to work with them. We share many points of view when it comes to developing software.
He has a nice sideline going on at agilestuff.com.
I learned today that people are spreading nasty rumors about me at my old job. Apparently, someone accused me of having badmouthed the company during my last days there; which is simply not true. It is a great company with a great product and I wish them all the success in the world (I own stock in the company, after all). And then, someone else questioned my behavior after I'd given my notice. I continued working to the best of my ability and even volunteered for a task that took most of my last week and involved training a newbie at the same time. If this is reprehensible, I hope everyone is just as bad as me when they leave their job.
A friend told me to forget about it and not let it get to me. But I feel hurt and it cast a shadow on what's otherwise been a great week at my new job. I'll heed the advice and not pursue the matter any further. It's just disappointing when you work hard to preserve relationships and one bad apple can undo it all and there's not much you can do about it. I can only hope that the people there will see this for what it is.
Started work at Google.
Last day at LinkedIn.
Gave my two week notice at LinkedIn.
Again with Skowronski. This time, it's Warren Keuffel and my beloved Software Development Magazine that are at it. In the June 2005 issue, Keuffel picks up Skowronski's rant and concludes with an omnious prediction that by focusing on agility, we might be driving innovation out of our field. To me, it looks like Keuffel fell in the same trap of seeing everything as a zero-sum game. I still humbly disagree, as you can read below.
I was finally able to attend a BayXP meeting again. I missed quite a few in a row due to working late those particular evenings at the office or other distractions. I was able to make it to the ThoughtWorks offices in San Francisco at watch a presentation on Fitnesse. Exposed brick walls, exposed old wood rafters, the place had character despite the earthquake retrofitting.
The talk was pretty lively and was a nice introduction to working with Fitnesse and its place in the development process than a nuts and bolts view into writing fixtures. Details of the talk are here.
I met with two former colleagues from my days at Epicentric and Vignette who were at the meeting. We all work for separate startups now.
Maybe Test-Driven Development is really MDA in Java in the way that tests are really an executable specification and writing them first is really a way to do design rather than testing.
Got a new Alienware PC. Ultimate gaming machine. :-)
Follow up on Victor Skowronski from readers' letters in the December 2004 IEEE Computer magazine. Readers comment on how Skowrowski either doesn't really understand agile processes or doesn't give them a fair chance. Agile methods promote adaptability, adjusting themselves to their surroundings and finding what works best for each individual team. This point was completely lost on Skowronski.
Of course, Skowronski had to respond. When he is not dismissive of the critique, he simply repeats himself. He really sees the problem-solver / people skill relationship as a zero-sum game. If you try to better skills on one side, it can only be at the expense of the other. Poppycock! I thought we'd moved past this idea in our understanding of personalities a long time ago.
One of the readers and Skowronski worry that agile methods keep putting off working on hard problems in favor of delivering features. As a result, they can let prevent a project from discovering fatal flaws until a lot of resources have been spent already. They must had skipped some pages when reading on agile methods. My understanding has always been that you tackle risk early on agile peojects, precisely to ferret out risk and identify those possibly fatal flaws as quickly as possible. Such flaws may very well include the team not being able to come up with a solution to a particular problem. But the agile team makes sure that the customer gets the most out of the project before they possibly decide to cancel it. And the customer, in discussion with the agile team, controls priorities and decides which risks to tackle in which order. The customer holds the strings of the purse and gets to stear the project. He or she does not do so blindly, but informed from the regular and frequent feedback from the developers.
Somebody on the TDD Yahoo! group suggested that advocates of test-driven development use a logo to tell the world. Someone put a few on testdriven.com and I put one of them on my website.
A colleague showed me an article in the October 2004 IEEE Computer magazine by Victor Skowronski. The title says it all: Do Agile Methods Marginalize Problem Solvers? In it, he says that great problem solvers work alone, at their own pace, and make progress in quantum leaps that cannot be rationalized or predicted. Since agile methods focus on collaboration and teamwork and small iteration that track progress, they make it hard for the solitary problem solvers to contribute effectively. The author argues that problem solvers are the best programmers, so an organization that adopts agile methods effectively cuts itself from its best elements.
That's a whole lot of baloney!
He is saying that entire organizations should jump through hoops in order to accomodate prima donas. It's OK if everbody else is miserable and morale is very low. The exceptional and unpredictable talent of the prima dona will make up for it and pull the organization through. When you find a business manager that buys this, let me know.
The reality of modern day software development is that it is a team effort. The biggest challenge is managing the development itself and making sure that the business side will get what they need in time. There are still hard problems that require lots of intellectual work, but there are many more projects that are mundane and require a large amount of less hard work. On the typical corporate project, you need teamwork and predictability which is what agile methods give you.
The author also contends that hard problems can only be solved by solitary labor, where the problem solver must reflect on the problem and will eventually receive illumination. I am not ready to admit that this is the only way to go. There are many examples of really hard problems tackled successfully by large teams: the space programs, the Panama Canal, modern computers. For large teams to work, you need good communication within the team and the ability to tap everyone's potential. Making everyone miserable and resting all your hopes on one miracle worker is irresponsible.
Today, I attended a developer testing forum hosted by SDForum and Agitar. The highlight was a keynote by Kent Beck himself.
The event started with Sriram Sankar giving a talk about extreme programming at Google and how it fits well with their culture of empowering developers. But given their scale, they need a little more process with some degree of initial degree and peer reviews both of design and before checkin. There is also a large body of mandatory rules that go beyond coding style to include testing practices. They have the good sense of providing initiation and training for new employees. They introduced XP as a grassroot, viral-growth effort and it seems to be catching on slowly. They have been able to have stable builds and can ensure backward compatibility thanks to a large body of tests. They also use live monitoring of production logs to drive projectors. I once saw a similar setup at Schwab, it's pretty neat. "Great code comes from happy XP engineers;" suddely I feel like a cow.
Next was a disussion panel with Rob Mee (Pivotal Computer Systems), Russell Gold (Oracle and HttpUnit), Sri Muthu (Wells Fargo), and David Vydra (testdriven.com). The main message was that the business side has always assumed that the development side was doing appropriate testing, even though it was not always true. But lately, they have started to ask for the artifacts of our testing. Since they always assumed we were testing, they won't be giving us more time so we can start doing it now. There was even a suggestion that it is tantamount to professional negligence for today's programmers not to do TDD. They have seen a roughly 30% adoption rate among programmers; much stronger with junior developers that senior ones that are already set in their ways.
Which brings us to the final keynote given by Kent Beck. The talk centered around the word accountability. Not as who gets the blame, but rather as being able to render account, why and how you did what you did. TDD helps us do this by recording our assumptions at the time we did the development. A new edition of his book, eXtreme Programming Explained, is due out soon, with updated practices and more feedback from real life experience.
I got him to sign my copy of "Planning eXtreme Programming", which I had just finished reading the day before.
The forum closed with a demo of Agitar's flagship product: Agitator. It analyzes your Java code and automatically generates test batteries that try to get 100% branch coverage. It was very impressive, the way they use all the constants in your code to generate test data and can automatically detect assertions in your code, which you can instantly turn into method or class invariants.
Closed the day with a BayXP meeting with Jeff McKenna. We discussed the planning game. He mentioned how you can use the release plan to provide a bound context for the iterations, so it doesn't look like an endless sucession of work. He found that for him, it was not worth the effort to estimate individual tasks to refine the estimates. Whether or not he does it, he gets the same accuracy. You still need to break down stories into tasks, but don't waste too much time estimating them. A lot of the talk was reinforcement of the contents of "Planning eXtreme Programming" and "Waltzing with Bears", two books I just read very recently. Nice coincidence.
We started doing planning with index cards at work, so this will be helpful. I actually got a coworker to come to the meeting too.
Started working at LinkedIn.
Volunteered to get laid off from Vignette.
Accepted a job offer from LinkedIn.
A friend asked me how I saw myself in the realm of software development. As I retold my earlier musings about engineering and craftsmanship, he mentioned that French carmaker Renault came up with a new slogan: "Créateur d'Automobiles", which loosely translate to "Creator of Cars." He suggested that I might consider myself a "creator of tools" or a "software creator." It suggests a certain part of innovation and care for one's work. It does not sound as quaint as "craftsman" and laypeople would get he gist of it immediately.
I don't care much for the work ethics in software that make it cool for someone to sacrifice their personal life to the company. Why would you give up everything that makes you a balanced individual to benefit a faceless corporation that will throw you away like a used towel the moment you are no longer worth their while? I've seen it with large corporations and I've seen it with startups. What you put into your personal life will come back to you throughout your life. What you put into a company will most likely never come back to you, unless you happen to own the company, and I don't mean owning a few thousand shares.
If you don't look out for yourself, nobody else will.
It's OK to go beyond the call of duty on occasion, as long as you stand to benefit from it in some remote fashion. But don't lose sight of your own best interest, don't let it get to a point where you are just being used. The others are in it for themselves, not for you. Stay with them only for as long as your goals lie in the same direction as theirs.
Read a chapter on Taylorism by Prof. Rochlin. It is interesting that I am currently reading Pete McBreen's "Software Craftsmanship" where he advocates that we turn away from from modern, neo-Taylorist, deskilled software engineering and return to the traditional ways of craftsmen.
The premise looks tempting, that software engineering should be driven like a craft, where masters lovingly guide and mold their apprentices, passing on their hard-earned experience. But I'm not sure this return to the ways of the past is really the answer. There is something to be said for the industrial revolution and the achievements of our modern technological society: longer life expectancy, more leisure time, etc. The sentimental attachment to idealized master-apprentice relationships and artisans who take pride in their work was a small price to pay, considering what society as a whole gained in return.
I'm sure I would enjoy my job a whole lot more under a craftsmanship model then the proposed software engineering roles where every task has been deconsructed and optimized. I would gain a lot in enjoying my life. But I'm not sure that it is in the society's best interest to have the entire profession go back in time like that.
While Rochlin lists the profound transformations to the workplace triggered by neo-Taylorism and its negative impact on the workers, he says we don't know what the longterm effect on society will be. It possibly will be negative, but it could also turn out to be positive. Industrialization has made the Western Hemisphere the dominant force on the planet. Would you go back to 19th Century living conditions just so blue-collar workers can feel better? Remember that back then, living was hard, with little leisure for most; child mortality rates were high. People didn't live quite that old. Do we reaaly want to go back to that?
I don't have any answers for now, just a bunch of questions and things to ponder for a while. More later.
Someone reacted to my suggestion for Martin Fowler's article yesterday by mentioning Pete McBreen's Software Craftsmanship. He said how it got him away from calling himself a "software engineer" and changing to a "software craftsman" instead. I went through some of the same questioning myself a while ago and I also feel closer to a software craftsman than an engineer. But the reality of it is that the average person sees all software professionals as software engineers without distinguishing between the finer points. So I need to adjust my message according to my audience, what else is new.
Attended tonight's BayXP meeting with guest Eric Evans. During the talk, there were some comments about what software architecture really means and it brought back memories of Martin Fowler's article on the topic: Who Needs an Architect?
Eric's talk was very enlightening. He discussed his book Domain-Driven Development and how it applies to extreme programming. His approach focuses on taking a careful look at the problem domain and deriving the vocabulary of the project from it. This helps keep the customer on board.
I also met a former colleague who is now doing eXtreme Programming at his new place of work. He described his experience in his blog. Reading it brought back fond memories of my first experiments with pair programming, and how I felt exhausted at the end of the day; but it was a good exhaustion, coming from knowing we had accomplished a lot that day. I'm glad Brian is enjoying his experience just as I did mine.
Dragged my direct coworkers (3 + my direct report) to a rehearsal for a talk I have to give tommorrow to the full Engineering department. They were very reluctant at first to have me waste a whole 3 minutes of their time. They even enquired if attending tommorrow's was necessary after having been through the rehearsal. Now it's not like I only see these people once a week. I go to lunch with them almost everyday, we sit in a bullpen together. We complain about the same things together. By now you should get it that we're fairly close to each other. And yet they would not lend me a hand when I asked for a test audience for my talk. It depressed me a little.
Played with Visio and Pavel's UML 2.0 templates. I really like the ball and socket notation for showing that a class uses an interface of another class. It is aesthetically very pleasing.
Forword to Domain-Driven Design. I really like how Martin Fowler says that domain modelers should be able to talk to customers in the domain language and talk with developers in the implementation language, e.g., Java. Do you think he means by domain modeler what our current analysts should be doing? I, for one think so, which makes the current situation that much more depressing.
Presentation judo. Very funny.
I just love it when I read about a new pattern only to find out that it describes something I was already doing for some time. This happened today, as a discussion on a mailing list pointed me to the Unit of Work pattern. It is described in a lot of details in Martin Fowler's book Patterns of Enterprise Application Architecture and is at the heart of the Hibernate framework.
The basic idea is to have an object, the unit of work, keep track of all changes to a group of objects you've read from the database (or created or deleted). When you are done manipulating these objects, you commit the unit of work object, which saves all changes to the database simultaneously. It does not address distributed databases and two-phase commit issues, but these could be orthogonal concerns, handled within the unit of work object itself, I guess.
It turns out that I did something similar on my own few years back, where individual changes to existing objects were persisted immediately but creations and deletions were accumulated in a Transaction object and committed together. It may very well be that by reading a lot about patterns and database mapping, I unconsciously absorbed the patterns and then recalled it when a need arose. It's just cool that I now come across this documented piece of knowledge that validates my decision from back then.
Mary Poppendieck presentation on raising productivity in software development. This is related to her work on lean software development. I've put my notes on a separate webpage.
Last month, a coworker and I got into an argument regarding the use of interfaces versus abstract base classes. We came to the realization that my coworker wants to expose the minimum API possible, taking into account issues of backward compatibility, whereas I want to grant maximum freedom to our customers. These two goals are not always easy to reconcile. Today, I found a bliki entry on Martin Fowler's website that sums it up pretty well. He calls it the directing attitude (my cowoker) versus the enabling attitude (me).
I checked and they fixed my name on Software Development magazine's website.
I just noticed that the article in Software Development magazine misspelled my name as "Tessler" instead of the correct "Tessier" with an "i". Darn! I've sent email to the writer, maybe they can fix the online version at least. Here's hoping.
OK, I was a little rash. Most of them are actually OK. It turns out that the first ones to answer were the one who took the least time to read what I had to say. After them, the other replies were very useful.
XPers are a just bunch of hackers.
I sent a message to a couple of mailing lists regarding a design issue I've been having at work, and they completely missed the point. I described the situation in a few classes and two alternatives, inquiring which one looked best. Their first reaction: this reeks of big design upfront, too much complexity, this is all bogus. It never occurred to them that there might exist situations where that is the simplest design that might work. They immediately went into a frenzy about only custom code is good enough. I never occured to them that I might have ended up there by refactoring some simple solution already. There was no benefit of the doubt, I was labelled a BDUFer the moment I set foot in there.
It just makes me mad.
Software Development magazine published a piece on open source software in which they mention Dependency Finder. It is listed right alongside heavy hitters like LAMP (Linux, Apache, MySQL, PHP), Perl, and JUnit. My name is listed with the likes of Richard Stallman, Larry Wall, Linus Torvalds, Yukihiro Matsumoto, Kent Beck, ...
... eh! ... wait a minute! ...
... all these guys are übergeeks! ...
They've put me in with a bunch of geeks! Args!!!
:-)
Or more precisely: :-D
For some time, I've been saying that if you can't communicate your ideas to others successfully, it is just as if you hadn't had them in the first place. What I mean by this is that the onus is on you to get the stuff out of your head and it is your responsability to get the message across to your audience. Not everybody agrees with me, but that's what I say anyway.
Now, don't you just hate it when you come to some great conclusion after a long and thorough reflexion, only to find out that someone from the Antiquities beat you to it by thousands of years? Today I came upon this quote attributed to Thucydides, allegedly over 2,300 years ago:
A man who has the knowledge but lacks the power to express it is no better off than if he never had any ideas at all.
A little more research showed that Thucydides was a historian. The quote is part of a speech by Pericles to the Athenian assembly, shortly before he died in 429 B.C.
I found the quote in How to Get a Paper Accepted at OOPSLA. It is now at the top of my list of favorite quotes.
I read a paper by Allan Shalloway, of Design Patterns Explained fame, on the usefulness of design patterns. Again, he warns not focus too much on the particular solution, but rather on the forces at play in the pattern and how they are resolved. That's where the true value of design patterns is. Some of it boils down to the usual "program to an interface, not an implementation" and "favor composition over inheritance". As always, you want to encapsulate what changes to limit the impact of these changes to the rest of the code.
I saw that ThoughtWorks is hiring.
Someone posted on the pragprog list that they were applying there
and wanted a little more information regarding their hiring process. Now,
Martin Fowler works there and I like him very
much. At UML 2000, he had talked about the place and seemed very ecstatic about
it. He is big on XP, and Alistair Cockburn referred to some of Fowler's
experiences with XP at ThoughtWorks. So I took a look at their website and it
turns out they have a office right here in San Francisco. My commute wouldn't
even have to change, their office is right by the train station. Now it
remains for me to see if I'm ready to move on and if I'd like to work as a
consultant. I'm still far from decided on either count.
I attended a webcast by Robert C. Martin on the intersection of agility, objects, and UML. He was his usual perky self and a lot of his material was the usual stuff about OO principles and dependency management. He threw in some updated additions, mentioning Model-Driven Architecture (MDA) and aspects. I was at work with some coworkers. They expressed some skepticism about the feasability of fully automated acceptance tests and whether or not his approach to documentation (or lack thereof) is realisic. For my part, I was pleased with the talk. The tone was relaxed and the contents very informative.
I read an article by Martin Fowler on accessors. It reiterated some of the ground rules regarding an object's state and how you expose it to other objects.
His bliki also had a reference to a Bill Caputo piece on XP. It's a reaction to a criticism of XP from Gerold Keefer. The whole thing seemed overinflated, but Gerold Keefer did raise some valid questions to make you apply some critical thinking before you implement XP in your workplace. Fowler and Caputo are quick to remind people that agility's focus is on people and finding ways to let a team do its work.
JavaPro also had an article on "interface-driven development". It would have been good, if not for the fact that I've been hearing this message ever since I opened the GoF book on design patterns. Since then, it has been one of my most important design rules: code to interfaces. I guess it needs restating every once in a while, to make sure everyone is aware of it.
I read a nice article on Test-Driven Development in JDJ. It's a nice, concise description of TDD. I like TDD. I try to use it as much as I can now.
I attended a webinar by Barbara Warthen where she tried to compare software development with software engineering. She's a process consultant and she basically exhorted the virtues of heavy-weight processes. She used the usual comparison of building a doghouse as opposed to a skyscraper and how the degree of complexity in software has shot up since the '50s. One nice thing is that she did provide updated data from the Standish Group on project success rates. Things haven't changed much since the '70s.
She tried to compare current project management practices to buying a car, saying the current state of affair was more like getting only half the features: no brakes, no steering, etc. Actually, I think the analogy works pretty well indeed. The advertisement says "starting at $9,999.99" but they show you the $20,000 model with all options. If you want the car on display, you're gonna have to pay a lot more in the end, or if you stick the price, you won't get what you were expecting. I was kinda happy to see this one backfire on her. :-)
She described software engineering as applying common sense to solving problem. To her, that's the essence of engineering in general. The fact that software is not a physical entity was irrelevant. I don't fully agree. The fact that software is not physical changes the whole economics of producing software.
She talked a little bit about IEEE software engineering standards and SWEBOK. She also touched on the SEI's CMM level. All sources that advocate very heavy processes. She did touch on agile methodologies toward the end, quoting common sense things like don't do documentation for the sake of documentation or don't follow your process for the sake of jumping through hoops. But she didn't go to any great length about this.
In the end, she claimed a good process and big design up front paid for themselves by reducing programming time. Since all the decision are made during analysis and design, the coding phase is drastically simplified. The way I understand this is that the analysts and designers call all the shots and validates their decisions using vaporware. Coding is reduced to mindless drivel for code monkeys to do. I don't care much to work in that kind of environment. Life is short, I want to enjoy it and find fun and fulfillment in my work. I don't care for being someone else's code monkey.
So overall, the webinar was useful and informative. It provided a lot of good and useful information. But in the end, I choose to disagree with her about the usefulness of heavyweight processes.
I read two useful articles.
The first one was by Eric S. Raymond of open source fame. He talked about how the open-source movement and agile programming have a lot in common. One thing is for sure, Mr. Raymond does not suffer from too much humility. But he goes about showing how the open source practitioners have been following agile practices for years but didn't have words to describe what they were doing. So both sides benefit from each other. Open source validates agile practices in real world development and agile methodologies provide a formal framework to discuss hacking, as Raymond calls it. You can read article at: http://www.artima.com/weblogs/viewpost.jsp?thread=5342.
The second article was much more enlightening. It was about ethics and professionalism for software people. A lot of people think of professional behavior as dressing sharp and not offending anyone. But author, Philip Greenspun, argues that real professionalism should promote and advance the procession. Professional programmers should dedicate themselves to high quality work, innovation, and sharing what they learn with others. You can read the article at: http://tinyplanet.ca/projects/professionalism.html.
I attended this month's meeting of the BayXP. Ron Jeffries was talking about some of the things that are on his mind lately.
First, let's talk about the speaker. He reminded me very strongly of a former coworker who acted as a mentor to me when I entered the workforce. It was a little uncanny.
The talk was lively as he led us through some of his latest thoughts on the subject of planning. Through his teaching exercises, he has had some insights into the dynamics of planning. Students with no real knowledge of the tasks' value or difficulty can still generate pretty good schedules. Even random schedules can still work out pretty good. So how can we apply this knowledge to real projects? No definitive answers yet, but some interesting questions. More to come later, I guess.
I have come to realize that the essential skill for anyone who wants to do any kind of convincing or mentoring is empathy. You just have to be able to put yourself in the other person's place and understand things from their point of view. Not just how you would understand things if, like them, you didn't know what you now know, but how they might try to understand things, how they think, how they might go about trying to solve a problem. The issue is not how you would do in their place, but rather how they go about it.
This came about after I discussed some complex piece of software with a coworker. We are both good at what we do, but I still had a hard time grasping some of the concepts he was trying to convey. Not because of their utmost complexity; some of them were pretty simple. It had more to do with how he chose to present them to me, in a manner that made a lot of sense to him but was quite unfamiliar to me. I eventually got what he meant, but I had to do quite a bit of work to get it. If I hadn't been in need of that information, I would not have bothered trying to understand what he was saying.
Now he could come back to me and say that I should have told him I didn't understand what he was talking about. But I really believe that it is the responsibility of the communicator to get the message across. You cannot count on your audience to go the extra mile. If it is important to you that your message gets across, then it behooves you to take the steps necessary for this to happen and communicate with your audience in a way that they understand.
More about this script I was talking about the other day. It scans code to collect lookup keys and generate a resource file with them. I have been using this script to verify that my resource file has all the keys needed by the application, but my coworker justs wants to use it when he's done with his application to generate the resource file automatically.
So today I took the script public within our development organization. Someone complained that we should not use the script and that everyone should maintain their resource file manually; to try an automated script is lazy and error-prone. Error-prone??? Synchronizing keys across multiple files and doing it manually is error-prone. Anything to automate that is a step up! And lazy? Why, lazines is the first virtue of a good programmer, according to Perl creator Larry Wall. Of course, he's talking about the kind of laziness that makes you do a lot of work now so you don't have to do quite as much later.
I was tempted to start a flame war over this, but in the end my better judgement prevailed. In the process, I reacquainted myself with Godwin's Law. I suggest you do the same.
When I write software, I care about doing a good job and writing well structured code that will be easy to maintain. Maybe I am not a computer scientist but more of a software craftsman. What kind of title would that make? I think it conveys a feeling of coming up with individual solutions adapted to the problem at hand, not applying rote techniques from a code book. It rings of taking pride in one's work, of being highly skilled at solving solving problems. That sounds good to me.
I had a chat with a coworker about agile processes, which turned into a discussion of XP versus CMM. While many consider them two extremes of one spectrum, I don't think it is the case. I think CMM has more to do with how you look at your process, whatever that process is. It could even be XP. CMM is more about how you monitor your process and look for ways to improve it. I do realize that most people take that as a license to have more paper and more bureaucracy, but it doesn't have to be that way.
With that same coworker, we worked on a quick Perl script to automate this one tedious task. He asked me to look at his first draft, clean it up and add two somewhat simple features. Later, when I showed him my result, we got into a discussion of the features and how they work. It took me a while to realize that I had assumed one way of using it and he had assumed another. It would be easy to make the script support both usage patterns, but we had to spend some time convincing each other that both were valid use cases. We managed to work it out, but it was unexpectedly hard. We are coworkers who work together all the time, we know each other, we work on the same problems, and still it took us a while to understand that the other could also be right. On one hand, I can't help thinking that if it is this hard when we know each other, what must it be between strangers? And what if they don't even share the same culture? On the other hand, maybe it was harder because we had high expectations of each other, since we are so close to one another.
I attended this month's meeting of the BayXP. John Levy was presenting the Sustainable Computing Consortium.
First, let's talk about the speaker. The invitation to the meeting made Levy sound like an old timer who had seen it all. He had been on large projects throughout his lengthy career and would have great insights into project management. I was expecting a wizened old man of the old school, with hard-earned knowledge about the nature of the beast. It would be great to hear why someone whom you would think more on the heavyweight side of process is coming down instead on the side of eXtreme Programming. Well, the guy is barely fifty. His resume looks fine, he's been around and on many projects, but so have Scott Ambler and Martin Fowler and the other advocates for agile processes.
And now for the Sustainable Computing Consortium. This was recently started by CMU, creators of SEI and the CMM levels. Not quite a crowd pleaser at XP meetings. Then, there is the list of founding members: Microsoft, Oracle, and a few others from pharmaceutical and financial outfits. Not exactly the first names to pop when you think agile development. More like the purveyors of bloated software and lovers of big process. Someone said this might turn out like CORBA, or another CMM-like excuse for throwing more process at problems. Finally, the membership cost of $25,000 kinda threw people off.
So while the goals might seem laudable, time will tell if the execution lives up to expectations.
At the office, most developers use IntelliJ to write Java and JSP code. I use Emacs.
I have to admit that IntelliJ that I almost switched, some time back, when I saw the support for refactoring and the "Find Usages" function, which mirrors Dependency Finder. Fortunately, a friend mentioned Xrefactory, an emacs add-on that does refactorings and some "find usages"-like functionality (and more). All for the small price of $29.00. So I have not jumped on the IntelliJ bandwagon, yet.
The main reason I want to stay with Emacs is so I can have the same development environment at home and at work. I can't afford the $500.00 to buy IntelliJ for myself. With Emacs and Xrefactory, I have the same environment at work and at home for Dependency Finder. That is, until you factor in that at work, I have a Win2k machine that is relatively robust, while at home I have a Win98 box that is very flaky. I cannot install Linux on it because I need Win98 for games, both for the kids and for myself. :-)
But these past few days, I have had to work on some JSPs that use custom tags developed by the company. Everyone is laughing at me as I struggle with them in Emacs, while they are having a good time with very extensive support by IntelliJ. Tag name auto-completion, automatic attribute detection, the works. Someone actually challenged me to find equivalent support for JSPs in Emacs.
I found references to
MMM mode at SourceForge. This
allows multiple major modes to coexist in the same buffer, so HTML chunks can
use html-mode and scriptlets can use java-mode or
jde-mode. From messages out there, it seems to require some
degree of adjustment to work correctly. And the last release dates back to
February 2001. Hasn't anyone done anything since?
Other references use multi-mode.el, a GNU package that is almost 10 years old!
Is there no hope for me to find a decent Emacs add-on for JSPs? Will I have to give up my beloved Emacs and succumb to IntelliJ?
On another note, I rediscovered Half-Life. I have been playing most evenings instead of thinking about Dependency Finder. I even reinstalled Opposing Force and managed to make some progress in it too.
Shared some thoughts with a colleage on what it means to be a software engineer versus the other designations. We did not come to any conclusion, except that in real life, the distinction does not matter all that much.
I'm catching blog fever. I need to start expressing my views too.
Started a reading journal to keep track of the books I read and what I think of them. I need to do the same for articles somehow.
I have been struggling lately with how to define myself. My web page starts with "I am a software engineer," but is that really what I want to project? What do people read in this? Here are some alternatives and what I think of each:
Robert Grady, in Practical Software Metrics for Project Management and Process Improvement, says engineers are after solutions, whereas scientists are after knowledge. I tried to looked into it a little further and now there is a debate going on regarding the nature of programming. Is is an art? A craft? A science? Engineering? Here's my take on the subject:
| endeavour | ... what they're after | |
|---|---|---|
| art | --> |
beauty, esthetics |
| craft | --> |
well built |
| engineering | --> |
pratical solution |
| science | --> |
knowledge |
Based on that, I think I'm a computer scientist, but not I am not formal enough to belong in academia. And I need to share my what I know a little more.
I visited Martin Fowler's website and read his latest articles on architecture and architects. He has some good insights into what one should look for in an software architect. I would like to think it fitted me.
Also found John Levy's website and read some of his thoughts on process. He's obviously given the topic a lot of thought. It is nice to see someone with his vast experience who believes in eXtreme Programming. I always have the impression that high level managers from large firms are more of waterfall type.
I went to Alan Shalloway's talk on "Transitioning to Agile". It was in a small room in a community center in Palo Alto. The walls had kids' artwork. It was very simple settings, which I didn't mind at all. It brought a very human dimension to the event. Alan apologized profusely about the facilities. Granted they did not scream "professional", but I liked them nonetheless. The talk was instructive, even though I already knew most of the material from reading Alistair Cockburn's Agile Software Development. It dwelt more on what agile is than really transitioning, but that was OK given it was a free seminar.
I started to read Alan's book, Design Patterns Explained, on the train before going to the seminar. He described the epiphany he had while learning about design patterns, that you should try to encapsulate the part that changes. This is what I learned when I read Wolfgang Pree's book on meta-patterns. Alan mentioned at the seminar that he thought Design Patterns by the Gang of Four had been hard to read. Pree's book is much harder still; it reads more like the guy's Ph.D. thesis. But the core material about hooks and hot spots in frameworks is so important that I think everyone should read it to really understand the essence of building flexible software. But it is not easily accessible to everyone, I must concede.