Resume Software Engineer by ellonnic

VIEWS: 232 PAGES: 18

									                                                    Dressler
                           1272 Pine Circle • Bellefonte • PA 16823 • (814) 308-2473

                                             Software Engineer

Overview
       7 years experience
       Primary Languages: C++, Java, and C#
       Education
            o School:        Duquesne University
            o Degree:        B.S. Comp. Sci.
            o Minor:         Math
            o GPA:           3.8 / 4.0 (Magna Cum Laude)


Professional Experience
    Software Engineer for Siemens (March 2005 - Present)
         My most recent work was on AWS 2.0; a revolutionary thin-client zero-install application focusing on using
           both textual and geometric criteria to search a database for 3D content and display any results in 3D. I wrote
           the complex communication pipeline between the HTML5 client and the server, as well as implemented the
           tools and mechanisms for interacting with the 3D scene. I also wrote the backend piece which exposes the
           native rendering engine and allows it to communicate to the client.

           Prior to AWS 2.0, I helped develop its predecessor AWS 1.0. AWS 1.0 is basically a Silverlight version of its
            current form.

           Prior to AWS, I helped develop and rearchitect PLM Vis, a cross-platform toolkit that allows customers to
            incorporate 3D content into their own products. I was also involved in many major enhancement projects.

           I also helped develop/enhancement several other Siemens applications: XpresReview, JTCompare,
            TestFixture, SEVTestFixture.

    IT Intern for The Hershey Company (Summer 2003 & 2004)
          I wrote a Java Servlet for storing SAP terminology into a local database, used ARIS to model HR processes,
            and performed some data entry in SAP.


Professional Highlights
   The team's first-pick developer for understanding any new technology and integrating it into new products.
   Co-architect of PLM Vis's current architecture (called SEV)
   The recognized team-expert on product architecture, threading, Java UI, Eclipse & RCP, and client/server interaction.
   Created a patentable IPC abstraction layer known as the ExecuteMethodMessage (EMM).
   Converted our proprietary Application Sharing product into a DLL for use as a service from Silverlight.
   Wrote the SEVTestFixture (the Eclipse RCP application that is used to develop and test all of PLM Vis)
   Project-lead on a project that represented a C++ tree-model using a Java UI.
   Wrote the PLMVisDebug system (a system for logging debug information and visualizing it)
   Rearchitected XpresReview (An application using PLM Vis) that uses MFC and a home-grown ActiveX control.
   Prototyped an elegant framework for a CAD translator test-suite that used COM, Xalan, Xerces, XSL, and XML.
   Wrote a Java Servlet that queried and contributed to a database.
   Wrote a system for cloning MFC toolbars and dynamically exposing them at runtime as Eclipse toolbars.
   Incorporated the use of Microsoft's Office Fluent UI into XpresReview – a free 3D Visualization product.
   Recognized the advantages of using the Eclipse IDE and ported the entire PLM Vis toolkit to use it.
   Professional experience working with the following technologies:
        C++              Java               C#                Silverlight        ActiveX            Xerces
        RMI              JNI                COM               MFC                Office Fluent UI   AWT
        SWING            Eclipse & RCP      SWT               Ant                Servlet            JNLP
        GWT              JSNI               HTML5             WebSocket          socket             JavaScript
        XML              XSL                DTD/Schema        Xalan
Miscellaneous Highlights
     Completed supplemental 400-level Artificial Intelligence course at Penn State University.
     Developed a 3D game-engine for a futuristic flight simulation game using OpenGL.
     Sole developer of the MTGDeckRunner product/website – a free online collectible card-playing engine.
     Created countless Unreal Tournament levels for personal amusement.
     Wrote a sophisticated Java SWING application for playing a complex card game.




Contents
Overview .................................................................................................................................................................... 3
Education ................................................................................................................................................................... 3
Prior Work .................................................................................................................................................................. 4
New SEV Architecture ................................................................................................................................................ 5
Execute Method Message (EMM).............................................................................................................................. 5
Toolbars ..................................................................................................................................................................... 5
Test Fixture ................................................................................................................................................................ 5
SEV replaces SingleEmbeddedViewer........................................................................................................................ 6
MTG Deck Runner ...................................................................................................................................................... 6
The Single-Thread Rule .............................................................................................................................................. 7
Thread-Safe or Unsafe? ............................................................................................................................................. 7
ViewerBaseBean, CViewerX, and CBaseView ............................................................................................................ 7
Java Trees ................................................................................................................................................................... 8
SEV Test Fixture.......................................................................................................................................................... 8
OpenFileInBeans ........................................................................................................................................................ 9
SEV Plug-In / Eclipse Toolbars and Menus ................................................................................................................. 9
PLMVisDebug ........................................................................................................................................................... 10
SWT Components .................................................................................................................................................... 11
Sockets & PLMVisSockets ........................................................................................................................................ 12
XpressReview Rearchitecture & Microsoft Office Fluent UI .................................................................................... 12
VisView with Tabbed Panes ..................................................................................................................................... 12
JTCompare ............................................................................................................................................................... 13
MFC Toolbar Bug Discovered & Fixed ...................................................................................................................... 14
Windows Azure ........................................................................................................................................................ 15
Transition from PLMVis to AWS ............................................................................................................................... 15
AppShare as a DLL .................................................................................................................................................... 15
EMM Strings to EMM Byte Arrays ........................................................................................................................... 15
VisualNavigator and Silverlight ................................................................................................................................ 16
Async EMMs in GWT ................................................................................................................................................ 16
EMMs with Object Serialization ............................................................................................................................... 16
WebSockets.............................................................................................................................................................. 17
A Meditation on SDLC .............................................................................................................................................. 17
Call in the A-Team .................................................................................................................................................... 18
Conclusion ................................................................................................................................................................ 18




