While initially conceived as a tool for data exploration (much like Jupyter for Python), Livebook has deservedly become a sensation in the Elixir community. It has been fantastic to see all the wonderful ways teams are leveraging Livebook for a range of different use cases. We have seen Livebooks being used to: Livebooks have also been used as the default REPL interface for project development.
Ask any software engineer to review key portions of production code, and inevitably, they will point out three things that need to be refactored. So why does so much bad, brittle, or misunderstood code remain running in production? The answer is simple: engineers are afraid to touch it. Refactoring tasks get identified and added to the backlog, but rarely make it into the current sprint. There are numerous reasons for this.
In our last development cycle, we spent time improving our table performance in AppSignal. As customers stay around for longer, data starts piling up. A view with just 10 items in the beginning gathers hundreds of items, and keeps growing. Besides filtering data in the front-end to reduce the returned data, we wanted to ensure our data could keep growing without timeouts in our GraphQL API or slow-loading pages in our app.
In this post, we will explore how event-driven architecture can make your app more responsive for users and decouple your modules for a better developer experience. We will also look at several methods of implementing event-driven architecture with Elixir. Elixir is particularly good for this because of the advanced and concise message-passing APIs that it offers and BEAM's outstanding support for concurrency. But first: what is event-driven architecture, exactly?
Rails' batteries-included approach is one of its greatest assets. No other framework makes it so effortless to get your application off the ground quickly, at least partially due to Rails' generators. If you've used Rails for any amount of time, you have come across generators. Need to create a new application? Run rails new. Need to scaffold a bunch of new models and views? Run rails generate scaffold. There are dozens more available to help you get started rapidly or streamline your workflow.
The Node.js team announced the release of version 18 on April 19. Node.js 18 has some significant new features that Node developers should be aware of. In this article, we'll look at some of the major highlights from this release.
Elixir is all about performance. Say you have an app up and running with Elixir, but some parts aren't working as fast as you would like them to. That is where profiling comes in. Profiling tools usually walk you through the frequency and duration of function calls and where they spend their time. Erlang has impressive profile tooling available at its disposal. In this post, we will look into three profiling tools in Elixir: cprof, eprof, and fprof.
Some exciting new improvements have been launched with React 18. When React 18 was announced a year ago, the team promised a gradual adoption strategy. Now, a year later, this is exactly what they've done and you can upgrade your app to the newest version. React 18 comes with a few breaking changes, depending on how you use it.
Object-oriented programming (OOP) is hard to achieve in a dynamic prototypical language like JavaScript. You have to manually stick to OOP principles because of language features like duck typing. This requires discipline, as nothing in the language enforces the principles. If a diverse team of developers with different backgrounds is involved, a codebase filled with good intentions can quickly become one chaotic mess.
Data integrity problems are among the most common database issues Rails developers face. Besides allowing for proper validation, correctly designed transaction blocks ensure that your data isn't partially created or updated. However, transactions can also harm your application — or even take down your whole database — when not properly designed. This article offers a set of good practices for working with transactions.
