Alexandre Seguin

#7663995
19/07/16

Internship in France for Olea Medical Solutions

Dear Stéphane Somé,

Having just completed the second year of my studies and going on my first internship, it is
surprising that it was done overseas in France. The attached internship report concerns the work I
have done at Olea Medical Solutions under the supervision of Cyril Di-Grandi, current acting CTO of
the company. More specifically it is about the project that was assigned to me during my stay in
Marseille (although I worked in La Ciotat). It will detail the problems I encountered while finding the
solutions necessary to complete the project, describe the knowledge I have acquired in the midst of
developing it, things I could’ve done differently in hindsight and my take-away from the experience.
The report will be written by me for you reading, hopefully it might help provide you some insights
on how this opportunity has helped me further my career.

Sincerely,
Alexandre Seguin
Internship in France for Olea Medical Solutions

By

Alexandre Seguin

#7663995

Submitted to

Stéphane Somé
For the course

CO-OP Mobility International 2016

(COOPMOBI)

University of Ottawa

August 18, 2016

1
Table of contents
Summary ................................................................................................................................................. 4
Introduction............................................................................................................................................. 6
Olea Medical Solutions ............................................................................................................................ 6
Background.......................................................................................................................................... 6
Reason for project ............................................................................................................................... 7
DICOM standard ...................................................................................................................................... 7
Description .......................................................................................................................................... 7
Structure .............................................................................................................................................. 7
Hierarchy ............................................................................................................................................. 8
Library .................................................................................................................................................. 8
Vaadin Framework .................................................................................................................................. 8
Framework Overview .......................................................................................................................... 8
Vaadin Components ............................................................................................................................ 9
Listeners .............................................................................................................................................. 9
Themes ................................................................................................................................................ 9
Interface ................................................................................................................................................ 10
Progress over development .............................................................................................................. 10
Final Version ...................................................................................................................................... 10
Reasons ............................................................................................................................................. 10
Important Aspect............................................................................................................................... 10
Data representation .......................................................................................................................... 11
Data Structure ....................................................................................................................................... 11
Inquiry ............................................................................................................................................... 11
Vaadin Data Structures...................................................................................................................... 12
Database ............................................................................................................................................ 12
Data Hierarchy ................................................................................................................................... 12
Uploaded Files ................................................................................................................................... 12
Code Design ........................................................................................................................................... 13
Overview............................................................................................................................................ 13
DICOM object .................................................................................................................................... 13
Study & Serie objects ........................................................................................................................ 13
Metadata object ................................................................................................................................ 14
GUI Package....................................................................................................................................... 14
Main Class.......................................................................................................................................... 14
Adding DICOMs ................................................................................................................................. 14
Other main features .......................................................................................................................... 15

Problems & Solutions ............................................................................................................................ 16

Reflection .......................................................................................................................................... 16
Communication ................................................................................................................................. 16
Code Organization ............................................................................................................................. 16
Debugging.......................................................................................................................................... 16
Servers & Support ............................................................................................................................. 17
Adequacy ........................................................................................................................................... 17

2
Conclusion ............................................................................................................................................. 18
Bibliography........................................................................................................................................... 19
Appendix................................................................................................................................................ 20

3
Summary
My internship for Olea Medical Solutions was a very fruitful learning experience.
During that time I was assigned a project with a fairly small scope, and company-wide scaling.
The company dealing heavily in medical imaging and post-processing, accumulated a large
amount of medical images (DICOMs) over time, and the current storage solution was the basic
file system of a server. My project’s goal was to solve that problem by creating a web-based
application that would allow storage, querying, altering, retrieval and deletion of these files.

DICOM files contain a very large set of elements which represents their individual
properties, making them fairly complex data structures, also making the storage of thousands
of these files in a database a complicated endeavor. A Java library called DCM4CHE was able
to help with this problem, providing a programmatic implementation of the DICOM standard
which was useful to extract pertinent information from the medical images.

The application was developed using a Java web application framework called Vaadin.
This framework allows developers to build websites in a fashion similar to regular web
development, while also taking care of most of the server-side work using a servlet. It functions
using component objects with various uses and listeners for user inputs to the application. It
can also be customized using themes and user generated CSS.

The interface of the application went through several changes during development,
partly due to my increasing knowledge, and also due to the vague nature of the project. In the
end, the final version took form to best convey information to the user as well as being very
convivial in terms of usage.