Overview
If the quality of a man is measured by his actions, then a software engineer should be measured by his engineering
achievements. This document summarizes the most significant events that have crafted me into the engineer I am
today, most of which occurred over the past seven years here at what is now Siemens.


Education
My interest in computer programming began shortly after my dad had bought me my first graphing calculator - a TI-83.
I was probably about fifteen back then (1996) and I remember sitting in the middle row of our van on our annual sixteen
hour drive to St. Louis while reading the manual for my new toy. It was then that I stumbled across the section on
programming. I was fascinated by the fact that I could make my calculator do my bidding. It was not long before I was
reverse-engineering games, writing my own games, and making it solve my problems in math class.

It was my success with the TI-83 that had let me to take two programming courses in high school; one teaching BASIC,
and one teaching Pascal. Since I was also taking music composition lessons on my synthesizer, I wrestled with which
major to take in college. After talking with several people whom I regarded as wise, I decided that Computer Science
was the more lucrative and safer alternative. Music composition would remain a hobby.

I attended Duquesne University and graduated with a Bachelors of Science degree in Computer Science. I also departed
with a dead even 3.800/4.000 GPA (Magna Cum Laude) and a minor in math. My 400-level Computer Graphics course
was by far my favorite. As the final project for the course, the professor held an art contest in which we all competed
for both grades and a prize. Since I was doing what I loved most, I took first place with ease.
For my graduation project, I decided to put both my Computer Graphics and Calc 3 skills to good use and write a 3D
flight game engine. By the time the presentation date had rolled around, I knew that my work was overkill for a
graduation project. The engine was so much fun to write that I simply could not help but continue its development
above and beyond its requirements. The professors were very impressed and responded that they wished all senior
projects were of this caliber.

The engine itself was quite innovative. It allowed the game developer to develop a world full of texture-mapped rooms
that a player could fly a small spaceship through. The rooms were dynamically loaded and unloaded at runtime to save
on memory and also improve the refresh rate. Since the rooms only contained primitive shapes and barriers, there was
no up or down. This meant that when the player was forced to fly upside down, the player would need to reinterpret
their world from a different perspective in order to be successful.

By the time I presented the engine to the computer science professors, it had included both weapons and weapon
pickups. Unfortunately, I lost interest after getting caught up on a complex mathematical problem and lost interest in
adding more functionality. Despite this, HTML5 has rekindled my interest in the engine and I plan on rewriting it for
HTML5 in the near future.




Prior Work
Prior to working for UGS, I had my fair share of crummy jobs. Only my two internships with Hershey Foods were
relevant to my future career. The most important task I did for Hershey Foods was to write a Java servlet in the
WebSphere IDE. The servlet was used to both augment and search their growing SAP terminology database.
New SEV Architecture
PLMVis had been growing more and more unstable and unmanageable for two reasons. First, the current PLMVis team
had inherited a rickety architecture from the original architects. Secondly, there were very limited resources available to
maintain it.

With an unusually large gap in the PLMVis delivery schedule, Jay decided that the weather was right for an extremely
risky move. He decided to pull Mike and I off of product maintenance, which at the time was desperately needed, and
instead divert our attention onto re-architecting PLMVis.

Jay knew that his product was falling apart and that removing two more engineers he had created a do-or-die situation.
To make matters worse, he only had two engineers available to build his new product and one of them, me, relatively
little experience.

Despite the atmosphere full of pressure, Mike and I formed an unusually innovative and industrious team. We decided
that as part of our design we would divide PLMVis into two separate processes – a Java process, and a Vis process. The
two processes would then be glued together at runtime using some form of Inter-process communication. Jay
suggested using Remote Method Invocation (RMI) and so I prototyped the RMI communication layer while Mike
prototyped the C3DViewer class.

Once I completed my work, Mike combined my prototype with his. This allowed him to demonstrate that even though
Java and Vis were divided into two separate processes, we could still host the window and place it inside a Java window.


Execute Method Message (EMM)
While Mike focused on the C++ process, I focused on the Java process. At the time, the original pattern for flushing out
the APIs we needed was by creating an RMI and JNI stub for each individual API. Then, one day while Jay, Mike, and I
were discussing our progress in Mike’s office, I had an idea that changed the future of PLMVis. I asked them what would
happen if we wrote a single message that wrapped our methods and was therefore capable of executing any native
method. This would require only one pipeline from Java to Vis instead of hundreds. I can recall immediately becoming
dismayed with my own idea after considering the complexity that would be required in C++, but this did not scare Jay.
Jay thought the idea was brilliant and instructed us to go implement it. Mike and I immediately began flushing out the
design for the new Execute Method Message (EMM) system. Since I had already been working on the Java side, I
generated all the Java classes and EMMs using an EMM generator tool I developed. Meanwhile, Mike wrote the core
code that continues to route EMMs inside of PLMVisUtils to this day.


