This (Invalid Apache directory – unable to find httpd.h under /usr/include/httpd/) error has been a thorn in my side while building a php rpm with the –with-apache php config argument. I’m running CentOS 6 and have the httpd-devel package installed which places the apache header files (including httpd.h) in /usr/include/httpd. Perms on the /usr/include/httpd directory are 755 and the files inside are 644.  Everything looked good.

Turns out that –with-apache builds the static apache 1.x module which isn’t really what you want if you have installed apache in the last 10 years. What you want instead is –with-apxs2 which will build the apache 2.x shared library.

One of the problems I recently needed to solve at work was moving (and transforming) a lot (TBs) of data from an old system to a new system. Solved it, and things were good. Unfortunately we (co-workers and I) have noticed that the script just stops working. It doesn’t crash it just stops doing anything. Through a bit of luck I discovered this was due to network IO (or lack thereof).

The problem I faced over the last few days is that the script stops transferring data over the network but doesn’t hit a network timeout. The transfer of data grinds to a halt and doesn’t trigger any of our monitoring. I’ve solved this with an inotifywait loop.

While the script is busy copying data it spits information out into a log file. It writes to this file a few times per second with occasional pauses of up to 25ish seconds to collect a new collection of work to transfer. It so turns out that inotifywait has a -t input which is timeout in seconds. If inotifywait gets a notify event it exits with code 0 and if it times out it exits with code 2. With that bit of knowledge in hand, I wrote a wrapper script that launches the aforementioned script in the background and then goes into an infinite loop. It then sets up an inotifywait with -t 60 and -e modify on the log file. If the exit code is 2 then it runs a ps aux | grep to get the pid, kills the script, and relaunches it in the background. In pseudo-code:

./ &
   inotify -t 60 -e modify /path/to/my/logfile
   if exitCode == 2 then
      pid = ps aux | grep myScript | awk '{print $2}'
      kill pid
      ./ &

With that in place the script runs until it stops outputting to the log file for 60 seconds which this wrapper script interprets as it failing. In that event the wrapper script kills the script, restarts it, and we’re back up and running again. Not something I would consider a long term solution but this isn’t a long term problem.

The most painfully obvious reason to keep a development journal came to me at work today. One of the major reasons to keep a lab journal is to log the experiments you run. This is so future you and others can read about how you did things and what results there were so that standards can be upheld and test can be rerun if needed. When I wrote my last post—and this has been baffling me all day—it did not occur to me that experiments = tests. When you are testing code write down what you did and what the results were. If you do that you won’t have to worry as much about forgetting what you tested, forgetting the results of your tests, convincing a coworker that you tested something, and convincing a coworker of the results of your tests. Future you will thank you.

Inspired by scientific lab journals I have decided to start a development journal. This may be considered a waste of time given programs being fairly easy to reproduce, comments acting as documentation within code, and source code tools providing a history which can be used to prove originality. I believe it can have other uses that will make it a valuable use of time.


One straightforward benefit is taking the extra time to consider decisions. Notes describing problems and notes describing solutions can both benefit. When bug fixing the act of listing all of the known conditions and factors may uncover the problem. Writing down what was done and the justification for doing it creates an internal dialogue which opens the doors for self evaluation.This evaluation gives time to analyze whether a solution solves the problem and whether another solution may solve the problem in a way that could be considered better. In the few days I have been keeping a development journal I have noticed a change in the design of the projects I have been working on towards a more structured use of design patterns. This is not enough to say the code I am writing is better but I consider it promising enough to continue with the journal.

Another potential benefit is the switch from keyboard, mouse, and screen to pen and paper providing a boast to creativity. This mental state shift will allow the problem to be looked at differently. Writing down the problem gives times to restate the problem which can also lead to being more creative. Sadly I can’t seem to find any evidence for this point so I’m not sure how strong of a benefit this is.

There are other benefits as well. Paper is a particularly good medium for drawing out UML, flow, state, and other forms of diagrams. It provides a place to leave more justification for why something was done than what is typically put into comments.

Even though writing out a journal is likely to slow down the development process some I believe the potential for better code outweigh this risk. I will aim to write another post when I have more anecdotal information. Also, I’ll edit this post if I can think of any other potential benefits.


While entertaining the idea of writing a development journal I read several posts about lab journals to determine how to go about things. Of particular aid was Maintaining a laboratory notebook by Colin Purrington. Unfortunately the world of science and computer science are different enough to make much of the advice inapplicable. There will be much to learn regarding what belongs and what does not but I believe there are a few things that carry over very well or seem useful enough to act as a starting point.

If you’re going to be spending a decent amount of time writing you might as well enjoy the process. Therefore, buying a good quality notebook and pen seem like appropriate first steps.

For a notebook I decided on a Kokuyo A5 B (the one with 28 lines) notebook with one of the A5 covers. The notebook+cover was more expensive than other nice notebooks such as a Leuchtturm (my second choice) but the cost of replacement notebooks is much cheaper. I personally wanted a notebook with faint or no lines. My Kokuyo notebook has faint blue lines, the Leuchtturn notebook I was looking at had dots instead of a being boxed or lined, and a notebook such as Whitelines notebooks may be work looking into. I would advice against getting notebooks with spiral bounding, perforated pages, or using a 3 ring binder as you really shouldn’t be removing pages from the notebook. I would also advise against using a 3 ring binder as you shouldn’t be adding pages to the journal. I would advise you to get a good quality notebook with glued or threaded binding. You want your notebook to last and be a potential reference.

Pens are probably much more about personal preference though I would say you should definitely be using a pen. Knowing you are about to write something down that you can’t erase, in a notebook that you won’t remove pages from, that someone else might read, gives an added bit of deliberation before you commit thought to paper. A nice pen also writes better and lasts a lot longer on the paper. I am currently using a fine tipped fountain pen because I enjoy writing with it. I would also be happy with a 0.38mm G2 gel rollerball or a 0.3mm Micron. Point here is to write with what you like to write with. You’re going to be doing a lot of it so you should enjoy the process.

To prepare your notebook you should leave a few pages in the front for a table of contents. If your pages are not already numbered you should number the remaining pages of the book. Put your name on the cover or the first page as well as the start of the date range the notebook will cover.

I am not completely sure of the best way to add entries into the book. It makes since to title projects as that gives a name for the table of contents and ties together multiple entries on the same topic. A date should be given to each topic. If a topic continues for multiple days without another topic interrupting it then you should probably put a date in the notebook for the start of that days notes. I would also think it generally better to not put multiple topics on a page though leaving sufficient space between topics on a page may make it clear enough that there are different topics.

This is all that I currently know and speculate about a development journal. I will provide further posts in the future as I discover more.

Here are some articles I found interesting from this week.

Automatic Deploys At Etsy by rlerdorf
 In which a deployment strategy designed for 0 interruption time is discussed.

Design Patterns after Design is Done by Jim Bird
Frames refactoring and code legibility in terms of design patterns discussing what works and what does not work.

6 Warning Signs That Your Technology is Headed South by Christopher Taylor
Discusses technological and personal costs of using old technology.

The Date Question by George Dinwiddie
Discusses software deadlines trying to get to the root of the question, “When will this software be done?”

Ambient occlusion for Minecraft-like worlds by Mikola Lysenko
Discusses Ambient Occlusion in voxel based games using Minecraft as a specific example.

Erlang at Basho, Five Years Later by Justin Sheehy
Sheehy talks about the challenges that were expected using Erlang and the challenges that were actually encountered.

15 workplace barriers to better code by Peter Wayner
A list of things that annoy programmers and get us out of “the zone.”

Why Javascript by Alex Russell
Russell defends javascript on the web and confronts frequent arguments against it’s use.

How Clutter Affects Your Brain (and What You Can Do About It) by Mikael Cho
A not exactly minimal article on minimalism and what effect clutter can have on your ability to focus and be creative.

Recently I needed to install Apache Thrift (version 0.9.0). This did not go as I hoped. Make failed with a message along the lines of “No rule to make target…” and something about ParentService.cpp. After trying several combinations of settings I managed to get pasted the issue. There isn’t really any active development on thrift so I did a git clone from their git repo. Manually installed autoconf because centos 6’s version was outdated –my distro from 2012 has a less up to date version than required by a product last updated in 2010. Ran the ./, ./configure, make, sudo make install. Done. Hope that helps someone.

tl;dr: If running into a “No rule to make target” error during the make of Apache Thrift 0.9.0, then head from git and build that.

I just found out that Posterous is going down. I’ve decided to give WordPress a try for awhile. This means I’ll have to pay money for what I was getting for free (custom domain name) but whatever.

One bit of good news is that Posterous has an export feature and WordPress can import that. I’ve been waiting for that to generated and happened to notice that there is fuck all for it to export. So screw it. I get a new blank slate to do absolutely nothing with.

Anyway, dear internet traveler, if you come across this post have pity on it. It’s likely to be a very lonely post on a likely ignored blog.