CodeIsGo.com

Kirupa wrote this short article in which he describes decision process when one needs to decide between 2 technologies. Two of the hottest technologies for building cross-platform apps these days are Progressive Web Apps (PWA) and React Native.

In a magical world, if cost and time aren’t a problem, you should build both a PWA and a React Native solution and architect your app in a way to re-use as much logic between the PWA, React Native-Android, and React Native-iOS projects as possible.

The PWA gets you the widest reach where any device with a browser can view your app. The React Native app gets you richness/depth where you get to take advantage of a device’s native UI controls for maximum performance and familiarity for users.

Questions and answers the article helps you with:

• Are you going mobile first or everywhere first?
• If you want the lowest-cost option for your development team, then PWA wins
• If you want the best UI responsiveness and performance, go React Native
• If you care about low-end devices, PWA is slightly better than React Native
• React Native creates a native app package (usually tens of megabytes in size!)
• What are you (or your development team) skilled in?
• Is your app consumer focused or enterprise focused?
• Do you need access to native device APIs?

Deciding whether to build an app as a PWA or using React Native isn’t a simple game of creating a scoreboard and seeing who ends up with the highest score at the end. Good read!

If you’re looking for a message broker for your next project, read on to get an overview of to of the most popular open source solutions out there. Introduction by Vitaliy Samofal.

Message broker translates a message from the formal messaging protocol of the sender to the formal messaging protocol of the receiver.

The necessity of improving system integration caused the development of message brokers, that is especially important for data analytics and business intelligence. In this article, the author looks at two big data tools: Apache Kafka and Rabbit MQ.

Introduction deals with following questions:

• Why did message brokers appear
• Message broker use case
• Messaging in a nutshell
• When is a message broker needed
• Comparison of Kafka and RabbitMQ
• Including back story, pros and cons, best usage cases

Both Apache Kafka and RabbitMQ are truly worth the attention of skilled software developers. Great!

The guide by Rahul Goradia on topic of UI Components Design System. You can think of it as an instruction manual. It’s also like an inventory which can be used to pick up resources and use them in your design.

A UI design system is a set of standards for design and code along with components that unify both these practices helping them complement one another and producing the exact result which is conceptualised.

To design consistent UI across every part of your design can be daunting. A UI system helps your users navigate intuitively and makes it uniform across your product, making them familiar with your design language.

The guide has then sections related to:

• Why do we need a UI System
• Creating a UI Design System
• Moodboards & colour palette
• Border radius and shadows
• Type scale
• Icons
• Buttons, sliders & progress bars
• Dropdowns, tags and popups (complex elements)

Keep it clean and simple. After setting your elements down you could start placing these elements in your design. Nice one!

Herve Khg published this hands on guide how he goes about migrating projects to serverless. The guise only focuses on the terraform code for building the infrastructure, not on the app code itself.

His article describes these steps on his journey:

• List of AWS Resources
• Building Database and migrate data — RDS MySQL
• Building S3 which serve as frontend
• Building CloudFront
• Building Route53
• Building API Gateway
• Building Lambda & Security Group
• Deploy your Terraform Code
• Enjoy Your Serverless APP

Each step has example code for terraform provided. Simples!

Written by Gareth Clubb this article is about improving the performance of the telegraph frontend. Improving the performance impact of third-party scripts on a website takes time; results won’t come overnight, but by being patient and chipping away slowly, eventually these efforts will be rewarded.

His article focuses on:

• Creating a Performance Culture
• Breaking down the silos (build a rapport)
• Deferring all JavaScript
• Regular audits of the tag managers
• Testing each additional tag request
• Monitoring
• Aim for smaller bundles and reduce parse/compile times

By following best practice advice for web performance, involving teams from across the organisation and making our changes visible – the business and most importantly our users can see the real benefits. No matter where a person lives, what device or connection they use – we should all have the same access to news and information.

Good read!