Toolbars
The toolbars were a later consideration. The toolbars really did not migrate to the top of the list until I had the Java end
mostly flushed out. Armed with experience from The Dynamic Toolbar prototype t, Mike and I together developed the
toolbar cloning process that PLMVis still uses today.


Test Fixture
As the SEV project neared completion, a testing utility was still required. Up until this time, each area of functionality
had its own separate Java applet and Jay had asked me to create a PLMVis testing suite that was capable of testing all of
PLMVis’ APIs within a single application. Seeing as how applet visualization was losing fashion, I decided to use a Java
application instead of a Java Applet and ported a few of the applets over to using the new framework I had created. It
was around this time that Dan Lee came on board and completed the process of converting the remaining applets. This
testing framework is still used today and even come with the PLMVis toolkit. It is called The Test Fixture.


SEV replaces SingleEmbeddedViewer
Towards the end of the SEV’s first development cycle, I was growing frustrated with the inferior text editor we used to
develop Java code (JCreator). Since I had already had experience with a wide variety of different Java IDEs prior to
working for UGS (Eclipse, WebSphere, and NetBeans), the editors we used for PLMVis really seemed like a step
backward. Brian had previously experimented with using Eclipse on the VisWeb architecture, but when I asked him
about what had been done, he was really just using Eclipse as a text editor and could not compile the code with it. It
was time for a big change. I decided to take our “SingleEmbeddedViewer” module, restructured it, and place it into the
Eclipse IDE. The advantages I experienced from this were immediate - it was truly an eye-opening experience.
Encouraged by my success, I also rewrote the build utility – this time using ANT instead of MAKE and batch files since
ANT was cleaner, cross-platform, and worked nicely in Eclipse. Once completed, this newly restructured module
became the “SEV” module and shortly after replaced the SingleEmbeddedViewer module.


MTG Deck Runner
During the period of time when I was writing the Java code for the SEV architecture, I also embarked on a home
development project – MTG Deck Runner. The goal was to produce a powerful virtual desktop for playing a variety of
different collectable card games at once. By the time it was complete, I had developed a complete application that
included a fully functional website, support utilities, version control, custom artwork, help pages, YouTube tutorials, an
installer utility, and branding. A user could simply browse to my website and the full MTG Deck Runner application
would launch outside the browser right in front of them.

Not only was the product very sophisticated and challenging to build, but the process of producing a production-level
applet from source code was difficult to master as well. By the time I was done, I could run a single batch file that would
execute the following tasks in order:

               Compile the Java source code into a Jar file
               Use a tool called ProGuard to compress and obfuscate the Jar file
               Sign the Jar file
               Use a tool called Lauch4j to create a Windows executable version for testing
               Replace the website’s existing Jar file with the new one

In my opinion, I had accomplished something marvelous. I had even acquired the services of an individual who was
familiar with the specific game I was trying to emulate the most. He thought the application was absolutely fantastic!
There was just one problem with my product – my intellectual property attorney said that my product was currently a
derivative work and could potentially ask for lawsuits. I therefore modified the application to avoid any intellectual
property issues, but then anyone who saw my website would be confused by its intended purpose. I completely lost
interest in the application. Despite MTG Deck Runner’s ultimate failure, I felt I had truly mastered the Java language,
especially Java threading and UI.
The Single-Thread Rule
Because of my experience with MTG Deck Runner, I had discovered and mastered The Single-Thread Rule in which all UI-
related work must be executed on the UI thread. It was because of MTG Deck Runner that had I realized that almost all
of PLMVis’ components were violating it. At the time, this was completely alient to the rest of the team. I made a point
of educating those interested in hearing about the rule and I embarked on modifying the PLMVis code to comply.


Thread-Safe or Unsafe?
Once upon a time, Kevin Guthrie began ranting on in large meetings about how PLMVis’ lack of thread safety was
causing all his woes. After all, the caveat that management had attached to the SEV from the beginning was that PLMVis
was not thread-safe. It was Stu Pond who followed suit and began vocalizing his anger with the inferior SEV design. He
made it clear to everyone on the call that there was no excuse for PLMVis’ lack of thread safety. Jay suggested that Stu
talk to me. When I received Stu’s call, he was frustrated and ready for a fight. To his surprise, not only did I know full
well about the Single-Thread Rule, but I completely agreed with him - PLMVis had no excuse to be unsafe. I explained
that I had already been taking efforts to close the threading gaps, both UI related and otherwise, and the task was
almost complete. Once the discussion was over and it was clear that we were on the same side, I countered Stu with a
challenge; once the repairs are completed, if you can find a threading issue caused by PLMVis, I personally will dive in
and fix it for you.” I gave my word and I kept it too. Kevin Guthrie was right; there was a threading issue inside of
PLMVis which related to the TI Viewer. Once I fixed the problem, PLMVis was subsequently advertised as thread-safe.


ViewerBaseBean, CViewerX, and CBaseView
I cannot help myself sometimes; when I see a design flaw, I just need to fix it no matter how mundane or complicated
the task. That was the case shortly after the SEV was born. When a new viewer was added, the code from another
viewer was usually copied to save time. So, as time progressed, the viewers began evolving in very different directions
due to either inconsistent or non-existent class inheritance hierarchies. Once I recognized the problem, I took it upon
myself to restructure all of PLMVis’ viewer classes (Java and C++) into a class inheritance pattern that was consistent
across all of the different viewer classes. For example, because of this effort, the Viewer3DBean, Viewer3D, IViewer3D,
CViewer3D, and C3DView class each inherit from their respective ViewerBaseBean, ViewerBase, IViewerBase, CViewerX,
and CBaseView. Now all PLMVis viewers (save the ViewerLite) strictly follow this pattern.

