CodeIsGo.com

An article about how to get started with logging in Kubernetes. This topic is quite extensive as there are many components to consider before having a complete perspective of what’s happening inside your applications. By Erin Baez.

This post gives you an introduction to recommended practices, tools, patterns, and strategies for logging in Kubernetes. You’ll learn that instrumenting your application to emit logs is not going to be enough. By default, Kubernetes emits a lot of logs from all its components, so you’ll have a lot of information. You’ll have to know where to look and how to manage all of those logs.

The main parts of this article:

• Starting With Kubernetes Logging
• Reading the Logs
• What Should You Log in Applications for Kubernetes?
• Architectural Patterns for Application Logs
• Exposing an Endpoint for the Application Logs
• Using a Sidecar Container
• What Other Logs Are Available in Kubernetes?
• Keep All Kubernetes Logs Together

… and more. In Kubernetes, you can consume several types of logs. But to get useful insights from all these logs, you’ll need to keep all of them together. Centralized logging becomes crucial in distributed systems like those you run Kubernetes in. When you have all the logs at the same place, you can go deeper when troubleshooting. Good read!

Let’s face it, life can be hard. It’s easy to say leave your problems at the door, but sometime common life stressors can affect employees’ personal lives so much that it creeps into their professional life. By Michelle Kankousky.

Increased levels of psychological or physical stress can have serious implications for their performance and that of their teams.

The article then goes in some detail into:

• What is a life stressor?
• What are the signs your employee is struggling?
• How can you talk to the employee about the situation?
• How can your business provide assistance?

No matter what the solution, the common denominator is consistency: each employee must be treated the same. Thinking ahead and establishing policies and procedures that address potential situations can help avoid problems. Good read!

Todd Palmer published this article about an architectural approach to better Angular applications. The article shows you how to keep your Templates declarative and dumb, your Components thin and smart, and your Services fat and happy.

The article will definitively answer your questions of how to structure your Angular application so the code is readable, testable, and maintainable. Specifically, this consistent approach makes our code more readable to others, especially those that are familiar with the approach. The code becomes more testable, because Services are easy to test.

A Template is Dumb when it doesn’t know anything about any other part of the application except for: Its Component and Its sub-component Templates. Services should be Fat and Happy. By Fat, I mean that business logic goes into your Services. When in doubt whether to put code into a Service or a Component, put it in the Service. Fatten up that Service and starve your Component.

The article is split into:

• Core Principles
• Templates should be Declarative and Dumb (Declarative, imperative, avoid complicated logic, small and simple)
• Components should be should be Thin and Smart
• Services should be Fat and Happy

A smart Component knows and controls exactly what the current state of the Template is. The Component determines exactly how to interact with the data model or Services based on user activity. Good explanation with examples of good and bac practice. All the code examples in the talk and article are in a GitHub repo. You will also get link to video resources. Nice one!

If you are an Angular developer there is no way you missed RxJS Observables but you might be less familiar with Subjects. Even though they are less frequent than simple Observables, they are extremely useful. Understanding them will help you write better, cleaner reactive code. By Dornhoth.

Observables are lazy Push collections of multiple values. A Subject is like an Observable, but can multicast to many Observers.

The article describes:

• Observables
• Subjects
• BehaviorSubjects
• ReplaySubjects
• AsyncSubjects

Intuitively, you can think of Observables as objects that emit streams of values. You need to subscribe to the Observable for it to start counting, the same way you need to call a function for it to be computed. Subjects are Observables. Nice intro into reactive programming!

Machine learning (ML), while it doesn’t exactly simulate systems in nature, has the ability to learn a model of a system and predict the system’s behavior. Over the past few years, classical ML models have shown promise in tackling challenging scientific issues, leading to advancements in image processing for cancer detection, forecasting earthquake aftershocks, predicting extreme weather patterns, and detecting new exoplanets. Posted by Alan Ho, Product Lead and Masoud Mohseni, Technical Lead, Google Research.

Google in collaboration with the University of Waterloo, X, and Volkswagen, announced the release of TensorFlow Quantum (TFQ), open-source library for the rapid prototyping of quantum ML models.

A quantum model has the ability to represent and generalize data with a quantum mechanical origin. However, to understand quantum models, two concepts must be introduced – quantum data and hybrid quantum-classical models.

