A previous project I worked on was to create an abstraction around various command-line invocations, the context here was automated testing on different platforms. The idea is pretty simple, rather than having to keep track of command-line flags and options, you just call this CLI and get a nice JSON formatted response. I knocked out a handful of commands, as did several other developers, and that's where things got interesting. Despite being both a young project and a simple one, discrepancies had already crept in.
GitArborist.com has now been live for four months. For previous info you can jump to the previous updates at three, two, and one months. June 2020 Stats First, the stats: Total Installations: 9 Scheduled PRs Merged: 16 PRs Merged: 36 (inc. scheduled) Repositories Watched: 1410 What's Changed GitArborist now collects user email during installation (with the required OAuth permission). This should make it easier to contact users with any announcements going forward, and also paves the way for paid plans.
What is Memoization? When developing applications we often have methods that run slowly. Perhaps they need to query the database, or hit an external service, both of which can cause them to slow down. We could call the method every time we need that data and just accept the overhead, but if performance is a concern we have some options. For one, we can assign the data to a variable and re-use it, which would speed up the process.
So you've been tinkering away at your side project web app and are now ready to launch it to the world. You fire up a Heroku account, push up the source code et voilà, you're on the internet. The thing is now you're running in “production” mode, so you're going to want to set up some infrastructure for your application. I'm going to be using Ruby on Rails here but the general ideas will be the same for virtually any web application on any framework.
Is Caching the Right Way to Speed Up Your Ruby on Rails App? 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, bolt on 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.
I've spent a few months now using the interactor gem, both in my day job and also quite extensively in GitArborist‘s code. My first time hearing about “interactors” was from a talk by Robert Martin on clean architecture, essentially saying that an “interactor” object should encapsulate a single “use case” or user story, basically the business logic. Therefore, if you look at a list of interactors in the system you can quickly determine what operations that system carries out (in theory).