This project was not as straightforward as it might sound. The independent evolution of each viewer had caused the
classes to appear and function quite differently from one another and they were evolving further apart each day as new
functionality was added and fixes were incorporated. To counteract this, each class had to be carefully examined for
contents that could be factored into a common base class. In many cases, this involved fundamentally changed the
design and order of operations. However, by the time it was complete, there was a glue now that held all of the viewers
together.


Java Trees
When Yinkun first joined the team, he needed someone to show him the ropes. I impulsively took him under my wing
and trained him. Before long, Yinkun had come up to speed and Jay had assigned us both to a brand new project with
me as the technical/project lead. The project was “Java Trees”, and its goal was to provide a tree solution on all
platforms by emulating the native tree behavior using the native runtime tree model, the Vis tree adaptors.

In order to solve the problem, I devised a clever design. Each JTree was entirely Vis-event driven. For example, if the
user clicked a checkbox in the JTree, Java would ask Vis to check the appropriate HPTree checkbox. If it succeeded, the
Tree Adaptor would immediately send an event to Java telling it to check the JTree’s checkbox. In this way, no changes
occurred to the JTree until it received the command from Vis. This mechanism allowed Vis to completely drive the
behavior of the JTree.

As for the implementation process, Yinkun owned the JTree code and I owned the remaining event pipeline, including
the Tree Adapter modifications and listener registration system. This clear division of labor worked particularly well for
us.

Although the Java Trees served for only one release, there are several reasons why the project still remains dear to me;
first, I had led my first project; second, my design was an especially beautiful and elegant piece of engineering; third, I
had made a great new friend.


SEV Test Fixture
No one asked me to write the SEV Test Fixture which uses the Eclipse framework. At the time, Eclipse was growing in
popularity and Jay had mentioned that the wind would soon be blowing our way in some form. I therefore dedicated a
portion of my hours during that period to learning the Eclipse framework. I started by following a tutorial from a book.
However, after a half dozen chapters, I grew irritated by the process of reviewing code that was irrelevant to my work.
So, in order to test my own understanding of what I had learned from the book, I decided to write an Eclipse application
that used PLMVis. Since the tutorial focused on Editors, Views, and Tree Controls, the old Test Fixture seemed like the
perfect candidate to port to an Eclipse application. By the time I was done, I had realized how much power we were
leveraging from the Eclipse Framework. A QA tester could open the SEV Test Fixture, open any number of test tabs,
placed them on different monitors, and then close the app. When they re-opened the SEV Test Fixture, it looked almost
as though they had never closed it. So the SEV Test Fixture was only a toy at first. It was not until the advent of the SEV
Toolbar & Menu system that the SEV Test Fixture became a necessity.
OpenFileInBeans
Prior to OpenFileInBeans, the customer’s program had to create the appropriate type of viewer object before it opened
a file. This meant that the application had to know ahead of time which document type would result from the file it
wished to open. This was very inconvenient to PLMVis customers, but due to the expected complexity of the solution,
Jay was hesitant to try to tackle it.

At the time, serious frame changes were anticipated in order to support the new API enhancement, which is why Jay had
asked Chris Walters to assessing the feasibility of the new API. When he was almost done implementing it, Jay asked me
take a look at it. I was dismayed by the extraordinary complexity of both the API and implementation. Unfortunately
for Chris, he was missing a key piece of the puzzle that would make his job much simpler. That key piece happened to
be in my local environment because I had only just completed it. The key was the ability to reparent the Vis windows
directly into the CBaseView object. Prior to this, the Vis view had to be created inside of the CBaseView object. On my
computer, I could simply steal it instead.

After I understood what Chris was trying to do, I implemented OpenFileInbeans on my own computer using the
reparenting technique. The resulting design was clean and elegant. OpenFileInBeans was now a simple two-phase
process where PLMVis first opens the file in Vis and then, depending on the resulting document type, an appropriate
Java viewer was created and the Vis window was reparented directly into the viewer. It also supported session files, in
which case multiple viewers could be returned.


SEV Plug-In / Eclipse Toolbars and Menus
Shortly after the SEV Test Fixture was completed, the Lifecycle Viewer project began. The Lifecycle Viewer project
would result in a whole new Eclipse Perspective inside of TeamCenter. This perspective would require that PLMVis be
used as a true Eclipse Plug-In instead of an external jar file. Also, PLMVis’ components would be used just as Eclipse
would have intended; as true Eclipse views and editors. Wrapping the PLMVis components as Eclipse Framework
components was an easy task since I had done this already inside of the SEV Test Fixture. Devesh only needed the SEV
Test Fixture source code to guide his development efforts.

