Recently, our team at Meteksan Defense is upgrading its development environment to use newer versions of many tools and programming languages. One of the more difficult transitions has been the upgrade of our C++11 code base to C++17 for our embedded applications. In this article, I will be showing some features of C++17 that can also be helpful in the embedded world. Note that the migration from C++11 to C++17 covers C++14 also, hence I will touch upon some aspects of it as well.

At one particular time, a developer would spend a few months building a new feature. Then they’d go through the tedious soul-crushing effort of “integration.” That is, merging their changes into an upstream code repository, which had inevitably changed since they started their work. This task of Integration would often introduce bugs and, in some cases, might even be impossible or irrelevant, leading to months of lost work.

As developers we understand the critical role teamwork and collaboration play in solving complex problems. Often, it’s that second set of eyes that uncovers an additional issue or sheds light on the root cause of a stubborn bug. Effective collaboration becomes a critical factor in determining a team’s success or failure, especially when debugging or troubleshooting problematic issues within complex applications.

A core belief of Memfault is that we can ship faster when we have good infrastructure in place. An essential piece of this infrastructure is tools to send firmware updates over the air. It enables the team to ship more often and spend more time building features. In this article, we look specifically at what is required to ship over-the-air firmware updates for Linux systems. A good OTA setup should allow you to quickly prepare updates and ship them with confidence.

Code instrumentation is closely tied to debugging. Ask one of the experienced developers and they will swear by it for their day-to-day debugging needs. With modest beginnings in the form of print statements that label program execution checkpoints, present-day developers employ a host of advanced techniques for code instrumentation. When carried out in the right way, it improves developer productivity and also reduces the number of intermediate build/deployment cycles for every bug fix.

Cloud native is the de facto standard approach to deploying software applications today. It is optimized for a cloud computing environment, fosters better structuring and management of software deployments. Unfortunately, the cloud native approach also poses additional challenges in code instrumentation that are detrimental to developer productivity.

Separate “debug” and “release” builds are very common in embedded development. Typically the notion is improved debug capabilities (less aggressive compiler optimizations, more debugging information like logs) vs. highly optimized and hardened production release builds. I’m here to describe disadvantages to this practice, and why it might make sense to consolidate to a single build! Like Interrupt? Subscribe to get our latest posts straight to your mailbox.

In your lifetime as a frontend developer that works with React, you must have come across several issues with debugging a containerized React application. I bet you can relate, you’re certainly not alone. Containerization has become an integral part of best practices for software development teams that want to create, test and deploy applications quickly and efficiently. However, despite its advantages, it also comes with new challenges for debugging and troubleshooting applications.

As React is the most popular JavaScript framework for creating component-based applications, you have access to a solid ecosystem of tools, resources, and best practices that can help with React debugging when something goes wrong. To create a high-quality React application, you can’t skip over the debugging phase of your software development life cycle including everything from addressing error messages coming up in the development phase to monitoring live errors in production.