Writing Software For A Living And For Fun

April 19th, 2017

Last week, I spent an evening fixing some bugs in the Linkage program. It’s a bit buggy since I added a bunch of complicated features like gears and fastening. Writing software is hard to do well but not hard to do badly. I once had to tell someone, in regards to some software having a bunch of bugs, that the software in question had more moving parts than the space shuttle and was written by one person over a few years. the effort put into the software was probably 0.00001% the effort put into building the space shuttle.

I forgot to publish the Linkage update so I’ll do that tonight. A few of the bugs were just annoyances that cropped up due to my not writing good code. For instance, I had added data to the linkage files that listed the selected connectors and links in order, instead of relying on a flag on each connector or link. But then the software processed the list front to back and ended up reversing the selections when doing an undo operation. I simply forgot at the time I wrote that code to check the order and do it right. It’s hard to do that sort of thing right when there is nothing in the code that is a reminder that the order is meaningful or that it might ever be backwards.

I did a little research last night on how I might make a simulation of a board game using HTML5. HTML5 is a shortcut for “JavaScript using HTML5 and maybe CSS3 features.” It’s the panning and pinch-to-zoom that is the hard part. I might just use SpriteKit for iOS. Speaking of iOS, when I typed “iOS” in an email using Outlook 2016 on Windows 10, the text got changed from “iOS” to “Ios” and then the stupid software automatically turned on the caps lock. WTF is with that? I should mention that a board game simulation is really just a computer game that is limited to interactions that could also be done with physical pieces on a physical table. It’s not really any sort of simulation.

The boss just asked about the time I would need to port a Windows client-server business app to iOS. I recently finished 90% of a project to port the same app to the web and the last 10% is being a bitch. The JavaScript to display the app UI was fun and the Java on the server to create the pages and deliver the data was almost fun. The feature to let users save their data and then load it up later, is not being so much fun. Mostly, it’s difficult to put a lot of effort into what seems like a badly-thought-out feature. I just can’t come up with an elegant architecture for this.

I am not prolific like some software guru types. There are people out on the internet that have published large numbers of interesting software experiments. But I still write a lot of software for fun on the side. I knew programmers that didn’t even have computers at home – it was clear that they were not really interested in programming and just worked in that capacity to have a job.

So the plan is to finish this web interface to the client-server business app, write an iOS version of the app, keep the Linkage program up-to-date, write a board game style app for iOS, keep working on the physical version of the board game (I’m designing the game itself while using the simulation as a way to test it), and do non-programming stuff like finish an almost done RBS, work on a new RBS, and play a bit of Forza Horizon 3. It’s going to be a busy spring and summer.

New RBS “Thrown Together”

April 12th, 2017

No, it’s not titled “Thrown Together,” that’s just a description of how I started it. As you can see in the video, the base is the working-platform for a previous sculpture (now sitting on a sheet of acrylic) and the motor mounts are just wood bits.

First Full Test


Solid State Track Switch


Solid State Track Switch

This machine has a solid-state track switch. It is “solid-state” because it has no moving parts. The momentum of the ball keeps it moving along the outer upper track until after the two tracks are merged into one. But when the ball travels back through the switch, it does not have the momentum to stay against the outer upper track and it follows the lower path. There is no noise because the tracks meet gradually and the ball never falls from one track to the other – it is simply on both tracks at the same time for a moment. Any clunking noise in the video is coming from the motorized lift picking up a ball and a new ball falling into place at the start of the track. it is unfortunate that the clunking sound happens at about the same time as the ball going through the switch.

After taking the video and pictures, I removed the sticker form the motor and blackened the casing. I also blackened the track. Once the sheet of clear acrylic is ready at the plastic shop, I’ll be one motor-mount and on-off switch away from being done.

Gears for Lifter #3

March 21st, 2017


The next lifter needs a crank that oscillates for about 200 degrees of a circle. The only way to achieve that is to use a motor crank to drive a crank on the big gear that then drives the small gear and its crank. 100 degrees of movement of the crank on the big gear is then 200 degrees of movement of the crank on the small gear.

See the video if it doesn’t make sense:


Send Complex JS Data In A Web Page

March 17th, 2017

I had a dilemma; how do I send a bunch of complex JavaScript data within HTML without using AJAX. The server is running Tomcat and the HTML content is generated by some Java classes triggered by a servlet. The funny thing about this is that once I solved the problem, I realized that I had solved it once before back when I created my trip log map page. But this new problem seemed on the surface to be different so the solution evaded me for a day or two.


Trip Log Page

The requirement is that a web page be sent to the browser and that a bunch of processing be done to manipulate HTML form content in the browser with no further server interaction. The data consists of rules for when to show and when to hide various form fields, as well as data to populate lists in the form conditionally on the selections from other lists. Imagine a web site where you pick the make of a car (Ford, Chevy, Toyota…) and then the next list contains only models from the selected car company (Bronco, Mustang, Corvette…). How would all of the models of all of the car companies be sent to the browser so that an extra query isn’t needed for the model field each time the make selection changes?

The company that I work for uses AJAX for another “product” but this seemed impractical since generating the web page takes a lot of processing time to get and parse data from a database. Doing that parsing each time a single field changes is not at all efficient. Plus, the other “product” usually has a few large lists on a page and my forms might have a hundred.


Option 1 was to use data attributes available in HTML5 and store all of the extra stuff that way. I opted against this because I would need to convert a two-level tree structure into some form of string that I could parse on the client. I hate writing code that parses or compares strings over and over again because I was schooled in writing very efficient code back when I worked on high speed search algorithms in the biotech field. In that field, writing one extra “if” test in a loop could make a product too slow to sell. This option would have made it easy to find the data content while looking at the visible tree of form fields, which would have been a nice side-effect.

Option 2 was to use the DOM by storing the data in div elements as if it were just more HTML content. The data elements would be hidden and would just be available to be read by the JavaScript when needed. This seemed like a pretty good idea because the data would be human readable during the development process. I rejected this option because I have no idea how a lot of extra hidden content would affect the page rendering. Like the first option, this option would have made it easy to find the data content while looking at the visible tree of form fields.

Option 3 was actually a bunch of failed ideas that never got past the first threshold of analysis. For instance, I could store XML data in an HTML5 data attribute or in one of those weird data elements that I have never used before. Or how about having a separate HTML select field for each variation of a list and then just displaying the one that has the appropriate data? That’s just another way to use the DOM and would add some work to hide and disable the unwanted “select” fields.

Option 4 was to generate some JavaScript code and pass it that way within a script element. It’s funny that this was not the first option since the trip log page does almost that exact thing. And now that I am writing this, I see that I didn’t do the best possible job on the trip log page because I generate, in PHP on the server, a JavaScript function that creates an array of trip information and calls functions to add data to the trip object. With this new Java project, I am just generating a global variable declaration and initializing it using literal data. I was just not as aware of how to declare and initialize a tree of complex data objects in JavaScript before now.

Above is a rough estimation of what the data will look like. This is taken from a working test case that doesn’t have a lot of content. But the idea of declaring the global variable and initializing it to literal objects, should be fairly clear. I manually added a lot of space and indentation to make it a little more readable in this example.

The final step in this development task is to write a JavaScript function that finds each of the form fields on the page and actually store a reference to the appropriate field object in this tree. Or maybe I’ll do it both ways and add a reference to the input field within this tree. That way, when a function gets called that a list selection is made, it will be easy to step through the form fields and change the field contents appropriate. It may not be obvious but the HTML form fields all have an “id” attribute that matches the “id” in this data structure. So making the cross reference won’t be hard at all.

Game Review: Unfair

March 14th, 2017


We backed Unfair by Good Games on Kickstarter having no idea what it would be like. But any game that shows a roller coaster on the box is my type of game!

I’ll get right to the point of this review: Unfair is a really fun game.

Now for some details and some pros and cons. The game is a card collecting game of sorts. But not like deck building games where you use some type of action to give yourself better cards in your hand. I haven’t played deck building games other than a few rounds of Dominion and it is nothing like that. But it’s not a board game either. it is a little bit like 7-Wonders and Sushi-Go in that you are trying to make sets of cards that go together in useful ways. but unlike those games, the mechanics of how you gets cards is very different.