Adding Vis’ toolbars and menus to the top of the Eclipse application was one of the most difficult software engineering
tasks I have tackled due to the number and complexity of the pieces required to satisfy the requirements.

               The toolbar and menu data needed to be extracted from the Vis process at runtime and promoted to
                Eclipse’s UI.
               The checked/enabled/visibility state of Vis’ toolbar buttons needed to be mirrored in the Eclipse UI at all
                times.
               The visibility state of Vis’ top-level menus needed to be mirrored in the Eclipse UI at all times.
               A Vis menu’s content was so dynamic that it had to be fetched from Vis at runtime each time the user
                clicked it.
               To simplify the design, all possible toolbar icons needed reside inside the SEV plug-in prior to its
                distribution. This meant that I had to write a utility to extract them from the Vis process and place them
                in the jar file before each release.
               The menus needed to be highly customizable.
                     o Customers may not wish to see some top-level menus and menu-items
                     o Some menus and menu-items needed to be appended to the customers’ top-level menus
                     o Customers wanted to insert some of their menu-items into the Vis menus.
                     o Customers wanted to override some of the menu-items’ behavior
Not only was this project delivered on time and with more functionality than anticipated, but it was superbly stable.
Once placed into production, it required virtually no further changes.


PLMVisDebug
I had always felt that my initial debug logging mechanism (using debug1.txt and debug2.txt) was inferior. In fact, even
while writing it, I knew that I would need to revisit it when I had more time. To be more specific, it lacked critical
information and it was also very difficult to read. Consequently, at one frustrated point in time I asked Jay for
permission to take the time to rearchitect it. In doing so, I added a modal dialog that would appear at runtime just
before any logging would occur. This dialog gave the user substantially more control over the logging system, such as
turning it off or adjusting how deep the stack traces were.




On the interpretation end, I provided a suite of views in the SEVTestFixture for analyzing the log data in a variety of
different ways, including search utilities, a threading window, callstack trees, and filters. Since the PLMVisDebug
project’s completion, I have fixed many complex PRs and I owe the speed of their resolution to the new logging
mechanism.
SWT Components
Just by writing the SEV Test Fixture, I knew that the AWT-SWT Bridge was going to be a problem. It was essentially a
hack that was required in order for us to parent Swing components inside of Eclipse’s components (although it can do
much more). This is how PLMVis’ ViewerBaseBeans are displayed in the SEVTestFixure today. It was because of the
awkwardness with using the AWT-SWT bridge that I had dabbled with placing PLMVis’ 3D viewer inside a real SWT
container. This was of course way before the Eclipse Toolbar project had even existed.

TeamCenter developers were no different. When they Lifecycle Viewer project was underway, they were forced to use
the bridge just as I had. So once TeamCenter wanted true SWT PLMVis components, my prototype was pulled from the
cellar, and incorporated into the toolkit. After the Java side and Windows-specific code was completed, Dan ported the
Windows-specific code to UNIX.
The SWT Components project was complex because it required substantial domain knowledge. Only someone with a
good understanding of PLMVis, Swing, MFC, and SWT could port both the viewers and View Components to SWT and
modify the SEV module’s architecture to make it elegant.


Sockets & PLMVisSockets
Remote Method Invocation (RMI) had been a source of issues since the dawn of SEV. On some UNIX platforms,
transmitting large amounts of data would cause RMI would fail (e.g. PMI Java tree on UNIX). Also, using RMI implied
that the Vis Process had to know how to start up the RMI server using the appropriate JRE version. Finally, the
generated RMI stub and skeleton had to be build by the ANT script and so could not leverage Eclipse’s auto-build feature
and would occasionally cause strange problems during development. These issues are probably the reason why Jay had
approached me at one point and asked me to investigate alternative forms of inter-process communication.

Sockets seemed like the natural approach because every other technology, including RMI, was an extra layer sitting on
top of them. I therefore started writing some test apps that used sockets to communicate with one another. There
were four test applications in total, a client/server pair written in Java and a client/server pair written in C++ - each client
was capable of exchanging data with each server. Even though I had the capability of using Java sockets on the client
and native sockets in VPRMIService, from a design standpoint I really did not want to maintain two different
implementations. That is why I decided to use a C++ to C++ socket – one in VisViewJNI and one in VPRMIService.

Jay asked me to incorporate my socket prototype into production code about a year after I had written the prototype.
At the time I was forging my way through the SWT Widget project’s SDLC project. However, the Waterfall development
process leaves plenty of free time to work on other projects between approvals. Therefore, I worked the Socket project
in tandem with the SWT Widget project and still had spare cycles left for PRs. Ironically, due to the issues I had
experienced relating to the Autotest mechanism that had been incorporated into the SEVTestFixture, it took just as long
to test the two projects it did to write them. Regardless, as a result of the Socket project, SEVJNI was pulled from the
build and replaced by PLMVisSockets, which both VPRMIService and VisViewJNI link to and use today.


XpressReview Rearchitecture & Microsoft Office Fluent UI
At one point in time, when my plate was relatively empty, Jay asked me to investigate using Microsoft’s ribbon
technology. My investigation revealed that Microsoft had recently purchased a third party’s Office Fluent UI
implementation and incorporated it into their latest version of MFC. In a short amount of time, I had created a test app
with a few simple UI controls displayed inside a ribbon. Once I showed this to Jay, Jay was very excited and asked me to
begin the task of rearchitecting Express Review using the new ribbon technology. I recall this assignment was pretty
easy. I took the existing UI, refactored it into ribbons, reparented VisView down below the ribbon, and then leveraged
the Eclipse Menu/Toolbar refresh thread to provide state update notifications. It was simple and elegant and once I was
95% complete, Jay handed the new design to John.


