|Ned Batchelder : Blog | Code | Text | Site|
» Home : Blog
I've written up a quick introduction to branching with Subversion: Subversion branching quick start. I've found that there are two hurdles for developers with source control. The first is getting started at all, moving from a file server to a Subversion server. The second hurdle is branching. It's a really powerful tool to have at your disposal. If you've never been comfortable with it, read the article.
One of the things that I really enjoyed about our trip to the White House was seeing a little bit of what goes on behind the scenes. The Time magazine White House photographers have a photo blog of those kinds of photos, which I find fascinating: White House Photo of the Day.
In these days leading up to the mid-term elections, there's been a great deal of excitement about the possibility of control shifting from Republicans to Democrats. There's also a steady undercurrent of the disillusioned claiming that there's really no difference between the two parties.
In some ways, they are right: both parties are prone to scandal, both spend more than their constituents would like, both tend to grow government, both need to practice more what they preach, both are likely to be beholden to "special interests", both fight dirty when their backs are against the wall, and so on. In short, they both tend toward the typical negative behaviors we find among those in power everywhere. This is what people mean when they say there is no difference.
And it doesn't help that the cliche distinguishing characteristics are contradicted frequently. Bush is a Republican, but spends a lot of money. Kerry is a Democrat, but is wealthy and privileged. When Bush came into office, there were those who pointed out that he was anything but conservative: in some ways he was a true radical, and they were right. So the classic differentiators are often proven wrong.
But I've been pondering this point for a long time: is there an essential difference between Democrats and Republicans? What is at the core of the character of the two parties? There is an essential difference, and it is summed up by their attitude towards Community.
By Community, I mean the balance between the needs of the individual and the needs of the group. Democrats lean toward the community, Republicans toward the individual. This inclination emerges in many aspects of political life:
These characterizations are simplifications of complex issues. Some classic differentiators are not explained well by this distinction (abortion comes to mind) but the general theme holds: Republicans tend toward individuals, Democrats toward communities.
I'm not making a value judgement. It's no secret that I vote Democrat, but my point here is not to sway anyone. I'm just trying to unravel a political puzzle.
Here's a debate that arose recently, about the extent to which dynamic typing can be taken, and whether it is too far. We have a function that takes a list of ids, but it can also be used in a way that gets the ids from another well-known place. It was originally coded like this:
ids is an argument that can either be a list of ids, or the string 'global', meaning go off and get a list of ids from somewhere else. But this use of the same argument as either a string or a list felt funny, so we changed it to this:
But now we have two arguments, both of which have to be defaultable, making it possible to call the function with no arguments, which is not a valid form of the function. Am I being too squeamish about the dynamic nature of the first form? Although Python doesn't mind, it feels strange to me for a variable to sometimes be a string and sometimes be a list. Is this pythonic? Or just a confusing abuse of power?
Pygments is a new pure-Python package for syntax highlighting source code. It seems very well done, and quite full-featured. Not only does it lex and color a bunch of languages, but it handles embeddings too, like Django templates in HTML. I use SilverCity on this blog, but have never liked that it calls into Scintilla DLLs to do the hard work, and isn't up to the task of two languages shuffled together. Pygments seems like a good alternative.
Larry Sanger is one of the two guys who founded Wikipedia. He had a difference of opinion with the other founder, Jimmy Wales, over the role experts would have in Wikipedia's content. As a result, he has announced an online encyclopedia called Citizendium. It will start as a fork of Wikipedia, but with be based far more on experts' contributions.
Mike (no last name) at Modern Dragons has a long and thoughtful piece about the prospects of Citizendium, with many links to other thoughtful pieces.
This is a long and nuanced story, involving complex themes of scholarship, community, and inter-personal conflicts between the two founders. Complicating the prognosis for Citizendium is the fact that a precursor to Wikipedia was an online encyclopedia called Nupedia, which relied more on experts than amateurs, and was founded by, you guessed it, Larry Sanger and Jimmy Wales.
It'll be very interesting to see how this plays out. Citizendium seems to be willing to go slowly (they plan to have a charter written within the year); the internet doesn't generally reward hierarchical structures; and it will be hard to "compete" with Wikipedia. But if it means we have a higher-quality encyclopedia, I'm all for it.
The venerable Tate Modern has a new art installation: Carsten Höller's Slides. It is what it looks like: a handful of big slides that "patrons" slide down.
I wish it were in Boston. I think it's an art museum I could get my kids psyched about. BTW: Here's the cool thing (for me): I discovered this via this tabblo.
I don't usually succumb to sending around funny cat pictures, but something about this series of cats with captions really got to me. The first few were like, "heh, cute", but then they overwhelmed me, and I couldn't stop laughing...
I say "sort of" because abstemi is not exactly the root of abstemiously, but is close enough. The point of the algorithm is to map words from the same root onto the same value. In this way, it's like a hash algorithm. The fact that the value it comes up with is often the root, or usually very similar to the root, is a nice side effect, but if it mapped all of the "catch-" words onto 117243, it would still work as the basis for a full-text search engine.
And of course, English is a bastard when it comes to this sort of thing, as you can see from the "caught" case.
BTW: Martin Porter (the author of the algorithm) has a marvelously (root: marvel) dry witty home page which starts off with a startlingly accurate prediction (roots: startlingli accur predict).
Also BTW: abstemiously is a word with all six vowels, in alphabetical order.
The following is an actual conversation that occurred tonight between me and a stranger on the telephone.
I just recently got a new camera (point and shoot, SLRs still scare me), and it has an SD card in it. My laptop has an SD reader in the side, so I don't need to use a cable to upload my photos any more. Very cool.
But not as cool as a camera with wireless built into it. The Nikon S7c not only has WiFi built in, but it auto-sniffs access points, and makes connecting extremely easy. Antonio has a complete review and more thoughts here. One of the great things about equipping the camera with WiFi is that they didn't do the more obvious thing and make it Bluetooth. Bluetooth is designed for short hops, to replace cables. Nikon could have made a small change, getting rid of the need for a cable by adding in Bluetooth. But WiFi is much more powerful, since it means you can be out in public, snap pictures, find an open access point, and start sending pictures. Very nice.
At Tabblo, we think the camera is cool enough that we're launching the first in a series of theme contests, with a Nikon S7c as the prize.
Google announced Google Code Search the other day. It's the Google search engine, but pointed at chunks of source code rather than at web pages. Koders and Krugle have both been doing this for a while, but it's interesting to see how Google's take on it differs.
Right off the bat, it looks like Google gives more results, but they are not always as useful. My first test search was for, what else?, my name. Google's returned 192 results, but many were lexicons for natural language parsers, where 'ned' appears at the end of 'aforementioned'. Koders returned 3 results, and Krugle returned 17. One immediately noticeable difference is the Google is finding code wherever it may be, while the other two are only looking in known code repositories. For example, Google found the zip files on my site where I distribute code, while the other two did not.
Krugle has more features, for example, the ability to limit search to comments, or to function definitions. I haven't used it enough to know whether that will be helpful or not, but it is cool to see that they parse the code deeply enough to provide the feature. Krugle also has an Ajaxy interface, which seems like overkill for a search engine. If I get used to it, it may be really nice, but it breaks all my habits in dealing with search engines and their results. On a non-search-related note, they have hip help-wanted ads on their site:
Overall, Koders seemed like the poor relation, with the fewest results and the fewest features.
One more thing: Jason Kottke has a list of interesting stuff (like passwords!) that you can find out with Google code search.
Carl Sagan knew how to glean larger lessons from astronomy: A Pale Blue Dot. The earth as a mote of dust suspended in a sunbeam.
BTW: anarchaia is a tumblelog (the new word for what weblogs were originally) full of similarly good brainy stuff.
Although I've been working in Python for a long time, every once in a while I come across a chunk of code that makes me stop and think, and admire its elegance and Pythonic nature. Raymond Hettinger's recipe for merging multiple sorted iterators is one of those pieces of code. It's only 29 lines including the supporting stuff, but it opened my eyes in these ways:
There's nothing like a succinct thought-provoking snippet to start your day.
Luke Plant has written a plaintive post about the difficulty of learning nice programming languages, but not being able to use them at work: Why learning Haskell/Python makes you a worse programmer. I know just how he feels, because I was in that position up until a year ago. It's difficult knowing that there are better tools out there, but having to work with what feels like stone axes during the day.
In my case, I was using C++ and C# during the day, and Python at night. I found a few ways to cope with the distance between the two worlds.
Get inspired. Sure, you can't express yourself in C++ the way you can in Python. But you can try to bring some of the dynamic or agile ethos to your static waterfall world. Maybe you can think about using functions as first-class objects, or start an automated testing effort. It's difficult, but if they're good practices in the open-source world, they're good practices in your environment. Be the change you want to see in the world. It's not all about what language you use, it's also what you do with it.
Side projects. Anything I did on my own time, I did in Python. This allowed me to explore the new world, and to express myself in it. Examples of this work were Nat's World, and the software that runs this blog.
In some ways, side projects only make the tension worse. Your fun project scoots along nicely with the new tools, while work continues to be difficult. Part of this may be because of the tools, but keep in mind: there's a reason they call work "work". Side projects are always more fun than real work, and you may be mis-attributing the reason for the joy. Maybe it isn't Python that makes the fun project fun, maybe it's that you get to pick the project, and you don't have to deal with Deadwood Dirk in the next cubicle! Your side project has no deadlines, no business goals, and so on. Side projects are a good way to stretch your skills, focus on areas of interest, expand your influence, and build new connections. But they aren't "real" in the hard ways that work is.
Tools. When an opportunity arose at work to create a tool, I wrote the tool in Python. This is how Cog came about, for example. There's bound to be some friction at work when the tool is introduced, since others there may not be able to maintain it. They may even view it with downright suspicion because it's written in a "toy language". But if writing it in your dream language gets it built when sticking to C++ would keep it from being written, then you should write it in Python and present it as a fait accompli. If it does a useful job, it will be accepted, and you'll have infiltrated the fortress walls with your language of choice.
Network. Read the newsgroups, read (or write!) a blog. Join a Meetup group. You can hang out with people that think like you do, and you won't feel like an outcast anymore. And they'll probably sympathize with your crummy work stories.
Get a new job. This of course is easier said than done. But jobs using the new languages and environments are more and more prevalent, and may be more possible than you think. And if you do get a new job, you can finally test your theory that work would be easier if you didn't have to deal with C++ (or C#, or VBscript, etc).
Yearning for better tools and languages is nothing new. Even once you get your dream development environment, you'll wish it were better. Doing something about it is the challenge.
Encouraged by the success of Wikipedia, I've noticed specialty groups starting their own niche encyclopedia. The first I saw was the cleverly-named Wookieepedia, related to all things Star Wars. The latest is Camerapedia, about photographic topics.
Wookieepedia is needed because the Star Wars community exceeded Wikipedia's tolerance for articles about fictional minutiae, and it will flourish because of its community's bottomless desire for such minutiae. It has its own wiki culture: the notices on pages requiring maintenance are all voiced by Star Wars characters. For example, the accuracy of Fifth Battle of Coruscant is called into question by Luke Skywalker screaming, "No! That's not true! That's impossible!".
But I wonder about the longevity of Camerapedia. Wouldn't all of it do well within Wikipedia itself? Can they attract an audience away from the ever-expanding Wikipedia? Should they? Is it better to have a separate dedicated photography encylopedia?
Some clever Japanese graphic designers realized that just because barcodes are functional doesn't mean they can't be pretty as well. They play around with the edges of the barcode to make them into integrated elements of package design, rather than blots on the landscape: Design Barcode. The video isn't a good way to study what they've done, but the Japanese-only Design Barcode site isn't yielding any nuggets either.
Since the flood Tuesday night, Tabblo has been returning to normal.
Considering how much water was spraying around Tuesday night, we came out very well. The guys on hand did a good job getting rid of most of it, and we called ServiceMaster to come take care of the rest.
They put water droids all over (actually, just powerful fans and dehumidifiers), which hum and spin all the time, dribbling into buckets to get rid of moisture.
Everything was placed on small styrofoam blocks (including one slow-moving engineer!). We don't know if they're to keep the tables from getting wet, or to allow the carpet to dry.
Remarkably, our Wall of Fame was mostly intact. The posters were subjected directly to the full force of the water, but they look brand-new.
Many offices have had their walls ripped open to let them dry out, and the power is off as a result. So we move into the public areas with our laptops, and keep on cranking.
I've redesigned this site. I'd been using the same design for the past 4½ years. Let me know if there are any problems.
Once again I looked into using a no-tables approach, but I didn't see how I could accomplish everything I wanted to with pure CSS. If anyone wants to take a crack at it, I'd be very interested to see how it can be accomplished.
There are a few things I couldn't get right. One of them is that the gap between a blog title and its date is different in Firefox and IE. I played with all sorts of margins and paddings and line-heights, and could not get them to agree.