The storage of the entire DICOM files being a hardly feasible option, a list a of the
important DICOM elements was obtained from all involved departments as to create a simpler
implementation of the medical images. The QueryableDicom was then stored in a data structure
provided by the Vaadin framework (JPAContainer) and stored in an H2 (sql) database.

The applications code was then designed with usability and readability in mind with the
advice of senior developers at Olea. The DICOM images stripped and simplified to better fit
the purpose of the project, had new properties added to them for further querying purposes. The
components were created in a way similar to CSS code to render the code intuitive to web
developers and all the listeners implemented in the main class. This main class also contained
all the underlying logic for the main features of the application.

4
 Several problems came up during the development, and solutions were found for all of
them. I learned a lot during the whole duration of the project, and in hindsight I would’ve some
things differently. A lack of communication early on did not help precise the exact nature of
the application that was needed by Olea employees, which was eventually obtained. There was
also a few code related issues that came up during the internship period, which were also solved
with time and help.

5
Introduction
This internship being almost over, it is refreshing to put the whole experience into
writing. It’s a nice synthesis of my experience, the knowledge I acquired, and the progress I
was able to achieve as a software developer. Not only was this my first professional job in my
field, but this was also the first time I really left the country of Canada. The really interesting
part of this job was that it was a position as a software developer in the medical field.

Olea Medical Solutions is a medical imaging software company. During my stay there,
I learned a lot about various topics, like the Digital Imaging and Communications in
Medicine (DICOM) standard for medical images by example. The developers were always
willing to help me had I any questions, which made the overall work environment was quite
relaxed. The company not being too big (around fifty employees) had a lot to do with it, since
within a week I knew almost everyone. My direct supervisor, Cyril Di-Grandi, is actually the
CTO of the company making any time he gave me all that much more valuable being so busy.

Only being there for four months limited the amount of work possible, and so I was
assigned a single solo project for the entire duration of my internship. It was to be developed
entirely by me, as a means to learn the various steps of a project’s development, starting with
research until the final release of it. Olea was more interested in my learning than obtaining a
properly working product. That motivated me to put in the work necessary to give them
something back.

My host company, being into medical imaging software, acquires massive amounts of
medical data under the form of DICOM files from various sources (clients, hospitals, etc.).
Whenever they need to test their software for certain conditions, they need specific files and
finding the right ones is like finding a needle in a haystack because of the terabytes of data they
have to sift through. That’s where my project comes in: they needed a tool to store these files
and be able to look through them, edit them and delete them if need be in an efficient way to
improve the productivity of their departments involved in development, quality insurance and
research.

Olea Medical Solutions

Background
The company was founded in 2008 by Faycal Djeridane, Benoît Gy, Cyril Di Grandi,
and Anca Mitulescu which made it at its roots a very small startup company. Now, eight years
later, the company has around fifty employees (ten of which are developers, not counting

6
interns) and still has a startup feel to it: open concept office, very liberal hours, long lunch and
break during the afternoon as well as a general friendliness in-between all employees. The
combination of all these things turned it into a really positive environment, especially for an
intern at his professional opportunity.

Reason for project

Olea has several products to offer in the field of medical imaging, all for the post-
processing of medical images to be exact. Due to this they end collect massive amounts of data
from various sources (be it hospitals, manufacturers, test subjects, etc.) that before this summer
were all stored in simple folders on the company server. That’s one of the hallmarks of the lack
of organization at Olea, which stems from its origin as a startup company. Among all of the
things I have learned while working here, that is the one I will need to work more on in the
future since it is the one I learned the least about. It did however lead me to spend more time
interacting with co-workers for various reasons, most of which had advice to me as a future
software developer.

DICOM standard
Description
The first thing I had to do for my project was to get acknowledged with the technologies
related to it. I started with the DICOM standard as it was the main component of the application
that I was building. DICOM is an acronym for Digital Imaging and Communications in
Medicine which is the standard for most things involved in the field of medical imaging. It is
the basis on what handling, printing, handling and transmitting medical information stands on
via its file format (.dcm) and its network communications protocol (working via TCP/IP). It
serves as a common ground for manufacturers to build imaging devices and software upon,
improving from the old system where only manufacturers could understand what the images
taken with machines meant.