VisView with Tabbed Panes
One of the many prototypes I wrote over the years was the implementation of tabbed views inside of the Vis Frame.
This was accomplished by finding relevant code on the Internet and figuring out how to graft it to the VFFrame module.
Although the prototype worked well and was even customizable, the concept of tabbed views had lost favor due to the
ubiquitous use of Microsoft Office Fluent UI. The project was consequently abandoned.
JTCompare
Jay had boasted a bit too much about the stability of the new SEV architecture. Jim Mohan soon used these boasts as an
opportunity to acquire some idle resources for his own projects. After all, how many engineers do you need to maintain
something that is not broken? To appease Jim, Jay decided to place me under Jim for a while. The project was to
improve the JT translator validation process as much of possible in just a few months time. Jay summarized it best when
he asked Jim, “So this is a matter of where do we get the most bang for our buck.” After several meetings with many of
his team members, the way to improve the validation process appeared to be to improve the tool they relied on most –
JTCompare.

JTCompare’s purpose was to compare two JT files and identify qualities that made the two files semantically while
ignoring syntactic differences. The tool was riddled with problems – little customization, cryptic errors, false negatives,
poor version control, incomplete coverage, etc.

I started the project by rearchitecting the entire application such that it was full of significant framework improvements.
The first change I made was to make JTCompare a COM application. This involved taking the application and dividing it
into separate COM DLLs. Once all of the test classes had become COM DLLs, JTCompare was able to dynamically find
and use the test DLLs at runtime. This was very useful because you could now add brand new test classes without
recompiling the frame code.

Another substantial improvement I made as part of JTCompare’s rearchitecture was to employ the heavy use of XML.
Prior to this, JTCompare had dozens of possible command line parameters that had to be very carefully passed to
JTCompare. I modified JTCompare so that it took an XML file as part of its input. The XML file clearly defined the
application-level parameters and added many more. Also, when JTCompare was run, it would output another XML file
containing every detail of what the tests had found. However, this was only an intermediate output. The input.xml file
could also point to an output.xsl file. Once JTCompare produced the output.xml file, it would look for an output.xsl file
and then use Xalan to perform the XSL translation upon the output.xml. This was a huge advantage because the user
had the power to filter and format the output any way they wanted, including HTML pages.

The last important rearchitecture improvement I made to JTCompare was the addition of what I called an “Aggregator
Plug-In”. An Aggregator Plug-In was essentially a COM DLL that would be used to append additional information directly
to the output xml file. This opened up a whole new level of power since anyone could now add things like triangle
counts to the output even though it was not related to a pass/fail test.
The new JTCompare was one of my most clever designs. Unfortunately, despite its power and sophistication, its
pending introduction met extreme resistance from the validation team. Most of them were dead-set against changing
their process. I remember sitting in Jay’s office after a meeting when he asked me how I felt about their level of
resistance. Jay said that if I felt it was the right thing to do, he would work to force this new software into their process.
However, I felt that if they were not willing to bend in order to improve their own situation, then it was not worth the
trouble of imposing it upon them. Consequently, the new beautifully designed framework was abandoned.

Jay and I were both frustrated – after weeks into the project we both discovered that they wanted improvements, but
they also did not want anything to change. In short, they wanted magic. Discouraged, Jay advised me to simply do
whatever I was capable of accomplishing within few months time and then return to PLMVis projects. With an end in
sight, I diverted my attention towards rigorously improving JTCompare’s test cases. This was almost guaranteed not to
impact the validation process, and yet it still offered the validation team substantial time savings.

PMI had been a particular point of heart ache for the validation team, and since Scot sits next to me I decided to focus
most of my efforts there. Prior to my changes, when the validation team used JTCompare to test PMI, it was a scary
process. JTCompare would spew out scores of errors, most of which (if not all of them) were completely bogus (false
negatives). Also, JTCompare would fail to detect significant differences between two JT files. Not only did I substantially
improved the coverage of the PMI comparison class, I virtually eliminated all of the false positives that it produced.

By the time I was done with the project, virtually every aspect of the JTCompare utility had been improved in some way.
With my time expired and the project a success, it was time to return my attention back to PLMVis.


MFC Toolbar Bug Discovered & Fixed
During the SEV development phase, we noticed that the cloned toolbars possessed an unusual bug. Namely, a user was
frequently incapable of positioning two 3D toolbars on the same row. Mike, Crystal, and I had each independently
investigated the issue but could not figure out the root cause. The problem was then ignored for years.

One day, Jay was receiving customers complaints regarding the toolbar issue and asked me to take a more detailed look.
I began by gutting out the toolbar code and reimplementing it from scratch. Even after the reimplementation, the issue
remained.

At that point I grew suspicious of Microsoft’s code. I therefore put on a debug development install of Vis on my
computer and began to debug the issue into MFC source code from the MFC’s RecalculateLayout call. After only a few
hours after being tasked with fixing the bug, I had discovered the very lines of Microsoft code that caused the mischief.
Specifically, MFC’s toolbar repositioning logic calculated the impact of each toolbar’s border, but it failed to account for
the fact that the toolbar might not be visible. The bug went undetected by Microsoft because the miscalculation was
only off by a few pixels for each invisible toolbar; meaning that the issue was only apparent when a CFrameWnd had
enough invisible toolbars to cause the miscalculation to exceed the height of an entire toolbar row.