Pirate Theme Cards

When we opened the box, we found that it was much bigger than needed. There is room for more sets of cards to be added later. Cards are in sets that each have a theme park “theme.” The different sets have a variety of strategy and difficulty. The sets have a bunch of different types of cards, and once the appropriate number of theme decks are picked (based on player count), cards from each deck are combined and shuffled into decks of the different card types. We discovered, hopefully correctly, that the theme decks that the cards came from means nothing during play. More on that later.

imageRobot Theme Cards

The types of cards are Park cards, Event cards, Blueprint cards, and a few others. There are lot of park cards, a lesser number of Event cards, and lesser still of the others. Each player gets the one Main gate card of the theme that they want (from one of the theme decks picked for the game). I won’t describe the entire game in this review; suffice to say that there are other things to do in the game than the few things I describe here. Players have a bit of game money to start with and anything thing that is built in the park and any employees, need to be paid for.

imageTypical Board and Player Setup

So onto the play. The starting player changes each round. There are typically 8 rounds to play. In order form the start player, each player takes an event card and saves it for a moment. Then one City card is drawn that has a global effect for the rest of this round. The City cards are just a way to throw in some random changes that affect all players. The players then in turn order play event cards until all players are done playing as many events as they want. This is an interesting part of the game because the event cards almost always have two options, one that affects the player that played it, and one that lets the player affect someone else. Simply put, there is an event card that lets you take half of someone else’s money if you want to play it that way. My family doesn’t do that sort of thing much.

Play continues with three or four sets of Park card plays. This part of the game is where you buy or build stuff in your park, or hire staff. All of the things you can build, including new attractions or upgrades, as well as staff you can hire, are in the form of Park cards. During these Park steps, you can also get new Event cards as well as Blueprint cards. Blueprint cards describe plans for your park that if you meet them, you get a bonus. Failing results is some points lost, so it’s not always wise to pick a really difficult Blueprint card.

imageNice Step Tracking Marker

After the three or four steps of dealing with park stuff, players essentially count guests in their part and add up bonuses to get more money. there are then some cleanup steps, like all players discarding cards if they have too many, and then the starting player changes and the next round is played.

My family has thoroughly enjoyed the game. Although we don’t play events that hurt other players (too often), the game doesn’t feel like group solitaire at all. The amusement park theme of the game fits with our like of amusement parks and the game is well designed and plays well enough that we stopped looking up instructions after the first one or two games. As a contrast, we still sometimes get out the instruction book for Firefly: The Game.

But there has to be something wrong with the game, right? Well, there are very few unclear instructions. In the setup, one step mentioned placing some City cards into a temporary pile. temporary? What does that even mean? it means that you are making a City card deck/pile and that you need to just start that deck/pile with some red city cards. There is a single other cards added into that deck/pile and then four blue City cards are placed on top of that. The word “temporary” didn’t make any sense because that deck or pile of cards isn’t temporary, it gets used in the game. Or maybe I just read it wrong.

What else is wrong? The instructions didn’t make it clear that the tiny theme icon in the lower right corner of each card is only there for you to sort the cards back into theme decks when the game is done. They don’t means anything during game play (although each player does get to pick which theme they use for their Main gate card, Loan card, and cheat-sheet card). It is only the large icons in the upper left of each card that have any meaning related to theme during the game (and other stuff depending on the icon).

Oh, and the different theme decks are not all cut on the same card cutting machine so some of the decks didn’t shuffle together easily.

Those are really moot points since we figured out that stuff during the first game and we were sure about all that by the end of the second. And there are many ways to shuffle a deck if needed.

imageTypical Employee Earning You Extra Income

The game is very pretty, well designed, and has a very usable board in relation to the space you need for laying out the cards that you play. The instructions are awesome compared to some games that I have. Play is competitive and very well paced. Siskel and Ebert would give it two thumbs up. If it were a hotel, it would be a five star hotel.

I must say, the Kickstarter page has a very good overview of the game and a link to a video. Ignore anything I said about game play and just check it out there:


