Thursday, October 30, 2014

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.
~~~~

Wednesday, October 29, 2014

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.
~~~~

Friday, September 19, 2014

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.

~~~~

Tuesday, September 9, 2014

Margaret Sanger

Margaret Sanger is credited with founding modern birth control tools and education for women in the United States. She began her campaign for women's health and welfare in the 1900s during the same time as the Comstock Laws (effective from the 1870s), which restricted the transmission of contraceptive information on the grounds that the materials were obscene.

~~~~

Wednesday, August 27, 2014

For some reason, the Play Framework docs give you an overly verbose syntax for setting up a fake application on each test:

    @Test
    public void findById() {
        running(fakeApplication(inMemoryDatabase("test")), new Runnable() {
            public void run() {
                Computer macintosh = Computer.findById(21l);
                assertThat(macintosh.name).isEqualTo("Macintosh");
                assertThat(formatted(macintosh.introduced)).isEqualTo("1984-01-24");
            }
        });
    }
It's much cleaner to do that with with the Helpers class and JUnit setup and teardowns (i.e., @Before and @After)

public class ApplicationTest {
    private FakeApplication fa;

    private FakeApplication provideFakeApplication()
    {
        return Helpers.fakeApplication(Helpers.inMemoryDatabase());
    }

    @Before
    public void startapp()
    {
        fa = provideFakeApplication();
        Helpers.start(fa);
    }

    @After
    public void stopapp()
    {
        Helpers.stop(fa);
    }

    @Test
    public void checkSums() {
        /* Runs in a FakeApplication context */
        Result result = Helpers.routeAndCall(Helpers.fakeRequest(Helpers.GET, "/sums"));
        System.out.println("sums result "+ Helpers.contentAsString(result));
    }
...
}
Using the wrapper can't even be justified for one-off tests except for the fact that you might forget to call Helpers.stop.

~~~~

Monday, August 25, 2014

Despite all of my posts discounting my TagFS (there are so many). I've started dog-fooding it, using a mounted TagFS for articles and things I've downloaded while doing research. It may be that standard Unix commands and file browsers are sufficient interfaces for the common case of tagging files. I will post back eventually if I make changes based on this usage.

~~~~

Saturday, July 19, 2014

What joy when the insouciant
armadillo glances at us and doesn't
quicken his trotting
across the track into the palm brush.
What is this joy? That no animal
falters, but knows what it must do
--Denise Levertov

~~~~