I could already test my proposed fix in Microsoft’s code by modifying the variables directly inside the debugger. I
therefore went to work and created a small test app that demonstrated the problem in isolation. To be more specific, it
was a single window containing two visible toolbars (and 18 invisible toolbars) and it was impossible to drag the two
toolbars onto the same row. I then sent the test app, bug description, and the proposed fix to Microsoft. About a
month later, they responded with a HotFix and the issue was subsequently resolved. Microsoft subsequently
incorporated the fix into their MFC code so that it was not a problem in later releases.
Windows Azure
One of my last projects on PLMVis was creating a prototype that used Windows Azure, Microsoft’s cloud computing
solution. The project was to create a 3D viewer in an applet that would load 3D product structure from Microsoft’s
cloud. However, what made the demo particularly interesting is that the content that was downloaded depended upon
which permissions the user had. This demo was performed at a JtOpen conference, and it remains special to me
because it was my first and only experience working in tandem with Microsoft developers.


Transition from PLMVis to AWS
I had mixed feelings when the news arrived that I would be reassigned from PLMVis to AWS. I had written a substantial
portion of both PLMVis’ Java and C++ windows code and so I will always possess affection for it. However, I also felt that
PLMVis offered few remaining interesting development projects and so I was psychologically ready to start anew.

I recall hosting a meeting in the conference room with the PLMVis team so that we could anticipate how visualization
might work inside of AWS. We exchanged lots of ideas and identified many things we wanted to do and change. Among
them was the idea of creating the VisClient. In reality, the meeting accomplished little. We collectively realized that we
simply did not know enough about the road ahead of us to take action.

It was at my PMP review meeting that Jay revealed that I would be responsible for SLClient’s Visual Navigator. At the
time, Jay called Visual Navigation, “The crown jewel of AWS”. At first I was admittedly disheartened. Although my
background had centered on a visualization product, my favorite work on the product had been framework-related.
However, after a couple hours of pouring over the idea, I realized the Jay was giving me a rare honor by entrusted me
with a very important task. I therefore embraced it and was determined to show my quality.


AppShare as a DLL
One early assignment that Jay had in store for me was to add AppSharing capability to AWS. I consequently dissected
the AppShare application source code and converted the entire application into a utility DLL that PLMVisUtils could use
at runtime to create and control sessions. Despite the fact that it worked great and was rigorously unit-tested, I
admitted to Jay that the solution was not scalable and would make for a poor long-term solution. This is because Visual
Studio’s MFC project-creation wizard tightly couples the UI and business logic right from the very beginning and
AppShare’s functionality was consequently distributed among AppShares many dialogs and user control classes. All my
DLL did was remote control the UI behind the scenes using threading and messaging tricks. The proper solution would
be to rearchitect AppShare such that the business logic was a separate DLL and then both Vis and the AppShare UI could
link to it. However, this would take many months.

Jay had other projects in store for me and so he retasked it to Matt McMinn. From what I can recall, Matt and the
original AppShare developer figured out a back-door way of tapping into the functionality that avoided using AppShare
as a DLL altogether and so together they eventually found an alternative solution.


EMM Strings to EMM Byte Arrays
One of the first things that Dan Lee and I had decided to do in preparation for AWS was to restructure the EMM system
to transmit byte arrays instead of strings. Dan took the Silverlight side and I took the native side. This required
significant effort since both the PLMVisSockets module and VPRMIService’s CExecMethodMsg class had to be
completely redesigned and reimplemented.
VisualNavigator and Silverlight
Jay referred to the Visual Navigator as “the crown jewel of AWS” because visualization was to be front-and-center in
AWS. Because of this I remember feeling very honored that Jay entrusted me with such an important chunk of his
product.

By this point in time, Dan Lee already had a test application that could connect to PLMVisSockets, open a file, push
mouse events down to Vis, and finally receive the resulting draw events back to Silverlight – and all in real time. The
module that his test application used was called the VisClient and the viewer control was called the SLContainer. My
responsibility for AWS 1.0 was to follow the Agile Software Development Process while writing the Visual Navigator,
which would be a massive wrapper around Dan’s SLContainer. Also, since the VisClient’s API was relatively thin, I also
ended up substantially beefing up the API support by wiring up new functionality from Visual Navigator all the way into
PLMVisUtils. By this time, I had also mastered adding complex dependency properties to the control.

The Visual Navigator was one of my finest works. The SLClient portion was completely my own design and my portion of
the code was remarkably stable despite all its complexity. But probably the single most innovative piece of the Visual
Navigator was the mechanism that governs the visibility and opacity of all the parts displayed in the 3D scene. I called
this mechanism “Hierarchical Set Theory”. The gist of the mechanism is that five different collections of
OccurrenceThreadPaths (VNT visible, VR visible, VNT Selection, In-Context Search, VR Selection) could be intersected to
determine what the scene should look like. Once this mechanism was employed in production code, there never any
problems relating to its implementation – it was a rock-solid piece of architecture.

By the time AWS 1.0 was delivered, I felt very competent at Silverlight. The data bindings, lambda expressions, and LINQ
queries that confused me at first had become second nature to me. Also, the client-side Visual Navigator code was
incredibly stable. I was quite proud of my work and felt satisfied in that I had learned so many new design patterns and
technologies.


