CodeIsGo.com

Mastering data structures is a non-negotiable skill for success as a developer. Efficient data structures help execute effective programs. Today, many programming roles require great knowledge of data structures. They are also a fundamental part of coding interviews. By The Educative Team.

In programming, a stack is an abstract, linear data type with a predefined capacity (or boundary). It follows a particular order for adding or removing elements. Linear data structures organize their components in a straight line, so if we add or remove an element, they will grow or shrink respectively.

In the article authors will cover:

• What is a Stack?
• What is a Queue?
• Pros and Cons of Stack and Queues
• Essential operations
• How to implement a Stack in Java
• How to implement a Queue in Java
• What to learn next & interview questions

Authors hope you now have a good foundation of how stacks and queues data structures work. There’s so much more to learn to master queues and stacks in Java. Nice one!

From the car straight to the app on your phone, check out how our America office uses Elixir’s fullstack capability to build a remote control car. By Ricardo Lanziano.

The basic idea is for us to move a pair of wheels. In order to do that, we need a device that is capable of power and can control a couple of motors. We decided to use a L298n motor driver that is easily available in the local electronics stores.

Elixir is undoubtedly one of the most comprehensive full stack languages available, offering battle-tested reliability and fault-tolerance on the backend. This is thanks to its origins in Erlang, the BEAM VM and OTP, powerful and agile frontend development thanks to LiveView and the ability to write to hardware with Nerves (not to mention the exciting developments happening in the machine learning space).

Main section of this article:

• Requirements
• Theory
• Starting the project
• Tune in
• Powering the device
• Moving the wheels
• 4 Sources and conclusions

Team had fun assembling the kit and working with Nerves. It was easier than we expected, and we found that Nerves is a very stable and solid frame- work for deploying Elixir applications in restrained environments without friction. Good read!

Looking for an easy guide on how to make a pie chart with CSS and HTML? Then you’ve come to the right place! By Hafsah Emekoma.

Pie charts have been used since forever to display data in an aesthetically pleasing manner; they help in analyzing data by showing how different segments of a larger data set break down.

In the article you will get information on how to build an interactive pie chart using only HTML and CSS that displays data about food consumption in a city:

• Basic HTML structure
• Creating the wrappers
• Basic styles
• Adding pie chart data
• Styling the chart and its keys
• Finish styling the pie chart
• Adding interactivity to the pie chart
• Adding the keys and colors
• Displaying text for entries
• Changing the border colors for flair

If you’ve finished this tutorial, you should now be able to build pie charts using only HTML and CSS. Building with just HTML and CSS can come in handy when building light projects where performance is a primary consideration. Nice one!

This post will reveal author’s experience of working in multiple startups. The views are completely driven based upon his personal experience and can be found biased. By Navneet Maheshwari.

Author realizes in recent times and strongly believe that the startups for whom tech is not the primary product should not get into building platforms from scratch at an early stage of their journey. There are multiple reasons for this including volatile business model which keeps on reiterating and evolving, the talent acquisition cost for the tech team that is very high, there will be a very high business learning quotient for developers, leading to a lot of communication, it takes a lot of time to build stable tech etc.

With the recent development in the Low code space, I feel startups should focus on building tech with these platforms before jumping on building a complete in-house stack. With the recent development in the Low code space, author feels startups should focus on building tech with these platforms before jumping on building a complete in-house stack.

There arises a plethora of platforms that can help you build any software without much need for engineering bandwidth. The Low-code/ No-code platform can be classified into the following segments:

• Frontend: (Website Builder, E-comm, Landing Page builder, etc). Some of them are Shopify, Webflow, WordPress, Wix, etc.
• Mobile App: (App Builder). Appsheet, Glide, Shopney, etc.
• Backend: Builder.io, Bubble, ERPNext

Author worked in 3 startups so far and there are is one thing that is common; Building Tech products is difficult: It’s not just simply coding and delivering a project. It’s a continuous reiterative process. Good read!

At Replay, we’re building a true time-travel debugger for JavaScript. Our technology records everything that happens in a browser, so you can use it to debug any page regardless of what frameworks or libraries were used to build it. That said, framework-specific devtools are a valuable part of the debugging experience. By Mark Erikson.

Replay’s recording capability is built into our custom forks of the Firefox and Chrome browsers and Node runtime. Firefox has been our primary recording browser thus far, but in Q4 2022 we started improving the Chrome fork to reach feature parity with Firefox. One of the missing features in Chrome was React DevTools support.

The article then describes in depth:

• Background
• How do the React DevTools work?
• Replay’s React DevTools support in Firefox
• Replay’s recording analysis APIs
• Using “Routines” for recording analysis
• Browser integration, stubs, and annotation timestamps
• Writing annotations for processing recordings
• Evaluating code in recording pauses
• React DevTools routine implementation
• React DevTools client-side implementation
• Deployment

… and more. The React DevTools backend was only designed to run in a real browser, and author pretty sure our protocol API wasn’t designed with “evaluate entire JS bundles” in mind. Happily, both were designed well enough that something like this was possible. Along the way, author learned a lot about our backend protocol API, how pauses work, evaluating JS as strings, and doing development + deployment on our backend repo. Godo read!

