Developer’s Toolkit: Dmitry Traytel

This post is part of a series where Behance developers talk about the various tools they use to get things done and make ideas happen.

1. Who are you, and what do you do at Behance?

I’m Dmitry Traytel, and I’m a programmer, part-time DJ, lunch-time sandwich connoisseur and the resident Russian at Behance. I graduated with a Computer Science degree from Binghamton University in 2007 and have been a Senior Developer here at Behance since early 2010. My main role on the team is to build new features and upgrade existing ones on the Behance Network, though I’ve also had a hand in developing portions of the Creative Networks, ProSite and The 99%. Much of my job involves coordinating with the design team to take a feature from its mocked-up design and building it out. That starts with getting the right data in the right way to drive the content, and I work with Chris Henry and the infrastructure that powers Behance to do that correctly. I then write application logic and create the object on the server side, building on top of the solid application framework that Bryan Latten and others have developed and continue to improve. Finally, I write the front-end markup, JavaScript (generally jQuery) and CSS to get everything to look great and run smoothly. This process requires me to have an understanding of our entire framework and best practices. From writing efficient SQL queries, maintainable front and back-end code, and fast, reusable CSS selectors, I generally have a part in each step of a feature, from architecture to production.

Read more →

Developer’s Toolkit: Bryan Latten

This post is part of a series where Behance developers talk about the various tools they use to get things done and make ideas happen.

1. Who are you, and what do you do at Behance?

Hey all, I’m Bryan Latten, and I’ve been a part of this team since mid-2008. My role at Behance is the Chief Software Architect. This involves ensuring that our development team can deliver clean, maintainable and scalable code. I have been the primary contributor to our own development framework which includes a system of libraries and tools that tie together best practices. These tools have forced consistency across a wide range of applications. I’ve had my hand in nearly everything Behance has built, or more accurately, rebuilt.
Read more →

Developer’s Toolkit: Chris Henry

This post is part of a series where Behance developers talk about the various tools they use to get things done and make ideas happen.

1. Who are you, and what do you do at Behance?

Hello world, I am Chris Henry, team member since March 2007. Over the years I have taken on a lot of roles at Behance, and regularly will wear many hats throughout the average day. From the beginning, I have been the team’s Backend Ranger & MySQL Wrangler, building much of the code and infrastructure that runs the Behance Network Gallery, Served Sites, and Creative Portfolio Display. As the company progressed, I have done work as an Ad Ops J-Ass, Big Red Button Pusher, Janitor, Email Navigator, and Firefighter for my work with the advertising side of the business, operations & build management, waste disposal, email marketing, and crisis management. Read more →

Developer’s Toolkit: Malcolm Jones

This post is part of a series where Behance developers talk about the various tools they use to get things done and make ideas happen.

1. Who are you, and what do you do at Behance?

Hey young world. I’m Malcolm Jones and I’m a Senior Developer over here @ Behance. I originally studied Computer Science at The University of Virginia, had some fun in the startup world while living in Washington, DC, then finally made the big move to NYC to join our awesome team here in SoHo.

On average I end up working on a lot of back-end / infrastructure type projects. In one project I worked on, I took our old image service application ( which handles all of the photo-manipulation actions on The Network and Prosite ) and redesigned it from the ground up making it easier for us to maintain and test using PHPUnit. To deal with our ever increasing traffic, its important that we can add more image servers on the fly to balance out usage between our websites. To make this process easier, I went a step further to automate the creation of new image service cloud servers by using Rightscripts ( courtesy of our cloud computing management platform Rightscale ). These days, adding more servers to our image service pool requires minimal thinking and only takes a couple of minutes!

Read more →

Wkhtmltopdf / Wkhtmltoimage x CentOS x Xen = Segfault Mania

The Behance Network uses a number of nifty little binary files to create some of the useful services that our platform offers. Two of them in particular are wkhtmltoimage and wkhtmltopdf ( both 64-bit static binary files ). These two files convert HTML to either a PDF or a thumbnail image of a full webpage and dumps the output. These tools work flawlessly on both our sandbox environments ( Ubuntu 11.04 ) and our production image servers ( CentOS 5.5 ). When we try to execute these files on one of our new Imageservice cloud servers ( CentOS 5.4 ),  we receive the dreaded:

“Segmentation fault”

Let’s start off with basics, what exactly is a segfault?