TFQ allows researchers to construct quantum datasets, quantum models, and classical control parameters as tensors in a single computational graph. The outcome of quantum measurements, leading to classical probabilistic events, is obtained by TensorFlow Ops. Training can be done using standard Keras functions.

For all the details read original article. Super exciting!

CSS is an easy language to learn (and to implement) for creating a beautiful website. However, when it comes to implementing CSS at scale, it’s not that simple. For large scale websites and applications, CSS becomes really hard to write in. By Thoriq Firdaus in Coding.

CSS specificity is crippling up, and so, using !important is often inevitable and eventually adds up to the CSS file size.

Well, the good news is that web developers have come up with several methodologies to help write and organize CSS better, such as BEM, OOCSS, SMACSS, and ITCSS.

The article makes a good explanation how utility-first CSS works. It also makes a brief introduction to Tailwind CSS and optimising file size. Changing the way we write CSS is not always easy. It means that we have to unlearn what we are already used to. Well done!

Anna Monus wrote this piece about variable fonts. Variable fonts are popular for two reasons: they expand design possibilities and improve website performance. While the former statement is definitely true since variable fonts do provide infinite typographical choices, the latter only holds under certain conditions.

In this tutorial, author conducts a performance test on a live server to better understand the performance trade-off of variable fonts.

The article dives in:

• What are variable fonts?
• How variable fonts impact performance
• The challenge of testing variable fonts
• The test cases

… and much more. Comprehensive charts and speed measurements are also provided. Whether using variable fonts is worth it performance-wise depends on how the decrease in HTTP requests and the increase in total page size balance each other out. Nice read!

An article about how author has recently helped a client migrate a set of complex Ruby on Rails applications to AWS, deploying across multiple environments and regions. By Jake Morrison.

The big driver for improvement, however, was the need to separate customer data by country/region. GDPR compliance is easier if they keep European data hosted in Europe. Customers in China were also complaining about poor network performance crossing the “Great Firewall”.

One of the most important design considerations was handling all their apps and environments with a common framework. If there are too many special cases, the system becomes unmanageable. It’s a false economy to optimize one environment with custom code, but increase the cost of managing the overall system. It is better to have a standard template with configuration options. On the other hand, we can’t have too much configurability, it must be “opinionated”.

The article then goes over solution:

• Architecture
  • Multiple AWS accounts
  • Sharing resources between accounts
  • Structure
  • Meeting legacy apps half way
  • Deploying with CodeDeploy and Capistrano
  • Encryption

… and more. Very detailed article with all the code and a complete example of deploying an app to AWS. Good read!

In this article by Lawrence E Hecht we look at review of industry studies of the service mesh. They indicate that Istio has an early lead as a preferred control plane.

However, service meshes usually also have a data plane component as well as other value-added functionality. The mix-and-matching of these often open-source components into bundled solutions is an ongoing process and may impact the eventual winners and losers in this space.

A recent report by StackRox shows that adoption of Istio in production doubled over the last year, but usage is still minuscule; Only 4% of the respondents say their organizations have it in production environments.

It is noteworthy that 86% of respondents in both the late 2018 and the December 2019 surveys said their organizations are using Kubernetes as one way to orchestrate containers and microservices.

Read article in whole to get full picture, charts and a bonus. Nice one!

The Server Query Cache (QC) is a well-known feature of MariaDB Server–it caches SQL statements and the corresponding result sets. Today we have faster, solid-state disks and more RAM, so the Query Cache is less important. Reducing reliance on cache alleviates its negative effects, such as mutex blocking. By Anders Karlsson.

A mutual exclusion object (mutex) is a programming object that allows multiple program threads to share a resource (such as a folder) but not simultaneously. Mutex is set to unlock when the data is no longer needed or when a routine is finished. Mutex creates a bottleneck effect. The blocking means only one query can look at the Query Cache at a time and other queries must wait. A query that must wait to look in the cache only to find it isn’t in the cache will be slowed instead of being accelerated.

The article then in some detail describes:

• Query Cache Flags
• Query Cache Concerns
• The MaxScale Query Filter
• Mutex Work Around
• Fixing the Query Cache

… and more. Everything is demonstrated in provided code examples. Plus instructions how to test. Good read!