Toptal Engineering Blog

From the very first days in our lives as programmers, we've all dealt with data structures: Arrays, linked lists, trees, sets, stacks and queues are our everyday companions, and the experienced programmer knows when and why to use them. In this article we'll see how an oft-neglected data structure, the trie, really shines in application domains with specific features, like word games.

Web Developers often fail to consider the consequences of thousands of users accessing our applications at the same time. Perhaps it's because we love to rapidly prototype; perhaps it's because testing such scenarios is simply hard. Regardless, I'm going to argue that ignoring scalability is not as bad as it sounds—if you use the proper set of tools and follow good development practices. In this case: the Play! framework and the Scala language.

A few years ago, driven by my curiosity, I took my first steps into the world of Forex by creating a demo account and playing out simulations (with fake money) using the Meta Trader 4 trading platform. After a week of 'trading', I'd almost doubled my 'money'. Spurred on by my own success, I dug deeper and eventually signed up for a number of forums. Soon, I was spending hours reading about trading systems (i.e., rule sets that determine whether you should buy or sell), custom indicators, market moods, and more.

Sometimes I hear people complaining about their clients, saying that they insist on using Rails, that they've had too much Kool Aid. If they are recruiters, they almost feel sick in the stomach from perspective of having to find yet another ROR primadona. From the programmers point of view it sometimes looks like clients don't have a clue. However, I believe most clients know their options just fine and they still decide to go with Rails.

Node.js shines in real-time web applications employing push technology over websockets. What is so revolutionary about that? Well, after over 20 years of stateless-web based on the stateless request-response paradigm, we finally have web applications with real-time, two-way connections, where both the client and server can initiate communication, allowing them to exchange data freely. This is in stark contrast to the typical web response paradigm, where the client always initiates communication. Additionally, it’s all based on the open web stack (HTML, CSS and JS) running over the standard port 80.

Sometimes, clients give us feature requests that we really don't like. It's not that we don't like our clients, we love our clients. It's not that we don't like the feature, most client-requested features are aligned perfectly with their business goals and income. Sometimes, the reason we don't like a feature request is that the easiest way to solve it is to write bad code, and we don't have an Elegant Solution on the top of our heads. This will throw many of us on fruitless searches through RubyToolbox, github, developer blogs, and stackoverflow looking for a gem or plugin or example code that will make us feel better about ourselves. Well, I'm here to tell you, it's okay to write bad code. Sometimes, bad code is easier to refactor into beautiful code than a poorly thought out solution implemented under a time-crunch.

It’s always fun to put your programming skills on display. A while back, I figured it’d be cool to try and control my laptop via my Android mobile device. Think about it: being able to play and pause music, start and stop programming jobs or downloads, etc., all by sending messages from your phone. Neat, huh?

Female engineers are valuable at Toptal. This is a piece about how we stand up for their rights and value them for their skills and talent.