Thursday, June 23, 2016

2016-06-23 Thursday - Code Is Not Design

Rebecca Wirfs-Brock recently posted an interesting discussion, entitled "What's going on here?"

The posting raises quite a few questions about the viability of maintaining design documentation, issues and concerns related to maintaining the synch between code and design artifacts, and the use [or abuse] of diagramming efforts.

Here's a comment I posted:

An interesting discussion you've raised here.

When approaching a new large code base, I tend to favor a combination approach of static analysis / model generation tools (deriving the meta view information from code as much as possible) - and adding a lightweight layer of additional (higher-level) architecture and business-process views.

I have encountered numerous engineers (and quite a few architects) who declare that the code is the design - and that it is the end-all, be-all of documentation.

In my experience, those folks are usually not working at the scale of software complexity that my client engagements entail. Their approach doesn't scale well when you need to communicate information to non-engineering team members, and would be very problematic if you need to share design considerations with outside 3rd parties (i.e. concerns related to code-based documentation resulting in excessive scope of disclosure, IP disclosure risks, security exposure risks, etc.). It also makes it exceptionally more difficult to rapidly on-board new engineers and architects.

I can cite one illustrative experience with a past client that illustrates the pitfalls of those who put their trust in the code explicitly as a means of deriving the "true" design/architecture of the system. In a system of ~1M lines of code, that had grown over almost a decade of layering on additional functionality, perhaps 30-40% of the code was no longer used, sat in "dead" areas of the system - and was manifestly misleading about what the system did - and how it did it. Repeatedly, in design review, after design review - team leads would correct my stated assumptions about what the system did in a particular case with the refrain "Oh. That code isn't used anymore". Frustrating doesn't even begin to describe the experience of trying to rely on the code to develop an understanding of THAT system. A set of high-level architecture diagrams - supported with high-level business process flows were exactly what the doctor ordered in that particular situation. 

I should also clarify that in my particular example cited above that there was zero support to clean-up  / prune the dead code from the system - given the intense competitive market pressures, speed of execution required by the business, cost constraints of resource limitations, and other higher business priorities.

Friday, June 03, 2016

2016-06-03 Friday - Technical Proofer (TP) & Technical Development Editor (TDE)

Based on the quality of my previous contributions as a Manuscript Reviewer, I have been Invited by Manning Publications to participate in the Technical Proofer and Technical Development Editor programs. Looking forward to continuing to contributing to the process of bringing great technical books to the market.

2016-06-02 Thursday - Go 1.7 beta

Go 1.7 Beta released this week

Thursday, June 02, 2016

2016-06-02 Thursday - WS02 Refresh

Doing a refresh on my knowledge of the WS02 technology stack and product offerings...will continue to publish my notes here:

It has been a few years since I last looked at the WS02 product offerings (previously evaluated their ESB and Registry/Repository for a client's Enterprise SOA initiative).

Here are links to my findings and JIRA issues submitted during my 2008 evaluation of WS02...

It was around this time that I also evaluated the MuleSoft Registry/Repository offering (Galaxy)

Wednesday, May 25, 2016

2016-05-25 Wednesday - Fixing my GDB (and Eclipse CDT Debugging capability)

I previously had my Windows 10 development machine configured to successfully develop and debug C++ programs from within Mars Eclipse - leveraging CDT and Cygwin.

I recently made some changes to my system configuration - and broke my Cygwin GDB debugging functionality.

After spending a few hours exploring the problem, I thought sharing this post might help someone else minimize their cycle time if they have a similar problem...

The first clue was in a Windows Command Prompt, I got the following error when trying to launch GDB:
"ImportError: No module named site"
Also, in Eclipse, when attempting to launch the debugger for a C++ program, I encountered this error message:
 "Could not determine DGB version using command gdb --version"
I  read several forum postings - and these were the relevant takeaways:
Now, in my environment, I had setup Python 2.7.11 and Python 3.5.1 - and since GDB relies on Python 2.7 - I thought, "ah, perhaps one of my library installs / updates has resulted in a broken dependency situation". So, I uninstalled and re-installed them both. 
No joy.
I then uninstalled and re-installed Cygwin.
No joy.
Then I tried alternating where PYTHONHOME and PYTHONPATH 2.7 vs 3.5
No joy.
Finally, I removed the System Variables for PYTHONHOME and PYTHONPATH.
When in the Cygwin bash shell (or Windows Command Prompt window) - the Windows System Variables for PYTHONHOME and PYTHONPATH were conflicting with the Python 2.7 version that is bundled with Cygwin - and a dependency for GDB.

So I then just added the dir for Python 3.5 directly to the PATH environment variable. 

Problem solved.

Sunday, May 22, 2016

2016-05-22 Sunday - Open Broadcaster Software

An interesting bit of Open Source software - possibly a good tool for recording instructor-led training material?

OBS Studio (formerly known as OBS Multiplatform) is a complete rewrite of the original OBS from the ground up, with the main goals being multiplatform support, a more thorough feature set, and a much more powerful API. While still in its early stages, releases are currently available for Windows, Mac and Linux.
OBS Studio will eventually support many of the advanced requested features not present in the original OBS, such as multiple stream outputs and scene previewing, the latter of which is now available in the current release.

Open Broadcaster Software is free and open source software for video recording and live streaming. Supported features include:
  • Encoding using H264 (x264) and AAC.
  • Support for Intel Quick Sync Video (QSV) and NVENC.
  • Unlimited number of scenes and sources.
  • Live RTMP streaming to Twitch, YouTube, DailyMotion, Hitbox and more.
  • File output to MP4 or FLV.
  • GPU-based game capture for high performance game streaming.
  • DirectShow capture device support (webcams, capture cards, etc).
  • Windows 8 high speed monitor capture support.
  • Bilinear or lanczos3 resampling.

2016-05-22 Sunday - Exploring Lattice Graphs in R

I'm exploring the Lattice Graphs library in R today...

Some background reading:

Wednesday, May 18, 2016

2016-05-18 Wednesday - My Protocol for Learning New Technologies

A former colleague pinged me today, asking how do I go about learning new's the slightly edited version of the response that I wrote: 

Depending on the specific technology, and whether you are going for depth or breadth, might well change how I would answer that question. Here's my general approach though: 

1) I usually first read the formal specification, the relevant RFCs, standards

2) I often assemble a Twitter List of the noteworthy companies and individuals that are contributing or are the thought leaders in that given technology 

3) I create a github project as my laboratory for experimenting with the technology (showing your work, and making it visible helps to motivate me to keep plugging away). Within the github project - usually using a naming convention of "Lab.xxxxxx..." I create a README file with links to references, tutorials, interesting articles, blogs, etc.  

4) I usually attend 1-2 conferences per year ( is one of my favorites - it gives me the greatest opportunity to hear about a wide diversity of technologies - from a globally represented attendee roster. in St. Louis is another good conf. for leading edge technology trends that may not be widely adopted yet - but are going to be very popular in 3-5 years - but some sessions can be a bit esoteric. 

5) I spend quite a bit of money every year buying books - and not just on the specific thing I'm learning - but on peripheral areas as well. My Kindle probably has over 100+ technical books on it - as well as whitepapers, references, etc. 

6) If a technology has a special niche in the area of algorithms, I usually read 4-6 academic research papers on the relevant current research for that area. 

7) I've found membership in the IEEE and ACM to be very useful to stay abreast of leading edge research and trends.  

8) I'm constantly downloading and experimenting with new Open Source software  

9) I read a lot of source code for Open Source software projects 

10) I usually attend 3-5 tech meetups in the Seattle area per month  

11) I have a few small personal software development projects that I continue to nurture privately, as a test bed for my experimentation with new technologies - for example, one is a code generation tool that can be pointed at a database schema and it will generate all of the SQL stored procedures, base object classes, etc. for over a dozen languages (~650K+ lines of code generated in less than 90 seconds)

12) Using Coding Exercises, for example, 99 Scala Problems