Uphill Forever

In many ways this is the follow up to hard is good and the post I promised recounting the lessons of the buildcloth v0.2.0 release This release of buildcloth is in some ways, the first real piece of software I've written from the ground up. I've written a bunch of code, and I've implemented a decent amount of functionality as extensions and additions to other programs, written some very small programs, and written an endless number of throw away scripts, but never something quite on this scale.…

Keep reading

Buildcloth v0.2.0 Release

Today I did a (slightly) more formal release of a software project that I've been working on pretty consistently for the last two months. It's an extension or elaboration on the buildcloth, and is the groundwork for some other projects I've been working on. While there are some new fixes and improvements to the initial meta-build tool components of the project as I'd been working on 5 months ago, this one goes even further and includes a complete build automation tool.…

Keep reading

Hard is Good

In the hard part of software you could easily chose to read the word "hard" as "sucky," which makes it seem like a big whine on the topic of "polishing your work is hard and annoying," but really, that's unfair. I think it's probably better to read the word "hard" as "important" rather than "sucky". While you may be able to get someone to try your software on the basis of its core implementation or design, people keep using software because it's reliable (i.…

Keep reading

The Hard Part of Software

I've been writing build system tool that allows users to specify concurrent build processes using a lightweight, Python-based system that minimizes overhead. Progress is decent. I hope to use this to replace a hodgepodge of fabric and Makefile for my work and personal projects. I have a decent spec (3 hours), an initial implementation of the internal parts (3 hours,) a good first draft at a command line utility (1.5 hours,) internal/APO documentation (10 hours,) and none of the unit tests and procedural and conceptual documentation.…

Keep reading

Topic Based Authoring Failure

I wrote a long time ago, about /technical-writing/atomicity which (more or less) is the same as topic based authoring. Both describe the process of breaking information into the smallest coherent blocks and then using the documentation toolkit to compile the kind resource. Topic based approaches to documentation promise reduced maintenance costs and greater documentation reuse. I'm not sure if anyone's used "ease of authorship," as an argument in favor of topic based approaches (they're conceptually a bit difficult for the author,) but you get the feeling that it was part of the intention.…

Keep reading

Build Stages

For work, I've been working on revising our build system so that less of the build definition happens in Makefiles and more of it happens in Python scripts. This post is an elaboration. I'm a complete partisan of reusing standard tools, and so moving away from Make felt like a big/hard jump. However: 1. Process creation is expensive, and every "job" starts a new shell and process, which takes time.…

Keep reading

On Generic Build Systems

I spent a bunch of time this week taking a bunch of my work project's build system. We've gone from having most of the heavy lifting done by Make, to having only doing the general high level orchestration with Make and doing all of the heavy lifting with (simple) custom Python code. The logic in the previous system was: Make is everywhere, stable, and consistent. In the spirit of making the project as compatible and accessible to everyone it made sense to use common tools and restrict dependencies.…

Keep reading