Search results for ""

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.

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.

If you haven’t tried AngularJS yet, you’re missing out. The framework consists of a tightly integrated toolset that will help you build well structured, rich client-side applications in a modular fashion—with less code and more flexibility.

One of the reasons I love working with AngularJS is because of its flexibility regarding server communication. Like most JavaScript MVC frameworks, it lets you work with any server-side technology as long as it can serve your app through a RESTful web API. But Angular also provides services on top of XHR that dramatically simplify your code and allow you to abstract API calls into reusable services. As a result, you can move your model and business logic to the front-end and build back-end agnostic web apps. In this AngularJS tutorial, we’ll do just that, one step at a time.

RWD allows a site to adapt for optimal viewing on a variety of devices that range in size based on a media query for mobile and other screen widths. Nowadays, your website will be visited by a wide variety of devices: desktops with large monitors, mid-sized laptops, tablets, smartphones, and more. To achieve an optimal user experience, your site should be adjusting its layout in response to these varied devices (i.e., to their varied screen resolutions and dimensions).

Inexperienced programmers often think that Java’s automatic garbage collection frees them from the burden of memory management. This is a common misperception: while the garbage collector does its best, it’s entirely possible for even the best programmer to fall prey to crippling memory leaks.

In this post, I’ll explain how and why memory leaks occur in Java and outline an approach for detecting such leaks with the help of a visual interface.

Python is amazing.

Surprisingly, that’s a fairly ambiguous statement. What do I mean by ‘Python’? Do I mean Python the abstract interface? Do I mean CPython, the common Python implementation? Or do I mean something else entirely? Maybe I’m obliquely referring to Jython, or IronPython, or PyPy. Or maybe I’ve really gone off the deep end and I’m talking about RPython or RubyPython (which are very, very different things).

While the technologies mentioned above are commonly-named and commonly-referenced, some of them serve completely different purposes (or at least operate in completely different ways). In this post, I’ll start from scratch and move through the various Python implementations, concluding with a thorough introduction to PyPy, which I believe is the future of the language.