Structure
The standard is defined with a very large amounts of attributes (data elements) which
are represented by: their tag (eight hexadecimal bits in the format of group XXXX, element
XXXX), visual representation (two letters that describe the data type and the format of the
value), the value length (defines the length of the attribute’s value), and the value field (contains
the data for the attribute). All of these attributes all have different uses, some of which represent
patient information, while some other are meant to be used for the calibration of various
machines.

7
Hierarchy
DICOM files work under a specific hierarchy. A file represents a single image, which
are grouped together in sets called series. You can identify which set an image corresponds to
based on its attributes. Every image has its own unique identifier (SOPInstanceUID), and so
does every series (SeriesInstanceUID). Every series is also part of a study, which also has its
unique identifier (StudyInstanceUID). These studies are done on a patient which also has an
ID, but in post-processing, patient information is anonymized for their safety. This standard
was the first thing I had to familiarize myself with during my project, since it is the backbone
of the application.

Library
To use these files in my application, I had to use a library of java methods called
DCM4CHE, which allows to manipulate the data contained in DICOM images for software
development. This library had implemented the DICOM standard into thousands of lines of
java code, giving me all the tools I needed to extract the information pertinent to my project
from DICOM images. This is also the library used by the developers at Olea for the company’s
product, Olea Sphere, which gave me the option to request help when it was needed. In the
course of learning how to use this library I learned a lot more about the DICOM standard, in its
programmatic use for medical imaging and post-processing, it’s importance for the medical
field and its specifications.

Vaadin Framework
Framework Overview
After familiarizing myself with the most basic concept behind the application, I started
looking into various java web application frameworks to build the application with. At my
internship supervisor’s suggestion, I looked into Vaadin which is a framework based on the
Google Webtool Kit (GWT). It’s currently up to its 7th version (Vaadin 7) and it turned out to
be a really good suggestions, fulfilling all of the needs for the project. I was able to quickly set
up a project on the IDE I had chosen (Eclipse in this case) using Maven for dependency
management (another suggestion of my supervisor and tool used at Olea). Maven is actually a
tool that takes care of linking your application to all the libraries it uses by storing them
externally so that any project can also use those libraries, which saves a lot of space on your
hard drive. Within two hours, I had completed a tutorial and had a basic grasp on how the
framework worked.

8
Vaadin Components
Any application developed with Vaadin revolves around its components. A component
can be a container, which are types of layouts with various methods of data binding, a field,
which the user can interact with, or one of the few that don’t fit in either of those categories.
Layout components are responsible for the overall look and usability of the page, the same way
a <div> tag can be used in HTML web development. Since these layout components are objects,
you can set their properties using setter methods. These properties are then turned into CSS
code by the framework backend, which gives you a lot of freedom in terms of design. Fields
behave in a very similar way to layouts, as they also have a lot of properties that can be modified
to generate CSS code, although some do have more usage flexibility than others. There is two
types of field, a generic abstract field, which the user can generate an action on the application
via simple input, such as a button or a text field, or an abstract select, which gives the user the
ability to select items and use these items to generate an action.

Listeners
All the interactions between the user and the applications are done through the use of
listeners. A component can have various listeners associated with it, and all it does is catch
certain events as they happen to initiate the actions specified as a consequence to a given event.
An example would be that when a button is clicked, the event representing the click is caught
by the application and then this activates the underlying logic, whether it’s being logged in to
an application or simply displaying a message. Most user interactions any component can have
an existing listener to provide different usages to developers using Vaadin.

Themes
Another cool thing about Vaadin is that it has themes. Themes are very large sets of
CSS code which makes your regulate the look of your application. This also includes a large
library of icons that you can use to make extra detailed buttons. An image speaks a thousand
words, and so a simple button with an X on it is much more readable than a button with cancel
on it by example. The application is built on the Valo theme (see appendix 1-3), which is a very
sleek and minimalistic theme for Vaadin applications. You can also implement custom CSS
using these themes in case the component attributes don’t have enough customization for you.
You create custom styles specific to a component that you can then add to any component of
that type.

9
Interface
Progress over development
I ended up making several versions of the interface during the development of the
interface, finding different ways to answer to the needs. All of them answered the same need in
different ways (see appendix 1-3), but the interface still evolved as development went on. In the first
version, I was still getting familiar with Vaadin, and most of the interface is actually incomplete. As
development continued from there, it became apparent that some things were possible while others
weren’t based on the amount of time I has given for the project, the limitations of the framework as well
as the ones in relation to my own knowledge. The second version had the table representing the data
separated from the search bar, and used a regular expression in the search bar to separate search values.