The NIST Cybersecurity Framework (NIST CSF) is a voluntary framework developed by the National Institute of Standards and Technology (NIST) to help organizations manage cybersecurity risk. It was created via an executive order from President Obama in 2013 to improve cybersecurity within critical infrastructure. By Julien Katzenmaier.

It provides a risk-based approach to identify, assess, and prioritize risk, and to develop and implement a comprehensive strategy to reduce it. It is composed of five core functions—Identify, Protect, Detect, Respond, and Recover—and ties into other NIST standards, guidelines, and best practices. The framework provides organizations with a flexible, repeatable, and cost-effective approach to managing their cybersecurity risks.

However, for organizations to meet NIST cybersecurity framework compliance, they must adopt a holistic approach toward cybersecurity, ranging from various practices, policies, and tools. Consult the article for table which shows how Sepio’s Asset Risk Management solution can help your organization align with NIST cybersecurity framework compliance so that you can manage risk properly and effortlessly. Good read!

How much does it really cost to buy more powerful cloud compute resources for development work? A lot less than you think. By Natalie Somersall.

The cost of hardware is one of the most common objections to providing more powerful computing resources to development teams—and that’s regardless of whether you’re talking about physical hardware in racks, managed cloud providers, or a software-as-a-service based (SaaS) compute resource. Paying for compute resources is an easy cost to “feel” as a business, especially if it’s a recurring operating expense for a managed cloud provider or SaaS solution.

The article details:

• Testing build times vs. cost by core size on compute resources
• How much slow build times cost companies
• How much context switching costs companies

When you ask a developer whether they’d prefer more or less powerful hardware, the answer is almost always the same: they want more powerful hardware. It’s cheaper—and less frustrating for your developers—to pay more for better hardware to keep your team on track.

In this case, spending an extra $4-5 on build compute saves about $40 per build for an individual developer, or a little over $200 per build for a team of five, and the frustration of switching tasks with a productivity cost of about an hour. That’s not nothing. Of course, spending that extra $4-5 at scale can quickly compound—but so can the cost of sunk productivity. Interesting read!

In the new project, there is no logging system at all, and since we all love the Grafana stack, we also decided to use Loki for logging. Loki is built on a microservices architecture, with all microservices assembled into a single binary. By Arseny Zinchenko.

The article then makes a good job explaining:

• Grafana Loki architecture
• Loki components
• Data flow
• Read Path
• Write Path
• Simple scalable deployment mode
• Microservices mode
• Grafana Loki Storage
• Loki Helm charts
• Helm chart, and Deployment Mode

… and more. All commands and configuration included. Loki receives data from multiple streams, where each stream is a tenant_id and a set of tags. When receiving new records from the stream, they are packed into chunks and sent to long-term storage, which can be AWS S3, a local file system, or databases such as AWS DynamoDB or Apache Cassandra. Interesting read!

Building service is easy. Isolating that service, it’s easier said than done. Anyone can build any service with any technology or stack. However, would this service last, or will it become technical debt? Many organizations trying to go all in with microservices end up with distributed monoliths instead of isolated services. By Diego Pacheco.

Because code isolation is not enough. We need to isolate the 3 frontiers being:

• Contracts
• Databases
• Internal shared libraries

Shared database is the most common mistake companies make. They create new services, but all share the same databases. Fixing this problem is hard. But possibly, there are patterns and approaches we do to fix database sharing. Like the Strangler Fig Pattern and many data migrations patterns.

Contracts matter more than implementation. Services are composed of 2 elements. The service contract and the service implementation. Contracts are the most important piece. Period.

Isolating internal shared libraries. This is the most controversial yet big problem all companies face, but only some realize how bad it is. Internal common shared libraries, most of the time, are evil and bring more problems them solutions. Authort lost count of how many companies, products, and projects he worked on that had bad libraries. They are everywhere in the industry. Interesting read!

How do you prevent the most common merge conflicts when your team is working on a Serverless application? How do you make sure that your team stays productive and avoids large merge issues while trying to update the same crucial files simultaneously? By Mark Curtis, Juan Peredo, and Tom Romano.

When multiple developers collaborate on a serverless architecture built with AWS CloudFormation, and its extensions such as the AWS Serverless Application Model (SAM), the nature of specifying resources in both the template.yaml and the optional OpenAPI.yaml specification for Amazon API Gateway leads to merge conflicts. These conflicts detract from the developer’s time and agility. Furthermore, navigating and maintaining the long template files required for a larger serverless architecture slows development as the developer scans large files to find a particular resource definition.

The article then describes solution to this problem:

• Rapid development
• Sample project
• OpenAPI and AWS service integration
• cfn-include and nested stacks

Following techniques mentioned here, you should be able to:

• Improve developer efficiency by decomposing large, hard-to-manage files into a series of well-organized and single purpose files
• Enhance developer productivity by allowing each developer to have ownership of their own piece of the code without having to coordinate with teammates
• Eliminate potential merge issues on the files that typically generate the most conflicts during the development of a typical Serverless API application

This post demonstrates techniques used by WRAP and AWS to rapidly develop and maintain key files in an Serverless architecture. Nice one!