:::danger
:fire: Please leave comments as feedback!

I'm looking for improvements to the ideas covered as well as how I phrased them.
But any frank feedback is welcome.

I also want to find out:
* If I covered the idea I wanted to cover in the presentation proposal found at the bottom of this page.

Also note:
* These are just speaker notes, the slides will contain more pretty pictures and less text
:::

[TOC]

## The slides

* Obiectivul acum este:
* sa avem un discurs coerent end to end, care are
* structura in ordine
* toate cuvintele
* ca sa putem incepe sa lucram la slideuri si separarea pe slideuri si ce contin ele
* si apoi sa aducem imbunatatiri la ceva ce deja exista

### Intro
* Hi, I'm Mihai, I'm a FrontEnd Developer
* I work in the Application Development team in Romania.
* We build applications for Ing employees.
* I will tell you about the app we are building, the troubles we had and how we overcame them.

### The project

#### Brief history of the three applications
* SPEECH
* Let me tell you a short story of this project was born. In the beginning there were 3 happy independent applications.
* Record - front-office system,
* Fabo - back-office system and
* RITM - application used by the customer support team.
* Each of them was written in ASP.NET Web Forms and jQuery.
* This is how they looked like.
* It looks like we're back to windows 98.
#### Their worthy successor
* SPEECH
* Now as they were getting old, they went to a bar and talked a lot.
* They realised it was time to retire.
* So one of them said,
* "Well guys we're getting old, we need a worthy successor";
* "Yes but who?"
* So they looked around until they found someone to build them one.
* It was going to be something fresh, modern and fast.
* It was going to be called NARC.
* What is NARC ?
* [insert gifu lu radu cu CRMs si apoi cu narc, apoi cu jocu de litere de la nacrm la narcm la narc]
#### The plan
* SPEECH
* "But how do we pass our legacy?" Asked one of the old apps.
* "Well, it's not going to be in an instant I'll tell you that", said the builders.
* "We're going to do it in stages.
* We will do it app by app, and screen by screen, using iframes for the old modules.
* We'll decommision the old ones as the new modules are ready. And we are going to start with Record.
* Great, so we have a plan.
#### The ideal scenario
* SPEECH
* Now, you know how we have theory on one side and reality on the other.
* In theory there is no difference between theory and practice, while in practice there is.
* We have this wonderful place where everything works just as it should.
* The pieces work out of the box, and fit together like legos
* [screen cu tpa, ing-web, orange juice]
* We've got guiding principles and some helper libraries in TPA ; ready-made web-components in ing-web; and a defined styleguide for the components in the Orange Juice. `canExtend`
#### What really happened - Real Life
* SPEECH
* Here comes Real Life.
* It's more unexpected, complex and sometimes just random.
* Ups and downs.
* So Let me tell you how we learned to navigate through this and what we learned along the way

### The start

* We knew a few things at the start.
* We knew we had to build a rocket, from a few parts.
* We didn't know how they fit together
* There wasn't any blueprint.
* We knew The road to production is long and filled with surprises.
* And we knew we had to carry a big shipwreck along with us
* So these were the three parts
* the rocket
* The road to production
* the the shipwreck
* Three parts? Three places where things can go wrong.
* Right?
* Well, not really.
* Because those parts interact and this creates friction between them.

### The milestones and turning points
#### First contact
* SPEECH
* But let's start with the start.
* Our big bang.
* On the 18th of January Radu, my colleague, sent me a presentation - "The evolution of the guide for the web".
* It gave us guiding principles for our own application
* use the platform
* consistent experience
* assemble your apps
* Then it promised the tools to enable those principles
* ing-web - a component package built on open source libraries, using the platform via web-components
* tpa-web - guidelines to structure your app and helper libraries
* orange juice - a design system, so everyone knows they are using an ing app

