Things I’ve Worked With

I have a long list of items that I’ve had some experience with on the first page of my resume. I’m going to add that list here with a bit more detail and perhaps a few extra items that I have knowledge of but weren’t directly part of any job I’ve done.

This list is currently a work in progress…both the content and the structure are being worked out as I go along. Click a link to see my comments on that piece of technology in the page below…

.NET, 3D transformations, ATL, Active-X/OLE, Advanced C++, Assembler Languages (Including Intel x86), C, C#, COM, Cryptography (Symmetric and Public Key), Data Compression, Dicom-3, Embedded Systems, Embedded Windows, Engineering Development in an FDA regulated environment, GIT, High Speed Data Acquisition, HTML, Image Processing, IEE802 Ethernet protocols, JPEG, Java, JavaScript, Lisp, MAPI, MFC, MRI, Multithreading, NT Service Programming, ODBC, Perl, Postscript, Relational Databases, SCSI, SNMP, SQL, STL, Sockets, Software Architecture, Sonet/SDHStepper Motors, TCPIP, TIFF, UML, Unix, VSS, Web Development, Win32, Windows Driver Development, Windows Operating Systems, XML, XSLT, WiX

More recent items, mix of things I’ve worked with and things I’ve been looking at as potentially useful..

Node.js, Angular 2, , Google Test, QNX, OpenGL, JQuery, Bootstrap, PHP, MongoDB, SQLite, ASP.NET, .NET Core, WebGL, Python, QT, Three.js, NUnit, R, WPF, OWIN, Wix, MySQL, Unreal Engine, MEAN, F#, RESTful Interfaces, Selenium, Blender, VR, Unity, Subversion, JSON, Single page web applications

  • Software Architecture

    I have been focused on the overall architecture of the systems I’ve worked on for most of my career. Relatively shortly after I started working at Howtek I took on the effective role of software architect for that team and designed and implemented the infrastructure and conventionse used by all of the subsystems in the scanners that Howtek developed after that point.

    I very strongly believe that a software architect must be involved in hands on coding in the system they’re developing. A close connection to the details of implementation helps to inform the connection between the architecture level and the implementation details, reducing the possibility that an elegant architecture might result in an unworkable system implementation.

    Object oriented techniques and
    modular design are a must in pretty much all current implementations bigger than dedicated controllers with a simple service loop and limited duties. Modularity is higly desirable for any system that is expected to evolve over time (and this describes most systems I’m aware of). Testability at a unit level is highly desirable though sometimes challenging when hardware subsystems and complex real time interactions are involved.

    I believe that the best software architectures make it as easy as possible to get the things the neepd to be done accomplished while making it as hard as possible to do things that shouldn’t be done. There is always a trade-off here as requirements shift over time and schedules sometimes mandate approaches that aren’t ideal. Trading off these imperatives is a central challenge in being an effective software lead.

  • Advanced C++

    I’ve been writing C++ for most of my career. I find the mix of object oriented features, procedural programming support and generics provides power and flexibility. It can be a challenging language to bring new engineers up to speed on and has a number of ‘sharp edges’ that need respect.

    I generally view it as two or three subsets of features. There is the day to day language where I don’t wind up creating new templatized code entities that much and use a relatively prosaic subset of the language. When creating new infrastructure, the range of language features expands substantially, but usually with an eye to creating components that engineers with less depth in the language can use without needing a full unserstanding of the internal implementation.

    I write C++ in large project environments (500k plus lines of code, small to mid-sized teams). Generally there is threading and interprocess communication. In most cases there is also hardware interaction and relatively strict timing constraints. Putting all of these together while building an environment where programmers with more limited C++ experience can be productive is a significant challenge.

    Lately I’ve been taking a serious look at the new standard (and the Boost library which allows back-filled support for many of the library features in older development environments). It looks as if there are quite a few interesting features in there (and the regex support as part of the standard library has already proven useful). Our implementation here at GE SMR is running on Visual Studio 2010 currently so some of the compiler updates are mostly futures.

    As part of the work involved with my first project at KMC I brought myself up to speed on much of the new material in C++ 2014. The concurrency facilities alone made my code less system specific and easier to understand than it would have been otherwise.

  • COM

    I very much appreciate the cross language capabilities, local/remote transparency and abstraction capabilities that COM brings to the table. It is very unfortunate that Microsoft stopped developing COM in favor of the .NET CLR universe when they did as I believe that many of the messy parts of COM could have been addressed and the result would have been much more broadly useful than the somewhat inward turned .NET universe.

    All of that being said, I have come to appreciate the ‘better java than java’ that C# provides.

  • STL

    The standard template library is now really just a slice of the standard C++ library. With the newer C++ standards that have been released recently, the ugly bits have largely been dealt with (smart pointers in particular) and coverage broadened in very useful ways.

  • Win32

    The Win32 API is still the backbone of the windows operating system (though in 64 bit systems it becomes a bit of strange naming convention).

    Anything that can be done on a windows machine can generally be accomplished using native code and Win32. In fact there are still a pretty wide range of functions that can only be accessed by using pinvoke from .NET to access native functions that do not have managed wrappers by default.

  • Windows Operating Systems

    I have been working with the 32 bit version of windows (and now 64 bit) since the second beta of Windows NT. I’ve worked with the server, client and embedded builds and built product around XP embedded and NT embedded. I’d put my knowledge of how windows up against just about anyone. I’ve written code from kernel drivers to services and on up to GUI code and various forms of scripting.

    I have been working with the 32 bit version of windows (and now 64 bit) since the second beta of Windows NT. I’ve worked with the server, client and embedded builds and built product around XP embedded and NT embedded. I’d put my knowledge of how windows up against just about anyone. I’ve written code from kernel drivers to services and on up to GUI code and various forms of scripting.

  • Windows Driver Development

    I have become involved in developing or debugging/extending kernel mode device drivers for windows (and long, long ago for Unix) several times. The kernel environment requires a rather different perspective than user mode but I’m comfortable enough in that environment that it isn’t an issue.

    The latest bit of kernel mode coding involved developing a monolithic WDM driver using the windows DDK for a new PCIe board that was being developed for our next generation MRI scanner prototype by engineers in Bangalore. the driver was successfully developed and moving large volumes of data through user mode test harness code before the project was shelved as GE decided to exit the specialty MRI market.

  • Unix/Linux

    Unix was the first ‘serious’ programming environment I encountered and I still like much of what I see there. In recent years I’ve spent more time programming under windows but I’ve hopped over to posix-ish environments often enough. They serve particularly well for ‘headless’ applications where the connection to the real world is either as an embedded system or a network connection.

    The fact that the ARM processors in a raspberry pi board run a pretty stock linux distribution decently for around $30.00 in hardware costs still astounds me. Add an AVR controller based arduino or three and you can build cool things for very little cash…
    I currently use two Intel NUCs for lighter development activities…one running windows 10 and the other Ubuntu linux. Some items get ported down to an rPi if there seems to be a good reason.

  • Perl

    Perl is a great language for relatively small tools that manipulate files, text and processes. It can be written quickly and do very sophisticated manipulations with relatively little work. For larger projects I’d tend to favor compiled languages with stronger type systems (for better compile time error checking) and better object oriented programming support.

    Lately I find myself using Perl less. The fact that javascript is more likely to be available by default on most platforms (and on windows has access to COM objects in many cases) makes perl less likely to be my first choice.

  • ATL

    The ATL library makes COM programming significantly less painful. It has now been a while since I had need of ATL as I’ve been spending my C++ time on posix platforms and writing in C# and javascript on windows machines. I’d still expect to use ATL heavily if I needed to implement (and for some of my sandbox work this may come up) COM objects again.

  • Windows Service Programming

    Unix has daemons and windows has services. In windows they environment seems a bit more structured as the service control manager can restart a failing service and there is a standard way in GUI, API and command line to send control requests to them.

    The coding is a bit different from a normal application as they receive control requests from the windows service control manager in a standard way. They also are expected to convey status back to the system, especially as they’re starting up and getting themselves ready for operation.

  • TCP/IP

    The standard way to send network data these days. TCP provides reliable, connection oriented transport and UDP provides unreliable datagram service. I have a pretty good understanding of the low level mechanisms of IPv4 as I have several times looked at implanting TCP on embedded controllers in products I’ve been involved with. These projects never reached the fully prototype stage so this remained a theoretical investigation.

    I don’t have significant experience with IPv6. I know where the relevant information is, but haven’t had the time or impetus to dig into it. Should the need arise, I’ll make the effort and I expect that it won’t prove significantly more challenging than IPv4 was.

  • Sockets

    As the normal way to write lower level networking code in C and C++ these have been of interest at various times in the past. These days I’m more likely to be poking at HTTRequest or something similar but for some things only the low level APIs will do…

  • Multithreading

    There are quite a few new (and revived old) approaches to managing concurrency that are worth paying attention to. Handled properly, threads and thread pools provide the most basic unit of concurrency management.

    Adding in the extra overhead of a process boundary forces a much coarser granularity. Cooperative multitasking in the node.js/windows message loop style tends to become difficult to manage rather quickly once the design gets large.

    I’ve built heavily threaded designs in a number of projects with good results. I’m staying aware of async, promises and other such but keeping baseline threading close for use as needed…

  • C

    The grand old man of high level systems languages. Still showing up pretty frequently in lower level embedded work and serviceable when necessary. I’d rather code in C++ where possible but C is fine where needed.

  • Embedded Systems

    I have worked in a broad range of embedded development environments ranging from small service loop based controllers to large systems with dedicated real-time controllers supervised by a windows or linux machine.

  • Stepper Motors

    At Howtek I wound up driving stepper windings pretty directly. We implemented a two stage pipelined windings register that was clocked by an timer counter with an IRQ triggered when the timer ticked. This allowed well controlled timing (with on the fly adjustment as the interrupt service routine could select the next interval for ramping) while leaving most of the details under processor control. It did take a bit of tuning of interrupt priorities to ensure that things ran smoothly when the system was heavily loaded, but once that was resolved it worked very well and was quite simple and inexpensive to implement.

    I’ve currently got a set of stepper controllers in the basement here as part of putting together a RepRap 3D printer. The project has been stalled lately as things have been too busy to spend time on the projects, but they look much nicer than the hardware we used at Howtek. They support micro-stepping and take a simple ‘step’ and direction signal rather than requiring the host to write winding states directly.

  • Assembler Languages (Including Intel x86)

  • SCSI

  • TIFF

  • JPEG

  • Data Compression

  • MAPI

  • SNMP

  • XML

  • VSS

  • Dicom-3

  • HTML

  • Engineering Development in an FDA regulated environment

  • Embedded Windows

  • High Speed Data Acquisition

  • Image Processing

  • 3D Transformations

  • MRI

  • Active-X/OLE

    ActiveX is a component technology for user interface plug-ins that had great potential when it was under active development. As it stands currently it is still an interesting technology in a number of applications. The rough edges around developing and debugging controls make it a but painful at times. I’d have to carefully weigh the advantages and disadvantages before using it in new development.

    I’ve worked on a number of systems where we implemented and used ActiveX controls.

    At Textronix/BTT the controls were part of the dynamic configuration of the system. At application start-up the user interface interrogated our run-time service for a list of modules installed in the system (cPCI cards plugged into the chassis) and created UI controls for each card on the fly. Each control was passed information about the specific identity of the hardware that it was associated with. This allowed us to independently develop the software stacks for each instrument (the service level components were COM objects). As we were working with teams in geographically distant locations the clean partitioning made the development process much smoother for all involved.

    At Oni/GE SMR we implemented our graphical prescription tools as ActiveX controls that wrapped third party control objects and provided functional isolation of the third party interfaces and coordination between isometric views. We wanted to isolate the main user interface implementation from the graphical viewer components to hedge against future requirements that might mandate migration to either a fully custom implementation or a different vendor. Exposing a task specific and much simpler interface to our application implementation made the prospect of such a change much less complex. The final implementation required three separate viewing panels (each an independent window control to the third party tools) to update in a coordinated fashion as the user manipulated any one of them. The wrapper component coordinated activity through a published/subscriber COM object that managed the requested transformations and updated each view and the user made changes by dragging grab handles on the controls.

  • Sonet/SDH

  • MFC

  • .NET

  • C#

    C# seems very much to be a better java. The language allows for a much broader range of approaches with less wordy code while preserving the productivity and powerful runtime library that long distinguished java.
    I’ve been on a few programs implemented in C# and at this point I’d likely see it as the number one option for a new project if there were no other countervailing forces.

  • Java

  • JavaScript

  • XSLT

  • Cryptography (Symmetric and Public Key)

  • Postscript

  • IEE802 Ethernet protocols

  • Lisp

  • UML

  • SQL

    As SQL is the nearly universal way to manipulate relational databases these days, it comes up rather regularly. I first began picking it up as I worked on the Dicom mini-database application at Howtek. We started out with direct file access only but were moving to a design that used a SQL database as a fast index for looking up a subset of attributes on demand toward the end of the project.

    The variety of SQL targets out there today is huge and I’ve since used SQL for working with everything from system logs to web site configurations.

  • ODBC

  • Relational Databases

    The back end to most SQL connections. Relational databases are no longer quite as ubiquitous as they used to be (NoSQL stuff and big data stores like Hadoop). They are still by far the most common ways to store structured information and are available in all sizes and price ranges.

    I’ve never had a reason to get involved in heavy duty database work, but they show up just about everywhere from system logging back ends to web site content management data stores. I deal with them as needed and feel that I’ve got a pretty good idea of what they’re capable of and how to use them.

  • GIT

    GIT has become my preferred tool for managing working code sandboxes. It is great for managing the process of syncing work between computers and onto portable storage reliably. As it is free and open source I can install it where I choose with no license constraints and as a full fledged source code control system there is no issue with maintaining branches or rolling back from failed experiments.

    At Oni/GE we were using VSS for primary source code control and looking to transition to team foundation server so I haven’t had a reason to set up a configuration that supported group interactions. Given its origins in supporting Linux kernel development it seems clear that it would work just fine in such an environment.

  • Web Development

    I’ve been using HTML and related technologies in small ways for years now. This is about the fourth web site/blog that I’ve had online (though the first that used real CMS software to manage its content). In the past I’ve used it as a convenient way to share information and to generate documents that looked better than plain text but without the messiness of using applications through aome sort of automation hooks.

    With this site I’m trying to move to a more polished style and extend my knowledge of HTML/CSS/JavaScript to the point where I can turn out content that is reasonably professional looking and reasonably ‘literate’ in web best practices.

    I’ve looked at HTTP as a transport for a couple of systems I’ve been technical lead on. So far they’ve all had adequate inter-process communications/remoting mechanisms in place and other priorities have always pushed off upgrading the comms layer. The commodity nature of HTTP (and its flexibility in terms of payloads) makes it very attractive for all but the highest performance situations I think. Add in the availability of encryption using TLS and proxy options and it has the potential to be one-stop shooping from local system IPC to long haul messaging.

  • Node.js

  • Angular 2

  • Android

  • Google Test

  • QNX

  • OpenGL

  • JQuery

  • Bootstrap

  • PHP

  • MongoDB

  • SQLite

  • ASP.NET

  • .NET Core

  • WebGL

  • Python

  • QT

  • Three.js

  • NUnit

  • R

  • WPF

  • OWIN

  • Wix

    The WiX installer package seems to be about the best open source installer package for windows out there at the moment. I’ve used it for a number of small projects and will almost certainly give it serious consideration next time I have a larger project that needs a formal installer.

  • MySQL (and MariaDB)

  • Unreal Engine

  • MEAN

  • F#

  • RESTful Interfaces

  • Selenium

  • Blender

  • VR

  • Unity

  • Subversion

  • JSON

  • Single page web applications

 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.