Taken from @hackedy's tweet , here's aninteresting Python surprise:

>>> {1: "one", True: "two"}{1: 'two'}>>> {0: "one", False: "two"}{0: 'two'}

There are two things happening here to create this surprise. Thestarting point is this:

>>> print hash(1), hash(True)1 1

At one level, Python has

In theory one of the advantages having of a SAN instead of simpledisk servers is relatively painless storage migration over thelong term , where given a suitablesetup and suitable software you can more or less transparentlymigrate data from old storage backends to new ones without anyparticular user-visible downtime. In practice I've come around tothe idea that we may never be able to do this in our fileserverenvironment and that in general ittakes a particular sort of environment to make it work.

Put simply, the disks

These days a common pattern in many languages is to have errors orerror exceptions be basically strings. They may not literally bestrings but often the only thing people really do with them is printor otherwise report their string form. Python and Go are both examples of this pattern. In such languages it's relativelycommon for the standard library to helpfully embed the name of thefile that you're operating on in the error message for operatingsystem IO errors. For example, the literal text of the errors and

Go makes using goroutines and channels veryattractive; they're consciously put forward as the language's primaryway of doing concurrency and thus the default solution to anyconcurrency related issue you may have. However I'm not sure thatthey're the right approach for everything I've run into, althoughI'm still mulling over what the balance is.

The sort of problem that channels and goroutines don't seem anentirely smooth fit for is querying shared state (or otherwisegetting something from it

The traditional reason to use web app frameworks like Django isthat doing saves you time and perhaps gives you a more solid andpolished result, possibly with useful extra features like Django'sadmin interface. But it has recently struck me that in many situationsthere is another interesting reason for using frameworks (or adefence of doing so instead of writing your own code).

Let's start by assuming that your application really needs at leastsome of the functionality you're using from the framework. Forexample,

While working on my Go sinkhole SMTP server , I managed to stick myselfwith an interesting little concurrency bug that I feel like writingup today. The server takes a file of control rules, and to be simpleit reloads and re-parses the control rules on every new connection.We do want to print a message if there's an error in the rules, butwe don't want to print it on every connection; that could be a lotof duplicate messages, even concurrent duplicate messages (since

Here, let me present you something in illustrated form, on a systemwhere /bin/sh is Bash:

$ cat Demo#!/bin/shfor i in "$@"; do  case "$i" in    *[A-Z]*) echo "$i has upper case";;  esacdone$ env - LANG=en_US.UTF-8 ./Demo a b C y zb has upper caseC has upper casey has upper casez has

An init system has two jobs : runningand supervising services, and managing what it runs and supervises.SMF is a perfectly good init system as far as the former goes, andbetter than some (eg the traditional System V system). It is thesecond job where SMF falls down terribly because it's decidedlycomplex, opaque, fragile, and hard to manipulate. The result is avery divided experience where as long as you don't have to doanything to SMF it's a fine init

In Unix and ASCII, bytes 1 through 26 are control-A through control-Z.But there are control characters outside that range: 0, 27 through31, and 127. As a result of writing up my _.screenrc I've become curious about what all ofthem are, so here's my handy chart: