Meeting room occupancy project

We have an issue with staff not reserving meeting rooms. You know the situation, team High-Strung did reserve the room, but when they arrive they find that team Anarchist has squatted and are well into their arguments discussions. I don't include myself in the "we," by the way. I am happy to meet sitting on the floor with a big pad of paper between the participants. Anyway, it got me thinking about how technology can be used to exasperate this problem. For example, a display at the door to each meeting room that told folks if the room was reserved, for how much longer, who was using the room next, and lastly a list of reservations for today and tomorrow. Or, better yet, some ambient situation awareness device like Illumigami.

Before reinventing the wheel I did look around for a tool like this. What I found was a market of crazy, obese, gold plated implementations that actually cost money and often often lots of it. I don't object to making money from software, but not from something so simple as this, that is something that requires hardly more than a single web page. And so the development began.

The webapp is in its very early stages of development. I have just touched the surface of the Google Calendar API and its use within a HTML/JS page. At this point I am only concerned with the mechanics and so have made little attempt to make the UI useable. My goal with the UI is to have a tablet by each meeting room running a browser in "kiosk" mode and only showing the meeting room page. The page will show the events for a user who has authorized and selected a calendar.

If you want a side project and are interested in working on this with me to complete it the project is at https://github.com/andrewgilmartin/meeting-room-occupancy. A live version is running at http://andrewgilmartin.com/meetingroom/.

An unfortunate choice of title

There is a new dark ages set of wargame rules out called Blood Eagle. While I know that I play a game that represents an immoral, cruel, and bloody human activity, but to name a game after one of its more heinous acts were the warrior
would have their spine column exposed and then their ribs severed from the spine and pulled open (to resemble wings). Finally the lungs were exposed (and in some instances covered in salt) to complete the torture and lead to the death of the prisoner. (source)
is too much for me. I won't be playing that game.

DNS records for site split between Blogger and colocation server

This posting is mostly here to remind me how to configure the DNS records for a site where the www subdomain's content is hosted by Blogger and other subdomains are hosted by my colocation server.

DNS A record

Host Points To TTL
@ 111.222.333.444 1 hour

DNS CNAME records

Host Points To TTL
* @ 1 hour
www ghs.google.com 1 hour
X Y.googlehosted.com 1 hour

Where X and Y are given by Google/Blogger.

When I figure out the MX records I will update this page!

"Splinters"

In a previous posting I wrote about using "splinters" to represent the kind of deadfall you find in the woods and bogs. I spent more energy that I care to admit settling on a source for the splinters: block planer shavings, chainsaw chunks, drill bit waste, ... In the end I used the dried up branches one drives over time and again on the driveway. A hand full of this material will spread out to a square foot of forest floor. Just split off a chunk, flatten it a few times with a hammer, and then pull it apart.

Preparing two more tables for May's Great Swamp Wargamers game night

Preparing two more tables tops for May's Great Swamp Wargamers game night. The table tops are 4'×3' hardboard glued and nailed on a framework made from 2"×1" pine boards. The edges are blue-taped to keep them clean until the terraforming is done. The terraforming is a simple process of

  1. Glue down any surface features. In this case, I am using "splinters" to give the appearance of deadfall found in a bog or forest floor.
  2. Paint the whole surface with an earth brown.
  3. Paint the surface features as needed. In this case a "wet" brown.
The remaining surface features are added in reverse order. That is, if you want daisies then put down the yellow flowers first, then add the grass, and finally add the dirt. The goal is that the items added first will absorb most of the glue so that when you get to step 8 what is on top will fall off.
  1. Using a spray bottle coat the entire surface with watered-down white glue -- about 1 part glue to 3 parts water. Use a spray bottle rather than a brush as it will apply a more even coating. A brush tends to leave ridges.
  2. Using a sieve apply a pattern of grass. When using Woodland Scenics's fine turf add some coarse turf to the sieve to slow the casting of the fine turf. If you don't do this then you tend to get mounds of turf rather than an even application. 
  3. Using a sieve apply to the remaining (non-grass) areas dirt. I use dirt from my yard that has been baked for an hour at 400° F to kill off the microbes. 
  4. When dry, turn the tabletop upside down and tap to remove excess grass and dirt.
  5. Finish with several applications of watered-down white glue or spray clear coat to fix the grass and dirt and make it resilient to playing on. I use a pressurized hand sprayer that is normally used for spraying insecticide. It can apply an even coat of the glue. The tabletop is noticeably wet after each spraying, but I do this outside on a warm day so that the glue drys before penetrating the hardboard.

Java 8 is not Java

Java 8 is not Java. Java 8 is a good tool. Java's shift towards being a functional language is unstoppable. Java, however, as a principled, strongly typed, object-oriented, imperative programing language is no more. I have heard the argument that as a developer I can stick with Java 7 syntax using -source 7, but this is not practical. Libraries will evolve to use use functional practices. Old bugs will only be fixed in these evolved libraries. As functional practices becomes ever more rooted in the libraries their use from Java 7's syntax will become ever more cumbersome and perhaps impossible. If you want to continue developing in Java then you and your team will have to evolve with it.

So these days I am thinking ever more about what language to move to. I think the perspective of my employer would be to remain with a language targeting the JVM. I haven't asked, but I know well enough its conservative approach to solutions. The software architect in me would like to pick a language that is more aligned with a fail fast approach to service runtime and its corollary of needing to start fast.

Lots of folks at this week's O'Reilly Software Architecture conference in NYC are favoring Go (commonly called "golang" to make the conversation clearer and searchable). That it compiles to a binary (and even a statically linked binary) for direct execution on the host is a significant boost to start fast. Starting slow would be your architect's fault: Too much in-process preparation and not enough just in time initialization or not enough externalization of functionality into a service. I will look at Go and its libraries. I do worry that is the new black, like Ruby was several years ago.

Its handheld not handsheld, people.

Finally, a sane design for a handheld device! The Kindle Oasis. Hopefully it rotates for lefties and for righties when writing notes on paper.

2D6 percentage dice

Sometime ago I found online a discussion about using D6 dice to simulate percentage dice. Unfortunately, I did not keep a link to the discussion. Anyway, I wanted to add my 2 cents and so here it is. You can use 2 D6 to compute a value over the 1 to 100 percentage range. The two dice, A and B, are treated as base 6 1st and 2nd place values. The range is 0 to 35, ie, ( A - 1 ) * 6 + ( B - 1 ), and so the percentage step is roughly 2.7%. This seems like enough granularity for most games using percentage dice. The lookup table is

123456
114791215
2182124262932
3353841434649
4525558606366
5697275778083
68689929497100
Source code.