It really isn’t that difficult

I’ve been contributing to Stack Overflow for 14 years: pretty much ever since it started. And every year there are Computer Science students who come up with novel ways of screwing up parsing and evaluating arithmetic expressions.

It’s a problem common to all Computer Science curricula: given a string that contains an arithmetic expression (something like 2*(3+1)/4), write a program that evaluates the expression and outputs the answer. There are multiple ways to solve the problem but the easiest as far as I’m concerned is called the Shunting yard algorithm, developed by Edsger Dijkstra. It’s an elegantly simple algorithm that’s very easy to understand and almost trivial to implement once you understand it.

Here’s the funny thing. Computer Science courses often teach postfix expression evaluation (i.e. evaluating “Reverse Polish Notation” like 2 3 1 + * 4 /) as an example of how to use the stack data structure. Then they teach the Shunting Yard and show that by employing two stacks you can turn an infix expression into a postfix expression. (For example, 2*(3+1)/4 becomes 2 3 1 + * 4 /). Then they give the students an assignment that says, “Write a program to evaluate an infix expression.”

The students dutifully go home and write a program that glues the two examples together. That is, the first part converts the infix to postfix, and the second part evaluates the postfix expression to get the answer. Which works. But is kind of silly because a few simple changes to the output method for Shunting Yard let you evaluate the expression directly–without converting to postfix. In my experience, very few students figure this out.

I actually had a job interview where they asked me to write an expression evaluator. I wrote it to evaluate directly from infix, without going through the postfix step. Those white board inquisitions are always weird. At one point as I was furiously scribbling on the white board, the interviewer asked me where my postfix output was? When I told him that I wouldn’t be producing any, he insisted that I must. I don’t argue with an interviewer (more on that in a separate entry) and usually take their advice, but here I told him to just sit tight; that I knew this was going to work.

The post-coding walkthrough was fun. Usually it’s a formality in which I prove to the interviewer that the code I wrote works as intended. The interviewer already knows whether it works or not, because he’s seen the same algorithm written dozens of different times, knows all the different ways it can be screwed up, and knows what to expect from the walkthrough. But this time the interviewer was following along intently as I explained to him how it all worked. A senior software developer at a major company had never before seen the Shunting yard implemented without that unnecessary conversion to postfix. Weird.

I wonder why this oddity exists. Do Computer Science instructors not tell their students that there’s a way to do the evaluation directly? Or do the instructors themselves not know? And then there’s the other question: why would legions of C.S. students every year come to Stack Overflow looking for the answer to a question that’s easily answered with a simple Google search?

Well, okay, I have an answer to the last one. Laziness. It’s easier to post a question asking, “What’s wrong with my code?” than it is to understand how what the code actually does differs from what it’s supposed to be doing.

Posted in Software development | Tagged | Leave a comment

But that’s the way we’ve always done it!

Some years back I did a lot of research on and experimentation with the binary heap data structure. During that time I noticed that publicly available implementations placed the root of the heap at array[1], even in languages where arrays are 0-based. I found that incredibly annoying and wondered why they did that.

As far as I’ve been able to determine, the binary heap data structure originated with Robert J. Floyd in his 1962 article, “TreeSort” (Algorithm 113) in the August 1962 edition of Communications of the ACM. As with all algorithms published in CACM at the time, it was expressed in Algol: a language with 1-based arrays. The calculation to find the left child of any parent is: childIndex = parentIndex * 2. The right child is (parentIndex * 2) + 1, and the parent of any node can be found by dividing the node index by 2.

When C gained popularity as a teaching language in the 1980s (for reasons that escape me, but I digress), authors of algorithms texts converted their code from Pascal (again, 1-based arrays) to C (0-based arrays). And instead of taking the time to modify the index calculations, whoever converted the code made a terrible decision: keep the 1-based indexing and allocate an extra element in the array.

It’s almost certain that the person who converted the code was smart enough to change the index calculations. I think the reason they didn’t was laziness: they’d have to change the code and likely also change the text to match the code. So they took the easy route. And made a mess.

