JL Gray and Gordon McGregor’s DVCon 2012 paper on Continuous Integration using Jenkins has been posted in the “Papers and Presentations” section of the Verilab website.
I was having lunch with JL awhile ago, and we were talking about some recent Verilab email threads.
Participation in email threads is fairly high at Verilab: If you ask a question, you’re pretty likely to get an answer. Or three.
But even though participation is the norm, there is no guarantee that you’ll get an answer. There’s no guarantee that the person with the most useful knowledge will chime in. Well, these aren’t novel concerns, and there are tools to address them: Bug trackers. I’m rather a fan of bug trackers, and I think they could be used far more widely than is typical. And foolishly, I promised JL I’d write a blog on the subject.
So I started to organize my thoughts: My central themes would be the interface and the data model. I would argue that the bug tracker data model is far superior, but the interface is often far too cumbersome.
A bug tracker keeps state (and state history) and responsibility metadata. A bug tracker manages a to-do list, and if it weren’t a useful data model, then to-do lists would have gone extinct; and that ain’t happening.
Any communication that desires a response is actually an addition to someone’s to-do list: “Please respond”. And the vast majority of communications do desire responses: “Please book me on a flight to Aruba”; “What’s the Emacs keystroke for …?”; “I’m going to see the new movie on Friday at 8, wanna come?”.
Why not use a bug tracker for all of them?
(more…)
At the end of August, I picked up a copy of “Beautiful Code” (O’Reilly, edited by Andy Oram and Greg Wilson) that was lying around the Verilab office. I’d just finished the last Harry Potter book, and I was in the mood for some lighter fare. I’m about 90% through it, although I skipped a couple of chapters entirely.
I had every intention of really studying and understanding the code excerpts, and I stuck to it for exactly one chapter. After that, I just couldn’t force myself. I’m sure that must say something about me, not sure I want to know what.
However, I enjoyed several chapters. My favorite by far is “A Spoonful of Sewage” by Brian Cantrill. It’s the story of hunting and fixing a lock order bug in the Solaris 8 kernel. I think a big reason for its appeal is it really is written as a story. And along the way, I learned about priority inheritance as a solution to a common resource starvation issue. To me, priority inheritance is definitely a beautiful idea. My second favorite chapter is “The Quest for an Accelerated Population Count” by Henry S. Warren Jr. The divide and conquer approach is another beautiful idea.
Other highlights: “Beautiful Debugging” by Andreas Zeller, “Multidimensional Iterators in NumPy” by Travis E. Oliphant (I almost skipped this one!).
A couple of chapters that I was really looking forward to after browsing the TOC were disappointing: “Subversion’s Delta Editor” by Karl Fogel and ”Distributed Programming with MapReduce” by Jeffrey Dean and Sanjay Ghemawat. I have a feeling I just may not be smart enough to appreciate the beauty here, but, well, I don’t.
The common element of my two favorite chapters is not that the code itself is beautiful per se, but rather the code embodies some non-obvious but elegant algorithm. The beauty is in the idea. So is the term “beautiful code” actually a vacuous, meaningless concept? No, I don’t think so. I think code itself can be beautiful: When a function, a purpose, a meaning, shines clearly, concisely, intuitively through an expression, that expression is beautiful in its own right; beauty in idiom vs beauty in idea. And if a language seems to offer such intuitive expressions regularly, you could conceivably consider that language beautiful.
But having said all that, I simply don’t believe that a crisp, sharp boundary between idea and idiom exists: Function is nothing more than interpretation of form. Language and thought are so deeply intertwined, and any concept can be considered at so many different levels of abstraction.
For example, the priority inheritance algorithm might seem to be far more idea than idiom, while a NumPy slice operator might seem more language bound; but the idea of a multidimensional iterator abstraction surely is not.
Of course, the complexity of “beauty” makes language and thought seem simple by comparison.
In a company like Verilab, full of consultants smarter than a brain pie, it’s not often the CEO gets to teach anyone anything technical. So forgive me for taking advantage of a rare opportunity.
This morning (well, morning to me in the US, afternoon to him in one of our European offices) one of the team asked an emacs question on our lively, internal, intercontinental, questions-answered-almost-before-they-are-asked forum. Specifically, he wanted to know how to change this:
a0_af0_high = a0_af0_high.get_write_data();
a0_af0_low = a0_af0_low.get_write_data();
a1_af0_high = a1_af0_high.get_write_data();
a1_af0_low = a1_af0_low.get_write_data();
a0_af1_high = a0_af1_high.get_write_data();
a0_af1_low = a0_af1_low.get_write_data();
into this:
a0_af0_high = a0_af0_high.get_write_data(); a0_af0_low = a0_af0_low.get_write_data(); a1_af0_high = a1_af0_high.get_write_data(); a1_af0_low = a1_af0_low.get_write_data(); a0_af1_high = a0_af1_high.get_write_data(); a0_af1_low = a0_af1_low.get_write_data();
Such a simple problem, so many interesting comments and answers.
Here’s a new English term I’ve just coined: reuseless code. It refers to code that was written in such a reusable way that it can’t be used in any way. Writing reusable code is a noble cause, but before you start it is better to clarify where, why and how you think your code will ever be reused, if at all. Skip this step and you can be sure that, despite your good intentions, someone else will have to rewrite the whole thing later on. You can also be sure that your code will be unnecessarily and overwhelmingly complex.
In a testbench different parts are likely to be reused in different ways. Standard interfaces are the number one candidates for reuse in the pure sense of the term; it is quite probable that they will be plugged in as is into an altogether different project later on. Data generators (i.e. an Ethernet packet generator), base class libraries and generic packages (register package) follow close. In fact, if you’re lucky enough, you will probably be reusing someone else’s code yourself.
(more…)
This note began as a review of the tech report “The Landscape of Parallel Computing Research: A View from Berkeley“, with David Patterson among the many authors. It turned into a trip down memory lane. By the end, I agreed with them that Something Big is in play.
As ever, I urge you to read the paper. It has received quite a bit of attention, so there is also much surrounding material - the group’s blog is one good jumping-off point.
