CodeIsGo.com

Filip Rakowski wrote this blog series about optimizing Vue.js application for perfromance. He focuses on code splitting our state management – Vuex modules.

Ability to code split Vuex modules is a powerful tool. The more data-related operations you’re dealing with in your application the more savings you’ll get in terms of bundle size.

This series is based on learnings from Vue Storefront performance optimization process. By using below techniques we were able to cut off size of our initial bundle by 70% and made it load in a blink of an eye.

The author then explains what are the possible ways to register a Vuex module and what are their pros and cons. He also writes about:

• Static Vuex modules
• Dynamic modules
• Properly code-splitted Vuex modules
• Lazy loading Vuex modules

Even though static Vuex modules registration is sufficient for most use cases there are some certain situations when we might want to make use of dynamic registration. Article is accompanied by example code, charts and links to further resources on the topic. Nice!

Adam Gajek about his experience with Scala programming language and about criticism about its mixed Functional and Object-Oriented Programming nature. He decided to compare both approaches in terms of extensibility based on the Expression Problem formalized by Computer Science Professor, Philip Wadler, who greatly contributed to the development of Functional Programming.

Our code is evolving all the time. There is always some refactoring, bug-fixing and (hopefully) additions of new features.

Software extensibility is vital so that one of the famous SOLID principles is dedicated solely to this subject, as is formulated by Bertrand Mayer’s Open-Close Principle.

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

The Expression Problem focuses on one of the most important features of code: extensibility. This can be described as the ability to evolve without:

• Affecting the clarity of the existing code
• Putting much effort into adding new functionality
• Breaking code that works properly

Read more about this interesting topic in this mini series of articles. Recommended for any programmer!

Bob Murphy published this detailed guide how to build a garage door monitor with your RaspberryPi. There are lots of garage door monitor projects on hackster.io and other Maker sites. Many are single-purpose solutions. The author wanted a project that would be extensible, to build on the skills learned for future IOT projects.

Also, he wanted a platform that was well-documented and well-supported. Adafruit’s cloud service for Makers, adafruit.io, fit the requirements.

An Adafruit Feather Huzzah checks whether the garage door is open/shut via a magnetic switch, then sends the current status to an adafruit.io feed.

His basic setup:

• GarageDoorMon doesn’t use a battery, it’s powered by a 5V adapter; you’ll need a long wire from the door and place the Feather Huzzah near a mains power source
• Logic is reversed, a ‘1’ is sent to adafruit.io when the garage door is open, ‘0’ when closed(SHUT)
• Raspberry pi zero W runs a system service to monitor the door status, shows on 4-digit display
• Can be used with IFTTT to notify user via email, text message etc
• The Pi Zero W uses MQTT subscribe directly from adafruit.io feed, via Python client code.

To get full information on the process, parts used, images describing the installation and setup follow the link to original article! Well worth your time!

It’s easy to think of tech debt as the monster in the codebase. But what does it actually consist of, and how can you manage it? Jennifer McGrath helps you to find out.

Technical debt is anything (code-based, or not) that slows or hinders the development process.

Explaining technical debt isn’t always so straightforward.A common perspective on technical debt is that it stems from engineers’ carelessness, hastiness, or even sloppiness, often in an attempt to achieve results faster.

But while technical debt can result from recklessness (inadvertently or not), it’s can also be leveraged deliberately. Just as you can borrow capital in a responsible or careless manner, you can create technical debt strategically or recklessly.

The article then goes on:

• What does technical debt look like?
• Automation and cognitive load
• Absence of context in daily practices
• Human factors
• How to prioritize addressing technical debt
• Use metrics to quantify the business impact of technical debt

In essence, creating technical debt is inevitable. You cannot avoid encountering it so long as you continue coding and growing. But addressing technical debt doesn’t have to come at a cost of your forward progress. Interesting read!

Posted by Hiranya Jayathilaka and Rachel Myers this article focuses on Firebase offers security rules – a powerful mechanism that helps enforce the security and logical correctness of your apps. The backend services use security rules to authorize and validate the requests made by client apps, and make sure they adhere to the policies that app developers have put in place.

The authors then share a few tips related to security rules and the Admin SDK:

• Admin SDK bypasses security rules
• Make certain data read-only
• Role-based access control with custom claims
• Temporarily withhold sensitive data from users

… and more can be found in the original article. Firebase takes a declarative approach to ensuring the security and logical correctness of your apps. By keeping the rules separate from application code, you can easily update your security policies, while keeping the application code simple.

