Clase Premier / Scarlett Johansson by César Moreno on Behance

Here at Behance, we deploy a lot of code, very VERY frequently. We are constantly adding new features to our applications, hotfixing bugs, and changing things to give everyone a better user experience.

The Problem:

Currently, we have 3 operations engineers who have the credentials to build our applications to our pre-production and production environments ( Myself, Ko Uchiyama, and Chris Henry ). If none of us are available for whatever reason, changes don’t get pushed. At the same time, if we ARE available, on a really bad deployment day we can receive anywhere from 12-30 requests to push changes which can REALLY interrupt our work flow or weekend ( Especially mine since I’ve become the “main build engineer guy” lately). How can we make this workflow better?

The Solution:

Build a robot to do it for you! Duh.

Read more →

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 all, I’m Ko Uchiyama and I am the Head of DevOps over here at Behance.  My main responsibilities are to make sure all of our systems are running smoothly – servers, databases, networks, etc.  I also do lots of automation work with bash scripting and Puppet.  I find it really helpful to automate as many tasks as possible, so that I can spend more time on the more important tasks at hand and being more proactive.
Read more →

If you’ve ever done a lot of JS development you might find the following situation familiar: you’re loath to open up the bowels of the sweet webapp you wrote because you know inside you will find hundreds of lines of jQuery selectors stacked on top of each other. Try as you might, they just won’t be tamed simply by separating out into distinct functions. Soon you’re lost in your own code, trapped in a Borgesian labyrinth of your own making.

That was one of the first challenges we ran into when I started working at Behance: the decentralized, deframework-ized nature of the client side code. Like many other shops, JavaScript was viewed with equal parts suspicion and distaste. But as our code grew, it became increasingly impossible to continue working the same way as thousands of lines of JS collided tectonically into each other as Everests grew out of merge conflicts.
Read more →

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 Kevin and like a few others on the Dev team, SUNY Binghamton is my Alma Mater. Personally, I play guitar, [lots of] video games and animate things once in a while. I’m also an avid C/C++ programmer. Overall, a very simple guy (despite the C/C++ part).

At Behance I’m a full time QA Engineer. It’s been a lot of manual testing of new features, automated testing and maintaining the framework that we use for those tests – our page objects. I focus a lot on enforcing a clear, maintainable pattern in our page objects, not just for ease of use (by me, Dan and potentially other devs), but for extensibility. It’s thrilling because I get the unique opportunity to focus on how efficient my code is and how to utilize and combine language features in nifty ways!
Read more →

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! My name is Mike Klein and I help make ideas happen here at Behance. My role on the team is Backend Developer and spend most of my days dabbling in PHP. Over the last few months I’ve worked on some awesome projects like social signup for Action Method Online, image service restructuring and project editor for the Behance Network. Besides coding, I also enjoy listening to music, collecting instruments and playing guitar.
Read more →

On behalf of the Behance Team, I’m proud to announce the opening of our public API and developer site: http://be.net/dev. We’ve been internally using a private API for well over a year now, creating our own portfolio website builder, ProSite. With this second version, we’re making it public: the developer community can showcase Behance’s sorted, curated and appreciated work in their own experiences.

Read more →

History

Behance Distributed Logging Application - Log View

What do you do when there is an error across 7 different web applications running in production and load balanced across roughly 200+ servers? Good luck logging into each and grepping some logs. No, crying won’t help; we tried that. Instead, why not build a tool to log all of those errors into a centralized location? After evaluating the many (fantastic) pre-built options like: Loggly, Splunk, even Syslog… we found none of them provided all the capabilities we wanted. The job to build our own solution was then tasked to Matt LeBrun and me, and here is our awesome journey.

Read more →

Making sprites sucks. They’re incredibly useful for web development since they keep assets minimal and HTTP requests (and thus loading times) low, but they are a huge time sink: somebody has to Tetris together a bunch of tiny images into one file so that they fit in as little space as possible, then figure out all the dimensions and coordinates of every little icon, make up class names for every single one, then write a bunch of verbose CSS so you can actually use the individual icons in the sprite. What a pain.

I used to argue with our designers about who should build sprites. But even if I escaped the burden of creating one, writing the related CSS was painful too. Adding a new icon to a sprite was regularly a source of mental anguish. Our main sprites can easily have over 50 different images and icons in it — when you run a huge website like the Behance Network or a complex web application like Action Method, it’s not unusual to be dealing with that many different icons. So we changed our spriting process completely.

Read more →

Here’s a trick that I just implemented on our own testing framework to handle custom annotations. Annotations are comments written in a standard format that are used to declare properties for tests, such as dependencies and grouping. You can read more about the standard PHPUnit annotations here: http://www.phpunit.de/manual/current/en/appendixes.annotations.html

There are only a handful of annotations available natively to the PHPUnit framework. I’ve written some code that allows you to create additional rules you might need, and trigger them with your own custom annotations. You’ll need to instantiate a ReflectionMethod and then parse the doc block for the proper data.

In the sample code provided below, I look for the annotation “@browser” to determine what type of browser to launch (Firefox, Chrome, Internet Explorer, etc.) If the browser is not found, then setUp() does not launch a browser. I create a user through the web app using Selenium, and then test that user with curl requests against our API. The curl requests did not require a Selenium browser, which saved about 10 seconds of setup per test.

Read more →

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?

My name is John Refano.  I’m a professional contrarian, noise-maker, perfectionist and coffee drinker.  Oh yeah, and I’ve been known to make websites.  I was born in New York, but lived in Philadelphia for the majority of the past 10 years.  I currently live in Brooklyn, and wouldn’t want to live anywhere else.  I also have a degree in Design, strangely enough.

I am a developer at Behance where my focus and interest lies primarily on the front end.  I use Sass, Javascript (thank Resig for jQuery) and PHP to build pretty things (About Behance, About Prosite) and style up stuff you just might use every day on the Behance Network.  I built most of the 99% Conference site, and put in a teensy bit of work styling the new Action Method Online.  I also helped on a big restructure of the Sass on our Served sites and CCN‘s with the rest of our awesome front end team (JFTW… our names all start with the letter J), finding ways to make things more efficient in terms of customization and reusability. I try to add cool stuff to our private little Sass framework when I can.  I guess in some capacity, I touch the part you see of everything we build here.

Read more →