JJinuxLand

The comm utility reads file1 and file2, which should be sorted lexically, and produces three text columns as output: lines only in file1; lines only in file2; and lines in both files. It's sort of twist on diff. It's nice because there's no formatting to get in the way. $ cat > 1.txt << __END__ 1 2 3 __END__ $ cat > 2.txt << __END__ heredoc> 2 heredoc> 3 heredoc> 4 heredoc> __END__ $ comm 1.txt 2.txt 1 2 3 4 Thanks to Krishna Srinivasan for teaching me about a new old-school tool ;)

I saw a fantastic talk yesterday: How to Protect Your Open Source Project from Poisonous People . If you help run an open source project, this is a must see.

For all its strengths, developing for the Web has become a gigantic pain in the rear, especially when compared to the Unix style of development. A few months ago, I joined a new startup. Almost all of it is backend processing that doesn't even use a database until almost all the work is done. Our only Web application is for a Web services API. Since I was mostly writing the code from scratch, my boss and I agreed that taking a Unix approach was best. Hence, we have a bunch of simple, standalone tools. Writing such tools is so refreshing. You know exactly what you need to do. They're only a few hundred lines long. You build a nice command line interface using optparse , you write some tests using nose , etc. It's all very straightforward and linear. Wanna know how to do a UNIX-style mashup? You use a pipe. Recently, I went to work on a Web application again, and I realized just how much of a giant pain in the rear it is. Here are some of the things you need to

By default, Google App Engine Web applications runs on yourapp.appspot.com. That means that some other app, e.g. badguyz.appspot.com, can set a cookie for appspot.com, and your app will get that cookie from the user's Web browser on subsequent requests to your site. This isn't some remarkable new exploit or anything. It's just something to keep in mind when running on subdomains like this. If you're worried about security, you should use your own domain name and cryptographically sign your cookies ( here's some example source code ).

Python has a wonderful interactive interpreter (i.e. shell). However, sometimes you need more setup before you can start coding. Previously, I wrote Python: Coding in the Debugger for Beginners . Google App Engine works a bit like CGI in that output to STDOUT goes to the browser. This breaks my normal "import pdb; pdb.set_trace()" trick. However, it's not hard to put STDOUT, etc. back so that you can use pdb in the way you normally would: for attr in ('stdin', 'stdout', 'stderr'): setattr(sys, attr, getattr(sys, '__%s__' % attr)) import pdb pdb.set_trace()

Have you ever wondered how it could be that Lisp is so powerful, and yet C is so much more successful and ubiquitous? How is it that so many brilliant coders know Lisp, and yet we so rarely hear from any of them other than Paul Graham? This is a great article that tries to explain it: the bipolar Lisp programmer .

I was thinking of Joel on Software's famous post Things You Should Never Do, Part I where he says, "[Netscape] did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch." Since Joel is from Microsoft, I was pondering what would have happened if the Microsoft NT developers had taken that advice and based NT on DOS. Perhaps it's illustrative to compare the quality of Windows ME vs. Windows 2000 and XP.