#### Uncertainty and excitement
* Separating the mockups into component types set out by TPA
* SPEECH
* So we were getting excited, but we still didn't know how to apply what we found.
* So We went through some links in the presentation.
* A We found a real world implementation for structuring the app.
* Then, more questions.
* How do we apply this for our app ?
* {SHOW MOCKUPS THAT ARE SPLIT INTO COMPONENTS AND LABELS}
* So we split our app into different components, according to tpa guidelines.
* This was before building anything,
* so we knew this was going to change
* But it's still a great exercise.
* {MAYBE INSERT MOCKUPS THEN, SCREENSHOT NOW WITH HOW THE APP IS SPLIT}
* This is how we started,
* this is how it is right now in our app
* That's all we had back then
* Some idea of the tools we'll use, mockups and a lot of questions.

#### The first visit
* Uncharted teritorry, validated a few of our attempts of making sense of the guidelines
* ensured a second visit
* SPEECH
* Some big news soon came.
* We will have a visit from the TPA and ING-WEB teams.
* We wanted to have lots of questions answered
* So we prepared
* We wanted to validate our component separation
* {INSERT IMAGE WITH COMPONENT SEPARATION}
* And we wanted to understand layering
* {INSERT SCREEN WITH TPA LAYERING}
* So We made a poc to make sure we understood the tpa layering
* {LINK CU CUM ARATA REPO-ul de POC}
* This is how it looked like
* At the end of the meeting, we had lots of answers.
* The bad part is this created more questions
* So we arranged another visit.
* And on this next visit the plan was to work side by side on building this rocket.
* We were excited!
* This was our confidence in the tools before and after we set up the visit
* {INSERT GRAPH WITH LOW AND HIGH CONFIDENCE BEFORE AND AFTER}
* Quite the dramatic change.

#### Baby steps and still a lot of uncertainty
* SPEECH
* Now, let's start building.
* Should we start from scratch?
* No. Remember the principle: Assemble your apps, don't start from scratch
* We looked for a starter project in our internal repositories
* We didn't find anything.
* Then, we looked in open source projects and found something.
* Create-lit-app.
* It had everything we needed
* {Show Code}
* It had web components, based on lit-element and lit-html
* A build tool
* A test setup
* Support for IE11
* It would be crazy NOT to use it
* So we did.
* Now we at least had something on the screen.
* And still a lot of questions?
* How do we manage state ?
* How do components communicate ?
* Redux was TPA's recommendation, but in an async application redux is not enough.
* {SHOW EXAMPLE OF MESSY REDUX WHEN ASYNC IS INVOLVED}
* We had guidance for other parts of the app...
* so why not for this?
* That's what we thought back then
* So we just put it in our list of unanswered questions

#### First phantom bug

* The more we experimented, the more our confidence grew.
* Until one day, when our screen went blank
* The app was still loading
* We checked the console, no errors.
* Hmm, What could be wrong?
* After a few tries, we noticed the render function didn't work.
* {Show picture of html fn import from ing-web and from lit-html}
* It didn't work when imported straight from ing-web
* It did work when imported from lit-html
* that's strange
* I guess I'll talk to someone from ing-web
* I prepared a sample repo
* {Show how the example looked like}
* Sent it
* And didn't expect to hear back anytime soon
* He got back to me the next day. YAY
* {INSERT YAY SOUND}
* It worked on his machine. Nooh
* {INSERT NO SOUND}
* No solution, but... the response was quick.
* To be fair, they did say there will be a great and quick support system around these tools.
* But I thought: 'Pffft... Yeah. Sure. Big Company, Big Words.'
* But boy was I wrong
* If you don't believe me, Try to ask something on the mattermost channel.
* {insert link}
* If you are struggling with a bug, or a specific problem, give the ing-web community a chance.
* In the end, we updated our app and the bug vanished.
* Like a ghost, never to be seen again.

#### Prepare for lift off

* ce vreau sa ilustrez aici
* ce aveam gata pana aici
* cum a functionat intalnirea
* am facut storyuri multe, le-am prioritizat si tot nu am putut sa le ducem la capat pe toate

