I just remembered that I once chatted regularly (maybe once a week) with a guy from China. It was early in college. He was a pretty cool dude. He even introduced me to his friend once.

I don't remember his name though :(
~~~~

Night Witches

Here's an article about the "night witches", Soviet bomber pilots from WWII, and a blogpost with links to a little more.
~~~~

Sort and replace identifiers in a sentence

I found this post on LinuxQuestions that interested me, so I decided to try my hand at it. What I wrote is slightly more general in that it sorts any identifiers matching a pattern rather than just identifiers with numbers. The program does 3 passes over the sentence: The second substitutes all of the matching identifiers with "{}", a string which can be replaced using Python's string formating function. The first pass extracts the identifiers and sorts them. The third pass is the actual substitution using the string formatter.

import re

word_split_regex = re.compile(r"[\W\s]*")
id_regex = re.compile(r"id\d+")
natsort_regex = re.compile('([0-9]+)')

# from http://stackoverflow.com/questions/4836710/
#  does-python-have-a-built-in-function-for-string-natural-sort#18415320
def natural_sort_key(s):
    return [int(text) if text.isdigit() else text.lower()
            for text in re.split(natsort_regex, s)]
def main(s):
    b = sorted(id_regex.findall(s), key=natural_sort_key)
    x = id_regex.sub("{}", s)
    print x.format(*b)

if __name__ == "__main__":
    import sys
    if len(sys.argv) > 1:
        main(sys.argv[1])

~~~~

Disable Checked Exceptions?

I recently was frustrated by the necessity of annotating every function in the call chain in order to not handle an exception at the entry point to my code. The module I am working on accepts many different signatures for essentially the same method:

public static void doTransformation(Transformer t, Source in, Result out)
public static void doTransformation(Transformer t, InputStream in, Result out)
public static void doTransformation(Transformer t, InputStream in, OutputStream out)
public static void doTransformation(String t, InputStream in, OutputStream out)
public static void doTransformation(String xslt, String in, Writer out)
public static void doTransformation(String xslt, String in, OutputStream out)

Only the first actually does the transformation, but this can throw an exception from an external library, and all of the others call it directly or indirectly. I didn't want to annotate all of these with a throws declaration because I didn't know if I would have to switch out Transformer for something else or add more such methods in the future.

My first reaction was to leave off and go read a book; so I did that and then went to sleep. This morning I was looking at the code again and I was reminded of the first tool (or maybe second after abstraction) in the programmer's toolbox: indirection. Although a checked exception, if unhandled, can introduce a lot of unnecessary annotations into your code, you aren't obligated to use that exception throughout. All it took was wrapping that exception in my own derived from java's RuntimeException, and now it passes through to a place where I can deal with the exception appropriately.

I should have thought of such a simple solution right away — maybe I'll remember not to be writing code when I'm so tired in the future!

I happened upon this excellent blog post on exceptions in Java. Really, I can only vouch for the headings and the comments, but it's a very good summary.
~~~~

I was watching this video here and, at the end, the speaker, Ghislain Nkeramugaba, mentioned that there is an unwritten rule that broadband Internet access is built out with road construction. Hearing this makes me think that the countries which are building out their infrastructure for the first time must be at a great advantage to older nations that had to patch centuries old (or older) infrastructure to bring broadband access. Especially in Europe where various buildings and roads may have been there for a millennium or more, bureaucratic restrictions may slow down build-out regardless of industrial sophistication. That certainly is not to say that countries like Rwanda have no areas which are worth protecting; however, I think there is always greater difficulty in tearing up and replacing established infrastructure versus adding something that did not exist before.

What's the upshot of this alleged smaller burden of history? It's really unclear to me as I have no background in the development of infrastructure. I do suspect however, that there are opportunities for innovative plans for building the networks that power developing countries and that these countries will be the laboratories of exciting new Internet technologies.
~~~~

I've thought a little about why it is that I have more trouble taking the time to learn some software development tools than others. In one part, I prefer software that is well maintained, well spoken of, and well-used. I am wary of newer tools (pretty much anything that can't be traced to before 2006).

My reason for avoiding newer projects has little to do with how well-made they are. I don't know if they are or not most of the time until I start using them and dig into the code. Instead, it's more that I fear taking pains to learn some framework or tool-chain only to have the usefulness of my learning negated by some other newer system.

The keep-up game never appealed to me. It's why I avoided the technology fetishism that lusts after the newest/fastest/sleekest version of a few-months old product. It's clear that it takes real work to keep abreast of such changes, to understand the strengths and weaknesses of a line of products, to make useful characterizations of a brand. The thing is, I have no head for remembering system specs, to do so would be a non-trivial investment, and that investment would be made moot two or three versions down the line. That's my concern anyway.

So, it's the same with software development tools, especially web frameworks. I would rather learn fundamentals of network programming and HTTP. Once learned, these provide a basis, or so I imagine, for extension in a greater number of directions than if I learned how to make a J2EE web app. Perhaps this is the wrong way of thinking about things. After all, knowing fundamental physics doesn't necessarily make you a good chemist, let alone biologist, although the latter are built up in terms of physics.
~~~~

Have an idea for a flat job-assignment structure for a consultancy or small-jobs company. The company has one corps of engineers who work client cases. Clients work specifically with one of these agent-engineers as long as the relationship lasts and they coordinate feature additions, formulate engineering tasks from customer issues, advocate for the task-engineers (we'll get to them), negotiate the up-front price of the task, and input tasks for completion. A second corps of engineers, when tasks are input, self-assign to the tasks they want to work on. Task-engineers can bring in or agree to work with other engineers and either work out a payment split among themselves or formally agree on how to split it. Task-engineers can also suggest changes to the payments which would encourage them to work on the task.

Naturally, there would be some tasks that virtually no one wants to work on because they're mundane, no one has the skills, or no one likes the company, or any number of reasons. For these tasks, there should be a coercive rule that, for instance, requires junior engineers to take tasks no one else acts on. Alternatively, there could be something like a points system. Really guaranteeing liveness of every task is the hardest thing to manage when you have self-election. It could be necessary to remove the guarantee of completion -- which would be awful -- or to outsource the tasks or to have such a large pool of workers that tasks rarely die and can be handled on a case-by-case basis.

~~~~