CircleCI Blog

CircleCI: SF or REMOTE fulltime (near pacific time), frontend, backend engineers and patio11-style marketing engineers.

At CircleCI (https://circleci.com), we're building Heroku for Continuous Integration. We have traction and revenue (and funding!). Our customers love us, because we move quickly and provide amazing support. All employees talk to customers and are on support rotation.

We eat our own dogfood, DevOps, A/B test, do Continuous Deployment and Customer Development.

We're still a small team, so you'll have a large impact on company culture. We're highly influenced by Valve's Employee handbook. SF-local employees have catered lunch every day.

The frontend is a fat javascript client, using HamlCoffee, Less and Knockout. We have a lot of interesting design and data-visualization problems that need to be solved, as well as A/B testing, landing page creation and funnel optimization.

The backend is written in Clojure. Backend engineers should know Clojure or another 'weird' language (Haskell, Scala, Scheme, etc), and Linux Devops (C compilation model, make, packaging).

Contact us at jobs@circleci.com. Include samples of awesome stuff you've done.

This is insightful. Of course, the OP is consciously playing off the earlier app-deployment spoof (https://circleci.com/blog/its-the-future/).

But this earlier spoof may well be based, intentionally or not, on the SOAP piece you linked -- which was a hit on HN 7 years ago (https://news.ycombinator.com/item?id=2079631).

Thus prompting the observation and related question: These three areas - front-end, deployment, RPC - seem to have engendered a churn in standard approaches, and a corresponding cultish devotion to certain toolkits -- leaving them open for satire. But yet, there is also a need for a guru to explain WTF to do, because a lot of practitioners need to get these jobs done.

So, what is the deeper parallel between the areas? E.g., a lot of corporate resources suddenly poured into these problems, and everyone is funded to come up with, and promote, their own solution?

Thoroughly agree that this is a human problem, but I think there are some amazing automated fixes for it, by incorporating code checkers into the continuous integration pipeline. Take a look at how the CII best practices badgeapp [0] uses pronto [1] to run rubocop [2] automatically for free via CircleCI [3] and surface those results via the Github Status API and email.

The whole point is to avoid having to manually complain in a code review. Instead, code reviews become a much higher level exercise discussing proper APIs and code structuring, not sphaghetti issues.

[0] https://github.com/linuxfoundation/cii-best-practices-badge/commit/9dabce047f9a0ab60988aa39ef6524c7e71c7426#commitcomment-18915455
[1] https://github.com/mmozuras/pronto
[2] https://github.com/bbatsov/rubocop
[3] https://circleci.com/

It appeals to me as someone who likes Circle's CI offering but wants to move away from Github.

I tried using Gitlab's CI and was surprised at how limited it was. The Gitlab CI syntax was harder to follow, and my integration tests took 17m to run when they ran in almost 1/3 the time on Circle.

A big part of the problem was that CircleCI lets me use an instance with 8 CPUs / 16 GB RAM with just a config file change[0], whereas every Gitlab instance is 1 CPU / 3.75 GB RAM unless you host your own runners.[1] But if I'm paying a company to manage CI, I don't want to provision my own hardware infrastructure

[0] https://circleci.com/docs/configuration-reference#docker-execution-environment

[1] https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html

This is a great approach, but detecting the user-agent is the wrong way to decide if you should pre-render the page. If you include the following meta tag in the header:

<meta content="!" name="fragment">

then Google will request the page with the "_escaped_fragment_" query param. That's when you should serve the pre-rendered version of the page.

Google has documentation on this here: https://developers.google.com/webmasters/ajax-crawling/docs/html-snapshot and we've been using this method at https://circleci.com for the past year.

Waiting for google to request the page with _escaped_fragment_ should also prevent you from getting penalized for slow load times or showing googlebot different content.

I've been using it in production for a number of applications for about 6 months now and haven't seen any performance issues. Prismatic http://getprismatic.com/ and CircleCI https://circleci.com/ both use ClojureScript for their front-ends. CircleCI open sourced their front-end here https://github.com/circleci/frontend/tree/master/src-cljs/frontend as you can see it's a decent size app, and Prismatic have blogged about Om and performance here http://blog.getprismatic.com/om-sweet-om-high-functional-frontend-engineering-with-clojurescript-and-react/

In general, there should be very little overhead compared to regular JavaScript once the advanced compilation option is used.