Front-end
- JavaScript Fatigue
- Concepts in JavaScript which can be hard to understand
- Async (callbacks, promises, generators, streams)
- Prototype
- Scoping
- Currying
- Concurrency model, event loop
- Never blocking
-
Handling I/O is typically performed via events and callbacks, so when the application is waiting for an IndexedDB query to return or an XHR request to return, it can still process other things like user input.
-
- Main event loop is single threaded
- but the browser or NodeJS can use MULTI THREAD for I/O operations
-
The event loop is what allows Node.js to perform non-blocking I/O operations — despite the fact that JavaScript is single-threaded — by offloading operations to the system kernel whenever possible.
- https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/
-
const add = a => b => a + b;
add(3)(5) // 8
// more realistic example
const currencyConverter = (from, to) => {
const convert = expensiveGetConfig(from, to);
return amount => convert(amount)
}
const fromEurToYpj = currencyConverter('EUR', 'YPJ');
let price = fromEurToYpj(123);
price = fromEurToYpj(23);Front-end
- Virtual DOM like in React
- State management like in Redux (Redux was inspired by Elm)
- Side effects management similar to Redux Saga
- All data in Elm is immutable like in ImmutableJS
- Type checking like with Flow
- Elm enforces a certain code style like ESLint
Disadvantage: small (but growing) ecosystem
DevOps
In order to increase the release frequency, more regression testing is needed and test automation should be fully embedded in the delivery pipeline.
DevOps
As a hacker
I want ...
So that ...
The Bol.com security team:
- Business Analysts
- Product Owners
- Information Analysts
- Developers
- Testers
DevOps
https://www.youtube.com/watch?v=b0VxVJLJUww https://www.datadoghq.com/
Traditional view of the stack: Frond End, Back End, Infrastructure 1 system with 3 perspectives
- Think about your system as a whole
- Get multiple perspectives
- Consider all 5 observability tools:
- RUM
- Synthetics
- Tracing
- Application+Infrastructure Monitoring
- Logs
RUM
Pokemon Go Views vs interaction (scroll-, click-, key-, no user interaction)
Synthetics
Latency
Example:
CDN with puppy photo's. CDN suffers massive DDOS attack.
- RUM & Synthetics: Will alert and can show what assets are slow or are not being served
- APM, Application and Infrastructure Monitoring: No alerts. Everything is fine!
Scenario: we're too popular
Everyone loves puppies and we're completely out of resources
- RUM & Synthetics, APM, Application Monitoring: Alerts that latency is high. Will not be able to help identify why
- Infrastructure Monitoring: Alerts on high resource use and may be able to trigger automatic remediation.
Anomaly detection (for example https://github.com/linkedin/luminol)
Front-end
Some non-intuitive tricks that lead to smaller bundles, faster parse times, browser-engine opts and de-opts, and faster perceived loads.
https://www.youtube.com/watch?v=cy4rCi9mry4
- Babel-preset-env (eg
last 2 versions)- https://babeljs.io/docs/plugins/preset-env/
- Drop support for IE11 (browser optimization for modern JS, less code in bundle)
- Compile your code twice with Babel: Give a different bundle to modern browsers which support ES6 modules
- target: { esmodules: true }
<script type=“module” src=“./compiled-with-fewer-transformations.js”>
- target: { esmodules: false }
<script nomodule src=“./compiled-with-all-the-transformations.js”>
- target: { esmodules: true }
- Tree shaking (Lodash)
importvsrequire- cut out debug tools
- Babel 7 (preset-env)
useBuiltIns: ‘usage’to polyfill less- loose mode
- node_env = production
- Use code splitting to lower the initial page load, delay the rest until later
- Don't use source maps in production!!!
- Scope hoisting https://github.com/rollup/rollup
- Great if you're developing a library
- Lot's of libraries use scope hoisting
- Function's are inlined instead of required with an expensive closure
- Webpack 3 uses scope hoisting
- 70K -> 37K (gzip) just by using scope hoisting
- need to use the
ModuleConcatenationPlugin
- Use image skeletons (svg, blur (1KB), solid color), load real images later
- perceived performance
- Reduce TTFB
- Server Timing API
- https://www.w3.org/TR/server-timing/
- just a response header server-timing:
<name>;dur=<duration>;desc=<description> - Example: https://gist.github.com/paulirish/a76ac17fc211b019e538c09d8d827691
- Only use this in development (makes request larger and you don't want people to know what you're using on the backend)
- Compress your API responses
-
there is literally no reason not to
- Original size: 241 bytes gzipped (73.28KB uncompressed)
-
- BROTLI compression format (developed by Google)
- Almost every browser supports it: https://caniuse.com/#feat=brotli
-
More effective lossless compression algorithm than gzip and deflate
- Much better load time
Babel is going to detect if you need loose mode or not and is going to automatically turn it on and off
Prepack: Partial evaluation https://prepack.io/
Prepack is a tool that optimizes JavaScript source code: Computations that can be done at compile-time instead of run-time get eliminated. Prepack replaces the global code of a JavaScript bundle with equivalent code that is a simple sequence of assignments. This gets rid of most intermediate computations and object allocations.
Angular
- AOT (AHEAD-OF-TIME compilation)
Angular Ivy
Hacker news clone:
| NAME | 3G TTI (sec) | 2G TTI (SEC) |
|---|---|---|
| PREACT | 1.5 | 1.92 |
| SVELTE | 2.2 | 2.5 |
| REACT + DOM | 2.09 | 2.57 |
| GLIMMER | 2.09 | 2.57 |
| ANGULAR | 3.2 | 4.3 |
Keynote
Software Architectures
https://www.youtube.com/watch?v=RJuP7ntB7hc
Making decisions by yourself is hard, let alone with a team. As developers, making good technical decisions in teams is key to our jobs yet we don't explicitly learn how to do that. ... I will introduce a framework teams can use to evaluate options and find consensus when making big technical decisions, with an example.
Consensus
- There is no consensus on what consensus means
-
Consensus means finding an option that all team members will support. It does not mean that all team members would select that option as their first choice.
-
Consensus is finding a way to move forward with a shared understanding.
- Consensus is not:
- Coercion / persuading someone
- Pure majority rule
- Compromise / an agreement made by each side making concessions
- half the code base in Elm, and half in JavaScript?
- Giving up
- Strive for consensus, have a fallback
Goal make the decision obvious as a collective brain A team decision making process
-
Understand the decision
-
Check our emotions
-
List options
-
Evaluate options
-
Are we ready to decide?
-
Build consensus
-
Sleep on it
-
Document it
-
Understand the decision
- What is the goal or problem?
- What is the cost of delay?
- What is the cost of reversing it?
- What are the risks and opportunities?
- risk: possible rewrite, technology too bleeding edge
- opportunity: next wave of technology everyone is excited about and enables us to develop really fast
- What is our context and appetite for risk?
- startup may have bigger appetite for risk vs larger company
- What is the conflict?
- personal one: underlying conflict. Super bored / excited about something, but team mates don't feel the same.
-
Check our emotions
- Put stickies on the whiteboard as a team:
- What are our fears / concerns?
- What are we excited about?
- What are the best and worst case scenarios?
- Then think about the things we're worried about or maybe unrealistically excited about:
- What info would enrich our intuitions?
- Is something or someone else influencing me?
- Put stickies on the whiteboard as a team:
-
List options
- What is the goal?
- What are the options?
- Brainstorm more options!
- Example:
- Should we use Ruby on Rails for our next big project?
- Goal: develop faster as an organisation
- Options:
- Yes!
- No, but for a smaller project.
- No, never.
-
Evaluate options
- You can do this on the whiteboard with stickies
- Simple pros & cons: Benefits & opportunities vs Costs & Risks
- Put stickies with pros and cons under each option
- Find the common elements
- Vote
- Everyone gets 5 dots and puts votes on what they think are the most important factors relevant
- You can put question marks where you think you need to clarify things with some more information
- Then you can look for the trade-offs per option
- This should make the decision more obvious for your team (based on the hard trade-offs).
-
Are we ready to decide or do we need more info?
-
Build consensus
- Agree on a consensus fallback method
- Because it is hard to build a consensus
- Agree on the main trade-off
- Map out your positions
- Everyone votes on 1 option
- Consensus check
- What if we went for the majority rule, how would people feel about that?
- Give how you feel between 1 and 5.
- Depending on the number you may need to talk more.
- Is there an option for mutual benefit?
- "Let's not do it for the big project, but let's do it as a prototyping thing. Let's learn about it together as a team."
- If you can't agree, agree how to move forward
- Fallback methods
- Leader decides
- More research
- Vote (minority cedes)
- Survey experts
- Agree on first steps or a sub-problem
-
It's really important to at least have something you agree on after this process. Because maybe you've spent like 2 or 3 hours talking. You really want to go away feeling like you've made some progress. You really want to have an island of certainty in the sea of uncertainty.
- Agree on a consensus fallback method
-
Sleep on it
- We think we're here, but in a week let's see
- A way to not be too attached to your decision when you come back and revisit
-
Document it
- Will help new team member understand why things are the way they are
- Will help you evaluate your decisions in the future: "Was that a good decision?"
In case of limited time or in a team team members who are very argumentative:
- Agree on a fallback method
- Appoint a sub-team (1 or more team members) to do the research and write a proposal
- The rest of the team get's a limited time to give feedback
- If no consensus is reached within the time-frame: fallback method
A few resources
- Book: The Right Decision, Stein
- Book: Collaboration Explained, Tabaka
- Talk: A young lady's guide to technical decision making, Majors
- Blog: Architecture Decision Records, Nygard
Game Dev
The internet offers an endless amount of simple online games like solitaire, minesweeper and hearts. However, these games are usually done with terrible UI/UX, lame graphics, full of banners and ads, and (dare I say it), built on FLASH. In this presentation I will talk about how I built a DOOM minesweeper game with React, Redux & Typescript.
Inspirational
At Springest, the leading marketplace for Learning, we do OKR-driven development. We've worked the Objectives & Key Results framework seamlessly into Holacracy. Holacracy is the self-management practice for running purpose-driven companies, on which we have been scaling for over 5 years. I show how Springest's purpose –"Helping people reach their full potential through learning"– trickles down to the Product Development circle, how it helps us adapt strategy, and how it perpetually forces us developers and product owners to think about the "why?" and the "why now?" of any project we undertake.
An simplified imitation of Springest’s structure
- Circle
- A group of Roles that all contribute to the same Purpose.
- Role
- An organizational entity used to define certain functions of the organization. The definition of a Role includes a Purpose to express, Domain(s) to control, and Accountabilities to perform. The only way for a Role to be created, revised, or destroyed is through the Circle’s Governance process.
- Link lead
- A Role that holds the Purpose of the overall Circle. The Lead Link is responsible for assigning people to Roles that have been created through Governance Meetings. The Lead Link also allocates resources and defines Priorities, Strategies, and Metrics within the Circle.
- Governance
- An explicit, written set of rules and expectations including the Circles, Roles, Purposes, Accountabilities, Domains, and Policies of the organization. The organization’s Governance changes in response to the demands of the environment through the processing of Circle member’s Tensions during Governance Meetings.
- Tension
- A person’s felt sense that there is a gap between the current reality and a potential future. The Circle processes member’s Tensions during its Governance and Tactical meetings. This approach ensures that Governance and operational changes are driven by real experience rather than theory. https://www.holacracy.org/glossary
Front-end; Advanced;
A story about global rewrite of enterprise application into React / Redux with the happy end. Migrating application into a brand new stack is not a big deal, but if you have a really huge app is can become a nightmare! I'd like to share our experience, lessons we learned, some architecture decisions we made during over a year rewrite process of one of the applications in Jira family.
Why a global rewrite?
- Old stack has slow development speed
- Old stack makes it hard to attract new developers
- Here is this old project, have fun! 😥
- Most junior developers only know new technologies
Lessons learned
- Don't rewrite everything all at once, but pick parts to rewrite (so you see the light at the end of the tunnel)
- Flow
- Documentation, no need to have knowledge of the whole project
- ESLint
- Consistent Filenames (https://www.npmjs.com/package/eslint-plugin-filenames)
Inspirational
As developers, we solve problems, we handle challenges almost every day. Some developers take their technology, tools, infrastructures and frameworks for granted - they "magically" work. They think that by simply using them, they are considered experts. The truth is that they are "expert beginners". However, there are developers who constantly keep learning, dig deeper and understand why things work the way they do. They are on the path to become experts. They are "Active Learners".
In this session, we will learn how to become Active Learners and how to avoid the "Expert Beginner" trap.
https://www.youtube.com/watch?v=3GrNFnKNy-I
-
In interviews a lot of seemingly good developers didn't pass the interview. Why?
- They use it every day, but cannot explain how it works
- not knowing the internals, how it was built and why
- They know its pros, but cannot explain its cons
- They know how to solve their problem, but think that it's the only solution
- They use it every day, but cannot explain how it works
-
The type of developer they want:
- Solves problems
- Any kind of problems
- Looks at the bigger picture
- Is an active learner
Novice -> Advanced beginner -> competent -> Proficient -> Expert | v Expert beginner
Some developers have "ten years of experience" or "the same year of experience ten times"
"This is a black box" "It magically works" "That was here before me" "The other team is responsible for this" "X sucks, Y is the best. It just is"
- Active learner is a mindset
- You realize that there is something bigger than what you currently understand and are taking the path towards becoming an expert.
- "You as a project"
- have a plan, set a goal and stick to it
- to avoid learning the same over and over again
- Read
- About things you know
- About things you don't know
- Share your knowledge
- Write on twitter or a blog
- Answer questions on StackOverflow
- Writing is not easy, you must really understand the things you write
- Leave your comfort zone
- Other technologies
- Other tools
- Other ecosystem
- Other team
- Other company
- Rediscover programming principles in other languages / frameworks
- After school activities
- Visit meetups
- Do side projects (create black boxes, code things you're interested about)
- Repeat