curriculum vitae
Werbung
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
