On my dresser was one of those little plastic hangers that socks are sold on. I was about to throw it away when I noticed it had an 800 number molded onto it. I was curious to see what would be at the other end of that number, so I asked Google about it.

It lead me to Conover Plastics, whose home page claims,

Conover Plastics, Inc. is the leading manufacturer and supplier of sock hangers. With over 30 years of experience making sock hangers, Conover has a great assortment of sock hangers. We have many standard sock hangers in stock - ready to ship the same day we receive your order.

Every once in a while, I get a glimpse into a corner of business I don't usually see, and am amused and impressed by the complexity of human activity. Here's a product I've seen over and over, and never thought about where it came from. And it turns out that there's an entire company that makes nothing but those non-descript sock hangers. Not just that, I'm sure Conover has competitors, there may be an entire sub-industry of sock hanger makers, or at the very least, specialty injection molded plastics.

The enormity of industry is an amazing thing. The fractal-like splitting of products and services down into component parts; the supplying and demanding of those parts from firms created purely to provide them; the trade associations, brokers, warehouses, and middle-men; the conventions, skill sets, sub-cultures and specializations are fascinating to me.

I partake in these sorts of specializations in the software arena, and to think that there's that sort of unseen complexity in sock hangers is astounding.

Somewhere at work we have a 200-page catalog just for shipping materials and another 200-page catalog of supplies just for manufacturing departments. Somehow we even a thick catalog just for audio-visual systems for churches.

This splitting into finer and finer sub-categories of specialization shouldn't surprise me any more, but it still does, and I'm proud and impressed to see the human beehive of activity at work.

I've updated my code generation tool, Cog. It's now supported on Jython 2.5, and I've removed the handyxml module it used to ship with, since most Cog users have no need of it. There's no functional changes.

Cog does one thing well: find snippets of Python code in text files, and run them, capturing the output and splicing it into the file. It can be used for all sorts of code generation and preprocessing tasks.

The irony of Cog is that I wrote it back when I worked in C++ and needed to generate code. Now that I work in Python, I don't need it, or so I thought. But this winter when I was writing my Whirlwind Excursion through Python C Extensions, I wanted a way to create the slides and the web page from a single source, and also not have to copy and paste sample code between runnable files and the text source. Cog would have been a great way to do this. For example, Paver uses Cog for just this sort of job.

But it didn't even occur to me to reach for Cog, and I ended up hacking something together. So I have to try to remember Cog in the future.

I updated Cog because I got two requests in one week to update it to keep it working on newer Python implementations. I'm going to start porting projects to Python 3.0, and Cog may be the first, since it is relatively small and simple.

A friend was getting started with Mercurial, and asked me for a few equivalents to commands he used in Subversion. I tried pointing him to a tutorial online that would provide the Subversion/Mercurial rosetta stone, and was surprised to find that there wasn't one I could recommend. So I wrote it: Bare-bones basic Mercurial for Subversion users.

Me, that is.

One thing social networks do very well is keep people connected together who may not have been connected at all before. It used to be that only those closest to you would know when your birthday was. Now entering it into your Facebook profile means that all sorts of people that you're just a little connected to know it.

Some people criticize social networks for replacing significant connection with trivial ones, that they're the fast food of relationships, edging out meaningful interactions with empty friendship calories. I find them instead to be a supporting structure: the information and connection they offer is a scaffolding on which to build, and can keep you connected with people that you otherwise wouldn't be able to stay in touch with.

I woke this morning to find I already had a dozen good wishes from people around the world, including at least one I had never communicated with before. What could be bad about that?

Bathsheba Grossman and Vladimir Bulatov make wonderful art objects. They're math-inspired, but you don't need a PhD to appreciate their beautiful organic forms. They're made with a 3D metal-printing technique that produces intricate sculptures impossible with other techniques:

I've blogged about Bathsheba before, but I just spent at least an hour poring over these artworks, and following connections from Bulatov's photos on flickr, so I thought I would share again. Also, Bathsheba has some models in plastic which reduces the cost.

Coverage.py v3.0 is done. There are new docs up, and final kits. The main change since beta 3 was how the standard library is excluded. I was being too aggressive, and sometimes excluding all the product code as well, depending on the layout of the project. Now it behaves much better.

If you haven't been keeping up with the changes since coverage.py 2.x, there are plenty of them, including greatly improved speed and a nice HTML reporting feature.

