Adding Services to FlowSharp


I’ve been reworking FlowSharp into a “Service Oriented Architecture.”  As the above overview diagram illustrates, there are now three major service blocks:

  1. Docking services – The toolbar and property grid are now dockable, and canvases are treated as dockable documents, so you can have multiple documents in one application.
  2. The various controllers and functions of FlowSharp have been converted to services (see below)
  3. As a result, I’ve been able to add the “shapes as code” in the FlowSharpCode project that I wrote about earlier.  The beauty of this is, adding the FlowSharpCode services “simply” requires defining the services in modules.xml and the additional shapes in plugins.txt.

The architecture relies on The Clifton Method discussed previously.

Here’s a full blown gloriosky architecture diagram:


Find FlowSharp on GitHub!

At the time of this writing, there’s still a few critical bugs to update the Code Project article, but I hope to get them resolved soon!

V.A.P.O.R.ware – Visual Assisted Programming / Organizational Representation


Actually the name of the application is FlowSharpCode, but VAPORware sounds more fun!

Article here.


This is purely a concept piece.  It’s intended to either inspire or cause an eye rolling “what a crazy idea” reaction.  It is crazy, in my opinion, but in a sense it’s crazy because in my limited use cases so far, it works.  And because it’s so crazy, the majority of this article will not be written, it’ll be screenshots of the application in use. The problem with this approach is that it ends up sort of looking like a PowerPoint presentation, which is hard to avoid!

Why I Closed my PayPal Account


It’s quite simple.  In whatever ways that I can, I refuse to support people / businesses that support Donald Trump.

On October 15, 2016, Thiel announced a $1.25 million donation in support of Donald Trump’s Presidential campaign.

And quite frankly, if you want to do something to truly protest the nomination of Trump, I suggest we make a collective and concerted effort to identify and withdraw our support from the businesses and politicians that support Trump, where it hurts them the most – their wallet.

What Skills has Working in Tech Actually Given You?


In TechChrunch, the author writes:

Do you work in software? Do you have more than a decade of experience? You do? I’m sorry to hear that.  That means there’s a strong possibility that much of what you know is already obsolete.

Certainly much of what I have learned in the technical realm is certainly obsolete. I haven’t coded in 6502, Z80, 8086, Cobol, Fortran, Pascal, C, or C++ in ages.

But much of what I’ve learned about writing documentation, communication, debugging, creating flexible architectures, making accurate time estimates, designing intuitive UI’s, and getting skilled at teaching others, those are skills that never become obsolete.

The most important skill, one that truly doesn’t get old, is the meta-skill of constantly learning new things … and that meta-skill can rust and wither away, too, if it languishes unused.

Agreed, but the skill of learning new things isn’t the only meta-skill.

Static Typing and Broken Software


Granted, I borrowed that image from here, where the author views people like me as “unhappy dogmatists who can’t bring themselves to leave the kiddie pool of strong typing.”  Yes, I am rather dogmatic about strong typing!  But to the point…

David R. Maclver wrote an interesting post “Static typing will not save us from broken software.


davidMacIver = HesGotSomeGoodPoints()
davidMacIver = ButHesAlsoWrong()

Make it more expensive to write broken software – write in a non-static typed language
Make it cheaper to write correct software – write in a static typed language

But because these bugs [those that happen in production] are relatively minor

Now that’s where I totally disagree. If a true static typed language had been used, or had been used properly (ie, semantically, which is the next level of strong typing), this case in point[^]

due to ground-based computer software which produced output in non-SI units of pound-seconds (lbf s) instead of the SI units of newton-seconds (N s) specified in the contract between NASA and Lockheed.

would not have cost the taxpayers $327.6 million

Dealing with type errors in a non-static language is not cheaper. I spend time writing unit tests and verifying the runtime by hand to ensure type correctness that I do NOT spend with static typed languages. Running an app only to discover I’m using a duck-typed variable before I’ve assigned something to it is a time waster. The benefits of static typing far outweigh the benefits of non-static typed languages, and I’m sorry David, that’s not opinion, but measurable fact.

Can duck-typed languages save time? Sure! I can replace a class instance that interfaces with hardware with a class instance that mocks the hardware as simply as the code above. I can add fields to a class outside of the class simply by making an assignment.

All of which are cheats and laziness, break the “code as documentation” fallback, and make duck-typed code more error prone and difficult to maintain.

Most existing static type systems also come with a build time cost that makes testing in general more expensive.

And the unit tests that duck-typed languages require often (in my experience with a small Ruby on Rails web app) take longer to run than compiling much more complex web sites.