CodeIsGo.com

Use technology to your advantage and enhance the retention rates of your training sessions. Classrooms change. Courses change. But the age-old struggle of any learning or development session stays intact. How to retain knowledge gained beyond the training session? And how to apply the concepts taught during training to a real-life scenario? By David Hand.

Students, instructors, and organizations – they all come across this pain point eventually. Conducting a session seems relatively easy. What’s difficult is translating that time into something productive, enduring, and usable – long after the session is over.

This is a gap that only worsens with time. Knowledge retention and how to apply it continue to be significant challenges that dilute the effectiveness of training programs. In a LinkedIn Workplace Learning Report 2020, Learning and Development (L & D) professionals showed that evaluating the effectiveness of learning programs topped the list of areas of their strategic focus.

Their strategic priorities are condensed around learning outcomes – with 38% who want to evaluate the impact of learning, 35% who want to improve learning engagement, and many who agreed that course completion may not be the right engagement metric.

Thankfully, modern tools like hands-on virtual labs can help accomplish this easily. They are driven by cloud and immersive technologies and add convenience as well as time-savings for students and trainers. They also deliver much more than that. Hands-on virtual labs arm both learners and instructors with multiple opportunities to enhance training and increase retention. Follow the link to the full article to learn how. Good read!

Containers still mean “Docker” to many people. Docker popularised the modern use of containers in software development and deployment. These days, other technologies are around too. Here’s how Containerd, Docker and Kubernetes relate to each other. By James Walker.

As Kubernetes grew and more third-party tools arose around Docker, the limitations of its architecture became clear. At the same time, the Open Container Initiative (OCI) began standardising container formats and runtimes. This resulted in an OCI specification defining a container which could be used by multiple runtimes, of which Docker is an example.

The article covers:

• The rise of containerd
• Understanding containerd’s role
• The OCI
• What about my Docker images?
• Kubernetes and Docker

Containerd drops in to abstract this low-level wiring. It’s intended as a “client layer” that container software then builds atop of. This might be developer-oriented software, like Docker, or cloud-oriented devops tools such as Kubernetes. Each high-level user-facing interface (such as Docker and Kubernetes) now benefits from a choice of interchangeable low-level container runtimes (like containerd and runC). Good read!

In this post, we will focus our story on how Minerva drastically simplifies and improves the data consumption experience for our users. Specifically, we will showcase how a unified metric layer, which we call the Minerva API, helps us build versatile data consumption experiences tailored to users with a wide range of backgrounds and varying levels of data expertise.

The Minerva API consists of the API web server, a metadata fetcher application, and several clients that integrate with Apache Superset, Tableau, Python, and R. These components serve native NoSQL and SQL metric queries to the downstream applications.

The article discusses the following:

• A metric-centric approach
• Minerva API
• The data consumption experience

Minerva introduced a novel way of thinking about data, not only is it centered around a business- and metric-centric user interface, we also need to adapt traditional BI tools (that mostly talk SQL) to the interface of Minerva API. In some sense, it is akin to fitting a new square peg (Minerva) into an existing round hole ( BI Tools). Very good read for anybody interested in data science!

If you’re a tester or developer who needs to work with APIs across different platforms, HTTP Toolkit is a valuable tool to keep by your side. By Anshul Behl. By Dennis Martinez.

When it comes to testing the APIs of our applications, we have lots of tools at our disposal. Most modern browsers have built-in tools for web applications to inspect any network requests made on any given page.

HTTP Toolkit is an open-source application that gives you the ability to handle most of your HTTP traffic inspection, and it’s an ideal way to manage your API requests in a single place. This article will go through the basics of using HTTP Toolkit and explore how it can help you debug and test your APIs. If you have to manage any APIs, mainly through a web application, keep reading.

The article provides more information on these topics:

• What does HTTP Toolkit provide?
• Using HTTP Toolkit to intercept traffic from a web application
• Using HTTP Toolkit to mock HTTP requests and responses

