curriculum vitae

CURRICULUM VITAE
Name:
Kai Hackemesser
Address:
225A Karori Road
Karori, Wellington 6012
04 973 6667
Home phone:
Work phone:
Cell phone:
021 078 77 46
Email Address:
[email protected], [email protected]
Work status:
I am a citizen of Germany. I am in New Zealand on a restricted Work
Visa which is valid until 6 June 2011. (PR application issued
December’09). I am permitted to work as Senior Java Developer in
Wellington.
EMPLOYMENT HISTORY
Dates:
May 2008 – current
Organisation:
Energy Intellect Ltd., Wellington
Energy Intellect is a company with more than 10 years history in
building managed meters and managing them with their own
applications. They are the only company worldwide that have the
hardware as well as the software developed inhouse. Their customers
are mainly in the NZ and AU markets.
The software team has about 15 members, including testers. Agile
Development was used to manage the team targets.
Position:
Senior Java Developer
Reported to:
Project Manager
Responsibilities:
As Senior Java Developer I was responsible for maintaining and
further development of four products, three of them were web
applications, one was a standalone Java application. I’m handling
problem support in second level support and training junior
developers.
Project Clariti
I was responsible to improve performance issues of the web interface.
Clariti is a web front-end that allows customers to display graphs of
metering data in various ways to compare and analyze data streams
related to meters and connection points. I improved performance by
adding filters to the web page to add cache-enabling, compression
and script-optimizations to reduce the number of required connections
and amount of data to be transferred per page call.
Project iBO
I was responsible to add new features to many reports and to improve
performance of database queries that feed them. iBO is a
management web application that allows to create reports on meter
configurations and customer-related data, as well as automated
billing; it is used to configure meters and their communication data
and associate meters with locations and responsible organizations,
too. Most of this data has a time dimension.
Both applications are written as JSP container using common
frameworks as Struts, Spring and Hibernate to connect to the
database back-end. They run in Tomcat web containers using SQL
Server instances as database back-end. The test and production
environments are Linux systems, the development systems mainly
Windows XP.
Project CSV Importer
I was building a new application to import external metering data in
two different CSV formats into the companies’ databases. The
Importer runs as a scheduled job with a file scanner that upon
detection of a new file starts its processing. It is able to automatically
handle files that are compressed in any of the major formats. It is
able to import multiple files in parallel threads and creates
automatically Metering configurations for unknown meters on
detection. The Importer is a module of the company's Scheduler
application that runs standalone using Spring and Quartz frameworks.
Project ECG Gateway
The Gateway is a linux based device that communicates to meters
connected to it via TCP/IP, RS485 and other protocols and provides
relay functionality to customers accessing these meters via Modbus
protocol or TCP Rs485 emulation. I was working on the administrative
web interface and on improvements on the emulation features.
Major
achievements:
Speeding up t-SQL stored procedures used in critical reports that tend
to time out after minutes to run in less than 20 seconds.
Improving access speed to Clariti web application for customers in
foreign countries by 60%+.
The team appreciated my troubleshooting skills.
Exposure to state of the art technologies as JPA, Spring, Hibernate.
Used tools like Eclipse, Maven2 in Windows and Linux
Dates:
September 2007 – March 2008
Position:
Senior Java Developer (freelancing, contract with Hays Germany)
Reported to:
Project Manager
Responsibilities:
Project BOB Text – September 2007 to February 2008
“BOB Text” stands for a new application in the Kreditwerk application
suite “BOB”, which is the result of a large scale transformation
process from old 3270 terminal based mainframe applications written
in Cobol/Assembler to a new Client/Server application with a
comfortable GUI written in Java. As there are many application
moving into the new framework step by step, the framework still
needs to bridge to old mainframe components and an emulated 3270
terminal.
The project team size was about 25 to 30 people working on different
tasks, we had a team for COBOL/MVS development, a team for Java
development, a team for the web administration tool development, a
domain experts team for testing and take over, and a team for letter
design.
Kreditwerk uses JBF (Java Banking Framework) API V1.0.6 as base for
their own framework “XBF” (extended Banking Framework). JBF
allows easy binding between the data model and the defined GUI
fields or command buttons.
They have developed a framework for MVS RMI called ORBX2
(http://www.orbx.de/). The definition of method signatures and the
data model is done by modifying a Rational Rose UML model, followed
by an automated code generation process for both the COBOL
copybooks for MVS and the corresponding Java interface.
The target application server was a BEA Weblogic V8.1 running on
AIX.
The letter editor was “Formstation” from “Invaris”
(http://www.invaris.com/k2_technology/k2_frameset_e/k2_frameset_
e.htm) which we implemented as custom swing component in our
framework.
The source code and library repository used by all Kreditwerk projects
was Rational ClearCase.
The project task was the development of an application to create
automated business letters.
There where following mayor requirements (to the Java developer
team):
● Letters consist of prepared text blocks but the Account
Manager is able to modify the letters by adding/removing text
blocks and even add text manually in a visual editor.
● All given text blocks contain variables which can be replaced
with actual data from the clients accounts, stored in the
mainframe database.
● The Account Manager can see a letter in preview with sample
data before further inputs.
● The Account Manager could decide between a German or a
French version of the letter, depending on the receiver.
● The Account Manager can select between different types of
data holders to fill the variables in the letter accordingly.
● A letter could be sent to up to 19 receivers, either as a 1:1
copy or as a reduced one without attached forms.
● The resulting letters could be bundled to be sent to one or
more receiver by address, for instance the Account Manager
who visits the customer.
● The letters could be sent additionally by email or fax, too.
● All paper letters will be processed in a batch job at the the end
of the business day.
● Development for JDK 1.4 Environment on client and server
side, but with Java 5 compatibility in mind.
The team size of Java developers was actually three persons. The
team leader was responsible mostly for communication with the
domain experts about mask design and the business process, and he
was working with Invaris people for required new features in
Formstation and to get it error free; I was almost responsible for UML
model design, database table design and Java implementation. The
third person was drawn to some task outside of this project, so I took
over his responsibilities soon.
Each application in this JBF/XBF framework is called a “makro step” or
“MAKS”, while each mask that the user has to pass in this application
is called a “mikro step” or “MIKS”. The user enters data into each
step's mask and proceeds. Our MAKS consisted of five “MIKS”. The
first one was for selection of the required letter and language, with a
search function for letters by keyword, a browse function to view
letters organized by business case and a preview function. The second
one ask the Account Manager for the source for variables, which could
be a clients account number, a loan identifying number, a bank code
number, an Account Managers ID and some others. Another number
was required to identify the receivers address. Some letter may need
more identifying numbers for special text blocks. It was even possible
to proceed this mask without a number for the address, but then an
extra step has to be passed to enter an address manually. Between
this step and the next step, the letter's raw data was retrieved from
the mainframe system, using the prepared ORBX interface, sending
data entered so far. On mainframe side the retrievers address data
was prepared into finished postal address lines, the variable data was
retrieved using the parameters given. As return data we retrieve a
kind of raw ASCII format describing the required letter base, the used
text blocks and set variables within. This data has to be send to an
Invaris DCS Server using a special EJB call. The main purpose of the
DCS server is to read an incoming request document and handle upon
it, for example returning a refined document or creating files for
further processing. In this case the call returned a binary “DDO” file
which the visual component of Invaris can display and modify.
Since “Invaris Formstation” is written in VB they delivered only a
automatically generated Java API which does the native calls to VB
DLL's in background. This leads to method signatures which where
looking awful to Java developers, for instance they use integer 0 and
1 for boolean values, or they use pointers to VB objects which we had
to convert into basic Java objects each time we had to modify
anything in the letter. So I suggested and implemented a helper API
to encapsulate the basic API, making it more transparent,
documented and comfortable to other developers. This saved us much
time in later development and made our code more readable.
The third MIK step of our application was splitted to two screens, one
for the Editor component and one for the actual MIK. Here the
Account manager can see the letter, as well as creating copies to
other receivers, how many printouts should be made, if transport
should be made by fax or email, if an TXT information should be sent
to a mobile. If the Account Manager wants to create copies to other
receivers, a forth MIK mask was presented to him to enter a receivers
account number or comparable to retrieve the address from
mainframe, or he could enter an address manually, like in second
step.
Almost all business logic behind the masks on client and on server
side was created by me. Just things happening behind the mainframe
or the DCS server haven't been influenced by me. The GUI design was
partly made by me. I was responsible for the JBF data model and the
method signatures to the mainframe server.
At the end of the business day a batch triggered process should start
the processing of the letters written that day. This means all letters
staying in the database table so far should be sent to the DCS servers
to be prepared for the printer queues and the stamping algorithms.
Since there were four DCS servers available this batch job should be
running multi threaded to become up scalable. I decided to use the
BEA CommonJ API to have a Workmanager handling this
multithreading work queue on the BEA Weblogic server. BEA V8.1
doesn't come with a workmanager built in, so we installed an open
source implementation called XcommonJ. We found on testing that
this implementation is not able to handle more than some hundred
jobs coming in at the same time. There were serious problem when
serializing the work units in the JMS queue. I took the sources from
XcommonJ, made some deep changes like don't saving EJB handles in
the queue but serialized work items. This lead to an performance
increase since before the change the XcommonJ Workmanager
created one stateful EJB for each incoming work item and stored the
handle. This lead to a need of a huge number of EJB's to be hold
either in memory or serialized on the hard disk. We removed this
completely but decided to make our work items serializable and put
them into the queue directly. This lead of course to changes in the
message driven bean that had to receive the work. After all it got a
very fast and stable Workmanager implementation, that can stand a
work list of the expected 20,000 letters per day. The number of active
MDBs of this workmanager implementation can be modified by the
deployment descriptor, so if in future there are more DCS servers
installed, our side of the system is upscalable. I also was responsible
for the class that selects and sends the work to the workmanager, as
well as doing the expected communication with the DCS server.
The database in background was a DB/2 for MVS, V8. The production
requirements were to use SQLJ for any kind of query to the database,
and all statements have to be bound to the database before they can
be used. This version of DB/2 wasn't able to handle stored
procedures. I had to write accessor classes for our modules which
needed to be interpreted by a SQLJ preprocessor.
Kreditwerk uses a slightly modified EJB 2 system. Beside of the
common EJB interfaces they defined a factory and a worker class.
The factory decides upon application configuration, how the worker
has to be called. It can be running as standalone rich client, doing all
the work on client side, or it can call an Application Server EJB for
function calls. This lead to the common problem that each methods
defined once had to be defined manually in seven classes or
interfaces. I suggested to use XDoclet for automated interface
creation, but the deployment process of Kreditwerk is somehow
written in stone and can't be modified so easy.
After end development phase in January we had a month of deep
testing by the domain experts, who brought up about 90 smaller to
mayor bugs or missing requirements which we fixed together in about
20 days.
Project Framework Upgrade to JBF V2 / Java 5 – March 2008
My responsibility was to find and remove problems in code resulting
from an upgrade to a new version of JBF/XBF. I could remove all
incompatibilities, beside of two where the JBF designers have to come
with a patch/update.
Project Framework Enhancement: View Manager – March 2008
JBF is build to handle all MIK steps in a single Window/JFrame. Our
Application BOB-Text had the requirement to show a separate editor
window. We solved that using some basic swing components and
emulating the bindings between the JBF model and our GUI. This
created the requirement in the Frameworking team to present a
common solution which makes the developer independent on the
information where the GUI component is in fact presented. I got
responsible to create this solution. I created a small API where users
can call the so called “View Manager” to show a visual component
(swing or heavyweight), together with some properties telling the
view manager how it should be displayed. The view manager can but
isn't forced to use all of this properties to decide in what kind of
Displayer the component is finally displayed. I defined three basic
displayers: a JFrame displayer who displays each component into a
new JFrame. The displayer can be configured for the left or the right
screen. Another displayer was the tabbed displayer, who would show
the components tabbed in a single Jframe. The third displayer was the
dialog displayer, who could display components as modal dialogs. The
displayer configuration is made by the framework on application
startup. Each component registered to the View manager gets a
unique Id which can be used by the application to show or hide the
component using a view manager method. If the component isn't
needed anymore it can be removed from the view manager. All
occurring window events where encapsulated into View Manager
Events which can be used by the application to monitor the state of
their component.
After creation of this View Manager API I had to do a demo
implementation in BOB-Text where we had made use of separate
windows. The implementation proved the usability of my code and it
also led to some nice simplicity in the code because all GUI logic
about Frame/Event handling could be removed.
Major
achievements:
Finished BOB-Text in given time, with some 20 days bug fixing while
test phase.
Exposure to banking domain, BEA Application Server, Developing
Framework API for Invaris Document Editor and self designed View
Manager.
Deep exposure to J2EE techniques and banking domain background
Dates:
May 2007 – August 2007
Organisation:
Avitech AG, Friedrichshafen, Germany
Avitech AG is one of the leading international technology developers
of IT systems for the aviation industry. They employ about 400
permanents.
Their software “AviSuite” is used bei Deutsche Bundeswehr and on
multiple international airports for management of flight data. It
creates reports for pilots, giving them important waypoint instructions
and information on starting and landing airports – as well as
important information about weather and dangerous things they will
encounter on route.
Position:
XML Report Designer (freelancing, contract with ASSPro, Germany)
Reported to:
Project Manager
Responsibilities:
“Avisuite” was using FOP 0.20.5 in that development phase, which
was deprecated. My first task there was to replace it with the most
current version 0.94. Since the API has changes significantly between
those versions it took some effort to reproduce the used functionality.
For instance the new FOP API is changed to fit to the
javax.xml.transform API, the old was more independent.
FOP was used to preview PDF reports before printing as well as
creating and printing these reports.
My next task was to reproduce some reports. The older version of
AviSuite created simple formatted ASCII reports from given database
data. The version we were working on created the data in XML
format, so it should be possible to customize the resulting reports on
demand for several customers around the world. For instance
Bundeswehr want's the output using a document format identical to
their manual forms. My task was so to create at first ASCII reposts
similar to the ones from old AviSuite using XML-XSLT transformation,
but also doing some special requirement reports for certain
customers. This was sometimes a very complex task, because XSLT
V1 doesn't give all means to do calculations, groupings and sortings
that were needed there. Instead I had to create XSLT “methods”
doing some calculations for me. I one case I even had to create an
external Java class to solve a requirement.
I created a URL resolver which could lookup files placed in external jar
files. The software architecture of AviSuite was planned in a kind that
resources should be placed outside of the application code in separate
jar files or directories. So customers could add their own resources
(reports for instance) as needed. The default URL resolvers used by
SAX and FOP created problems resolving all kind of URL's. My version
was more flexible and helped much resolving all kind of URL's from
application or from inside the reports.
I also created a test JDBC driver for the application testing. Because
sometimes it was needed to redirect some queries to another DB to
do some monitoring/measuring, but the software forced a fixed JDBC
datasource, I created the so called “MockupJDBCDriver”. From outside
it was instanciated with a target DB connection and a Driver class to
knock out. I then removed that Driver class from The JDBC driver
manager and replaced it with itself. So as soon as the application tries
to use that other driver (for instance an oracle driver) it actually uses
the mockup driver with its fixed target datasource.
Major
achievements:
Learned much about Maven 2 in Software architecture. Exposure to
aviation domain. Deep exposure to XSLT processing and possibilities
of Apache FOP 0.94
Dates:
February 2007 – March 2007
Organisation:
Service Zentrum Bayern (SZB), Nueremberg, Germany
SZB is the largest service partner for savings banks in Germany and
is handling transactions between 120 mandants in 8 German
countries, resulting in ca. 160 million transactions per year.
Position:
Web Designer (freelancing)
Reported to:
Team leader
Responsibilities:
SZB had the requirement of an administrative application to allow
some actions their current software doesn't offer. These requirements
where:
● All ATM machines report every night their current fill state.
They want to see which ATM machines didn't send or if their
report was not complete transmitted
● Their software created automatically refill orders to be sent to
client banks and their money transport companies. They want
to preview that orders with possibilities to void them, and then
the rest should be sent by fax or email to the corresponding
partners.
● They want some statistics pages for different business data,
like orders per money transport company and such
● They want a respond link page where the money transport
company specialist can confirm the order reception and later
can mark it as accept and completed.
This project was a pilot, means, we should only create basic
functionality to prove the ability and possibility of the application.
The projected time range was 5 weeks, the team size was four
people, my responsibilities was the setup of a Websphere application
server and needed resources. Then I had to prepare the web pages as
described in the requirements, using JSP and JDBC. Since time was
short we decided not to use advanced techniques like tag libraries,
but the application backbone should be designed with SOA in mind.
We had some trouble setting up our development environment
properly, since RAD 7 had some flaws and bugs, what lead to some
reoccurring misconfiguration's. The project organization was not well
dome, because results were expected very early. I had to do the
website design about three times, first time a simple blender with
static data behind to present a first frontend, a second one with a
finished model, and a third time after we found that the designed data
model wasn't representing the customers model in a right way. Of
course only some loops and queries had to be redone, the HTML/CSS
design wasn't affected.
The pilot project was finished successful almost in time, but the
expected following assignment wasn't made, since SZB started a
merger/relocation process and their project was put on ice.
Major
achievements:
Exposure to JSP, RAD 7 and IBM Websphere Application Server 6
Dates:
September 2006 – January 2007
Organisation:
DB Systems, Frankfurt a. M., Germany
Position:
Senior J2EE Developer (freelancing)
Reported to:
Team Leader
Responsibilities:
DB Systems is the IT system partner of Deutsche Bahn Group and is
supporting 80.000 users in about 380 productive IT systems. It is
maintaining thousands of user desktops and software products, as
well as creating DB specific applications.
Project Trassenportal – September 2006 – December 2006
Deutsche Bahn is in a changing progress from a before governmental
owned monopole railway corporation into a private owned company
that has to deal with competition. They now have to make their
railroad network available for other companies, that need to purchase
passing rights on certain network passages for either a single time or
on a regularly base. This led to the requirement to create an
administrative application where these other companies can enter
their passage wish or could change it later on.
My task was to help creating this application. Their domain experts
already had made a good analysis on the expected business cases
and supported us with many charts and decision tables and
documentation describing all possible flows and we only had to code
it.
The team size at DB systems for Java Application Development was
about 10 persons. About 3 – including myself - where responsible for
the part of the application described now:
A customer had first to select a train number. These where either
drawn from a number pool reserved for the customer or it has to be
an individual, free number, depending on the customer type. Our
software had to check if the customer selected an appropriate
number. (We created an administrative tool, too, to assign train
number pools to customers.) Then the customer had to enter
parameters for the requested train route for later use, as a starting
and ending train station, number of locomotives, power of the
locomotive, its braking capabilities, number of wagons, kind of load
and many others. These parameters must have been entered by the
customer to proceed.
If the values make sense, his order was accepted and forwarded into
a “task box” of an route specialist. The customer could see in his
“task box” all his requests and their state. The specialist uses the
given parameters in another part of the application (were I wasn't
involved) to define the actual possible train route, exact start and end
times, conditions and of course a price. Or he could deny the request
because it wouldn't fit into existing route usage.
I was working together with my two colleagues to implement these
requirements, designing GUI, handling distant server calls, JDBC to an
Oracle DB, and so on. All methods we created were tested against
JUnit tests while developing.
The application is running on a Bea Weblogic Server and functionality
on distant servers was called using RMI via dynamic proxy classes. All
code was written in Java 1.4. DB Systems used a self made GUI
framework to make it more easy handling data tables on screen and
to provide a unique designed front end for all application parts for
Deutsche Bahn.
Project Functionality Test – January 2007
When our Application was finished I was transferred to the testing
team. We had to simulate request of routes, creation of routes,
accepting/denying of routes in hundreds different variations.
Major
achievements:
Exposure to transportation domain, Java development, working with
Proxy calls.
Dates:
August 2006
Organisation:
Pixel GmbH, Munich, Germany
Position:
Web Developer (freelancing)
Reported to:
Project Manager
Responsibilities:
Project “e-gas”
Pixel is a software consulting company with about 100 permanent
employees. They are creating applications for private companies and
governments.
I was substituting a person going on vacation in a project that was
ending shortly in future. About 8 People were working on the final
development of the application.
“e-Gas” is a web application for management of transactions in the
European natural gas market. Anyone in Europe who is dealing with
natural gas has to care for a transportation route between source and
sink via certain pipes and knot stations. The gas must not be mixed
with gas from other customers, because each load has certain
parameters of pureness or mixture, so a route also contains
information about the time of transportation. This application is made
for the management of gas transportation contracts. My part of the
work was creating a few dynamic web pages using JSP and Struts.
The complexity within this project lies in a data model where any
change of almost any data has a timed validity. For example if a
company name changes, one record had to be updated about when
the name gets invalid, and another record contains information about
when the new name gets valid. You could change the view date of a
contract to a point in past and all data you see is then what was valid
at this time point in past. On one hand this lead to great flexibility, on
other hand it makes database queries more complex. I helped
designing the queries for extracting timed data, too.
The view page of contracts also showed a time table when and how
much gas from a certain quality has to be transported per day from
where to where. For dates in the past it has to be shown how much
actually was transported. These values are recorded hourly at every
knot in the net. The contract data also define how much this values
are allowed to differ.
The application was backed with stateful EJB's, and I had to create
some EJB methods for my web pages. Pixel used XDoclet and Ant to
do an automatized code generation.
Beside of the simple display of these contract/actual data, I had to
create an export functionality to an MS Access application as well as a
PDF report page. I made both of these Exports by first generating a
xml source file containing all relevant data, and then creating a XSLT
transformation file for it. The transformation was done on server side,
and then the result was shown to the client. Of course my http
response used the correct information to let the web browser start the
right application for it.
Major
achievements:
Exposure to the Energy Market domain, Handling data with timed validity,
development of JSP using Struts, XDoclet, EJB.
Dates:
March 2004 – July 2006
Organisation:
UGS Solutions GmbH, Stuttgart, Germany
UGS is a leading global provider of product life-cycle management
(PLM) software and services with nearly 4 million licensed seats and
46,000 customers worldwide. They were recently bought by Siemens,
Germany. One of their leading products is “TeamCenter Enterprise”
(TCE, earlier named “Metaphase”) for management of product data.
Position:
Senior IT Consultant (employed)
Reported to:
Project Manager
Responsibilities:
TCE is very customizable in its data structures, methods and front
ends. It supplies a basic thin client (web front end), a Java based rich
client (for CAD data management) and a Background Server, which
are connected through a three-tier-architecture. TCE needs a servlet
container like Apache Tomcat for Rich and Thin Client functionality, or
any modern Application Server. This architecture supplies customers
with about 80% of all what they need for their product data lifecycle
management. The missing 20% of features can be customized into
either by the client itself or by trained customizers like me.
UGS arranged further education to me to make me able to customize
and administrate TCE. After two month of training and even a three
week period working together directly with software developers in
their development center in Minnesota, USA I was sent to customers
to support them in customizing their requirements into TCE.
Project Wörwag, February 2006
I was needed as expert for the TCE reporting engine. Wörwag was a
pilot project, since it was the first customer in the varnish and color
domain using TCE for management of its color recipes. A team of
three people was working on fulfilling the basic requirements for this
project. The data model had to be modified, the web front end had to
be extended, and there should be a report output comparable to their
forms used to that date. My task was beside of helping with
installation and administration to create these reports using the
available XML output from TCE to create XSL-FO stylesheets for the
final reports. I've learned XML/XSLT/XSL-FO transformation for this
project, and the reports were looking acceptable to the customer. I
can't tell if this project was a success finally, when I left UGS they
were still in decision process.
Project BEHR January 2005 – July 2006
BEHR is a leading international company producing climate
aggregates for automotive usage with more than 60,000 people
employed. When I was needed there they had a software release
upgrade going on from an older TCE version. They have built in house
their own rich client application for TCE. For TCE I installed a new
Websphere Application Server installed on a Sun Solaris platform and
was responsible for administration and deployments for the next few
months. After the new Version was going live, I was taken into a 5
head development team to implement new features into their local
rich client application. For me this was almost GUI building, doing
some basic business logic tasks and calling the backing server
methods for any kind of data.
Beside of these tasks there was a major pain about TCE at BEHR side,
because they had large performance problems. I got the task to
deliver some solutions. At first I tried to optimize the local client
application. The start up time of the client was about two minutes at
the beginning. By paralleling some of the startup procedures as well
as optimizing the classloader algorithms I could half the startup time
to about a minute. I also found some bad code style in some
component preparations, so I could for instance speed up the filling
time of some combo boxes by factor 30. On the way I also optimized
some GUI focus problems to make it more comfortable, as well as
reducing some memory needs. This was very appreciated by the
BEHR employees.
Another performance problem was caused by a huge amount of data
that was exchanged between the TCE server and the client
application. After measure we found that about 10MB of data was
transferred transparently – just on log on. Since some of the clients
from other continents were connected to the server just via a small
shared 2MBit connection or even just a ISDN dialup connection, this
was a huge bottleneck. I designed a small proof of concept application
in Java using a compressed channel via TCP connection. It works like
a SSH tunnel, but it had a small monitoring web interface to display
the average compression rate and the amount of data that was
compressed in a browser, as well as to open/close channels. I used
Java channel technology instead of streams to make use of faster I/O.
After all this tunnel created less then 10% delay for the transfer, but
compressed the transferred data by more than 90%, resulting in a 9
times faster startup of clients behind small bandwidth connections.
The results where so impressing that they took the tool at once into
production.
Another area where I was responsible for was the creation of HTML
reports from the TCE XML reporting engine. The reporting engine at
this time created a flat list of product part data and their relations to
other parts (parent-child relations almost). In my reports I had to
reorder that data some times to create a hierarchical tree structure
and then to display it in a dynamic HTML report that need to be
printable. BEHR was a very satisfied customer when I left the project.
Project Daimler-Chrysler April 2004 – December 2005
Daimler-Chrysler is a large automaker in Germany with a large R&D
department. They use TCE for many years in their development lifecycle.
I was there to help them customizing the new TCE Rich Client for use
at their CAD development. My first task was to be the single point of
contact (SPOC) between Daimler developers in Germany, EDS/UGSDevelopers in the USA and Daimler developers in India. I collected the
requirements Daimler wanted to implement in the rich client and took
them with me to the developers in Minnesota, to see what is possible,
what not, and how long an implementation would take. Together with
another developers in USA we modified the Rich Client API for some
of the features, that weren't so difficult to realize, but some of the
requirements were not easy to implement and I hat to report later to
Daimler that it would take many more man-days then expected to
implement that. Daimler decided to not implement these features and
I supported them until end of the year with other customization tasks.
Major
achievements:
Good understanding of J2EE, Web services, Web applications in JSP,
Servlets. Various Application Servers, Deep exposure to TeamCenter
Enterprise Software.
Deep Exposure to XML transformation.
Dates:
February 2003 – February 2004
Organisation:
Nestlé Globe Center, Frankfurt a. M., Germany
Nestle Globe is a project to unify the nestle IT infrastructure between
all facilities.
Position:
Middleware Expert
Reported to:
Team Manager
Responsibilities:
2nd Level support, Middleware Administration
Major
achievements:
Understanding of MQ Series / Websphere MQ, Middleware architecture,
AIX administration, AS/400 Administration
Dates:
July 2002 – January 2003
Organisation:
Ton & Tronic GmbH, Darmstadt, Germany
Ton & Tronic was a small software forge, creating hard-/software to
smaller companies.
Position:
Visual Basic Developer, Crystal Reports Designer
Reported to:
CEO
Responsibilities:
Creating a VB application using an old Foxpro application as pattern.
Creating Reports comparable to old Foxpro reports.
Major
achievements:
Visual Basic Development, MS Access knowledge, Chrystal Reports
Reporting Engine
Dates:
Organisation:
Activest, Munich, Germany
The Activest Group was the asset manager in the HVB Group, the
second largest bank in Germany.
Position:
Java Developer
Reported to:
Team Leader
Responsibilities:
Creating a performance test program to simulate user access to a
web application, with interpretation of the server response,
automated form filling and sending. The program should measure
response times and should fire its requests in parallel with a
configurable number of simulated users at the same time.
Major
achievements:
HTTP, DOM, HTML, JDBC, Interbase SQL
Dates:
May 2001 - April 2002
Organisation:
Deutsche Bank, Frankfurt a.M., Germany
Deutsche Bank is one of the world’s leading international financial
service providers.
Position:
Cobol Developer
Reported to:
Team Leader
Responsibilities:
Creating a conversion program to convert customer accounts from
local european currency to EUR currency in a batch job using a MQ
Series API.
Creating an administrative module to modify online banking card
holders data.
Major
achievements:
Cobol Development, MQ Series, MVS, DB/2
Dates:
November 1999 – May 2001
Organisation:
Deutsche Telekom AG, Frankfurt a. M., Germany
Deutsche Telekom is one of the world's leading telecommunications
companies.
Position:
Network Engineer / External IP Specialist
Reported to:
Team Leader
Responsibilities:
Management of custom IP networks, Setup of VoIP servers and
networks, writing a administration application for RAS-configurations,
writing an application to record project related work time.
Major
achievements:
ASP, JSP, Java, Scripting, IP Networking, DB2, MSQL
EDUCATION/QUALIFICATIONS
Completed qualifications:
Institution:
City/Country:
Qualifications:
Year completed:
Sun Certification
Institution:
City/Country:
Qualifications:
Year completed:
Specialized high school
Stuttgart
Sun Certified Java Programmer (SCJP)
2006
Nidda, Germany
Specialized university-level graduation in electrical engineering
1994
Partially completed qualifications:
Certification as “Sun Certified Java Developer” – in process, will be finished 2010
Study for a German Diploma in “Applied Computer Science and Mathematics” at “University
of Applied Sciences” in 1998 in Fulda, Germany – will not finish this but may try to use
reached papers to get a comparable Bachelor qualification degree.
TRAINING COURSES ATTENDED:
2006 – LP IT Training course “Enterprise Java Beans” in Germany
PROFESSIONAL MEMBERSHIPS
Mena in NZ - www.mensa.org
HOBBIES/INTERESTS
Reading (History, economy, politics, technical books, science fiction)
Internet, Further Education, Family, Genealogy, Handwork, Electronics