Toptal Blog

Elasticsearch provides a powerful, scalable tool for indexing and querying massive amounts of structured data, built on top of the Apache Lucene library.

Building on the foundation of Elasticsearch and the Elasticsearch-Ruby client, we’ve developed and released our own improvement (and simplification) of the Elasticsearch application search architecture that also provides tighter integration with Rails. We’ve packaged it as a Ruby gem named Chewy.

This post discusses how we accomplished this, including the technical obstacles that emerged during implementation.

The need to adapt legacy code and systems to meet modern day performance and processing demands is widespread. This post provides a case study of the use of Erlang and CloudI to adapt legacy code, consisting of a decades-old collection of multi-user game software written in C, to the 21st century.

Making a basic Android app is easy. But making it reliable, scalable, and robust, on the other hand, can be quite challenging. With thousands of available devices pumped out from tons of different manufacturers, assuming that a single piece of code will work reliably across phones is naive at best. Segmentation is the greatest tradeoff for having an open platform, and we pay the price in the currency of code maintenance, which continues long after the app passes the production stage.

In this post, we’ll walk through a solution: automated crash reporting with ACRA and a Cloudant back-end, all visualizable with acralyzer.

As modern web applications do more and more on the client-side (the fact itself that we now refer to them as “web applications” as opposed to “web sites” is quite telling), there has been rising interest in client-side frameworks. There are a lot of players in this field but for applications with lots of functionality and many moving parts, two of them stand out in particular: Angular.js and Ember.js.

Angular.js has already been introduced on this blog, so we’re going to focus on Ember.js in this post, in which we’ll build a simple Ember application to catalog your music collection. You’ll be introduced to the framework’s main building blocks and get a glimpse into its design principles.

When people think computational geometry, in my experience, they typically think one of two things:

1. Wow, that sounds complicated.
2. Oh yeah, convex hull.

In this post, I’d like to shed some light on computational geometry, starting with a brief overview of the subject before moving into some practical advice based on my own experiences in computational geometric programming with Python.

I’ve been an Engineer at Toptal for just about one year now, working on the same project since I joined the network: Ondello, a service that connects doctors and patients over WebRTC.

When I first joined Ondello, I was hired as a Senior Ruby on Rails Developer, tasked to build a service up from scratch. These days, we’re a team of multiple developers working on a fairly large, complex system.

With this post, I’d like to share the story behind Ondello. Specifically, I’d like to talk about: how a simple application became not-so-simple, and how our use of cutting-edge technologies posed problems I’d never considered before.

More often than not, the software we write directly interacts with what we would label as “dirty” services. In layman’s terms: services that are crucial to our Python application, but whose interactions have intended but undesired side-effects—that is, undesired in the context of an autonomous test run.

As a veteran telecommuter through multiple jobs in my career, I have witnessed and experienced the many joys of being a remote worker. As for the horror stories, I have more than a few I could tell. With a bit of artistic inclination and a talent for mathematics, I also have a fascination with patterns: design patterns, architectural patterns, behavioral patterns, social patterns, weather patterns—all sorts of patterns!

When I first encountered anti-patterns, I discovered a trove of wisdom I wish I had known before I had learned the hard way. Anti-patterns are recognizable repeated patterns that contribute significantly to failure. For example, the manager that keeps interrupting the employee in order to see if the employee is getting any work done is engaging in an anti-pattern that serves to prevent the employee from getting any work done!

Based on my own experiences and experiences of friends and co-workers, I am assembling descriptions of anti-patterns related to telecommuting.

If it ain’t broke, don’t fix it.

It’s a well known phrase, but as we know, most of the human technological progress was made by people who decided to fix what isn’t broken. Especially in the software industry one could argue that most of what we do is fixing what isn’t broken.

Fixing functionality, improving the UI, improving speed and memory efficiency, adding features: these are all activities for which it is easy to see if they are worth doing, and then we argue for or against spending our time on them. However, there is an activity, which for the most part falls into a gray area: refactoring, and especially large scale refactoring.