¶   Custom DIY Link Shortening for Your Networks: a nice style for uniform and short URLs to your identities online

¶   Cryptographic Right Answers: with the latest best practices for crypto problems

¶   TDD Anti-Patterns: a funny skewering of what people do wrong in unit tests

Susan and I are going to Paris for a week in July, and taking Max (17) and Ben (11). We're looking for ideas of things to do there, especially unusual ideas that we won't find in the guide books. Ruins and climbing are the kinds of things the boys talk about when we ask them what they want to do. Already on our list are the catacombs and sewers. We might skip the Louvre entirely. Mont Saint-Michel is fascinating, but seems like a 3.5-hour trip there, so it's doable in a day, but it would be a really long day.

Any recommendations?

Here's a great Venn diagram about how to be happy in business:

I like that the diagram isn't symmetric: the "learn to monetize" segment directs you to move those activities to the center, as does the "learn to do this better" segment. But when you are doing something well, and getting paid, but it's not something you want to do, the instructions aren't to learn to like it: they're to say no.

I really like this math geek clock:

I find the labels intriguing. Two I didn't understand, and had to look them up: 1 is Legendre's constant and 4 uses a negative modular exponent. The only one I don't like is 3, because it isn't a number, it's a numeral. It isn't a value that evaluates to 3, it's a character entity that displays "3".

I attended an interesting panel discussion the other night about cloud computing. Six startup CTO's were there to talk about their experiences with Amazon's services:

• Prakash Khot from Dimdim
• Aaron White from Doink
• Mark Pascarella from Gotuit
• Joe Berkovitz from Noteflight
• Philip Jacob from Stylefeeder
• Brian Whitman from The Echo Nest

I really liked this panel because they were all technical and heavily involved in real day-to-day dealings with cloud computing. It's easy to find breathless hype about how EC2 is going to revolutionize startups. This was a much more balanced view of what it's really like.

I took some sketchy notes. Perhaps because the speakers knew everyone had heard the positives, or perhaps because I already knew the positives, these notes skew toward the negatives.

• All used Amazon services, and most if not all of them seemed to use RightScale to manage them.
• Cloud is great for quickly deploying new servers.
  • Load testing: set up two machines, let them pound each other.
  • Handling unexpected demand.
• It's scalable, but not like normal computing:
  • Higher latency.
  • Higher error rates.
  • You have to pay much more attention to your error handling code.
• Cloud limitations:
  • Can't send lots of emails, since you need a spam-whitelisted server.
  • Disk I/O in the cloud is a lot slower than in real machines ("punishingly slow").
  • Want a db server with 32Gb RAM? Amazon doesn't offer it.
  • Want dual hardware load balancers? Amazon doesn't have it.
  • PCI (credit card) compliance is a problem: use a 3rd-party cart or PayPal instead of doing it yourself in the cloud.
• Amazon is clearly the leader.
  • Microsoft has a service (Azure) in beta, but it's very Microsoft-specific.
  • Intuit is creating a service.
  • No one mentioned Google App Engine.
• The lock-in is latency:
  • Transfering data within the Amazon services is free.
  • Transfering data to an Amazon competitor: not free.
• Cost: cloud is more expensive than real machines.
  • Cloud is good for elastic computing, not for high constant demand.
  • Cloud is good for getting started without capital outlay. Many of the six startups represented got started before being funded.
• Cloud further enables virutal companies. A bunch of guys with laptops can move office wherever they want, don't worry about where the servers are.
• They all muttered knowingly about the day Amazon's cloud was down.
  • "You could read about it on Twitter, but all the avatars were missing, because Twitter kept them on S3."
• Cloud encourages queue architectures.
  • Pipelined role-based "machines".
  • The work of the app is broken into smaller pieces, distributed onto a broader network of virtual boxes.
  • Number of machines in each role can be altered dynamically to deal with the actual load right now.
• You need monitoring services external to your cloud!

One interesting side-node: the panel was at the Vilna Shul, a historic temple on cramped Beacon Hill. They could invest in some cushions for their 1840 high-backed pews, but other than that, it was a nice change of pace to be hearing tech discussion not among monitors and keyboards but torah holders and time-worn paint.

Titus said that a side project is like a mistress: you only spend an hour a night with her, catch as catch can. I totally agree. Except these days, while trying to put the finishing touches on a release, what with packaging and docs, it's like spending an hour a night working on my mistress's tax returns.