(Aside for non-techies: ‘typing’ is the model by which a programming language structures data. A strongly typed language forces you to use each value in your code as a single type (ie, is this a number or a word or a record representing a country, etc.), while a weakly typed one will try to guess the types based on context (so you can, for example, add the characters “23” to the number 8 and get 31. A statically typed system does all this checking before the code ever runs (and usually refuses to run if any of the checks fail) while a dynamically typed system waits until a line is run to check (and will run just fine with code that makes no sense as long as you don’t actually get to that line of code). Wikipedia probably explains it better. Anyway, typing is a pretty big factor in a language’s ease-of-use, since it affects how much work the compiler/interpreter can do for you in terms of validating code or figuring things out from context.)
I’m trying something new this week: working on a slew of new features for GeoServer in a branch of my own. It’s kind of nice to have my own sandbox, although when I finish with the new stuff I’ll be making a pretty substantial patch to the main GeoServer branch, meaning it will probably require a vote at the weekly GeoServer meeting. Still, I’ll be able to keep my stuff separated and versioned while waiting on the 1.7.0 release, and I think the new features will be pretty exciting at the end.
What am I working on? A few things are on my plate right now:
- Make human-attended configuration for regionating a performance tweak rather than a necessity for regionating to work at all
- Experiment with some alternative ways of expressing the tree (basically, fake the inclusion of all features by drawing the first few in vector form, and including a raster background with the rest)
- Allow users to set custom templates for the KML popups on a higher level than individual layers.
If you want to help me out, you can check out the work in progress and let me know if you see anything broken in Google Earth (aesthetic opinions welcome as well!) Just visit http://publicus.opengeo.org/dwins_kml/mapPreview.do and click on any of the KML links, then browse around. (You’ll need Google Earth, of course; you can grab the installer from http://earth.google.com/) There will probably be another update here with more info about checking the different alternatives once I get the different visualization modes working, so stay tuned.
Mel Chua writes about code review tools in a recent blog post, pondering whether a software code review tool could benefit OLPC (where she’s now employed, doing QA and, knowing her, a zillion other things). I was about to just make a comment there, but I realized I have a fair bit to say, so full-fledged blog post from me it is. The only potential benefit she directly mentions is that
there’s this constant loop of feedback and revision happening with code – imagine something going around and around in a positively improving cycle – and when it’s ripe and ready, someone with privs can pluck it from that cycle and make it a commit (as opposed to a linear “go forward… get stuck here… if it doesn’t work discard it out of the waterfall completely” system).
She also links to a video of a Google Tech Talk by Guido van Rossum (of Python fame) about Google’s code review process, along with a tool he wrote to make it easier. (The open-source version can be found here.) There, he enumerates several benefits of code review:
- You can catch bugs before they make it into revision control
- Senior developers can impart knowledge to n00bs
- Senior developers can verify that said n00bs can be trusted with commit privileges (this is a big one in the open-source world)
- Team members can familiarize themselves with each other’s strengths and weaknesses
- In general, you get the benefits of pair programming without the scheduling constraints.
A while back we installed a trial version of Atlassian’s Crucible code review tool at OpenGeo to use for GeoServer development. I personally ended up using it for only two reviews: a (vast) speed improvement on the code that builds regionated hierarchies in GeoServer, and to review a patch submitted by Wayne Fang of Refractions Research. Maybe this means that constant code review is not well suited to use by smallish groups (I interact with about 4 developers who actually work on GeoServer on a regular basis, and most of the time we work pretty independently on separate parts of the project. We are geographically dispersed, so often Important Stuff happens while I am asleep.) Anyway, I’d say that of the benefits Guido mentioned, only the first couple really came into play. Interestingly enough, the KML regionating work ended up being a more-or-less complete rewrite, including a new algorithm, so familiarity with the code wasn’t that important in the end. Much of the discussion around the patch from Wayne was related to style and design concerns (does that class name really signify what it’s actually doing?) rather than behavior, so may have actually been better served by the mailing list.
A couple of other random thoughts:
- Code review is a process. Including more process means more training needed by people coming onto a project, though this can be mitigated by restricting the complicated bits to senior members, or, ideally, an automated system. I don’t think it’s a foregone conclusion that adding code review to a project’s policy will make it a better project; it should be considered against the weight in developer ‘activation energy.’ For something like GeoServer, where development is fairly process-heavy anyway, this is pretty marginal (and I’d be interested in seeing where a more serious trial of code review could get us.) For something with less dependencies, less API to get acquainted with, a quicker test suite, etc, it might be overly burdensome.
- Guido also mentioned that code review will happen whether you set aside time for it or not since any bugs that make it into the codebase will have to be fixed. It may be a better strategy to just fix the bugs that are caught in QA, directing developer attention to the most egregious bugs first. Catching bugs by inspection is not exactly bulletproof. Of course, if you’re relying on code review as a means of maintaining some minimal level of API design quality, going back after the fact is a bit tougher. But then, you can review API design without going through a line-by-line audit of the code too.
- As I mentioned earlier, I work on a pretty small team. Patches to GeoServer from developers who don’t already have commit privileges are fairly rare. I might appreciate code review tools more if I had more occasion to assess whether or not a particular change was up to par for the project I’m working on.
Poking around WordPress.com today, I noticed this blog post on the WordPress.com blog about an updated theme. It’s funny how changing something like a page template can get so much pushback from users who have somehow managed to make their blogs entirely dependent on it (take a look at the comments to see what I’m talking about). Kinda reminds me of something I said a while back.
So, it’s been a little over a year since I started working at The Open Planning Project (and I just had a birthday too). Seems like a decent time for some retrospection.
Thirteen months ago, I wasn’t really sure what I was going to be doing at TOPP. After my interview I was told I’d be working on OpenCore, the software that powers openplans.org, but when I showed up, it turned out that I was actually working on a different project, in a different language, in a different stage of maturity, in a different development style. We don’t even use the same bug tracking software.
I’ve had some projects that have gone well, others that seemed underspecified or overscoped (not an exclusive or, mind you.) Things that seem worth mentioning include regionated KML (aka Vector Superoverlays), a framework for REST plugins to GeoServer, and one such plugin that marks the beginning of exposing GeoServer’s data in a RESTful hierarchy. Maybe less exciting are an authentication plugin that lets GeoServer work as part of an OpenCore site, a largely neglected REST API for manipulating GeoServer’s configuration programmatically (hopefully I’ll be able to give this some love soon), and the foundations of a slick new administration tool for GeoServer.
When I started, I knew a fair bit about the semantics of Java, 2d and 3d graphics, networking, HTTP, XML, and the basics of comp sci (algorithm analysis, computation theory, exciting stuff like that). Since then I’ve dealt with databases a bit, dealt with a couple of specific applications of HTTP + XML, sort of grazed python once or twice, hung out with experts in tons of fields, and even done a bit of user support on the GeoServer mailing list. It’s even gotten to the point that you can google things other than my name and have me show up early in the results, how cool is that?
I also kind of randomly started the TOPP Talks project, so that’s neat.
All in all, it’s been a pretty exciting year. It’ll be interesting to see what goes down between now and next September.