Dave Mielke

Email: dave@mielke.cc / Phone: (613) 726-0014


I am able to objectively think through all aspects of a complex programming project, and to tackle it in a way which minimizes disruption to the existing environment. I have undertaken such tasks with determination - knowing that the goal could be achieved. I have gained experience, especially at the systems level, during the past many years (since the mid-'70s) which has been both broad and deep.

An example which illustrates all of the above is how I played an instrumental role in maintaining the availability and stability of the software development environment of BNR/Nortel's most significant revenue-generating division, the DMS family of products, as I oversaw and actively participated in its migration through a series of incompatible host platforms while managing to preserve a large amount of its original code base. It began on VM/CMS, was first migrated to VM/ESA, was then migrated to Unix (HP-UX, Solaris), and was finally migrated to Linux.

In addition to my extensive experience with Linux, Solaris, HP-UX, and VP/CMS, I also have some experience with AIX, MTS, UTS, and a couple of NAS server platforms (EMC, NetApp), and have now begun to work with Android. I adapt well to new and changing requirements.

What I enjoy the most is to tackle challenging programming projects which deliver real value to others. I like to both design and code, and work best when I have a fair degree of freedom in choosing how to best achieve the desired goal. I like to gain a full understanding of the whole picture, and strive to advocate for changes being made in the correct places even if those places are outside my official areas of responsibility.


Volunteer, B2G User Interface Development2015-2015
The National Braille Press

The B2G (Braille to Go) is a new, Android-based, braille tablet being developed by The National Braille Press. I was asked to design and implement a user interface for it.

Designed a comprehensive set of screen navigation actions, as well as ways to clearly render each type of screen element in both braille and speech. Designed a table-based system to define the key bindings for the screen navigation actions, and the braille representations for characters. Designed a locale-based scheme for selecting which set of braille character representations to use. Designed a way for braille to work in Android's recovery mode. Implemented all of the above, and wrote the document.

The document for the B2G's user interface can be found at [http://brltty.app/archive/B2G/UserInterface.html].

Volunteer, Project Administrator and Primary Contributor - BRLTTY2000-PRESENT
Free / Open Source Software

BRLTTY is a project which enables blind people to use braille devices on their computers. In addition to being freely downloadable and easily buildable by anyone, we also provide prebuilt Windows and DOS binaries, as well as an Android package, and several Linux distributions (e.g. Debian, Fedora, Ubuntu) include it. It can be found at [http://brltty.app/].

Designed and Implemented 16 braille device drivers, and oversaw the development of 10 more. Maintain and upgrade all 36 (10 were already written when I took over) on an on-going basis as needs require. This work has involved building relationships with manufacturers in order to gain access to their design-level documentation. Due to the high cost of these devices, it has also involved borrowing them from manufacturers, vendors, and owners.

Restructured the code from being fairly Linux-specific to being mostly portable with small platform-specific stubs. Additional flavours of Unix, as well as Android, Windows, and DOS, are now supported.

Added support for USB and Bluetooth I/O (only serial was formerly supported). Implemented a portable layer for all three so that the drivers could be fully portable. Then implemented a generic I/O layer so that the drivers now only need to provide I/O requirements to the core at startup.

Moved as much common functionality as possible from the drivers into the core.

Designed and implemented a table-driven, user-editable capability for mapping braille device key combinations to screen navigation functions. Formerly, the bindings were hard-coded within the drivers, and users had to accept whatever we decided.

Added a fair amount of support for screen navigation by speech. This required not only introducing many new speech navigation functions but also implementing speech drivers for several text-to-speech engines.

Software Architect, PLS/Protel Transition to GENBAND2010-2012
GENBAND, Inc.Ottawa, Canada

Supervised and actively participated in the transition of the PLS and Protel software from Nortel to GENBAND. Also helped other groups transition their environments, as well as made many suggestions to GENBAND IT regarding how they could safely grow their infrastructure and make it more consistent and easy to maintain. GENBAND grew from about 500 to about 2500 when it acquired our Nortel Business Unit.

Added support for JIRA reasons to PLS. GENBAND wanted to use JIRA rather than ClearQuality (which Nortel was using).

Implemented software for managing NAS mirrors and snapshots, as well as the locking and unlocking of databases, for use with both PLS and ClearCase. This enabled reliable backups of the data to be taken. This software is highly configurable. It is also largely generic, with only small bits of targeted code for NAS type and for database type.

Implemented a tool to monitor ClearCase view storage, and to automatically send alerts to users and to administrators as needed.

Ensured that the PLS and Protel software ran essentially flawlessly. Ensured that a company in Turkey was well-equipped to take over PLS administration so that that work could be out-sourced. Eliminated my own job.

Software Architect, PLS/Protel Sustaining2005-2010
Nortel Networks, Inc.Ottawa, Canada

Not much inspirational was going on. Nortel was more interested, at this point, in running as low risk an operation as possible so that it would be divestiture-ready. We were to ensure that everything kept running smoothly, to make tweaks here and there as needed, and to make any needed changes in order to accommodate infrastructure changes. I was retained until our Business Unit was divested (to GENBAND) as I was the only remaining subject matter expert for the PLS and Protel software.

Software Architect, PLS Infrastructure Optimization2000-2005
Nortel Networks, Inc.Ottawa, Canada

Designed and implemented a way for a PLS database to contain revision-controlled versions of code which was not yet build-ready. This was necessary in order to better support code inspections very early in a product's life cycle because PLS is not that good at parallel development. Formerly, users tended to not store their code in PLS until it was build-ready, and would pass it around for inspection via email, FTP, etc. This was not only extremely error prone but also violated data access security policies and enforcements.

Designed and implemented the capability for the web PLS server to impose database access constraints so that export control regulations and license agreements could be enforced. This capability could easily have been then added to the PLS database engine itself, though that was never done due to the low risk approach that Nortel had begun to ever-increasingly take. This capability resolved the problem of external personnel being on-site. It also made it much easier for PLS administrators to audit these rules, and to keep them up-to-date, than was possible for the old, cryptic, network firewall rules which PLS administrators did not have direct access to and which network administrators could not directly audit.

Designed and implemented a tool to properly manage NAS mirrors and snapshots, as well as the locking and unlocking of PLS databases, so that consistent checkpoints could be made from which reliable backups could be taken. Formerly, Unix PLS database storage had inherent reliability as persistent mirrors were being used. That valuable disk space had to be freed up, in favour of snapshot (or checkpoint) volumes, as Nortel began to experience its financial troubles.

Designed and implemented a new inter-site software distribution system for all of the PLS- and Protel-related software. Nortel no longer wanted to pay for the license for the older third-party tool that we had been using.

Took part in a major, company-wide audit which endeavoured to assign a formal owner to every single piece of code. This became especially necessary as Nortel was laying off so many people. It involved adding hooks into the PLS database engine in order to track who was looking at and/or updating what.

Software Architect, PLS/Protel Migration to Linux1998-2000
Nortel Networks, Inc.Ottawa, Canada

Anticipated the eventual migration from relatively expensive/slow Unix workstations to relatively cheap/fast Linux desktops. Advocated, along with individuals in other areas, for this change, and proceeded to lead and actively participate in the needed work in our area in spite of general company opposition to it due to a general distrust of free software. We were ready by the time IT decided to accommodate Linux, and our users were among the first to make the switch.

Enhanced and retrofitted PLS- and Protel/Unix-related software such that it could also run on Linux. The majority of this work involved dealing with assumptions in the code regarding integer sizes, pointer sizes, and data endianism. Since Linux systems typically run on Intel-like hardware, it was our first little endian platform. This involved some database redesign as well as reworking and judiciously testing every single low-level database access within the code.

Software Architect, PLS Usability Enhancements1996-1998
Nortel Networks, Inc.Ottawa, Canada

Designed and implemented an improved command line interface for PLS. Introduced features like command line editing, command line history, and command output redirection. Formerly, all users could do was fully enter each and every individual PLS command line. If an error was made, the whole command line had to be reentered. If a command was needed multiple times, it had to be entered that many times. Also, there formerly was not an easy way to capture the output of a PLS command in a file for future analysis.

Designed and implemented an object-oriented interface to the PLS database engine in Java. This fully exposed, in a straightforward and unambiguous way, all of PLS's user-facing functionality. Formerly, users needed to do a lot of reading and digest a lot of information in order to attempt to fully grasp all of its features and intricacies.

Software Architect, PLS Web Server Development1994-1996
Bell-Northern Research, Ltd. (BNR)Ottawa, Canada

Designed and implemented a web server which provided read-only access to the PLS databases. This work was done in spite of a fair number of doubters as the World Wide Web was still in its infancy at that time and its vast possibilities were largely unrecognized. One unforeseen but significant benefit of this work was that it made it much easier for marketing and other customer-facing personnel to access product documentation. Another one was that it was a major factor in BNR passing a quality audit since it gave all employees immediate and easy access to revision-controlled quality control documentation.

Designed and implemented a VM/CMS server which enabled the web PLS server to query project management data that was still residing on the IBM mainframes. This enabled that data to be migrated on its own, independent schedule.

Designed and implemented a tool to convert documents which were written in IBM's Script/VS and Script/GML languages into plain text, Post Script, or HTML. Applied this tool to all such documents in order to create Unix-friendly versions of them. This removed our IBM mainframe dependence for viewing older documents.

Software Architect, PLS/Protel Migration to Unix (HP-UX, Solaris)1992-1994
Bell-Northern Research, Ltd. (BNR)Ottawa, Canada

Designed and implemented the Protel/Unix run-time environment. This was the first major step required so that the large code base already written in Protel/370 could be reused on Unix platforms. Implemented a single version which, with a minimal amount of conditional compilation, runs on all flavours of Unix. This approach made accommodating each new flavour of Unix relatively easy to do.

Designed and implemented a portable view of operating system and network functionality, along with VM/CMS- and Unix-specific implementations. Converted all PLS- and Protel-related software to use this paradigm. This enabled the single implementation our existing source, without any further modifications, to run on both IBM mainframes and Unix systems. Major code reuse! We were not only able to reuse our existing code but also could proceed with the confidence that no new problems were being introduced at that level.

Designed and implemented a single-threaded, event-driven server for inter-site file transfer using our portable operating system interface. This enabled PLS sites to be on both IBM mainframes and Unix systems. It also enabled us to do things better than IBM's RSCS file transfer capability did them. One should always be wiser the second time around.

Had to reimplement all of the command scripts because REXX, VM/CMS's primary command scripting language, was not available on Unix at that time. Chose TCL as our primary Unix scripting language. Developed a large set of shared TCL code as we progressed so that each successive script became increasingly easier to write due to code reuse from the earlier work.

Software Architect, PLS/Protel Migration to VM/XA and VM/ESA1991-1992
Bell-Northern Research, Ltd. (BNR)Ottawa, Canada

Enhanced all PLS- and Protel-related software so that it would also run on IBM's new VM/XA and VM/ESA operating systems. Chose the approach of single executables which would run on all three platforms (the third one being the older VM/CMS operating system) while others were choosing separate implementations per platform.

Team Leader, PLS Operations1986-1991
Bell-Northern Research, Ltd. (BNR)Ottawa, Canada

Trained PLS database administrators at Development Partner and Joint Venture sites to set up their development environments, to monitor the usage and performance of their development environments, and to resolve known problems. Also helped them debug and work out ways to resolve new problems. Each of these sites needed to be as self-reliant as possible due to the major time zone differences as well as to the usually poor international connectivity between them and us. Connectivity was typically achieved via low baud rate serial links passing through multiple providers in multiple countries, not via anything resembling the internet, back then.

Designed and implemented the SOS system image generator. Originally, the images were generated by running a special SOS command on an emulator. This change reduced image generation time from a few hours down to several minutes. The image generator creates the entire module table structure for a full system image (just as the system-resident module loader would), supports multiple module (input) formats, supports multiple image (output) formats, and supports multiple target operating systems.

Designed and implemented a telnet-like server for the VM/CMS operating system. It was a single-threaded, event-driven, server which utilized K-Net servers for TCP/IP, and VM/CMS's VTAM capability for virtual terminals. It provided network login capability to the mainframe-resident development environment. Facilities like ssh and telnet, which we take for granted these days, did not exist, at least on IBM operating systems, in those days.

Designed and implemented an MTA (Message Transfer Agent) which linked Cocos (BNR's proprietary electronic mail system) with the notes capability of the VM/CMS operating system. This finally enabled the equivalent of live email communication (something we take for granted today) between BNR (including Northern Telecom) and its Development Partners and Joint Ventures.

Designed and implemented a server which enforced project management rules so that a given release of a given product could only be modified in accordance with what was allowed depending on where it was in its life cycle. Formerly, any designer could update any code he had access to at any time for any reason.

Took over support of the Protel/370 run-time environment. Protel/370 was a proprietary language which was used to implement many key components of the PLS, Protel/DMS, and Protel/370 tool sets.

Continued to maintain the NT40 emulator (see 1980-1982: Software Designer, SOS Module Loader).

Team Leader, PLS Infrastructure Development1984-1986
Bell-Northern Research, Ltd. (BNR)Ottawa, Canada

Was sent to England to set up the entire DMS Development Environment on the IBM mainframe which had just been installed at BNR's brand new Maidenhead site.

Designed and implemented a way to take good backups of PLS databases. Regular system backups were inadequate because the databases could be modified while those backups were taken.

Designed and implemented a way for a PLS database to exist at more than one site, and for transactions to be submitted for processing at any site. This was necessary so that designers could work locally at their own sites, rather than remotely at the single central site, since inter-city communication links in those days tended to be slow and/or unreliable. It also enabled BNR to distribute its ever-increasing central designer load across several local mainframes. In addition, it was instrumental in enabling BNR to begin to work with Development Partners and Joint Ventures.

Enhanced the PLS database engine to work with the subcommand capability of the VM/CMS operating system. This enabled the scripting of PLS commands together with host operating system commands, which enabled the development of powerful PLS command macros which could be used by both users and product builders to implement high-level functionality.

Designed and implemented PLS's initial security model. This involved introducing user groups, restricted access to source, controls for what could be updated from which site, etc.

Introduced and maintained a dedicated RSCS network for transferring PLS transactions between sites. RSCS was IBM's facility for transferring files between computers. Using our own RSCS network meant that PLS transactions would not have to wait behind other inter-site traffic. It also enabled us to use different practices than the corporate network like transferring more than one file at the same time, prioritizing certain types of files, etc.

Continued to maintain the SOS system module loader (see 1980-1982: Software Designer, SOS Module Loader).

Continued to maintain the NT40 emulator (see 1980-1982: Software Designer, SOS Module Loader).

Software Designer, DMS Development Environment1982-1984
Bell-Northern Research, Ltd. (BNR)Ottawa, Canada

Designed and implemented a generic base environment on top of which VM/CMS servers could be easily implemented. The base software took care of environment setup based on easy-to-write server-specific data files, activity logging, event scheduling, function invocation authorization, etc. It supported asynchronous requests (via the SMSG and MSGNOH commands), as well as synchronous requests (via both the VMCF and IUCV mechanisms provided by the operating system), so that derived servers could easily be utilized from almost any client environment. Each function was implemented by its own executable, which could be either an EXEC (script) or a MODULE (binary).

Designed and implemented a VM/CMS server which provided general users with controlled access to privileged operating system capabilities. This enabled users to do many things for themselves which formerly required bureaucratic procedures and personal assistance by IT staff.

Designed and implemented a VM/CMS server which governed access to BNR's then seriously overloaded IBM mainframes. This enabled many simultaneous users to get their work done slowly as opposed to lots of simultaneous users not getting any work done at all.

Designed and implemented a VM/CMS server for maintaining PLS databases, and for processing PLS transactions. Formerly, users would submit transaction requests by form for overnight processing by an administrator who had write access to the databases.

Continued to maintain the SOS system module loader (see 1980-1982: Software Designer, SOS Module Loader).

Continued to maintain the NT40 emulator (see 1980-1982: Software Designer, SOS Module Loader).

Software Designer, SOS Module Loader1980-1982
Bell-Northern Research, Ltd. (BNR)Ottawa, Canada

Designed and implemented the SOS system module loader. The loader keeps track of which versions of which modules comprise the currently running system, maintains code location data for system monitoring and debugging tools, enforces inter-module dependencies, ensures that the system components automatically initialize in the correct order, and facilitates safe module replacement on a live system. It makes it relatively easy not only for designers to test their changes but also for customer system upgrades.

Maintained and enhanced the NT40 emulator. The emulator was implemented in IBM 370 Assembly Language, ran on an IBM mainframe running VM/CMS, and emulated the NT40 instruction set. Emulations of new machine instructions were added as they were developed. Emulations of existing machine instructions were made more efficient.

Software Designer, SL1 Development Tools1978-1980
Bell-Northern Research, Ltd. (BNR)Ottawa, Canada

Implemented a linker for the SL1 product.

Implemented an assembler for the SL1 product.

Undergrad Student, Paid Assistant to Head of Faculty of Computing Science1975-1978
University of British Columbia (UBC)Vancouver, Canada


Undergrad Student, Computing Science1974-1978
University of British Columbia (UBC)Vancouver, Canada

High School Student1970-1974
Lord Byng Secondary SchoolVancouver, Canada
Grades 9-12.
Elementary School Student1963-1970
Jericho Hill School for the BlindVancouver, Canada
Grades 1-8. Did Grades 3 and 4 in one year.