HTTP Toolkit makes this intercepting and mocking easy through the “Mock” section. This section allows you to set any rules for handling different kinds of captured HTTP traffic. You can create a rule by selecting the HTTP method you want to monitor, filter those requests, and choose what you want to do next. In the free version of HTTP Toolkit, you can pause traffic before making a request to an application or service, after receiving a response, or both.

Once you begin inspecting traffic, HTTP Toolkit will collect every single HTTP request and response made from the apps and services you’re tracking with the app. It displays helpful information such as the HTTP method (GET, POST, etc.), the response status codes, the host where the request went to, and the URL path. From there, you can filter the requests or get a detailed view of any specific item and see almost every detail for the request and response. This information is invaluable when debugging apps or services connected to the Internet. Good read!

As automation becomes crucial for more and more business cases, there is an increased need to test the automation code itself. This is where ansible-test comes in: developers who want to test their Ansible Content Collections for sanity, unit and integration tests can use ansible-test to achieve testing workflows that integrate with source code repositories. By Anshul Behl.

Both ansible-core and ansible-base come packaged with a cli tool called ansible-test, which can be used by collection developers to test their Collection and its content. The ansible-test knows how to perform a wide variety of testing-related tasks, from linting module documentation and code to running unit and integration tests.

The article explains the following:

• How to run ansible-test?
• How to test your collection using ansible-test?
• Sanity tests
• How to ignore sanity tests?
• Unit tests
• Code coverage
• Integration tests

As shown above, ansible-test can provide a lot of value testing Ansible Content Collections thoroughly. You will get further learning resources in the article as well. Good read!

What are the differences between Single Page Apps (SPA), Server Side Rendered Sites (SSR), and Static Site Generator based sites (SSG)? How do they compare in performance, SEO, developer experience, and flexibility? In this article, we give you an in-depth comparison of SPA, SSR, and SSG to help you make an informed decision on which strategies to use for your next front-end project. By Jacob Jackson.

The three different strategies have unique architectures. Often, if you are using a JavaScript framework, the simplest approach is to make a single-page app (SPA).

The article then explains:

• The three strategies to JavaScript app development
• When to use each approach
• Performance
• SEO
• Flexibility
• Ease of development

To ensure a good user experience, your website needs to be fast. Some approaches are faster than others. In general, SSG sites and SSR sites are faster than SPAs in terms of loading content. SPAs, as mentioned earlier, need to download the JavaScript for the app before they can display content.

However, in some cases, SSG and SSR can be slower. Because the server sends the HTML along with the JavaScript, there is a certain amount of duplication in the code. This means that the overall downloaded file is bigger, making the Time to Interactive (TTI) slower. Regardless of this file size increase, SSG and SSR will usually get better performance because of the faster content loading time. Another thing to note is that SSR sites can sometimes be slower due to the files needing rendering on every request. However, this can be mitigated by using strategies like edge computing.

Each approach to building a website with a JavaScript framework has its pros and cons. SPAs are best for heavily interactive apps where JavaScript is essential, and development resources are limited. SSG sites have the best performance and are good for sites with purely static content like marketing sites. SSR is good for more advanced sites that use more dynamic data without using client side JavaScript. Nice one!

This best-practices article intends for developers interested in creating RESTful Web services that provide high reliability and consistency across multiple service suites; following these guidelines; services are positioned for rapid, widespread, public adoption by internal and external clients. By Love Sharma.

Article begins with elaborating on each box by starting with its principles:

• The six principles / constraints
  • Client-Server: Separation of concerns is the principle behind the client-server constraints.
  • Stateless: communication must be stateless, as in the client-stateless-server (CSS) style
  • Cacheable: To improve network efficiency
  • Layered system: A client cannot ordinarily tell whether it is connected directly to the end server or an intermediary along the way
  • Code-on-demand: REST allows client functionality to extend by downloading and executing code in the form of applets or scripts
  • Uniform interface
• Best Practices
  • Keep it simple and fine-grained
  • Filtering & ordering: For large data sets, limiting the amount of data returned is vital from a bandwidth standpoint
  • Versioning: There are many ways to break a contract and negatively impact your clients in API development for any given resource.
  • Pagination: One of the principles of REST is connectedness – via hypermedia links
  • Resource-naming
  • Monitoring: Make sure to add all kinds of monitoring to improve the quality or performance of your API
  • Security: Authorization / authentication, CORS, TLS, Idempotence

… and much more. Also consider self-descriptive messages: Each message includes enough information to describe how to process the message. Create APIs that mimic your system’s underlying application domain or database architecture of your system. Eventually, you’ll want aggregate services — services that utilize multiple underlying resources to reduce chattiness. Good read!

Sure, Google Cloud offers world-class infrastructure, but one of the main reasons that customers choose our platform is to run their applications on one of our managed container platforms: Google Kubernetes Engine (GKE), the most scalable and easy to use service from the company that invented Kubernetes; Anthos for managing containers in hybrid and multicloud scenarios; and Cloud Run, our serverless platform for containerized workloads. By @google.com.

The list of top popular articles for 2021 includes:

• Introducing GKE Autopilot: a revolution in managed Kubernetes
• Introducing Google Distributed Cloud—in your data center, at the edge, and in the cloud
• Introducing WebSockets, HTTP/2 and gRPC bidirectional streams for Cloud Run
• Introducing GKE image streaming for fast application startup and autoscaling
• 4 new features to secure your Cloud Run services

… and more. Please follow the link to the full article to get the rest of the resources.

The idea of clean code gained popularity with the publication of Robert Cecil Martin’s “Clean Code: A Handbook of Agile Software Craftsmanship” in 2008. However, the principles of clean code date back to the beginning of software development, and Martin’s book is an essential manual for people who aim for cleanly written code. It’s a programming classic, and if you’re serious about coding, you should read this book cover to cover! By Ritesh Shah.

The article main points are:

• Why write clean code?
• 7 “Clean Code” principles
  • Follow the KISS, DRY, and YAGNI rules
  • Naming conventions: Use intention-revealing names
  • Functions with the same level of abstraction
  • Readability over conciseness
  • Don’t include (too many) comments
  • Consistency throughout the code
  • Don’t obscure logic with error handling
  • Elegant code or workable code?

Clean coding is not a skill you can master overnight. Instead, it’s a set of principles that you need to incorporate into your coding life — and apply them whenever you write or fix code. Programming is both a craft and a science, and you can only learn to write better code with time and perseverance. We liked this one: Comments should, in fact, explain “why” you did something instead of “what” is happening in the code. Excellent!

Efficiently dealing with an incident or crisis weighs heavily on three main factors; preparation, process and the tools you have to hand. The latter can greatly influence your incident management process and a cyber incident management platform should make the implementation of your incident response quick and easy rather than hinder it. By Cheryl.

So before considering a tool to help manage incidents, consider your incident / crisis management plan! Do you have one? Map out a clear incident response plan for your department and essentially for your business.

Cyber security incidents happen on a daily basis, preparation is vital for phishing attacks, insider threats, denial of service disruptions, malware and ransomware, to name but a few.

These incident response strategies are often IT oriented, but an incident can often require the input and action from beyond the IT department should an event escalate into a crisis affect the organisation as a whole. The article then reads about:

• So what’s the difference between an incident and a crisis?
• An incident platform is for life not just for cyber!
• Be prepared
• Theory test before practical

Breaking this down into 2 areas, firstly you should consider the business culture and resource you already have. Secondly, comes the features and benefits that you require and have determined aren’t already covered by existing tools and processes. A “last but not least” consideration for your incident response platform is how easily you can use it to train staff on? Good read!