* SPEECH
* We had a starter project and some conventions
* {Show screen}
* We also had big plans.
* We wanted to work on our most important components
* One of them is the grid
* The grid is an interesting story.
* There wasn't any internally we could use.
* The think ingat the time was to build our own, and contribute it back to ing-web.
* We first thought, maybe they want us to build it from scratch
* As an engineer, you might think "Yes, let's build it. It's a great challenge".
* But, we had a few issues
* A lot of requirements
* web components were new to us,
* and a planned June release.
* Then we looked at what's available
* There were only two options.
* Two big open source projects that are already proven
* They are used by other companies in production.
* They both had an enterprise version.
* So we built a simple wrapper component for the vaadin-grid.
* {SHOW CODE HERE}
* We still didn't know two things
* One. Can we contribute it like this?
* not from scratch etc.
* And two. If yes, then how do we do it?

#### The second visit and a new hope

### Priorities - sources of friction
* So when they visited, we tried to work this out as well.
* We discovered they were great guys
* Reasonable and helpful.
* And that there is a process for something to get into ing-web
* You first create some specs
* {image}
* Then these get discussed and finalised
* Only then, a team gets assigned to build that component.
* But for the grid, the choice was to build their own.
* They had additional requirements, a11y wise as well as security wise.
* {ILLUSTRATE CSP}
* It also had a much lower priority for them than for us.
* So we went our own way.

### The good
* Despite this, their visit gave us a few BIG Wins.
* One. A better structure to our project, that encourages separation
* {SHOW IMAGE WITH BEFORE AND AFTER}
* Two. Useful file naming conventions, encouraged by TPA
* {SHOW IMAGE WITH FILE CONVENTIONS}
* Three. Coding Standards.
* They are enforced through Pre-commit hooks.
* We now have these for linting, formatting and consistent commits.
* {SHOW IMAGE WITH THE SCRIPTS}
* This just makes it easy to do something the right way and just makes some mistakes harder.
* No project should start without these.
* It prevents a lot of discussions, around code style, spacing.
* This is something that should be enforced.
* They should be taken as a given from the start.
* Otherwise, we as developers might start a war over this.
* It's for our own sanity

#### Confidence boost & Other important decisions
* ce vreau sa zic aici:
* ca vizita ne-a ajutat sa ne dam seama ca altii au alte prioritati
* ca noi le avem pe ale noastre
* ca nu exista recomandari pentru toate librariile si ca putem sa punem ce avem nevoie si sa luam decizia asta pentru noi.

* The visit itself was very productive
* We made great improvements to our rocket.
* We also understood a few things.
* First. There are people behind these entities and they are willing to help.
* Second. Not everything is set in stone.
* Using web components is, ing-web is, tpa structure is. But for other needs you can make decisions on your own.
* This is what we did when we introduced redux-saga.
* We wanted a way to handle async data flows, isolate business logic from the view
* {SAMPLE REDUX SAGA CODE from our app}
* and make flows easier to test in isolation.
* {REDUX SAGA TEST PLAN}
* Third. Turns out Explicit and direct communication really helps.
* Hm. Strange.

* So now the rocket was on its way.
* We solved a few communication issues, that could have derailed us but didn't.
* What can go wrong now.
* Ah yes, the shipwreck we had to carry.

#### IE11 is HELL

* IE11 is HELL
* No really, just look.
* This is not a coincidence.
* It's a black hole. It sucks everything in.
* Your time, your effort. It gives nothing back.
* It's like a ship on the sea with small holes in it.
* You need to patch the holes.
* {EXAMPLE with the $id and $name selectors}
* Did you know about this?
* This is not something a polyfill can patch.
* You can almost hear the water coming into your boat
* {WATER SOUNDS}
* We stopped this leak
* We replaced the selectors
* Easy, right?
* But where there's a crack, there are always more.
* And They kept getting bigger.
* Like this bug, that appeared in lion
* https://github.com/ing-bank/lion/blob/28590dbf523bf72ed7930eba92e6ab59e70ffdac/packages/field/src/FormControlMixin.js#L150
* This is simply a polyfill that doesn't behave like its native implementation.
* Soon enough your time is spent more on fixing these holes than building the rocket.
* This is time, forever wasted.
* Our team alone reported 4 bugs to lion.
* {Screen with bugs reported}
* But we realised early that putting out fires like this is not smart.
* So we became proactive.
* We added a checkmark to our pull-request template
* Works on IE11.
* So no branch will be merged without first making sure it works on IE11.
* It's a small change, but great for peace of mind.

#### Growing pains.

