Experience
Summary:
Baker is an OSS Library/framework for orchestrating (micro)service-based process flows (see here).
These process flows are defined using a java/kotlin or scala dsl. Baker can execute these flows with an in-memory (cats/cats-effect) runtime for
quick and stateless processes, or an akka cluster based runtime for persistent processes which can be long-running.
Since operations for akka clusters need specific knowledge, bakery was developed. This allows our team to operate all the akka clusters, while exposing it
as a service for other teams. Bakery is part open source, but our team also maintains
an ING specific implementation using ING frameworks.
Role:
-
Thinking of and developing new functionality.
-
Assisting other teams with their baker/bakery APIs (both new and existing baker/bakery users)
-
Operations for our bakery clusters (deploying new versions, resolving incidents)
-
Upgrading several consumer APIs to a newer versions of bakery with improved architecture (V2 to V3).
-
Helping bakery users with testability and improving service stability by providing both
interactive and
standardized kibana dashboards for their corresponding clusters.
-
Improving azure devops yaml pipelines to be more safe and automated.
-
Doing secure code reviews.
-
Working on a new API (which uses baker/bakery) for making sure negative interest rates are calculated on a per-customer level, instead of a per-account level.
Apart from delivering business value, it's helpful to use your own product (baker/bakery).
-
Migrating code from Java to Kotlin.
Technologies: Scala, Kotlin, Java, Akka, Cats, Cats-effect, Spring, Maven, Sbt,
Baker, Azure Devops Pipelines, Docker, Kubernetes, OpenShift, Angular, Typescript, NPM, NodeJS.
Summary:
New ING android app feature for becoming a new customer at ING.
The feature identifies the customer using a face and passport scan, requests user information such as
phone number, e-mail address and the product the user wants to open. Helps reduce traffic to physical branches,
as well as giving new potential customers the onboarding experience they expect.
Role:
-
Refining and developing new functionality.
-
Bridging the knowledge gap between frontend (Android/iOS) and backend (API) developers/teams.
-
Doing secure code reviews.
Technologies: Android, Kotlin, Gradle, Azure Devops Pipelines.
Summary:
Frontends and backend APIs for opening new consumer payment accounts
in the My ING environment, by branch employees or backoffice employees.
The APIs orchestrate the process of checking product and personal eligibility, requesting an iban,
the payment account, the my ing account, billing, debit card(s).
Role:
-
Refining and developing new functionality.
-
Leading technical alignment meetings where we discuss technical improvements for our
area in Amsterdam.
-
Simplifying codebase, improving unit and cucumber tests, improving the maintainability of the codebase.
-
Improving CI/CD pipelines, making them faster, more automatic and more robust.
-
Migrating our components from a Gitlab, Jenkins, TFS, Ansible and RHEL VM environment to a
Azure Devops Pipelines, Docker, Openshift/Kubernetes environment.
-
As a so called 'Security Champion' reviewing code for common security issues.
-
Investigating and resolving issues, often spanning multiple teams.
Technologies: Java, Kotlin, Spring, Maven, Gitlab, Jenkins, TFS, Ansible,
Baker, Elm, Azure Devops Pipelines, Docker, Kubernetes, OpenShift.
Summary: An application for supporting and empowering sales consultants to find and communicate to customers.
Enables the consultant in planning sales trips, customer call days and receiving customer orders.
Role:
-
As the team's tech lead and most experienced team member, taking the lead in figuring out which
technologies, libraries and architecture to adopt, and which not to adopt.
-
Representing the team when there are technical matters to be agreed upon between our team and other
teams.
-
Investigating and solving complex issues that arise, preferably involving team members to
spread out knowledge and preventing single persons becoming a bottleneck.
-
Refining user stories and working on architecture.
-
Developing frontend, backend and deployment script code.
-
Operations work and third line customer support.
Technologies: Scala, Play! framework, Typescript, Angular 2-7, RxJS,
SBT, Rest, MySQL, GIT, Gitlab, Jenkins, Akka streams, Google maps, Linux, Python 3, SAML, OAuth, gradle.
AWS: RDS, Elasticache, S3, ELB, EC2, Kinesis, Elastic Search, EKS (kubernetes)
Summary: The design chapter together with
the IT Director were responsible for architecture, technology choices and inter-team agreements. The
design chapter consists of the most senior members of the different teams.
Role:
- Representing the team in team multi-team architecture questions.
- Collaborating with other members to set up and improve inter-team/company-wide agreements, policies and processes.
-
Working on company-wide research and design on behalf of the design chapter.
In particular:
Data ownership/mastership policy
More and more teams work independently and data is spread across teams and components.
What are the responsibilities of being an owner of data? Together with the IT director I prepared a
workshop to discuss within the design chapter what these responsibilities are. Based on these
discussions I created a document, which after review by the members of the design chapter became the
data mastership policy document. This document describes in a very practical way the
responsibilities of being a data owner. It includes things like which documentation is required,
functional and technical requirements for services, how to handle changes and how to comply to security and privacy regulations.
Aanvragen architecture
Randstad Groep Nederland has a large monolithic legacy application. There is a push to split
the monolith into smaller applications to handle subsets of business-related and administrative
processes. I've been working on moving the part of the monolith that handles talent requests
(in dutch 'aanvragen' = a requests from a company to randstad for temp workers).
One thing complicating this effort is that the 'aanvraag' in the monolith has been also used
for a things that are fundamentally different. This means that different types of 'aanvraag'
in the monolith need to go to different new systems. I've talked to the different parties to
find out which parts need to go where, what systems need to be changed and how.
Kafka (proof of concept)
In a small team, we looked at what is needed to be able to use Kafka. We've tried hosting it
ourselves in AWS, and also looked at different suppliers for SaaS solutions. With this information
we made a recommendation.
Summary: An application for the sales consultant to register and administer orders (or 'aanvragen' in dutch) of the client.
Role:
- Helping design the architecture of the application that was going to replace the existing proof-of-concept.
More specifically
- Considered the short-comings of the current situation, the business ideas for the future and technical
trends within the company and in the industry to develop a list of technical criteria.
-
Used these technical criteria to evaluate possible frameworks and technologies.
-
Created a small POC for the top contenders and decided the frameworks and technologies to use.
- Becoming the team's tech lead in March 2016, after the then most senior developer leaving and starting a new team.
- Developing and maintaining backend services, frontend web applications, databases and data-pipelines.
More specifically
- Developing reactive, fault-tolerant, stateless applications and rest services.
- Developing front-ends using a combination of Play! and AngularJS.
- Deploying and maintaining amazon web services such as MySQL databases, EC2 instances and Elasticache.
- Developing data-pipelines using akka-streams, decoupling our applications from its peers.
- Developing zero-downtime deployment scripts for continuously deploying the resources mentioned above to AWS,
becoming one of the first development teams to be responsible for both dev and ops.
Technologies: Scala, Play! framework, Javascript, AngularJS, SBT,
Rest, SOAP, MySQL, GIT, Gitlab, Jenkins, Akka streams, Linux, Python 3, SAML, gradle.
AWS: RDS, Elasticache, S3, ELB, EC2
Summary:
Rebuilt a section of the application for administering time sheets. The web-application is now mobile-first and provides
a good user-experience.
Role:
Backend application development. Designing the user interface. Designing services layout.
Technologies: Java, Spring, Hippo, Java servlet pages (jspx), SOAP,
XML, SVN, Jenkins, Maven.
Summary:
Rebuilt a host of web application pages from Oracle ADF into Hippo (currently called Cloudreach)
components.
Role:
Backend application development.
Technologies: Java, Hippo, Spring Framework, JSP/JSF, SOAP, SVN,
Jenkins, Maven
Summary:
An upgrade of the MWP application (described below) from Oracle ADF 11g to 12c.
Role:
Individual project, backend development
Technologies:
Java, Oracle ADF, Spring Framework, JSP/JSF, SOAP webservices, SVN, Jenkins, Maven
Summary:
An application in support of a new business idea. The business idea was discontinued rendering the
application obsolete.
Role:
Backend application development.
Technologies:
Java, Oracle ADF, Spring Framework, JSP/JSF, SOAP webservices, CSS, SVN, Jenkins, Maven
Summary:
Built a backend application for handling incoming job applications.
Role:
Backend application development.
Technologies:
Java, Oracle ADF, JSP/JSF, Business Components, SVN, Jenkins, Maven
Summary:
Web application for clients and people who work through Randstad/Tempo-team/Yacht. The application
contained many different features like logging hours, calling in sick for employees, or approving hours
and requesting a candidate for clients.
Role:
Backend application development, working on the service bus, creating releases
Technologies:
Java, Oracle ADF, Spring Framework, JSP/JSF, Oracle Service Bus, Oracle SQL, SVN, Jenkins, Maven
Summary:
Took several technical courses in Java, SQL, Network programming (in C), C++.
Built an application in C# for comparing commercial off the shelf applications for my Master thesis.
Technologies:
Java, SQL, C, C++, C#
Summary:
Before developing applications professionally I created several applications for
personal use.
Replay reporter
As a beta tester for a game (Dota) and was supposed to make a report after every
test game. This application extracted some information from the replay, made a screenshot and used
this to create a report automatically.
GHOST++
Personalized a warcraft 3 bot, which also hosted games.
StreamRipper
An application to download radio streams and split them into smaller parts so that I could put them
on my mp3 player.
WebpageMp3Downloader
An application that looked at a webpage and downloaded all the mp3 files on that website.
LanOverInternet
An application that sent fake UDP multicast packets so that you could play a game that was meant for
playing on LAN over the internet.
UDPTunnel
An application that connected to the same application on another computer and tunneled all UDP
traffic so that you could play certain LAN games over the internet.
MW2AntiLamer
Used packet sniffing and sending fake incorrect data to a modern warfare 2 server so that a certain
player (cheater) would be kicked from the server.
Technologies:
Visual Basic .NET, C#, C++, TCP/IP, UDP, WinPCap, Windows Forms, Windows Presentation Foundation
