Suppose you’re building a service that depends on several other services to work. You write a bunch of code and carefully include error handling code and have a plan for what happens if each service your new service calls fails. Naturally, you want to test your code. These services are invoked over a network. Perhaps they’re web services but they may be some other network protocol. Suppose further your code is nicely factored so there’s a “client” class that presents the network service as a library API to the rest of the service. [Read More]

In my learning programming post I wrote about some approaches for learning to program and linked to a bunch of resources. Some of my insightful friends pointed out that most programming teaching doesn’t cover debugging and that lack leads to a lot of frustration. This is particularly hard on those working alone or with other people that don’t know how to debug. Debugging is the art of figuring out why a system doesn’t work. [Read More]

I’m interested in how people learn to program. Over the past few years, friends or relatives have asked me about resources for learning to program for themselves or for people they know. I’ve collected and refined that advice here. It’s hard to know what approach will work for someone to learn to program. It’s hard work so it’s important that each step be interesting and rewarding enough to keep going particularly when there’s no external force such as formal courses. [Read More]

RFC 761 section 1.2.2. 2.10. Robustness Principle TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. RFC 1122 elaborates with section 1.2.2.: 1.2.2 Robustness Principle At every layer of the protocols, there is a general rule whose application can lead to enormous benefits in robustness and interoperability [IP:1]: “Be liberal in what you accept, and conservative in what you send” Software should be written to deal with every conceivable error, no matter how unlikely; sooner or later a packet will come in with that particular combination of errors and attributes, and unless the software is prepared, chaos can ensue. [Read More]

FileIO

I wrote (the first version of) the LambdaMOO FileIO patch a long time ago, but I didn’t use it for very long and haven’t been the maintainer for a long time.

The link I had to the current version is dead.

toaststunt is a LambdaMOO fork which includes what appears to bea modern version of FileIO. I have not used it.

MOO Server Software I’ve written two LambdaMOO server extensions. ext-xml – This I still use. It’s part of the server I run today. fileio – This I haven’t used in a very long time, and haven’t been the maintainer of the patch for nearly as long. I do not have the current version of the source. The source for the server that Waterpoint runs is available on GitHub at wp-lambdamoo. This includes both the modern version of the ext-xml patch as well as the other patches to stock LambdaMOO Waterpoint uses: [Read More]

Software

Most of the software I’ve written is not open source.

Much of the open source code I’ve written or contributed significantly to is hosted on GitHub.

I also wrote some software around and within LambdaMOO.

What is LambdaMOO? LambdaMOO is a MUD server. You can read more about it on the LambdaMOO server home page. It is essentially a programmable chat server. That simplifies things a bit since one could write non-chat networked applications on top of LambdaMOO. “MOO” is just a shorthand way to refer to LambdaMOO. LambdaMOO is also the name of a MUD that uses the LambdaMOO server. LambdaMOO, the MUD is at lambda. [Read More]