An article by Aphinya Dechalert about her journey from zero to dev lead and what she wished she could learn early in her career. The moral of her story – protect your time.

Twenty years from now you will be more disappointed by the things that you didn’t do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover.

When I started down my path as a developer, I found myself eager to please and prove to everyone that I am a proficient and capable at coding. As a result, I would do anything that my bosses and managers required I do – from organizing office events, getting gifts for birthdays, leavers and anniversaries, to playing the UX designer and marketing campaigns coordinator – whilst being the lead developer.

‘Busy’ is what happens when you forget to protect your time and neglect to nurture yourself.

She then explains how to protect your time:

• Set your boundaries
• Limit your active connections
• Be aware and wary of time sinkholes that do not benefit you mentally or physically

Learning to prioritize oneself is an art form that needs to be practiced and developed over time. Very wise!

Thoughts from Robert Collins on luck of continuous delivery in Free / Libre and Open Source Software projects (FLOSS). He outlines how continuous delivery could work for such a project.

The core of this article could be described as: Pick a service discovery mechanism (e.g. environment variables), write two small APIs – one for flag delivery, with streaming updates, and one for telemetry, with an optional aggressive data hiding proxy, then use those to feed enough data to drive a true CI/CD cycle back to upstream open source projects.

He also describes why you would want CD:

• Lower risk upgrades
• Faster delivery of new features
• Better code hygiene

He then presents his working model for CD which includes feature flags, telemetry etc. You will find charts explaining CD and learn about challenges faced by OpenStack project when talking about CD and distribution. Interesting read for anybody working on [FLOSS](and Open Source Software) and FOSS.

A piece from the pen of Peter Parkanyi about challenges and approaches to testing. There has been a lot of research on the software crisis and how to get out of the mess we’re in, and it often contradicts the wisdom of the crowd. He takes a look at different strategies that drive software quality, and where they actually make a difference.

From the bottom to top, he generally looks at software verification at the following layers: type system, unit tests, integration tests, and organizational management structure.

The author then dives into:

• Management
• Integration tests
• Unit testing
• Type systems
• Weak but static
• Dynamic

Software development is a process, and it’s practically impossible to achieve perfection. As long as the team has a plan to approximate it, and everybody is committed, we can call it good enough, then get out of the office to enjoy the sun. Interesting!

Iskander Samatov is this introduction into Strategy design pattern and JavaScript. One particular piece of syntax that is unlikely to ever change in ES6 is if / else and switch statements.

The Strategy pattern was popularized by GoF (Gang of Four) and is a great tool for adding mutable, interchangeable parts to certain pieces of your application logic.

Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

It belongs to Behavioral pattern family. This family addresses responsibilities of objects in an application and how they communicate between them at runtime.

Strategy implements the variable parts of the functionality with an agreed upon interface for otherwise generic object which we call “Context”. The context uses different strategies to perform a certain task based on the client’s invocation.

Think of the set of strategies as a toolbox and the context as a craftsman. The craftsman uses a different tool depending on the job. But in this case, all the tools have the same type of instructions on how to use them.

The code analysis for Passport.js library is also included with example code and charts explaining the pattern. Nice one!

An article by Nebojsa Radakovic from bejamas.io, in which author shares their experience with the headless CMSs they used so far on about 30 JAMstack projects. JAMstack is a modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup.

Static websites have evolved to embrace innovative technologies and today they can do things such as handling real-time requests, processing payments, managing customer accounts, carrying out full website search, and a lot more. That’s why we don’t call them static anymore, we now call them JAMstack websites.

Headless CMS decouples content management from the presentation layer. The article then compares these systems:

• Contentful
• Sanity
• Netlify CMS
• Dato CMS
• Storyblok
• Strapi
• Prismic
• Wordpress API
• Google Spreadsheets API

It is hard turning a blind eye to the benefits of using JAMstack (and headless CMSes for that matter) from web developers and marketers perspective. Read full article to learn more!