At home, we were missing the ability to print from our iPad or iPhones. While I'm not an OS zealot (anymore), I did upgrade to an iPhone last month, and have had an iPad for a while now. They're very useful for casual computing, checking email, browsing. But if we needed to print something, it was a hassle to fire up a laptop or desktop computer to use our networked printer. It turns out that Apple's AirPrint uses DNS Service Discovery, an open standard.  There are programs out there for Windows and Mac to let you share a printer attached to that OS via Airprint.  It turns out, you can use it on Linux if you run the Avahi daemon and CUPS. Of course someone has already figured out how to do it: CUPS with Apple AirPrint, using a python script airprint-generate. I was following the instructions, but the airprint-generate.py program would not generate the XML file to make it all work. Diving into the code, I saw that the printer had to be configured as a shared printer in CUPS, which makes total sense. I didn't have it configured that way, since its a network printer, any other device could connect directly to the printer server. The setting can be changed through the cups web interface or by adding the line below to your printers.conf file. airprint-generate.py will now find your printer and generate the configuration file to add to your avahi services directory.

Shared Yes

The one downside to this setup is that the computer running cups + avahi has to be on for this to work. But, you could buy an inexpensive ARM device, like the upcoming Raspberry PI or another one listed here and build yourself a custom, Airprint compatible printer server.

Carl Erickson observes that a small, boutique team of developers can be massively more productive than a larger team.

To complete projects of 100,000 equivalent source lines of code (a measure of the size of the project) they found the large teams took 8.92 months, and the small teams took 9.12 months. In other words, the large teams just barely (by a week or so) beat the small teams in finishing the project!

Its immediately reassuring to see those numbers, since I've been on enough projects that, once they start falling behind, the temptation to throw more programmers at it grows. Project managers see it as a resource scarcity problem (not enough programmers) and don't realize that coordination and communication burden that they adding by bringing more people on to a project. Now you have a new group of programmers that need to be brought up to speed, learn the codebase, and accept design decisions that have already been made. You're lead programmers won't have as much time to actually program, since they'll be helping bring everyone else up to speed. Developers have known about this for years, Fred Brooks wrote the book in it - The Mythical Man-Month.

But while the study's conclusion is reassuring, I wonder if there are other factors at work. Theres an obvious selection bias in the type of people who go to work at a large IT programming department/shop versus those who choose to work solo or in smaller teams. Are large teams filled with junior 9-5 programmers who just want a steady job but punch out in the evening? Do smaller teams attract more experienced and productive people who prefer to work smarter rather than harder? From the study summary, it doesn't look like they considered this aspect.

Perceptive and made me chuckle.

Meanwhile my smartphone will be lucky to survive 34 months, and is only able to receive commands from Earth if I hold it out of an upstairs window...

Source