Final Version
If these are compared to the final version of the interface, it’s obvious that the second model
ended up being cast aside for a more simplistic design. In the final version, the only information
displayed is what the user is looking for. The filters are applied directly on the columns, instead of
having a search bar of some kind. All your options are available upon a single click after selecting
images, and the data is displayed as soon as the application opens. You can add more images, modify
them, delete them, or even create a zip file to download them in a package and also which columns (and
filters) are visible (see appendix 4 for action chart in French).

Reasons
This design was chosen to fit the time constraints as well as the available technologies under the
Vaadin framework. The table and its filters are provided by a plugin called Filtering Table that allows
you to add filters to any column of a table, as well as customize the pre-existing filters. This enabled me
to have a very ‘to the point’ design that shows all the pertinent information a user could be looking for
while letting him (or her) search for the specific image he is looking for. The other plugin I am using
for Vaadin is called Plupload, and its purpose is to let users drag and drop folders to upload DICOM
files to the application, the basic Vaadin component for uploading not having these capabilities. That is
an important feature because DICOM images are stored in a hierarchal fashion in the file system (A
study folder contains its series’ folders which contain all their respective DICOM images), and
uploading the DICOM files folder by folder, individually choosing the files, would take an excessive
amount of time.

Important Aspect
The part of the interface that was most worked on was the one involved in the adding of DICOM
files to the archive. The departments using the application had similar and yet different thought on how
this should be done and I tried to accommodate all their needs without having these features clash with
each other. The most important part of this feature was the ability to add additional information to the

10
uploaded files on top of the data pulled out of their original properties. As was described earlier,
DICOMs function in a very specific hierarchy: a study contains several series, which in turn contain
several images. That being said, some studies would have all the same data inputted, while others would
have series that had varied information. For that reason, the menu had to be designed to easily display
all the required information without being overly cluttered. For that reason there are three lists, on
representing the study (using the study’s unique ID), one representing the underlying series’ descriptor,
and a final one showing the selected series’ unique ID (in the cases where several series had the same
descriptor). That is also the reason why there is two buttons to seemingly ‘add data’ to the application,
one is used to add the additional information to the uploaded files, and the other is to write those files to
the database. If those files do not have any inputted data, a confirmation dialog will open to ensure that
you want to write those objects to the database even if they lack said data. It can also happen that out of
a study, a serie was not meant to be uploaded with it for various reasons, and so there is also a button to
delete any selected serie from the upload list. In terms of the information you can add, there is three
default properties that all files should have, and then a set of others that are situational based on the type
of medical imaging used to create the DICOM file. The selection of those properties generates a custom
field to enter data. The menu to modify selected rows (images) in the data container (table displayed) is
based on this and functions in a fairly similar manner, although the list of uploaded files are not shown
due to the modifications only being applied to selected rows.

Data representation
When a user opens the application, he or she should be able to see right away pertinent
information before doing any sort of filtering. For that reason, the columns that are visible by default on
the data table are the most basic ones. The name of the DICOM image is visible, followed by the
comment column (which can be anything the user chose for the uploaded cases), and then the three
default metadata properties added during upload to the archive. These columns most appropriately
summarize what type of DICOM image this specific row holds. That way, even by adding filters to the
table, users will have a general idea of what the results entail.

Data Structure
Inquiry
While learning about Vaadin, I was also looking into various data structures to store the
DICOM’s information in. Unsure of what I was looking for, I read papers on how DICOMs can
be stored in an effective manner. Reading all of this information made me realize that I didn’t
need to be able to search through all the DICOM tags, as there’s thousands of them. After
querying all the departments meant to use the tool, I had a list of the useful attributes. From
then on it was easy to extract the useful information from DICOM files and store these newly

11
created objects in a database. Due to the simplicity of the data structure, a simple relational
database was needed.

Vaadin Data Structures

Another great thing about Vaadin is that the framework takes care of all the backend
work necessary to build an application. A developer only has to hook it up to a database service
through his chosen means (there are several available). After some research, I found that the
JPAContainer was fairly easy to use and worked very well for simple CRUD (Create, Read,
Update, and Delete) applications. The JPAContainer is a data source that can be bound to certain
Vaadin components, known as containers (such as a table). JPA itself stands for Java
Persistence API, which is used for storing, querying and managing data in between Java
applications and relational databases. This is in line with the data structure I wanted to use for
the application.