Programmers in C-derived languages (C++, Java, C#, JavaScript, Python, etc.) learn early on to start counting at 0 because arrays start at 0. If you want an array that holds 100 items, you allocate it: int a[100];, and the indexes are from 0 through 99. This is ingrained in our brains very early on. And then comes this one data structure, the binary heap, in which, if you want to hold 100 items, you have to allocate 101! The element at index 0 isn’t used.

That’s confusing, especially to beginning programmers who are the primary consumers of those algorithms texts.

Some argue that placing the root at array[1] makes the child and parent calculations faster. And that’s likely true. In a 0-based heap, the left child node index is at (parentIndex * 2) + 1, and the parent index of any child is (childIndex - 1)/2. There’s an extra addition when calculating the left child index, and an extra subtraction when calculating the parent. The funny thing is that in Algol, Pascal, and other languages with 1-based arrays, those “extra” operations existed but were hidden. The compiler inserted them when converting the 1-based indexing of the language to the 0-based indexing of the computer.

But in the larger context of what a binary heap does, those two instructions will make almost no difference in the running time. I no longer have my notes from when I made the measurements myself, but as I recall the results were noisy. The difference was so small as to be insignificant. Certainly they weren’t large enough in my opinion to justify replacing the code. If my program’s performance is gated on the performance of my binary heap, then I’ll replace the binary heap with a different type of priority queue algorithm. A paring heap, perhaps, or a skip list. The few nanoseconds potentially saved by starting my heap at index 1 just isn’t worth making the change.

The C++ STL priority_queue, the Java PriorityQueue, the .NET PriorityQueue, and python’s heapq all use 0-based binary heaps. The people who wrote those packages understand performance considerations. If there was a significant performance gain to going with a 1-based binary heap, they would have done so. That they went with 0-based heaps should tell you that any performance gain from a 1-based heap is illusory.

I am appalled that well-known authors of introductory algorithm texts have universally made this error. They should be the first to insist on clear code that embraces the conventions of the languages in which they present their code. They should be ashamed of themselves for continuing to perpetrate this abomination.

Posted in Software development | Tagged | Leave a comment

First, prove that it’s possible

Building on my previous post about finding a working solution first, before thinking of optimization issues.

I have been fortunate to work on many interesting problems in my career, and I have used that approach every time: first, find something that works. Maybe it works with a subset of the actual data, or solves the problem for specific cases. Maybe the initial solution takes two full days to come up with a solution using only 0.1% of the data. Or perhaps it’s only a partial solution.

That’s okay! As they say, Rome wasn’t built in a day.

Software development involves a certain amount of discovery: figuring out how to do things. The first part of figuring out how to do something is determining if it’s even possible. You need an existence proof. Once you have an existence proof, everything else is just optimization.

Don’t laugh. I’m not trying to minimize the amount of work that might be involved in optimizing a general solution. Rather, I’m saying that no amount of optimization can possibly help if you don’t know whether a solution is possible.

As a senior developer, I’ve dealt with this too many times. Management decides they want a new feature and immediately builds a team to start implementing it, not stopping to ask themselves whether a solution is possible. In one memorable case the problem they wanted to solve was essentially a 10,000 node traveling salesman problem to which they wanted the optimum solution. They built a team with a half dozen programmers and set them to work building the backend infrastructure and asked me to lead the development effort. It didn’t take me very long to determine that what they wanted to do was impossible. It took months to convince them that we could provide a “good enough” solution (at a huge cost, I might add), but that we couldn’t provide a guaranteed optimum solution at any price.

Programmers often aren’t any better. Faced with a problem, many programmers immediately begin searching their brains for all the optimization tricks they’ve learned over the years. That’s all well and good, except they often forget the first step: is a solution even possible.

Upon reflection, that is one of the key differences between a computer science curriculum and a programming job. An undergraduate computer science curriculum teaches one how to solve problems that have known solutions. The basic assumption behind every assignment is that a solution does in fact exist. The student’s task is to discover and implement that solution. But in industry we are often faced with problems for which there is no known solution. We have to determine whether a solution is even possible.

I’ll admit that, even now, I usually approach new problems with the assumption that a solution is possible. But, having been around the block a time or three, I’m prepared for the possibility that a solution is not possible, or not possible given the constraints under which I am working. That’s where things get really interesting. Anybody can write a program to find “the answer.” It takes an entirely different set of skills to write a program that selects the “best” or “good enough” answer within the constraints of time and budget.

Posted in Software development | Tagged | Leave a comment

Find a solution first

I’ve mentioned before that I contribute to answering questions on StackOverflow. Something I see all too often is a question asking for “the most efficient way” to solve a first- or second-semester homework problem. It’s clear from the content of the question that the person asking has absolutely no idea how to approach finding a solution.

The best advice I ever got about computer programming, and I was fortunate to get this advice very early on, was essentially “Find a solution. Any solution. Prove that it works. Then find a more efficient solution.” I got that advice 45 years ago and it’s never failed me. In fact, the times I’ve ignored that advice and gone straight to looking for an efficient solution have been some of the most difficult.

There are two primary benefits to finding a simple (non-optimum) solution:

  1. You gain insight into the problem by observing how your solution works.
  2. You have a known-good solution against which you can test any optimized solution.

Don’t discount the power of those benefits, especially in entry-level computer science work. The assignment is, essentially, “solve the problem.” A simple solution fulfills the goals of the assignment. Do that first! Then, if you’re curious (or can get extra points), spend some time looking for a more efficient method.

This advice helps not only in school, but also once you get out in the workforce. Very often you will be tasked with solving a problem like a data conversion: a one-time job. The simple solution might take a day’s worth of effort, combined manual work and computer processing. Or you could spend a week developing an optimized solution that will convert the data in an hour of processing time. Which do you choose? I can tell you up front that your employer will be much happier if you get it done tomorrow rather than next week.

Sometimes the non-optimum solution is good enough. Implement it and move on.

You can write a working program and then spend a bit more time making it fast. Or, you can write a fast program and spend the rest of your career trying to make it work.

Posted in Software development | Tagged | Leave a comment

Shingles is no fun

I am suffering through my first experience with shingles. No, not the roofing kind. Shingles is a disease characterized by a painful skin rash with blisters that occurs in a localized area. It’s caused by the chickenpox virus. If you’ve had chickenpox, then likely the virus is lying dormant in your nerve cells, where it will come back to haunt you when you’re older.

It’s … unpleasant. And from what information I’ve been able to gather, what I’m currently experiencing is a rather mild case.

According to the Wikipedia article, about one-third of all people will experience at least one attack of shingles in their lifetime. Shingles is more common among older people. If you live to 85 years old, your chance of having at least one attack is about 50%. The article says that fewer than 5% will have more than one attack.

Risk of death from shingles is very low: between 0.28 and 0.69 deaths per million. Combined with the apparently low likelihood of a second attack, some would say that I’m being overly cautious in contacting my doctor to get the vaccine. My response to them is, “tell me that again after your first experience.”

If you’re over 50, talk to your doctor about getting the shot. The vaccine doesn’t guarantee that you won’t have an attack, but studies show that the likelihood is reduced something like 90% over three or four years, and if an attack does occur it will be less severe. Worth repeated trips to the doctor, in my opinion. My “mild case” was quite uncomfortable for a couple of days and it’s going to itch like crazy (like poison ivy) for the next week or so. I’ve known people who’ve had it much worse. Believe me when I tell you that you do not want to experience it.

Posted in Uncategorized | 2 Comments


Upon return from the sawmill I was faced with the daunting task of unloading those big pieces of wood from the trailer. The smaller piece, of course, was no problem. At less that 200 pounds, getting it off the trailer and onto the garden cart was trivial. I was a little intimidated by the larger pieces, though, and decided to wait ’til the weekend when I could get a few friends to help. But then I saw the weather forecast and realized that I wouldn’t be able to get the truck and trailer into the back yard if I waited. Rain always turns the back yard into a very soggy mess.

I thought about it overnight and decided that if I could load the big log all by myself, then I should be able to unload the two smaller pieces by myself, as well. The next morning I backed the trailer up to the slab behind the garage and started working. My idea for the smaller piece (approximate weight 800 lbs.) was to lever it up and get some rollers under it. Roll it off the trailer and onto the slab, and then use the same technique to position it on the slab. I enlisted Debra’s assistance in moving the rollers.

Trailer positioned for unloading
I drove a wedge under the log to simplify getting a lever under it.

Unloading the smaller piece went almost exactly according to plan. I just had to get the bottom of the log high enough off the trailer deck to put a couple of rollers under it. The rollers are 1-1/4″ plywood dowels that were formally jousting lances at Sherwood Forest Faire. When they break they’re thrown into a big pile. We go by periodically to scavenge a few to keep for various projects. Truth to tell, rollers wasn’t a use I had envisioned when I gathered them.

Rollers in place

With two rollers under it and the 2×4 supports removed, a medium-hard push at the back was all it took to start moving. Every foot or so, Debra would put another roller under the front and I’d remove one from the back. There was no worry about the trailer tipping because the larger log (1,200 lbs.) was forward of the wheels. We quickly got to the end of the trailer.

Preparing to come off the trailer

The idea here was to roll the piece off the trailer onto the first log, then forward onto the second and transition back down to the dowels. I didn’t plan this well. I made two errors. You can see in the first below picture that the first log rolled forward, as expected, but it’s still forward of the piece’s center. There’s no support at the back. When I rolled it forward a little bit more, off the trailer, two things happened. First, the log tilted back. It also pushed the trailer forward because I had forgotten to chock the wheels.

Coming off the trailer
Oops! The log fell back, off the rollers.

This was just a minor problem. It took a few minutes for me to lever the back end up and get another log under it. Then we rolled it forward onto the smaller log and back onto the dowels. After that it was a simple matter of pushing and moving rollers. This goes a lot faster with two people: one to remove rollers from the back and another to replace them at the front.

Back on the dowels
In place, sitting on bricks.

My original plan for the larger piece was to tip it sideways and roll it off the trailer onto the slab, then wrap a chain around it and pull it up on end with the truck. I have no idea why I thought that would be a good idea, but by the time we got the smaller piece in place I realized that I could use the rollers with the larger one, as well.

We used the same technique to get rollers under the big piece: a wedge to make a space for the lever, then put it on blocks, slipped the rollers under it, and removed the blocks. It rolled with surprisingly little effort.

Moving on the rollers

I could have planned this one a little better. I knew that the trailer would tilt when the log moved rear of the wheels, and the log would roll off the end. In fact I was counting on it because I didn’t want to deal with trying to step it down off the back of the trailer. But I should have placed some blocks at the back to provide a primitive ramp. In retrospect, I’m lucky that the thing didn’t have enough momentum to tip over.

This didn’t really pose a problem. The lever is a wonderful invention. I lifted the front with a lever, which allowed the back to roll almost completely off the trailer.

After that it was pretty easy to put a block under the back and a roller under the front to get it going again.

At this point it was just replacing rollers again as we moved forward. Something to note if we ever do this again: be careful with alignment of the rollers. We had a little trouble with it rolling in the wrong direction because we had placed the rollers at weird angles. They don’t have to be exactly parallel with each other, but should be within 10 or 15 degrees of perpendicular with the intended direction of travel.

These two will sit here on the slab until I’m ready to work on them. I’m not going to wait for them to dry, as that would take too long. Air drying time is approximately one year for every inch of radius. I’m not going to wait 15 or 20 years before carving. Not that I could: powder post beetles would have them falling apart long before that.

I’ll of course have to move these again when it’s time to work on them, but that doesn’t worry me. We got them off the trailer with little effort. Moving them on a flat slab shouldn’t pose a problem.

Again, don’t underestimate the power of simple machines. Debra and I unloaded these two pieces (approximately 800 lbs. and 1,200 lbs.) by ourselves using a wedge, a lever, and some rollers. And without expending a lot of physical effort. Had it not been hot and humid, I probably wouldn’t have broke a sweat. It really was that easy. Took a little brain power to figure out how to do things, but we didn’t have to exert ourselves.

Posted in Wood carving | Tagged , , | Leave a comment

Sawmill Day

Unloading the ash trunk

The nice thing about the sawmill is that they have tools to handle these big logs. Bill’s truck with the boom on it easily picked the Ash trunk off my trailer. We also used it to move the log into the sawpit, and to load the larger piece onto the trailer when finished.

The first task was getting a smooth cut on the bottom. We laid the log on its side and Bill got out his trusty little 72″ chainsaw. The thing’s a monster but it made quick work of sawing through the bottom of the log.

Making the first cut with the 72″ chainsaw

Then we picked it up and put it in the sawpit to make two cuts: one at the top to give a flat surface for the coffee table, and then one about 18″ from the top to separate the coffee table base from the rest of the log.

We ran into a couple of problems. I thought I’d gotten all of the screws out of the log, but I missed two of them. The first one destroyed the sawblade. While digging out the first one we discovered another. I’ll do a better job of checking for metal in the log next time.

The second problem was an oversight. When we placed the log for the second cut, we didn’t see that a bulge in the log would impede the blade. Well, not actually the blade but rather the mechanism that the blade rides on. We got about 3/4 through the log and couldn’t go any further. So we lifted the thing out of the pit and Bill finished the cut with that monster chainsaw.

In addition to the big log, I brought a smaller piece of Ash that I’d collected during the Great Icepocalypse of 2021. Ha! When I collected that piece, I thought it was large and heavy. It’s about 4 feet long, two feet wide, and a little over a foot thick. I just had Bill make two cuts to flatten the top and bottom. It’ll be a coffee table when I’m done with it.

And there’s my three pieces, nicely strapped down on the trailer, waiting for me to unload them. That should be an interesting job.

Posted in Wood carving | Tagged , , | Leave a comment

Loading the Ash trunk

I’ve been trying to obtain a very large piece of wood for a project. It turns out that getting a piece of wood that’s 36 inches in diameter and three or four feet long isn’t all that easy if you don’t know an arborist. I got a call from a friend of a friend, somebody who had cut a tree down for a customer and wondered if I was interested in it.

I arranged to go get the trailer that the trunk was on and bring it home to dump the log on my driveway. This is Ash, about 4-1/2 feet long and between 36 and 40 inches in diameter. I estimated the weight at 2,000 lbs. I unloaded it by wrapping a chain around the log and then pulling the trailer out from under it.

My plan for the log is a big carved chair, and the base for a large coffee table. But the first thing was to get it cut into two pieces. My chainsaw is only 16″, so there’s no way I can get even close to a reasonable cut. So I had to get the log onto my trailer and up to the sawmill. Trouble is, I don’t have anything that can lift that kind of weight.

But I do have some simple machines and a little ingenuity.

I positioned my hydraulic jack under the front of the log and jacked it up in small increments, bracing it as I went along.

The trailer is 18″ off the ground. Only 14″ to go!
Gettin’ there.

When I got it high enough, I replaced the hydraulic jack with a farm jack. That solved most of the lifting problem, but I had to be careful to brace the back so the log didn’t roll to one side or the other. It wasn’t difficult to get the log up to the required height and braced securely.

The next morning I hand-positioned the trailer under the log and stated loading. The idea here was to wrap a chain around it and pull it onto the trailer with a hand winch (what we call a “come along”). The only twist was that I didn’t have enough chain. Turns out that a 38-inch diameter log is just short of 10 feet in circumference. I had a 12-foot chain and the cable on the come along isn’t long enough to reach from the front of the trailer to the back. So I had to re-purpose my bicycle lock cable. Plenty strong enough: braided steel cable 3/8″ in diameter.

The 2×12 planks serve as sleds. Friction between the log and the sled is higher than between the sled and the trailer deck, so the boards slide on the deck.
The log under the back rolls as the trunk is pulled over it.

I made a few mistakes here that I will correct if I ever have to do something like this again. In particular, I should have put jack stands under the back of the trailer. I did eventually, but before I did the weight of the log put a lot of stress on the trailer hitch ball and receiver up front. Had that failed, the back of the trailer would have come down, potentially crushing my foot or anything else that was under it.

After getting the trunk onto the sleds, it was easier than expected to winch it up onto the trailer. I had to disconnect and re-position the winch at one point, and jack up the back so I could get another sled in position, but there weren’t any real surprises.

Putting a sled under the back.
On the trailer. Time to reposition the winch.

At this point all I had to do was tie it down for the trip to the sawmill. I suppose I could have done a better job of centering the log over the wheels. The log weighs 2,000 lbs., and the trailer is only rated at 3,500. But it towed okay.

All told, loading this log onto my trailer took about four hours of work, most of which was spent figuring out what to do next. Having never done anything like this, I was extra careful about making sure everything was secure. I didn’t want a ton of wood to come crashing down on me.

Don’t underestimate the power of simple machines. The most complicated piece of equipment I used here was that hydraulic jack, and I could have done without it, substituting a lever and fulcrum. Replacing the farm jack would have been more difficult, but again possible with levers. Nothing I did required a lot of physical effort. The most taxing part of the whole thing was operating the winch. Even so, somebody half my size likely could have done it.

Posted in Wood carving | Tagged , , | Leave a comment

Wedding bowls

Back in May I decided to make a couple of bowls for my niece’s wedding in late July. Finding wood to make bowls from is no problem: we lost an Arizona Ash tree in the Icepocalypse of 2021, and there’s plenty of that lying around. Originally I had intended to make just one bowl, but then decided on two.

Although I did turn a few bowls when I was a member of TechShop, I don’t have a lathe and have no real plans to get one. I carve my bowls with an angle grinder and Foredom power carver.

I started with an end grain bowl: just a piece from one of the larger limbs, about 9″ in diameter and about 4″ tall.

The bowl blank is mounted on my holding jig: a piece of galvanized pipe attached to floor flanges screwed to the bowl and to the work bench. I’ve tried many different ways of holding a piece when working on it, and this is the one I like best. It’d be different if I were doing a more detailed carving, but for carving bowls this is fantastic. It holds the piece securely and I can move around it. The pipe flange is attached to the top of the bowl.

I’ve seen some people hollow the bowl first, before shaping the outside. I don’t understand how they can do that. I always shape the outside first. Here it is after rough shaping.

One of the things I’ve struggled with is smoothing and sanding after the bowl is carved. Smoothing the outside of the bowl can be a very big pain once it’s in the shop. What I do is rough carve the outside, then smooth it with 36, 60, 80 and if I can, 120 grit flap wheels while it’s still on the holding jig. About half the time I can’t get to 120 grit because it burns the wood. It depends on the type of wood and the moisture content. Sometimes I’ll do the 120 grit sanding by hand while it’s still mounted.

Wood scorched with 120 grit flap wheel
Hand sanded to 120 grit

This bowl was a bit difficult because it was too small to hollow with the angle grinder. I had to resort to my Foredom power carver and a 1″ ball burr. Hollowing took a while. Sanding took even longer, and I had to fill a couple of voids with crushed Malachite. But it turned out really nice.

The second bowl is from the same limb, right next to the round bowl. This one is oblong, about 9 inches wide and perhaps 16 inches long. Depth is about 3 inches. Here it is, sitting on the holding jig before I started carving.

Sometime between when I carved the round-ish bowl and when I started on this one, I remembered that I had an Arbortech Mini-Turbo attachment for my angle grinder. That made hollowing this bowl a lot easier.

To hold the bowl in place, I flattened the bottom with an electric hand plane and then glued it to a piece of wood paneling I had left over from when we remodeled the house. I then clamped the paneling to the workbench. This works well, but separating the bowl from the paneling when done is a pain in the neck. I’ve since experimented with several other options, including using less glue (holds well, but still difficult to remove), double-sided tape (works very well and easy to remove), and gluing the bowl to a piece of stiff cardboard (holds well and easier to remove than paneling or plywood). My preferred method is the double-sided tape, but sometimes it doesn’t hold and I have to resort to the cardboard and glue.

One thing I haven’t tried yet is blue painter’s tape and superglue (put a piece of tape on the bench and on the bowl, and add a few drops of superglue to hold them together). I’ve seen that used to good effect in other woodworking situations. I expect it’ll hold well, and removal should be trivial.

I did initial smoothing with a 36 grit flap disc on the angle grinder, then hand sanded to 220 grit, starting at 60 and working my way up. I was pleasantly surprised at the figuring in the wood. I had to get it wet and snap a picture when I had finished the 60 grit pass. It’s just so dang pretty.

Sanded to 60 grit

There were a few small cracks in the bowl that I filled with crushed turquoise. The result is, I think, quite beautiful.

Finished bowl

Finish on both bowls is Half and Half, a product of the Real Milk Paint company. It’s a 50/50 mixture of pure tung oil and an orange solvent. People I trust say that it’s the best spoon finish, so I figured it should be great for bowls, too.

Posted in Bowls, Uncategorized | Tagged , , | 2 Comments

Starting over

It’s been several years since I actively maintained this blog. I went through a bad time, mentally, prior to and just after the COVID pandemic during which I inadvertently lost much of what I had posted over the years. The text of the blog entries is in a MySQL database file that I can probably read if I put some effort into it. The pictures are gone.

That said, I’m finally coming out of my mental haze, and trying to get back on a more even keel. Time to re-start the blog.

As in the past, I’ll write about whatever is on my mind. Computer programming and wood working (carving, mostly) are probably my most frequent areas of interest, but there’s no telling what I might delve into.

Also note that the format here is likely to change in the near future. I just picked a basic theme to get started. Fiddling with formatting is not high on my list of favorite activities, so it might be a while.

Posted in Uncategorized | Leave a comment