Happy Pi Day 2016! (Galperin’s method)

This year for Pi Day, I have a demo of π’s appearance in bouncing balls, also known as Galperin‘s method due to a paper published in 2003 (Playing Pool with π (the Number π from a Billiard Point of View”, Regular and Chaotic Dynamics, V. 8, No 4, 2003). Here is a youtube video demonstrating the phenomenon:

Numberphile also produced a video about it, and the NY Times Blog also gave a different derivation.

Here’s a link discussing the math.

Basically, conservation of momentum and conservation of energy produce a system of equations that reduce down to stating that the the cosine of the number of collisions will change from positive to negative at an integer equal to [10^N*π], so the number of collisions will produce digits of π!

FoxCon2016 – abstract and references

Abstract: Building Webapps to Help You Build a Jeep

Historically, automotive plant operators received part numbers and VINs in printed formats to run production line (including sub-assembly lines, e.g., sequencing and kitting). These “broadcasts” or build sheets were temporarily attached to cars and quickly discarded upon vehicle completion. In contrast to the traditional printouts, this talk will introduce mobile webapps as an effective way to replace paper printouts and provide vital production information quickly and efficiently. Videos of an automotive plant assembly line will illustrate how operators receive and use information from both the original paper and new webapp formats.

References and External Links (videos, etc.):

Megafactories Ford F150
23:50 final assembly – JPH through 25:49

Four Principles Lean Management – Get Lean in 90 Seconds

Megafactories Dodge Challenger
Broadcast sheets

Kanban Pull Simple Demo
Shows kitting concept

Sonic Production at Lake Orion
Shows kitting carts on the assembly line

Digital Picking System By nbtprofessional

Chrysler Group LLC Belvidere Assembly Plant
at 3:39, sequenced parts in carts

FoxCon2016 – Schedule

Saturday January 30

Time        Speaker        Topic

08:00-09:00 Bob Ruple      Opening Comments

1 09:00-10:15 Bob Pierce    Automating the manufacturing process powered by VFP – A Case Study

10:15-10:30                Break

2 10:30-11:45 Kevin Cully    Xojo Development with focus on 64bit apps and Raspberry Pi

11:45-12:45 pm             Lunch at Park Inn Hotel

3 12:45-02:00 Mike Levy     On my way through the Actor Model, I met Microsoft Orleans

02:00-02:15                Break

4 02:15-03:30 Ondrej Balas   Custom Middlewate in ASP.NET 5

03:30-03:45               Break

5 03:45-05:00 Dave Bernard   The Driverless Car Revolution

Sunday January 31

Time         Speaker       Topic

09:00-09:15  Bob Ruple     Opening Comments

6 09:15-10:30  David Johnson Building Webapps to Help You Build a Jeep

10:30-10:45                Break

7 10:45-Noon   Phil Sherwood The Business of Software

  Noon-1:15 pm               Lunch at Park Inn Hotel

8 01:15-02:30  Brian   Koryzinski          The Secrets of LINQ: the modern day Houdini/Introduction to  DocumentDB

02:30-03:00                Closing Comments

3:00 pm                    Conference Dismisses


CodeMash 2016 Recap – Day 4

ASP.NET 5: How to Get Your Cheese Back

This talk didn’t do much for me except convince me that Microsoft continues to struggle for relevancy by reinventing the wheel. Rewriting ASP.NET from scratch only serves to frustrate everyone involved with it. Not worth my time.

A Developer’s Journey from Object Oriented to Functional Programming

This talk was basically an intro to F#, which I’ve played with before. I wish the author had spent more time describing the good parts of functional programming because he spent a lot of time just talking about object oriented design. I guess there’s no substitute for reading a good textbook functional programming, but I don’t think any minds were changed in the audience.

Having said that, it is definitely possible to go overboard with pure functions or LISP-style macros that later make the code unreadable and unmaintainable. It’s hard to find the sweet spot of a functional language that doesn’t require extra deployment dependencies, and it is still possible to debug it without going insane (haskell is too pure to debug without going insane), and it has enough popularity with other programmers and businesses to not destroy anyone’s career and/or code base.

Or you could just keep writing in a common language (like C# but with more lambdas and linq) and wait for this fad to pass, much like every attempt to popularize functional programming in the past.

Cure What Ails You With This Rx: An Intro To Reactive Extensions

I love the idea of Reactive Extensions. It’s async plus events as an enumerable, which should be a winning combination. If there’s one subject I should really spend more time doing and less time just thinking about, it is this one. I don’t like how some of the transformation functions have opaque internal state (distinct when changed), and it’s all really just for loops under the covers (i.e., iterators), and some of the operands cause every result to be loaded into memory simultaneously (sorting, order by), and some of it looks like a bad SQL optimizer, but the final result looks so clean and simple that I’m left convinced that I should do it anyway.

This talk was presented well, and I wish the author the best of luck with his crazy beehives and temperature measuring circuits, whatever they were.

Side note: maybe Stephen Cleary will finally update Nito Sockets to use Rx, and then I’ll be set for life. 🙂

Software Development Lessons Learned from Industrial Failures in the 1980s

This was the worst talk because it was entirely plagiarized from an NPR story about NUMMI. It didn’t even have programming. I think that NUMMI and the Toyota Production System are very important subjects in the automotive industry, but the author of this talk spent most of her time giving out prizes and stealing photos from websites and books without attribution. It was at this time that the downsides of CodeMash became apparent to me: there are no published proceedings, so you can’t cite work in the conference or hold anyone accountable for the content of their talks. The turnover in technology is so fast that trying to find the signal from the noise in the abstracts is going to be almost impossible anyway.

Oh well, I got plenty of value out of the other talks at CodeMash.

Great Galloping Cuckoos: Algorithms Faster than log(n)

I love to learn new algorithms, and this talk covered a few of them:

This talk made me realize that the majority of programmers in the room had not gotten a CS degree in college, and they did not know the basics of analyzing algorithms in operations performed or memory usage. It worries me to think about how much code must be written without coming close to the harder topics, theoretical or practical. (Heck, I’ve seen lots of buggy implicit FSMs and bad network socket code, so I shouldn’t be surprised.)

The author was trying to do something weird with his Raspberry Pi cluster and full text searches of billions of chemical formulas, which is exactly the kind of madness that CodeMash should encourage.

Cross-Platform Desktop Apps with Electron

Somehow I ended the conference back on node.js, but this time for desktop apps, not for servers. It does sound much easier to go cross platform with javascript and Chrome than with Xamarin. Too bad the GUI looks uniformly bland, much like Java desktop apps from 15 years ago. It still might be worth a shot anyway.

Closing Ceremony

Wow, this was not worthwhile at all. I should have gone home early because the odds of getting anything in the lottery were very bad (mostly because I didn’t know you had to put your ticket into the lottery bowl on Friday morning, but not sooner than that, or else you couldn’t win).

Final thoughts: I was pretty tired at the end, but I was glad that I went. It so rare for me to get to talk with any other programmers, let alone experts, and I easily got the value I’d hoped for out of informal discussions about SQL Broker and linq and async. Here’s to next year’s abstract submission going better.

CodeMash 2016 Recap – Day 3

CodeMash was great. I had a good time, and I learned about several important new programming languages and libraries. I’m writing up my notes here about the talks I attended to motivate myself to follow up on them.

The point of going to a conference like CodeMash is to keep learning new technologies. The relentless rate of change in programming can be overwhelming, but it is important to keep learning anyway, even when the latest fads appear to be reinventions of old ideas. (E.g., slack is just IRC on mobile devices, but it seems to be replacing email.) Anyway, to the talks from Day 3:

Node.js Crash Course

The bottom line I got from this was that when people talk about microservices, they probably mean node.js. It’s appealingly simple: service side javascript with isolated databases are fairly easy to develop and deploy, and the js single event loop structure encourages you to simplify your architecture. Best use: websockets, push notifications in real time.

Overall: an excellent talk about a popular subject.

Get Some REST –On Practical RESTful API Design

This talk was overly academic, being pedantic about how URLs should identify objects, not actions. Sure, if you buy into the whole REST architecture for everything, then it is a good idea to have some standards, but I didn’t learn any new practical parts of this subject.

Microservices – Beyond the Hype

I’m not sure that this talk really got beyond the hype, but it was a rare instance where the abstract perfectly matched the presentation, and I can’t really add much beyond what the original author wrote:

“Microservices are all the rage these days. Everyone is trying to sell their vision of SOA as “microservices”. You know it has reached the mainstream, because the backlash has started, too. When you boil it down, Microservices trade business domain complexity for infrastructure complexity. If you have a lot of business domains, this can help keep your software from turning into a big ball of mud. If you don’t, it’s just building complexity for complexity’s sake. In this talk, we will look at why and when you would want to build microservices, how you would do so, and what to avoid. We won’t fixate on the size of services, but on how to split things apart. After this talk, you will know if you should consider using microservices.”

My favorite part of this talk was the discussion of “The Eight Fallacies of Distributed Computing.

Async Everywhere!

I love Stephen Cleary’s work, and multi-threaded programming is one of my favorite areas to work in (regardless of language). The main point of this talk that driving the adoption of async is being driven by mobile first development (required by app stores) and by cloud first development (scalable server utilization). I couldn’t agree more with this message.

Having said that, async/await is just a compiler trick. It’s really powerful in some scenarios, and it’s helpful to have the compiler create a FSM automatically, but I don’t think it really makes the hard problems any easier. How would you use it to solve the dining philosopher’s problem or multiple producers multiple consumers problem? I think actors and message passing are required to tackle the hardest problems, and I hope that more programming languages add first class support for those techniques. Async/await is progress, but I’m still “await”ing the techniques which will want to make me forget about mutexes forever.

Anyway, I really loved this talk, and I hope Stephen Cleary keeps raising awareness of this topic.

A Deep Dive Into Modern Crypto

Wow, rarely does a presentation make me worry as much as this one did. It’s scary to list all of the broken techniques still in popular use: DES, 3DES, RC4, MD5, SHA1. I guess I’d heard most of the flaws before from Bruce Schneier’s blog and books, but I haven’t seen it all laid bare before. Especially worrisome is the thought of general purpose quantum computers in only 15 years, which could cut the strength of all crypto in half (256-bit ECC RSA down to 128-bit equivalent security) while providing no easy path forward except to massively increase key size.

It’s a thought-provoking and deeply worrying topic with implications for online commerce and national security.

Intelligently Extracting Data from PDFs

Well, what can you expect from a product pitch? I agree that PDFs lose a lot of information present in the original document (e.g., semantic organization between lines and pages), but I really doubt that OCR’ed text can really be as good as the originals.

The author is an expert on the subject matter, and if this is the most important problem facing your business, I guess I would agree with buying the product he was selling (despite the lack of comparison to other products).

Everything you wanted to know about writing async, high-concurrency HTTP applications in Java, but were afraid to ask

I felt this talk was overly specific to the author’s product and implementation of HTTP downloads, but he had a lot of entertaining pictures and metaphors. My favorite: CLOSE_WAIT socket errors are like hiding in a grocery store after the business has closed.


SQL Server Users Group Presentation (NWO-PASS)

I was pleased to present my talk, SQL Server Notifications In A Manufacturing Environment, again for the Northwest Ohio SQL PASS Chapter. I removed the C# code and replaced it with information relevant to a database administrator – what a Query Notification looks like inside SQL Server, how it affects other clients, etc. The revised slides are linked here Johnson Sep 2015 NWO-PASS-SQL Server Notifications. I also made some printed handouts with a summary of the talk – handouts for NWO-PASS Meeting.

The turnout was pretty good, and I got a lot of interesting questions. The most frequent question seems to be about how the Query Notification interacts with transactions, which I addressed in my slides. To summarize the answer: a QN becomes part of the transaction that fired it, so if that transaction rolls back, so does the QN. It’s not really much different than how the actions of an INSERT/ UPDATE/ DELETE database trigger become part of another transaction.

How old is kitting? Hint: very old.

Kitting is a type of materials feeding, which has been defined as (Oskar Carlsson et al., 2008):

In manufacturing systems, the practice of delivering components and subassemblies to the shop floor in predetermined quantities that are placed together in specific containers is generally known as “kitting”.


This idea is obviously much older. From doing some research, I found articles going back to 1990s describing kitting:
The idea of using kits seems to be old even by the article titled, “Kitting versus line stocking: A conceptual framework and a descriptive model” (Bozer and McGinnis, 1992).


One of the common complaints in the literature seems to be that kitting does not add value; it is just a form of buffering in the supply chain. A movement to make kitting leaner or remove it entirely seems to have been discussed in the mid 2000s (Vujosevic, 2008). But the problem at that time was that kitting was controlled by the inventory management team, which had no direct or real-time feedback from the production line. When a computerized Manufacturing Execution System (MES) was integrated into the kitting process, there was more value added.


Skipping ahead a few years and watching some online videos (Muir Omni Graphics, 2012, Youtube), kitting seems to have been integrated into much more diverse applications, e.g., printing stickers on a sheet of paper. Some people consider kitting to be part of 5S, a specific type of organization. Really, all of these ideas lead back to Japanese manufacturers in the 1980s, and by that I mean the Toyota lean manufacturing revolution.  But since Taiichi Ohno was inspired by the efficiency of American supermarkets in the 1950s, it’s fair to use the ideas of the Toyota Production System in modern processes (e.g., kitting).


So the origin of kitting is somewhere in either a 1950s shopping cart or a 1980s Toyota kit, but either way it’s coming from lean manufacturing. I think one of the best examples of this type of manufacturing was covered in the NPR story, “NUMMI”. I highly recommend it.

C# network sockets vs C++ Win32 IOCP

I spend a lot of time working on low level network protocols for proprietary hardware, and I normally use Win32 IOCP in C++. But a few projects must be implemented in C# for business reasons, and so I’ve spent a some time implementing nearly equivalent code in the .NET Framework. I figured it’s time to write up my favorite C# solutions so far.

Option 1: EVAP (event-based asynchronous pattern) with Nito Async Sockets. I had an excellent discussion with Stephen Cleary last year about asynchronous socket operations last year, and he convinced me to try his library. I’ve used it on several large projects now, and I really like it. It makes callbacks painless because Nito automatically marshalls into the original (i.e. GUI) thread.

Having said that, I can do the same thing in C++ with only a little more effort using IOCP. Using a background thread to call GetQueuedCompletionStatus and then using PostMessage to get to the GUI thread via a standard window message queue isn’t really that hard. I agree that it requires more code, which means more opportunities for errors, but it’s almost equivalent to what the the .NET Framework is doing, which requires more overhead. Some people have complained about slower speed for high throughput servers with the C# approach, and my experience supports the fact that even the best practices in C# will always be slower than the C++ options.

Option 2: await NetworkStream.ReadAsync and WriteAsync (only in .NET 4.5 or newer). I really like this solution for some specific network protocols. These methods allow all the benefits of simple async / await implementations without having to write a Task-based wrapper and handle a bunch of edge cases with Exceptions. If you can’t target .NET 4.5, then you’re stuck with writing wrappers for Socket.BeginReceive and Socket.BeginWrite and related methods. I’d go back to using EVAP before using the Begin/End pairs because it’s easy to leak kernel resources if you don’t catch all the Exceptions in EndReceive.

In C++, there isn’t anything like async / await, but you can fake it. If you read up on how async is implemented, it is just an automatically generated finite state machine applied to a transformed version of the original C# code. It’s a really powerful compiler trick, but I have to write FSMs anyway for my programs, so I incorporate the socket events into a larger FSM for the other state transitions in the program. I’ll grant that it’s a pain to handle both synchronous and asynchronous completions of WSARecv because it doubles the number of state transitions (must check for WSA_IO_PENDING, must free the OVERLAPPED structure only after the IO has posted on the IOCP, etc.). But it’s still doable. I’ve done worse. Don’t judge me! 😛

Option 3: Rxx (Extensions for Reactive Extensions) with
FromAsyncPattern. OK, I admit I haven’t actually tried this approach yet, and I’ve found a lot of skeptical discussion about it. It looks like it might work, but it’s as convoluted as anything else I’ve ever seen with EVAP or await based code. I’m not convinced that I can debug it yet (debugging is twice as hard as writing the code in the first place).

In conclusion: I’m sticking with EVAP until Stephen Cleary finds a way to make Rx with sockets tolerable or until I can install .NET 4.5 on more of my target machines at work.

Mandatory knowledge for programming interviews

(This is a “kids of today” complaint, so skip it unless you’re willing to hear complaints about job interviews.)

Public service announcement to job applicants: you must know what O(N) notation is for the code you write for both runtime operations and memory usage. I don’t care if you have a computer science degree or not, but you cannot write good implementations of algorithms if you don’t have a clue about it. Your “8 years of experience” on your resume is garbage if you can’t tell me why an O(N) array search is slower than an O(log N) search in almost every case. Also, you need to know how much memory you allocated, even if you don’t have to explicitly free it because the garbage collector cleaned up your mess.

No, the programming language doesn’t matter. No, your favorite library does not matter. No, there is no magic speedup to be found in Linq, inlined functions, lambda functions, or whatever other garbage you googled. Kids of today! Geez, get offa my lawn.

And while I’m at it, you must know the fundamental rule of multi-threaded programming in Windows: there is only one UI thread, it owns all UI objects, and you cannot access any UI objects from any other thread. Not ever! Your program will crash and burn with some cryptic errors the next time your callback in the thread pool tries to change the text displayed on screen. If you don’t know how to transition from background threads to the UI thread, that is your fault. No, you can’t get away with it because there was no compiler warning message. No, you can’t catch every multi-threading exception and silently discard them. No, the operating system will not help you to fix this error. No, your favorite programming language does not absolve you of this responsibility, even if it does have a billion ways to manage threads (C#, I’m looking at you).

Does nobody learn these concepts anymore in college? There are so many excellent textbooks available, and it is your responsibility as a professional programmer to read at least some of them. Reading “Sams Teach Yourself C# in 24 Hours” and writing garbage code for a few years does not make you a professional.

Please read some or all of these before applying to a job and sending me an 8 page resume with glowing but vacuous recommendations:

Foundations of Computer Science, which is the Stanford textbook used in programming and CS classes. Specifically, Ch 3. The Running Time of Programs.

Introduction to Algorithms, the MIT standard textbook. Please dear lord tell me you know what a hash function is and what it does. (Or map, dictionary, associative array, or whatever other name your favorite language is now using; the name doesn’t matter as long as you know when to use it.)

Cracking the Coding Interview: 150 Programming Questions. If you can’t write code without an IDE (i.e., by hand on a whiteboard or on paper), you’re not going to pass an interview.

The Art of Computer Programming by Don Knuth. Any volume. Really, anything written by Knuth. If you don’t know what a regex or Turing Machine is, you’ve got a lot of catching up to do. No, seeing “The Imitation Game” does not count.

Operating Systems: Design and Implementation by Tanenbaum et al. You must know what a mutex is and why you’d need to use it. No, you cannot google it during the interview. No, you cannot avoid learning about how the OS schedules and manages threads inside your process, even if you never explicitly control it.

Kids of today! Geez. Now please excuse me, I have to mow my lawn.