Database
The JPAContainer uses a configuration file called persistence.xml attached to your
project to create the persistence engine for the application. The properties specified in this file
are set specifically to match a certain database, in the case of my project I chose to use H2 for
two reasons. Firstly I already had experience with PostgreSQL, my other choice, and also, the
developers at Olea were also using it for their application. In the case I had issues, I could ask
them for help regarding the database. Being able to ask help from my peers was one of the
things I really appreciated at Olea, as I could avoid hours of googling by tapping in my
colleagues knowledge.

Data Hierarchy
Due to the implicit nature of the hierarchy between DICOM files, I wrote an algorithm
that specifies which serie and study every single image is part of. It simply sets these attributes
on every DICOM during the upload process so that the hierarchy can be applied into actions
that work specifically on a given serie or its entire study. This is useful specifically to filter for
a specific set of images, or to select a whole study/serie.

Uploaded Files
Another small choice I had to make while developing the upload process of the
application was to choose how to store the uploaded files turned objects until they were
committed to the database. For reasons involving algorithm construction as well as speed, the
basic array was chosen, also giving a hard cap to the amount of files being uploaded at once.

12
Code Design
Overview
Once I was done learning about all the related technologies and themes, and had a
defined usage of the application, is when the project started coming together. In terms of the
actual code, it comes together in the form of several Java classes separated in their respective
packages: the app package, which holds the classes generating the web application and the
underlying logic, the gui package, which holds the classes responsible for the creation of
component, the obj package, this one holds all the object classes used in the project, as well as
a utils package which contains the utility class used in the project (given to me by one of the
developers to help me develop algorithms). There is also a few other packages included, all of
which relate to dcm4che, the java library for handling DICOM data.

DICOM object
Out of those last packages, I use the java object implementation for DICOM images to
be able to easily extract the relevant information from those files and input them into my own
implementation of DICOM images (which only contain information pertinent to Olea). That is
represented in java object form as the QueryableDicom class. These objects have properties and
values directly taken from DICOM images, some derived from DICOM elements by passing
them through an algorithm and some added by user input while uploading DICOM files to the
application. The constructor for the object is called during the upload process as to instantiate
the objects right away, using the DicomObject (java implementation of DICOM image files) as
a parameter. The class contains getters and setters for all attributes as well as the algorithms
used for setting the derived attributes.

Study & Serie objects

Two of the attributes of the QueryableDicom object class are also objects designed for
the project. They’re fairly simple in implementation, mostly used for setting a direct hierarchy
between the QueryableDicom files instead of the implicit nature of it. At the project’s
completion, this hierarchy was used in a single feature, but had the development time been
longer, it could’ve been very useful for other interesting facets of the application: grouping
images in sets dependent on their hierarchy for easier browsing of the filtered data; ability to
hide a given set of images to add precision to filtering; etc.

13
Metadata object
The last object used in the project represents the metadata properties that can be added
to QueryableDicom via user input during the upload, which can then be modified by selecting
rows and using the item modification menu. This implementation also links the data to their
respective field to obtain a cleaner and sleeker code. Since the type of data used for properties
can vary, the method to the field values also determines which type the field uses to avoid
failures when the user tries to input information.

GUI Package
There is one class responsible for setting the properties of the components used in the
application, and the other two classes in the gui package are responsible for building the custom
column filters used in the table containing all the data (the code is just an extension of the
Vaadin plug-in used for the table). The CompBuilder class which instantiates all of the Vaadin
components and returns them as to generate the components from the main class. It’s coded in
a way resembling a CSS sheet, with a lot of re-usable component creation methods to promote
code utility. This also makes the code easy to read for someone unfamiliar to the Vaadin
framework, because it is built in a way that is intuitive to web developers.

Main Class
The class tying all of that up together is the main one called ArchiveUI. It generates the
user interface using all of the components from the component builder (which by itself uses 400
lines of code) and then a method generates the interface out of the layouts, components and
abstracts, followed by methods responsible for the initiation of the application. The rest of the
main body of the code is composed of listeners to the various actions you can input on the
applications. Most of these listeners only modify the visibility of certain components, which is
how the navigation of the interface is done. Visible and not is one of the states a component can
be in, it can also be enabled and disabled as well as read-only or not. Read only is not a state
used in this project, as I went for the more practical approach that buttons and fields are only
visible when they can be used. That is truth for all but the menu, because some actions are
dependent on having rows selected in the table containing all of the DICOM objects.

