We've all been there. You're clicking around your Rails application, and it just isn't as snappy as it used to be. You start searching for a quick-fix and find a lot of talk about caching. Take your existing app, add some caching, and voila, a performance boost with minimal code changes. However, it's not this simple. Like most quick fixes, caching can have long-term costs.
The world is full of linear relationships. When one apple costs $1 and two apples cost $2, it's easy to figure out the price of any number of apples. But what happens when you have 100s of data points? What if your data source is noisy? That's when it's helpful to use a technique called linear regression. In this article Julie Kent shows us how linear regression works, and walks through a practical example in Ruby.
Go has built-in features to make it easier for programmers to implement logging. Third parties have also built additional tools to make logging easier. What's the difference between them? Which should you choose? In this article Ayooluwa Isaiah describes both of these and discusses when you'd prefer one over the other.
When you deploy a new Rails app, you typically face a double-bind. If you use an easy platform like Heroku, you could create problems for yourself as your application scales. If you use a more fully-featured platform, you risk wasting time on ops that could be spent on your product. What if you could have both: an easy deployment option that is easy to scale?
If software's been eating the world for the past twenty years, it's safe to say machine learning has been eating it for the past five. But what exactly is machine learning? Why should a web developer care? This article by Julie Kent answers these questions. I don't have kids yet, but when I do, I want them to learn two things: Whether or not you believe that the singularity is near, there's no denying that the world runs on data.
Are you on DEV? Did you know that it's open-source, and that it uses Honeybadger? We just launched a new feature to help communities like DEV fix more errors together! Software development is more fun with friends; that's why we've built tons of collaboration features into Honeybadger over the years, making it easier for teams to fix errors. Recently the team at DEV emailed us with a feature request: could we make it easier to involve the broader DEV open source community in the error-fixing process?
The ability to search through individual error events (we call them Notices) has been one of our most requested features. Today we are shipping an updated section to our Errors page that allows you to do exactly that.
As programmers we often have to mentally run code. To imagine how a program will behave given certain inputs. This is hard enough for experienced developers. But for juniors? It can seem impossible. In this article, Melissa Williams argues that pry is an invaluable tool for junior rubyists because it allows them to see exactly what is going on as their code is run.
Have you ever been neck-deep building a new feature? You're working at capacity. You need to test something out so you paste an API key into your source file with every intention of removing it later. But you forget. You push to GitHub. It's an easy mistake, and potentially a very expensive one. In this article, Julien Cretel explores the nuances of this kind of data leak, offers suggestions for recovery when leaks happen and gives us options for preventing them in the first place.
We've all worked with tightly-coupled code. If a butterfly flaps its wings in China, the unit tests break. Maintaining a system like this is...unpleasant. In this article, Jonathan Miles dives into the origins of tight-coupling. He demonstrates how you can use dependency injection (DI) to decouple code. Then he introduces a novel decoupling technique based on delegation that can be useful when DI is not an option.