With Firebase you can patch any detected security vulnerabilities instantly, without having to go through a long and arduous app rollout. Nice one!

An article by Iain Collins on how and why to use custom error types in JavaScript. Handling errors can be tricky. How Error() historically worked in JavaScript hasn’t made this easier, but using the Error class introduced in ES6 can be very helpful.

In JavaScript some vendors have implemented a conditional catch clause but it’s not a standard and not widely supported in browsers. As a result of not having a standard way to define errors — or to return them when throwing them from a server to a client — information about an error being returned is often lost, with projects featuring bespoke error handling.

The article dives into:

• Comparing how Throwing errors is done in other languages
• Defining error types in JavaScript
• Returning Error objects from Promises
• Serializing Error objects in JSON

JavaScript actually has a several core Error types by default, but they are quite niche and of limited usefulness for error handling in most applications.

However, with ES6 you can extend the Error class and define custom errors with their own behaviour – such as logging errors automatically – and you can choose what detail to add or include when returning an error. Good read!

The more code you have, the less agile you are. Code is a liability, not an asset. It’s like tar.

An article by Matt Reyer from Slimvoice – a webapp without JavaScript is a series where he documents how he rebuilt his app, Slimvoice, using as little JavaScript as possible. He’s tried to present JavaScript alternatives and encourage those who reach for a SPA for every project to give it a second thought.

Motivation: deliver an amazing user experience with a great design while drastically reducing the complexity of the code, maximizing reliability, and minimizing the cost to the end user.

The author then describes how he has put frontend together:

• Plain old HTML and CSS
• The Checkbox/Label trick
• The / elements
• Forms & Input validation

Author concludes that plain HTML inputs covered most of his needs, but he found himself wishing for more innovation in the HTML spec to cover more inputs and remove the need for JavaScript altogether.

And one advice standing out? Don’t be scared. You can build it yourself! You don’t need a framework! Great read!

Rafael Sales wrote this article about gRPC as alternative to REST APIs. gRPC is an open-source remote procedure call framework and Protocol Buffers is a mechanism for serializing structured data.

A remote procedure call framework is used when applications running in different processes need to exchange data. It shouldn’t matter whether these are running in the same or different machines, or one is running in the cloud and the other in a desktop/mobile client.

The article briefly introduces gRPC and explores the core features of gRPC and Protobuf, and compare to JSON REST APIs.

gRPC uses HTTP/2 as its base transport protocol. It benefits from the multiplexing feature of HTTP/2 to execute requests/responses in parallel using a single TCP connection, reducing the hardware resources usage in both client and server compared when comparing to HTTP 1.1.

It also supports bi-directional streaming, which makes it capable of handling long communication patterns such as chat and file download/upload split in chunks.

Protobuf, for short, is a language-independent mechanism for defining structured data. To learn from what pieces Protocol Buffers consist and why Google has chosen them to use wit gRPC read the rest of the article. Super useful!

When you start developing your first Scala projects, you may sometimes miss out to address one common problem with pattern matching, and that is error handling. This article by Eugene Krotov teaches how to do it.

In the article, author looks at a few ways to handle the MatchError runtime exception in Scala:

• Adding a default case _ to catch all unmatched options
• Using the keyword sealed with the base class or trait for matching options (although this is a workaround not a problem solver)
• Changing the compiler options to stop compilation whenever there are warnings produced thanks to sealed

The article provides step by step instructions, code examples and more. It reviews the listed ways to address or mitigate the problem. Very good and to the point!

An interesting article by Carl Fredrik Samson about his journey with Rust. He started with porting some code from a familiar language, C# or C++ in this case. But if you just port the code you will probably miss some of the features that makes Rust special.

In this post he talks about how to port a short raytracer written in C#/C++ codebase to Rust, then applying some simple optimizations by leveraging some features in Rust.

Author then explains each line of code and how it was ported from C# to Rust (or as close as he could get). The observation?:

Rust is pretty similar to the optimized C# when we run the code ported line by line as similar as possible, but the memory usage is less than 1/4 of C#.

Then he describes:

• Optimizing part 1. Use iterators
• Optimizing part 2. Buffer the results if you can
• Optimizing part 3. Using Rayon
• Bonus: Fixing the huge increase in memory usage.

Rayon is a paralleization library for Rust, and gives us superpowers if you already have a piece of code that uses an iterator to produce a result.

Read more to learn how they slashed down render time to one ninth of original! Good read for anybody interested in systems programming languages like Rust.