Adding DICOMs
The project had a very small scope set in terms of needs, the most important one is the
ability to properly add DICOM files to the application so that they can be queried. I described
the interface for this process earlier in the interface section (see appendix 3 for visual reminder),
as well as the reasons for it being the way it is. The underlying logic for that process is just as

14
important. The upload is done through the Vaadin plug-in called Plupload which extends the
regular Vaadin upload component to give it more flexibility in usage. This gives the application
the ability to use folder drag and dropping for upload. The uploaded folder is then searched
recursively for files matching the chosen filter (in this case, .dcm files). This custom component
implements several listeners associated to various states in the upload process: files added, start,
progress, complete. With these the application is able to display the progress of the upload on
a sub-window and once it’s done open the menu for the manual input of additional information
unto the newly created QueryableDicom objects. There is listeners for the change in selection
in the study unique ID list as well as the series name list, which allows for selection of series to
modify. These automatically select the proper underlying items and display them in the
appropriate list. The concept is similar in terms of the metadata selection list: you pick the ones
you would like to apply unto the files on top of the three default ones, and as you select them
they become visible in the form right beside the list. This functions via a listener, clearing out
the form’s layout from fields on every change and simply adding the ones selected based on the
condition that they are selected. Out of all the other features of that part of the application, the
smallest one is the most complex. In the case where a user needs to remove a serie from the
uploaded sets of data, it is possible to select a serie and simply delete it. This was complicated
due to my earlier usage of the array data structure to store uploaded QueryableDicoms. To
delete part of the array, it’s necessary to parse through the entire thing, deleting matches to the
selected serie, keeping a counter of the deleted files and adding all the remaining
QueryableDicoms into a temporary list. Afterwards, the array is re-iterated across as to replace
all the values with the remaining ones, and then the leftover objects from the old array is
nullified using the counter.

Other main features

The other required features (the ability to edit, remove, download and query DICOMs)
of the application aren’t as complicated as that one, mostly because it’s the pillar that allows
the other ones to work. The edit feature works about the same way the add feature works, with
the same type of metadata selection and field verification. The delete feature just fetches the ID
of the selected rows and deletes the entities from the database, the associated DICOM file from
storage and then refreshes the page. The query feature is fully implemented by the Vaadin plug-
in Filtering Tables that adds the ability to set filters for any column (custom or default for data
type) and the download feature is taken care of by using a java zip library and the Vaadin
component for downloading files from the server.

15
Problems & Solutions
Reflection
Putting some thought in my internship made me realize that there is a lot of things I
would’ve done differently if given the chance, whether it was a problem that arose or just a
mistake on my part. Not only that, but it also allows me to reflect on my growth as a person and
a software developer. Opportunities like this come along once in a while and even more so
projects in a setting like this don’t appear that often either.

Communication
In hindsight, I would’ve tried to communicate earlier on with the product users as well
as my peers. I can use this newfound knowledge on my next project as to give myself more
accurate goals. The vagueness of the project did give me a broader learning experience, this
being an internship it turned out to be fine, but for an actual employment it would be better to
be more efficient in that regard. To help Olea avoid future issues like that in case this project is
picked up in the future, I wrote a comprehensive documentation. It details the project need, the
usage of the framework, the design of the application as well as the logic behind the code in
broad terms. That way any future work to modify the application will start on a well-informed
base.

Code Organization
Although my code worked very well (after being debugged), it was originally not well
organized, everything being put together in a very large method. This was due to a lack of
teachings in terms of proper code infrastructure other than the Model View Controller
architecture. After reviewing it with my supervisor I was able to create a more comprehensive
code that was definitely more readable and usable by others. This goes in hand with the
documentation I have written for future development in the application. It also was a good way
to learn how to properly write code, and a good introduction to coding in terms of high
reusability (write methods that don’t have a singular purpose, as in called several times in the
code).

Debugging
The biggest problem I encountered is a recurring one that every developer faces:
debugging. I had a small amount of experience with debugging via my programming classes in
university and high school, but nothing of this scale. With several thousand lines of code, any

