.jpg)
We kicked off our 2022 North-West events calendar on Thursday 7th April with MCR Tech Connect - our first in-person meetup for two years (thanks Covid 🙄). Organised by our Front-End specialists Charlotte & Megan, we brought together over 70 of our Northern tech community to listen to 5 brilliant speakers from Matillion, Booking.com & BJSS. The evening was hosted by our friends over at MoneySuperMarket in their uber impressive Spinningfield office with amazing views over Manchester. We’ve shared a round-up and the recordings of all 4 talks from the evening, check out all the highlights below.
📹 Watch the highlights video here!
Escaping the Second System Syndrome by Focusing on Fundamentals
Filip Banasiak, Senior Front-End Engineer @ Matillion
Matillion are on a mission to make the world’s data more useful, and they’re currently working on two main applications to help them accomplish it – METL & Matillion Data Loader (MDL).
Filip and his team are currently re-writing a new version of MDL from scratch using React & TypeScript. Excited about the opportunity to create a big system from scratch, they realised rather quickly that they may have the beginning of what’s known as the ‘second system effect’.
In his 1975 book “The Mythical Man-Month”, Fred Brooks described the second system effect as the tendency to over-engineer the second system with all the ideas and frills that the engineer couldn’t use in their first one. Filip and his team knew the best way to avoid the second system effect was to focus on the fundamentals of React and follow good programming practices. These are 4 of the general guidelines they wanted to stick with:
1. Avoid hasty abstractions and repeat code on purpose.
‘DRY: Don’t Repeat Yourself’– was a term coined in ‘The Pragmatic Programmer’ in 1999, and stated that every piece of knowledge needs to have a single, unambiguous representation in a system in order to develop reliable and easy to understand software.
But not all duplication is bad and it’s possible that this drive to keep code DRY from early on can lead to wrong assumptions which in turn can lead to abstractions created too early.
Using repetition on purpose will lead you to better abstractions as you’ll give yourself time to see them forming more naturally. It will help you spot actual commonalities, or maybe even realise that you’re looking at 2 completely different use cases.
2. Break down wrong abstractions by starting over
‘The fastest way forward is back’. – Sandi Metz
Remember that refactoring is not a failure, it’s a lesson leaned and a step in the right direction. It’s also an investment in time saved in the future.
The wrong abstraction perhaps didn’t start out wrong. It may have been correct at the beginning, but as time went on and more people worked on it, it became difficult and expensive to work with.
3. Write what you know
Don’t focus on what might be, or what may be needed in the future. Focus on what you know today and write your code naturally. Requirements might change which can leave you with confusing codebase that covers use cases that don’t even exist.
4. Use children pattern for better composability
The children pattern is one of the absolute basics of React and is one of the best tools we have to improve the composability and readability of our components. Using children you can compose fields however you want. There are 2 main benefits of this approach:
Reusability: you can use that same container component in multiple places easily, and you know it will always behave in the same way, regardless of what fields are rendered.
Resilience: it’s trivial to respond to design changes and to move children fields around or add/remove a new one.
Viv's Short Course on Web Accessibility for Front-End Developers.
Viv O’Brien, Front-End Engineer @ Matillion
In order to design inclusive experiences, we need to become familiar with how users use our interfaces and consume and navigate our content. Around 1.3 billion people across the world live with some form of disability. But with many websites missing vital accessibility features, millions of users are being excluded from accessing web applications. This illustration from Microsoft helps to highlight the different users who may be using your web interface.
There are 4 main principles of accessibility guidelines and 3 levels of compliance:
(Read more on the WCAG Guidelines here).
How accessible is your website?
You can test the accessibility of any website using Axe - an accessibility testing engine for websites and other HTML-based user interfaces. It's fast, secure, lightweight, and was built to seamlessly integrate with any existing test environment so you can automate accessibility testing alongside your regular functional testing.
Through a site scan, Axe will reveal any modifications you need to make in-order to improve the accessibility of your site. There are 4 different levels:
Critical: Completely Results in blocked content for people with disabilities.
Serious: Partial results in serious barrier - partially preventing people from accessing fundamental features or content.
Moderate: Results in some barriers for people with disabilities, but will not prevent them from accessing fundamental features or content.
Minor: Considered bugs.
Lighthouse is another tool for testing and improving the accessibility of web pages, but is more likely to reveal false positives.
So what are the next steps? Instead of just testing your site after it’s live, you can shift that left through the power of automation by testing as you build. Matillion incorporate end to end testing using Cypress axe.
Irrespective of the framework or technology you use, we should all build for accessibility. Viv highlights, “as Front-End Developers, it's our primary role to build the user’s interface of a site or application. With this in mind, it's important to consider that end-users can range from permanent, temporary or situational disabilities. After all, each of us will fall on different parts of the spectrum throughout our lifetime. As Cindy Li says “We are all just temporarily abled.”
💡 You can read more on Viv's talk here: Inclusive Design at Matillion: Building for Everyone
The Search For a Modern Front-End Developer.
Jess Wong & Jay Nelson, Software Engineers @ BJSS
The role of a Front-End Developer has changed drastically in the last 10 years. Websites have become much more advanced, tooling libraries are continuously evolving and new frameworks are being built on a regular basis.
Whereas the front-end used to purely mean the front-end of an application or website, it now handles much more, including:
| -Security (user authorisation, form handing) -Accesibility -UX interactions & animations -Routing |
-Offline Data Handling (PWA) -Payments (web APIs) -API integration -Server-side rendering |
So when hiring Software Engineers, what is it we’re actually searching for? Jess shared two diagrams to highlight the change in skills required for both Front-End & Back-End Engineers over the years.
By being too rigid in the specifications and experience required using particular tools or frameworks, you run the risk of stunting the career progression of your employees and limiting their growth. As the lines between Front-End, Back-End & Full Stack Engineers continue to blur, try to decide on your non-negotiable skills & be open to compromising on everything else by placing more focus on aptitude & personality.
The perfect hire very rarely ticks every box on a job description and organisations who wait for the complete skillset will not only have to compete in a crowded marketplace where salaries are rapidly increasing but will suffer a longer time to hire.
Up & Running with AWS CDK at Booking.com.
Farhan Idris, Senior Software Engineer @ Booking.com
❗️Unfortunately due to a technical issue, we were unable to record Farhan's full talk. You can find all the slides to his talk here or connect with him here to ask him any questions on Booking.com’s AWS CDK endeavours.
AWS Cloud Development Kit (AWS CDK) is an open-source software development framework used to define your cloud resources in a familiar programming language. It supports TypeScript, JavaScript, Python, Java, C#/.Net, and Go (in developer preview).
Booking.com embrace AWS CDK along with Cell-Based Architecture (CBA) for 100's of interconnected systems as they modernise their tech stack.
So, why use CDK?
Re-usability:
-Able to create reusable cloud components with constructs
-Store this in external libraries and share across the organisation
Flexibility:
-Able to define what resources you want and the permission to set for resources etc.
-Very developer friendly and can be embedded in a team’s existing ways of working
Enforce Engineering practices:
-Integrate common practices for developers for our infrastructure, such as code reviews, version control and unit testing
Ownership:
-The team own the infrastructure of their resources for the given service and they can decide what they want or need.
For larger organisations with many teams that are building hundreds of services with CDK, there are some fundamental considerations before you begin:
1) Agility: how quickly you can meet challenges
2) Scalability: how this can be leveraged when having multiple services
3) Modularity: how can you group appropriate services in a group and be able to connect to other groups of services
4) Maintainability and governance: how do you manage all your services as a whole.
What’s CBA? (& it doesn’t stand for can’t be arsed!)
Cell-based architecture is an approach built around the idea of grouping services and data together under a cell infrastructure, with a cell gateway at the borderline.
Why have a cell gateway? It’s to ensure the safety gate keeper, that deals with anything that goes in and out of the cell. It also provides the flexibility for services to expose only what they need outside the cell and keep what is confidential inside the cell.
A huge thank you to our 5 excellent speakers for presenting - you can connect with them all via the links below. If you'd like to give event speaking a go yourself, you can register your interest here and let us know what topics you're interested in sharing with the tech community. We're always keen to hear what you want to see and hear at these events, so please share any thoughts with us so that we keep organising events you actually want to attend!
Filip Banasiak of Matillion
Viv O'Brien of Matillion
Jess Wong & Jay Nelson of BJSS
Farhan Idris of Booking.com
Our next event will be taking place on Thursday 19th May featuring speakers from our Platform Engineering & Infrastructure network. Stay tuned, we'll be sharing more details very soon...
