At Curalate, we need to be able to use data to demonstrate that our products hold value for our clients. One of our products, Fanreel, uses user-generated content to enhance online shopping experiences and product discovery. We record and store usage metrics from Fanreel but we also need to take those usage metrics and connect them to product purchases. If Fanreel analytics were a puzzle, purchase information would be the last piece and historically, Google Analytics or Adobe Omniture served as this last piece. However, every ecommerce site is different so sometimes the intricacies of Google Analytics and Adobe Omniture got in the way.

Jenkins is an incredibly powerful and versatile tool but it can quickly become a maintenance nightmare: jobs are abandoned, lack of standardization, misconfiguration, etc. But it doesn’t have to be this way! By using the Jenkins Job DSL plugin you can take back control of your Jenkins installation.

Curalate uses a micro-services infrastructure (SOA) to power its products. As
the number of services began to grow, tracking down performance issues became
more difficult due to the increasing number of distributed dependencies. To help
identify and fix these issues more quickly, we wanted to utilize a distributed tracing
infrastructure. The main goals were:

The good people at The Muse have made a lovely profile page detailing what it’s like
to work at Curalate. We’re extremely proud of the culture we foster, the vision we pursue, and the
products we build. You can check out more about the profile at the main
Curalate blog.

Say you want to track the health of your API. Pingdom is probably your first move.
But what if you want to track thousands of endpoints? Suddenly you’re looking at a monthly bill of
over $500! So, what if you’re willing to build an API health tracker yourself?
This blog post is for you. Not only can we beat $500 per month, we can build our API health tracker
for damn near free!

At Curalate we’ve moved towards a microservice architecture with each service living in its own git repository. For the most part,
we’ve standardized the way we build our Scala projects using Apache Maven to manage dependencies and
compilation. This is convenient since any Curalady / Curalad can clone one of our repos and type mvn install at the root with the
expectation that everything will compile successfully on the first try. We wanted this same ease of use for our Scala projects that
needed access to native libraries and this post explains how we obtained it.

Since Curalate began three years ago, our build and deploy pipeline has changed immensely. From a manual process run locally on our laptops to an automated system consisting of Jenkins, Packer, Chef, and Asgard, the progression has given us confidence in the system and allowed us to develop and deploy ever faster. In this post I’ll talk about how we build and deploy our code at Curalate. We’ll cover where we started three years ago, where we are now, and what the future holds.

Emojis, the tiny pictographs in our phone’s keyboard, have become a important form of communication.
Even Oxford Dictionary named 😂 the word of the year for 2015.
Though maybe not worth a thousand words, each emoji evokes a much richer response for the reader than boring old text. This makes sense: people communicate visually.

When I came to Curalate, our dashboard was a bunch of page-specific jQuery mixed with some helpful libraries. Naturally, this setup became unwieldy as we added more developers to the team and more features to our product. This model became unmaintainable as we planned on more cohesive and complex features and we decided to begin using Angular. The change was welcomed throughout the team and has changed our development process for the better, but migrating to Angular did not come without issues. In this post, I’ll describe the performance bottlenecks we encountered when creating one particularly complex feature using Angular and the methods we employed to solve these issues.