Lifter #3, Maybe?

March 3rd, 2017

Here’s a picture of a lifter ideas I threw together. The cool part is that the ball is lifted almost straight up – this is a straight line approximation mechanism – without a typical elevator or chain lift.


The line where the ball goes up is drawn for analysis bit when done, there will be no vertical supports in that spot. The ball will be lifted straight up along that path.

I am also going to build a lot more track around this lift. The lift is interesting but I’ve spent too much time on mechanisms lately. I want to build some track so I can design in a solid state reversing mechanism.

It’s funny how the picture looks like a bicycle design. Those circles, just like the vertical line the ball lift follows, are just drawings in the simulation and won’t be in the final work.

Ball Lifter #2 Done!

March 3rd, 2017

Rolling Ball Lifter #2 is done. Here’s some video and pictures of the finished product. A quick search of this blog will yield other posts about the construction process.

This Rolling Ball Sculpture, Marble Run, or Kugelbahn, is mostly a mechanical ball lift. The track is minimal to keep from hiding the machinery. It took two years of very intermittent work to finish.



Hilarious Comment on Programming Stupidites Page

February 10th, 2017

I was reading a bunch of funny programming related stories on a page dedicated to programing stupidities, and came across this:

About four years ago, I was working on a project that, among other things, involved porting several million lines of code. While not technically real-time, the code needed to be reasonably fast. At one point, I found the following gem:

unsigned long reverse(unsigned long theWord)
    unsigned long result = 0;
    int i;
    for (i = 0; i < 32; ++i) {
        if (theWord & (unsigned long) pow(2.0, (double) i))
            result += (unsigned long) pow(2.0, (double) (31 – i));
    return result;

Obviously, the purpose was to reverse the bits in a word. Naturally, I called all of my colleagues over to see this, and we all marvelled[sic] at how someone would think that a conversion to floating-point, a function call, and a conversion to integer could be faster than one shift operation. To say nothing of the possibility of rounding errors completely screwing up the, um, algorithm.

Not wanting to leave an exercise for the reader, here’s the replacement:

unsigned long reverse(unsigned long theWord)
    unsigned long result = 0;
    int i;
    for (i = 0; i < 32; ++i) {
        if (theWord & (1 << i))
            result += 1 << (31 – i);
    return result;

I just wanted to point out the irony of it: I could say that “I marvelled[sic] at how someone would think that using an “if” test in this code is at all optimal.” But I won’t do that since my replacement might not be the pinnacle of performance either. I’m just pointing out that it’s funny to see someone write unoptimal code while condemning someone else’s unoptimal code. Here’s my better replacement, which may not be the best but is better than that person’s best:

unsigned long reverse(unsigned long theWord)
    unsigned long result = 0;
    int i;
    for (i = 31; i >= 0; ––i) {
         result |= ( theWord & 1) << i;
        theWord >>= 1;
    return result;

There is no “if” test in this. There seems to be one less math operation too, but I’m not sure if the loop counter is optimal. I could have left the loop as “for( i=0…” and then written slightly more complex code but I’m not sure if the more complex shifting counteracts a more efficient loop counter.

The lesson? Humility is important. Don’t condemn someone’s code unless you are 100% sure that yours is not also condemnable. Or at least admit that you are not sure yours is the best either.

Also, long values could be more than 32 bits in these modern times, so a bit count check at the beginning of the function, or a comment about assuming that “long” is 32 bits, would be appropriate in there.

New Linkage 3.4

January 13th, 2017

Linkage 3.4 is now available. I got rid of the Elements panel and button. You will now need to right click to insert elements into the mechanism.

There are other changes mentioned in the first section of the PDF documentation and in some previous blog posts.

Get it here.

RBS On/Off Switch Beta Test

December 31st, 2016

I made a makeshift part to hold the far end of the on/off switch pull rod. Here’s a few pictures:



Once I make the decorative part to hold the end of the rod, I’ll cut some threads in the end of the rod and screw on a steel ball. The switch pulls out to turn on the machine, making it easy to turn it off in a hurry.

Oh, and the base is going to be 3/4” round acrylic the size of that piece of wood.