Toptal Blog

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.

Effective interviewing and hiring is as much of an art as it is a science. Nonetheless, approaches and methodologies do exist for evaluating the more subtle dimensions of a software developer’s skills and abilities. When used collectively, these techniques yield a highly effective screening process with a proven track record of success. That process is what this post is all about.

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 application, but whose interactions have intended but undesired side-effects—that is, undesired in the context of an autonomous test run. For example: perhaps we're writing a social app and want to test out our new 'Post to Facebook feature', but don't want to _actually_ post to Facebook every time we run our test suite. The Python `unittest` library includes a subpackage named `unittest.mock`—or if you declare it as a dependency, simply `mock`—which provides extremely powerful and useful means by which to mock and stub out these undesired side-effects.

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.

In 2007, Bennett Haselton revealed a minor hack with major implications: querying ranges of numbers on Google would return pages of sensitive information, including Credit Card numbers, Social Security numbers, and more. While Haselton's hack was addressed and patched, I was able to tweak his original technique to bypass Google's filter and return the same old dangerous results.