* Now the rocket was up and running.
* Our team came together and built this.
* We had a lot of outside help at the start.
* We dealt with a few issues early on.
* Some technical, some organisational.
* We patched a few big holes on the shipwreck.
* But also managed to keep our focus on navigating the rocket to production.

#### The first release
* SPEECH
* This is how the project looked like at release
* {SHOW IMAGE OF PROJECT AT RELEASE}
* Looks good, but a work in progress
* What do you think happened at release ?
* Nothing
* I just wanted to say that.
* We were ready.

#### Paying it forward
* Helping others with their own rockets
* SPEECH
* Building this, teaches you a few things about the tools you use and what you can do with them.
* We had people help us at the start.
* It was invaluable.
* Now it was our turn.

* Team X was was planning a rewrite of their own.
* Using ing-web.
* So we held 1 day workshop for them, to help them familiarise with ing-web.
* We tackled most of their questions.
* They were quite similar to the ones we had when we first started.
* * Having a page with a grid
* Setting up a skeleton project
* Routing
* State management
* Component communication
* Sometimes this is all you need to kickstart your project.

#### Competing concerns hell
* stuck between a rock and a hard place
* SPEECH
* But back to our project.
* Our most recent problem is even juicier.
* It's both technical and organisational.
* They feed into one another.
* {Ilustreaza cele doua prin cercuri}
* You have the old app and the new app on one side
* Business constraints and UX styling constraints on the other
* {ilustram ce scriu in astea doua paragrage}
* And now let me illustrate the problem
* Our users use the app at 150% zoom
* They do this because the font in the old app is small
* The font in the new one is normal
* But the old and the new run at the same time.
* {imagine cu grid vechi si bara de sus noua}
* The business constraints
* everything on one page, no additional scrolling
* So using css scale to increase the size of the old app is out of the question
* UX constraints
* Ing-web components are customizable
* Up to a point.
* This is to maintain visual identity.
* I get it
* But this also means we can't change the css without extending the components.
* So we did
* It's a compromise, It's not supported. But it's something we had to do
* At least for the moment
* {show image of extension of components}
* Let me tell you how I see the solution for this.
* You bring the decision makers to a table
* You let them come to an agreement.
* I as a developer don't have that decision making power.
* But I am impacted If the two don't talk.
* I have to make compromises.
* These can lead to technical debt.
* And as you know, all debt must be paid. Eventually.

### present and future

#### major questions but still ready
* lazy loading
* ready for independent publishing
* exploring micro-frontends
* SPEECH
* This hasn't stopped us however.
* This is how the project looks like now
* {show project structure}
* Thanks to the tpa provided router, we lazy load our page components
* {show them page component}
* We also load their related sagas and redux reducers lazily as well
* {show example of this}
* You can't see the difference between lazy and eager loading in Chrome
* But in IE11...
* Well, just look
* {show video of difference}
* Right now, our next step is exploring micro-frontends.
* {SHOW EMPTY PAGE}
* This is how far we are in our exploration.
* `canExtend` with performance improvement in IE11
* {SHOW VAADIN SEARCH}

### Some lessons
#### Tackle One Thing at a Time
* SPEECH
* First understand your tools, then improve and contribute. In this order.
* Remember every team has their own objectives and timelines and their own project.
* Make sure your house is in order before focusing on other objectives.
* Ours was to learn the tools we were given
* To get the rocket to production
* In one piece.

#### Experiment a lot at the start. Ask questions
* SPEECH
* Building POC's early helped us a lot
* You don't know what you don't know until you start building.
* Building early means, making mistakes early.
* Making mistakes early, means learning early.
* Learning early means improving while the stakes are low

#### Find mentors
* others who used the same tools
* SPEECH
* People who already use the tools you are planning to use, know more.
* Plain and simple.
* We were lucky to get this for FREE.
* But if you are in a similar situation
* Reach out to someone who already did something similar.