Async EMMs in GWT
Aynchronous behavior was ubiquitous in AWS 1.0. Any time the Visual Navigator wanted to fetch data from Vis, it
would come back asynchronously. Also, the VisClient’s socket mechanism was asynchronous, but it had a complex layer
on top that made it look like it was synchronous. With most of the client leveraging ansychronous behavior, it made me
wonder why EMMs were synchronous at all. When I wrote the EMM-handling client code for AWS 2.0 using GWT, I
therefore made all EMMs asynchronous. This made each EMM substantially more thread-safe at the cost of bloating the
code to invoke an EMM.


EMMs with Object Serialization
AWS 2.0 utilized a technology which Andreas coined geometry slinging. Geometry slinging is the process of loading the
3D file on a server and transmitting all the geometric information to the client for all real-time rendering. Accurate
geometry slinging is a complex process that requires the serialization of complex objects over an IPC pipeline. To
support this, Andreas first wanted me to modify Vis to send several EMMs in a single socket transmission. However, this
had several limitations and after a long discussion with Andreas, he agreed that I should enhance the EMM system to
support the transmission of complex objects.

The requirement to pass complex objects via EMMs was the reason why I wrote the SerializableEntity class. A
SerializableEntity object is simply a byte array that has methods for serializing and deserializing the following types of
values:
       Primitives
       Arrays of primitives
       SerializableEntities
       Arrays of SerializableEntities

The EMM class itself is a SerializableEntity. An EMM is special case of a SerializableEntity because it also has header
information such as the method ID and view handle.

To support Geometry Slinging, five different kinds of objects required serialized over the socket, some of which
contained other complex objects. It was the introduction of the SerializableEntity made Geometry Slinging possible.


WebSockets
Edward Slavin wrote the original Triangle Slinging prototype using JavaScript. His prototype relied on WebSockets for
communication between the client and the server. It was his application which demonstrated how to use WebSockets
in HTML5 using Javascript. However, we were not using pure Javascript, we were using GWT, which made things far
more complicated. This was because every GWT WebSocket implementation in existence only supported transferring
strings, not binary. After hours of research, I discovered the reason. Google Chrome only recently fixed a bug that
prevented the use of binary in WebSockets. So, although Google Chrome supported binary in WebSockets, the GWT
implementations did not – yet. Therefore, I took preexisting WebSocket implementation and heavily modified the
source code to use binary instead of strings. After combining the use of my binary WebSocket with the use of GWTGL’s
typed array classes, I had a clean GWT WebSocket solution to the problem. Without a binary solution, triangle slinging
would be in jeopardy.


A Meditation on SDLC
At Siemens, I have employed the use of two different kinds of software development processes, Waterfall and Agile.
Waterfall’s strength is found in preplanning. By writing down your complete design and by obtaining the approval of
your peers, the developer increases the likelihood of having a high-quality product. Its weakness, however, is in how
much time and effort the process consumes.

Perhaps surprisingly, I have always loved expressing my ideas regardless of the medium (verbal, paper, video, etc).
Conveying complex ideas to others can be thought of as an interesting logic challenge. However, the appeal becomes
lost when the Software Development Life Cycle (SDLC) requires that the developer flush out obscure areas with
superfluous boilerplate information, and then obtain the approval of busy people who may only see a small portion of
the document as relevant to their work. Also, it is usually very difficult and time consuming to express complex designs
and systems cleanly on paper. For this reason, I was thrilled when I was told that we would be switching our software
development process from Waterfall to Agile. Jay told me that it was geared for rapid software development and that
based on my six year history of quickly implementing great ideas with great designs, Agile would suite me perfectly.

Agile is a great development process, but true-blue Agile is not what we used for Visualization in AWS. In Agile, stories
are decomposed into tasks and any developer should theoretically be able to complete any task in roughly the same
amount of time as anyone else on the team. Using Agile, we ended up with the same silos of domain knowledge that is
typically associated with the Waterfall development process. This is undesirable since one of Agile’s purposes is to
distribute the knowledge equally among all the team members. Despite our Agile implementation, our silos evolved
regardless due to expertise we each had prior to AWS. It simply made sense for us to develop code in the area where
we could benefit most from our own backgrounds. However, as an unintended side effect, as our niches became better
defined, the visualization scrum meetings also became more wasteful. Towards the first release, no one, save perhaps
the manager, understood what any of the other developers were talking about. Everyone in the scrum would listen
patiently and wastefully as each other person would in turn explain the construction of their black box.

I feel that Waterfall’s downfall is that it involves too much up-front design work and does not handle “gotcha”s well. It
also tends to get bogged down in the approval process. Agile seem to be the other extreme. Developers invest little
time in design and consequently need to redesign later as functionality was added to the product. I suspect that there is
probably a hybrid between these two approaches that would work better than either of them independently. This
should be investigated.


Call in the A-Team
I have a long history of solving problems cleanly and quickly, and on occasion even being the backup plan where others
have failed. I can recall five distinct occasions (some mentioned above) where Jay felt that an experienced developer
had spent too much time (weeks or months) struggling to solve a particular problem and asked me to either help out or
take over. On each occasion, a solution was found within two days. All software engineers are good problem-solvers,
but what I feel separates me from the rest of the pack is the hunger I have for the answer.


Conclusion
As the computing industry has changed, so too have my skills and purpose. I have led projects, architected and
rearchitected complex applications, simultaneously completed several complex projects at once while following the
SDLC, introduced new technologies, discovered and employed novel design ideas, and worked with customers to resolve
problems and add new functionality. I am proud of the engineer I have become and I will continue to passionately
pursue the horizon.

								
To top