16
little thing can cause the whole application to crash and so debugging was the most time costly
activity of mine during the development of the application. I quickly learned to use the debugger
in a more concise manner to get to the bottom of my problems much faster than I used to, as
well as being able to find where errors were happening based on cryptic error messages. I also
found the usefulness of sprinkling info logs all over my code as to have a more concrete idea
of how errors would happen, where deadlocks happened, and what caused the crash specifically
just as it happened. The goal is to potentially prevent these issues while developing, instead of
running into them later and spending time trying to figure where it happened.

Servers & Support

I also ran into quite a bit of issues with the server-side of the application, for hardware
as well as human reasons. This being my first experience with working the backend of an
application, I was mostly moving forward blindly. This did substantially improve my
knowledge of application deployment, as well as of database connection types. The support
department of the company being quite small, they were very in demand in general, and so I
mostly had to figure out how to do the testing of my application by myself. During this I also
learned how to package an application to be tested locally without running a database or server
as a service. The server software I used is Tomcat 8, and I ran the H2 database locally in
embedded mode in conjunction with my application. The test package was never used in the
end, due to the limitations of the proxy and environment variables on user’s computers and lack
of support from the IT specialists who were busy and/or on vacation at the time. After that, I
was set up with a Linux server (CentOS 6) running on a virtual machine accessible from my
computer, however I was not given full permissions on the server which also limited my ability
to have the web application tested.

Adequacy
This was my first real work experience in my field, and so my arrival at the company
was quite stressful. I knew ahead of time what my project would entail to some degree, but I
did not know I was going to be working alone, nor that my supervisor would be the CTO and
Technical Director of the company, which made him very busy. Most of the learning I had to
do was done on my own, and for a while I felt ‘unqualified’ for the work I was doing, having a
very looming feeling of inadequacy. However, as time went on, I gained a lot of confidence as
I gained more knowledge in the area of expertise relevant to my project. With help from various
developers at Olea, as well as my supervisor, I was able to properly gain the gusto necessary to

17
apply myself to the task at hand. The feeling of inadequacy receded as the development of the
application went forward until I was fully confident in my abilities as a developer.

Conclusion
All in all, this experience was very beneficial to me as a software developer, an employee as
well as a person. Working in a professional environment in Europe, an ocean away from Canada, gave
me a new perspective on my career as well as my abilities. The project I was given fulfilled me as an
employee and gave me a good reason to challenge myself as a developer. Through learning new
material as well as new teamwork methods, I have improved over these (almost) four months. The
project, seemingly simple at the start became fairly titanic for a simple intern: create an application to
upload, store, query, and retrieve DICOM files in a time efficient manner.

Due to this project, I was forced to get out of my comfort zone and apply myself into areas of
the industry I had never considered before. It also gave me the opportunity to use technologies I had
never used before, such as Vaadin, Tomcat and H2 databases among others. I learned a great deal
about project resource management due to my singularity as a working force for the project. I also
gained knowledge about interface development, through the help of the interface designer here at
Olea, who gave me tips during the development of the application.

Even though I was faced with many problems during development, I sought to overcome them
(mostly on my own, sometimes with my seniors help) to succeed in developing a finished product.
Whether it was a software issue, a people one or even one concerning myself, this opportunity allowed
me to enlarge my problem solving skills as well as my communication skills.

I was offered a place here at this company after my studies if that interested me, once again
proving the good heart of this enterprise. Working here for my first internship was a delight, and I can
only hope that my future endeavors will be as great as this one. A job overseas is not easy to obtain as
a student, and I’m grateful that I could even do this, and so I suggest anyone wishing to do something
similar to do it. Put in work, talk to the right people and believe in yourself and you will be following
your dreams in no time.

18
Bibliography
Darthmouth College. "DICOM Attributes." DICOM documentation. N.p., 2005. Web. 1 Aug.
2016. [http://northstar-www.dartmouth.edu/doc/idl/html_6.2/DICOM_Attributes.html].

Vaadin. "Vaadin Framework Documentation." Book of Vaadin. N.p., n.d. Web. 08 Aug. 2016.
[https://vaadin.com/docs/-/part/framework/].

Olea Medical. State of the art Visualisation & Post-Processing Application. N.p., n.d. Web. 16
Aug. 2016. [https://www.olea-medical.com/].

19
Appendix

Appendix 1: First version of the application interface

Appendix 2: Second version of the application interface

20
Appendix 3: Final version of the application interface

Appendix 4: Action chart for the application

21