@MApp – a Developers take on an amazing RF Design and Drafting Application

My friend and colleague recently wrote an article on the (sometimes known as @MAppDR, ATMapp or ATT_MApp).   A strange twist of events also resulted in me working very briefly with the most "recent" build of the product.  It had been many years since I really saw the application running – so I had a bit of a fresh eye.  This made me a little bit nostalgic, and also quite proud.  We had really made some amazing software when you got right down to it.  Unfortunately, in "internet years" it has sadly become a dinosaur.

Long ago (it seems like a lifetime) I worked for a company called Kanotech.  One of my first real development projects of scale was on the .  @MApp was a powerful extension built for AT&T/Comcast cable.  My first task was to head to Seattle and learn how field technicians would walk the existing RF Plant (fancy word for cabling and RF equipment) and map the existing assets, on paper.  The first task was devise a way to run @MApp on one of the early rugged .  I walked the streets of the greater Seattle area with some of the field technicians and got my first introduction into the world of cable TV networks.  At the end of this trip I had a collection of notes and enough information to design and implement the pen based version of @MApp.  This was the beginning of my life with @MApp.

With the bigger picture in mind, there were many underlying goals for @MAppDR, one of the key needs was standards enforcement (and creation -  Evan created the first solid standard which, though very much evolved is still in use today).  Like many organizations back in the day (and likely even today) the mapping data being generated was garbage.  Each division, each consultant, sometimes each drafter had their own set of "Standards".  As Evan put it, the mapping data was "Only good for printing" – and even that was a stretch in some of the sample data we saw.  Our top priority was to create a set of tools which facilitated drafting standards compliant drawings – as well as a method to test each drawing to ensure the drawing was truly compliant.

Under the hood, @MAppDR was all database driven.  Layers, cable types and properties, even symbols and block attributes could be configured in the database.  Generic lisp calls were defined to allow simple wrapper functions to be created to add new entities to the application.  The application had been created using an extensive amount of , VB6, , Python, and SQL Server/Access databases.  Let me tell you, I still have nightmares about parentheses =).@MApp DR drafting tools

Page 1 of 4 | Next page