According to Wikipedia ( http://en.wikipedia.org/wiki/Segmentation_fault ):

A segmentation fault (often shortened to segfault) or bus error is generally an attempt to access memory that the CPU cannot physically address. It occurs when the hardware notifies a Unix-like operating system about a memory access violation. The OS kernel then sends a signal to the process which caused the exception. By default, the process receiving the signal dumps core and terminates.

Read more →

Why you should love Luxury Problems

One of the biggest differences between folks on the business side and the engineering side is the way they view certain problems. While having tons of data is seen as a serious issue that requires tons of management by developers, business folks tend to see it as a boon, as a way to build a business. Since problems like this only show up after bit of success, these can easily be dubbed luxury problems. A lot of the time, these luxury problems manifest themselves as scaling issues, mostly in the database layer.

As the Behance Network has grown and traffic increased, more and more challenges appeared. We’ve taken these problems as a sign that things are growing. Our MySQL databases are a great example. No matter how poorly the database was designed, when it was brand new and empty, it performed great.  Especially in the incubation stage, when the Behance Network saw very few visitors, and only had a little bit of data to contend with.

Once we put some stress on the server, things fell apart quickly. Looking back, this was a great problem to have, considering the alternative was to never have problems because no one ever puts data into your app. It was also an opportunity for our team to take a look at what happens under load, and find ways to fix it. As we’ve found out, this isn’t just a simple opportunity, but a never ending cycle of struggling to keep up with demand. I hear this is what some business folks call a “viable business model.”

Without problems stemming from growth, there are few opportunities for a team to learn the best way to solve tough problems. These moments should be looked forward to, not dreaded. Notes, knowledge, processes and data the comes from resolving tough problems should be regarded as the most valuable property a company has.

Programmers and Designers: Can’t We Just Get Along?

It’s been said a million times that programmers and designers just don’t get along. Just do a Google search and you’ll find plenty of articles attacking the subject from different angles. My favorite reasoning in one article I read was that we can’t get along because one group is right-brained and the other is left-brained. This all seems silly to me, and I don’t think designers and programmers need to clash nearly as often as they do.

There was a SXSW conversation a couple years back about this topic, and our Chief Designer, Matias Corea, said it felt like a therapy session in there. It shouldn’t have to be that way. I believe developers and designers can and must get along to make the best product.

Read more →

Fix or Manage?

Sometimes bugs come along that require significant work to fix. Depending on what project timelines are like at the moment, sometimes fixing the bug isn’t the best option. For example, a race condition in the caching architecture causes pages to be stale. The persistent data store is correct, but the cache is not. To the person who just triggered the update, there’s a bug. The information on the public side is not in sync with the information they just entered.

So, like any other bug, a report will eventually percolate down to the dev team. People scream, fortunes are lost, the svn blame command is used, and the devs who wrote the code pee their pants. Once the chaos dies down, the actual prognosis of this issue can turn out to be extremely grim.
Read more →

MySQL skip-name-resolve

Small, obscure optimizations sometimes have the potential to make the greatest impact.  For example, every time a connection is made, MySQL will do a DNS lookup of the host that is trying to connect.  If MySQL is handling many connections, the overhead of an extra DNS lookup can be hefty, simply because of the number of extra operations that have to be performed before MySQL can actually start doing actual work

Thankfully, there is an option in recent versions (4.1+) of MySQL that will instruct MySQL to skip the extra DNS lookup.  It’s a fairly obscure option called skip-name-resolve. The only caveat to using this option is that the users defined the GRANT tables can only use IP addresses as hostnames.  For most MySQL users, this shouldn’t be an issue

Development without Internet Access

While flying to Austin for sxsw, I had a small programming task. Take a string of a few search terms, break it apart and highlight those terms in another string. It’s a straightforward task, and probably a wheel that’s been reinvented thousands of time in the history of computer science. I approached it as an exercise, to see if I could add another squeaky wheel to the pile. My goal was to do it without using any 3rd party code or any resources. I had no access to documentation, google, stack overflow, or any of the other resources I use constantly to get my job done every day.

The code that I produced was bloated, naive, and horribly inefficient (I suspect). While writing it, i knew I wasn’t really on the right path. When I got back to New York, I took a look at it, and more or less decided I had wasted my time. Then I realized I had written it on a plane, and had nothing better to do. I simply got myself into the zone, and wanted to work through a problem until it was solved. After I got over my initial disgust, I wondered what aside from boredom and stubbornness had prompted me to complete the task. Read more →