#### Help yourself, then help others.
* given the same amount of time what would you focus on, what is more important
* SPEECH
* This might be controversial.
* We wanted to contribute to ing-web.
* In the end we didn't.
* We will in the future.
* But at the start we were barely familiar with the tools and the process.
* Our focus was to build a solid foundation for our app.
* And you know. Projects are messy at the start.
* But as they mature and stabilize, you can focus on other things.
* It's the same principle in a plane when the oxygen masks come down.
* You first help yourself so you can then help others.
#### Speak up on what doesn't seem right, early and often, don't let issues pile up.
* SPEECH
* I think we can only grow if we let our truth out.
* My experience is subjective.
* I could have easily just shut up.
* Take up this technical debt, and not speak about something like conflicting requirements
* Like those between UX and the Business.
* It can be interpreted in a number of ways.
* But I think it just shows, we care.
* We care about what we build
* We care about our users.

* Thank you for listening and thank you for everyone involved in this project.

### A few thank yous
* Team
* Pascal and indirectly everyone who helped him
* ing-web
* TPA

## What was written in the presentation proposal
### The Synopsis

Learning to steer a rocket with no driving licence while towing a shipwreck

Supercharged development with web components, ing-web and tpa architecture....with IE11. A 6 month journey navigating with one leg into the future of the web and another into the depths of IE11 hell.

Gradually migrating a legacy CRM to web-components, ing-web and tpa-architecture.
How we started, how the project evolved, where we are now and next steps.
All explained with a focus on highlighting the interactions and sometimes conflicting objectives between the project team and the library teams (ing-web, tpa), and how we solved them.

The objective here is to provide teams starting new projects with insight into the benefits and also the problems of working with ing-web and tpa, the people and the libraries and how to get over those bumps and deliver your project

### FOCUS

- Conflicting objectives between the project team and library teams and how we solved them.

### OBJECTIVE

- ing-web and TPA benefits, problems and solutions or workarounds to problems

## Tags
`toBeDeleted` ; `detaliu`; `necesitaImagine`

### What’s with the title?

#### Learning to steer
* Find our way successfully to production
#### rocket
* Speed
* state of the art technology - web components
* Many parts little margin for error
#### no licence
* no previous experience with the enforced technologies - web components, ing-web, tpa structure
#### towing a shipwreck
* Bringing our own baggage to this.
* Why we use IE. No! Why we HAVE to use IE.

## Feedback 29.10.19

* the rocket was up and running twice said
* prepare questions
* Why are you stuck with IE11
* sync slides with speak
* slides 22; 48; am sarit aici
* 62
* team X - Wholesale Banking et 9
* slide 54 - POC - project structure.
* slide 39 - dupa ce vorbesc de shipwreck. zic pe scurt de ce suntem legati la gat de IE11
* sa ilustrez ca ne-am consultat pentru sagas. chiar daca decizia am luat-o singuri.
* business requirements explained. --> fiecare click conteaza.

* feedback Dan 29.10.19
* O sa facem screen by screen sa nu includem iframes
* sa se inteleaga ca nu asta e directia pe care o luam
* iframes reprezinta trecutul nu viitorul
* why we're stuck
* activeX to communicate with peripheric device. there is a plan to decommission this, and make it available in edge si chrome.
* grid
* don't mention accessibility the CSP.
* coding standards
* tool, help
* at the start e mai periculos. e bine sa fie la inceput.
* redux-saga
* ceri feedback, pornesti discutia
* dar tu stii cel mai bine ce e acolo si tu ramai cu decizia la final
* la release
* a trecut releasul
* am asteptat, am asteptat si n-am primit nimic si ne-am intrebat daca s-a promovat sau nu - chiar a ajuns in productie ?
* paying it forward
* coding standards pt ceilalti
* lazy vs eagers
* 2 chrome, 2 ie
* future
* efort la ie11
* agream cu business owners ca trebuie gasita o solutie pt ie11
* exploring solution to give up ie11
* change from might to will in the future
* help yourself -
* make explicit that we used ce era in ing-web
* doar ca nu am contribuit nimic
* pun slide cu ce am folosit
* Sectiune pe ing-web contribution. we now feel ready for our own contribution
* bug reports
* am incercat si cu o componenta
* acum ne simtim destul de maturi sa contribuim
* ce am folosit din ing-web

### feedback 5.11.2019
* care e treaba cu tpa, ilustrat vizual si cu celelalte
* vizual
* Recor...d
*