Green text, black background
I tend to do my development using vim, in a terminal window connected to a remote server that looks very much like the production environment. Thankfully, I am not the only one who works this way. Perhaps I'm not crazy after all?
Green text. Black background. I’ll tell you why right now. I’m an old school DOS guy. My first word processor was Wordstar and that’s the word processing program I came to associate with the fugue-like state of maximum productivity: the Zone. This is why I continue to favor colored text on a black background in my current favorite editor, Textmate. The coloring reminds me of an primal safe place where the tool is serving its purpose — to get the hell out of the way so I can go be exponentially more productive.
This is why, as engineers, we stick with something that works for us. This is why the ancient likes of vi and Emacs continue to flourish. Once we find a tool that works for us, once we’ve chosen that tool, it becomes ours and remains ours. It allows us to get foamy.
I've had similar experiences with Dreamweaver and other WYSIWYG tools, where they are just too helpful and end up jumbling up my carefully formatted code. To be honest, I never even really liked working in Eclipse, either. It's just too distracting, and again, too "helpful" for my taste. But like Rands says, to each his own.
via Rands In Repose
Rethinking “control” in software engineering
I just read a short but interesting article by Tom DeMarco on the concepts of metrics and control in software engineering. Here's the bottom line that really resonated with me:
This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects.
That might not sound intuitive at first, but it makes sense after reading what he has to say.
The article (PDF) is available here: http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf.
Actually making money with open source
No, I'm not talking about how to earn money by working for Canonical. This is a post about actually designing a new piece of currency using open source software, especially Python. A quick summary: The Netherlands wanted to commemorate its rich history in the field of architecture, so they held a contest for the creation of a new coin. Using a bunch of open source software and many hours of hard work, both on the artistic and engineering side of things, Stani Michiels was able to come up with a truly inspiring design. Please read his blog post for some great, large pictures and a detailed overview of the process he used.
Python 2.6
If you're a Python developer, you should really read about what's new in Python 2.6, which was just released a few days ago. There are a number of significant changes and additions, so this is a long document, but it's worth going through. Most importantly, 2.6 is a stepping stone to the upcoming 3.0 release, so it's a great way to get used to the future of Python while still having the choice to use older syntax.
Does the government fear innovation?
Yes, of course they do. They're the government. Nothing moves quickly, and innovation is stifled 95% of the time. But alas, even Uncle Sam can't hide under the information technology of the 90's forever. As the web begins talk of Web 3.0 (whatever that really means), the federal government is beginning to look into taking advantage of some of the Web 2.0 technology that has been around for a couple of years.
The launch of A-Space, "MySpace for the intelligence community," was very publicly announced as a new attempt to foster information sharing and collaboration across agencies. But whenever you deal with sensitive or classified data, security becomes a major hurdle to data sharing.
Anyway, this Federal Computer Week article, "Play it safe on the interactive Web," caught my attention. It attempts to give tips to federal IT-types on how to avoid taking any risks while trying out some of the latest Web 2.0 tech. I couldn't help but feel that the author misses the point of interactive, collaborative, service-based systems. It seems more like a list of how to safely give the appearance of venturing into these new technologies.
The very first suggestion is to isolate new cutting edge initiatives from the rest of the organization. Well, doesn't that defeat a lot of the point? You can't create a great new interactive, web-based analyst interface to query multiple, disparate databases across various agencies if you are going to keep things isolated (as an example). Tip number two: "keep an eye on XML." Sorry, but XML is not some newfangled thing that might be useful. I'm positive that it's already all over government IT systems. Sure, it can present new challenges in sharing data, but it also allows for new, innovative solutions to old problems. (Just remember that XML is not always the right tool for the job.)
I must say, the article isn't all bad. It does bring out some issues with Web 2.0-type systems, such as the need to really validate untrusted user input. And I can't argue with the last tip of embedding security into the development process. But overall, I think the government should be more aggressive in adopting new ideas and software technologies. Security should be included, but not a roadblock.