arohner

Yes. I'd pay money for an OSX UI to backup my laptop.

Hey, sorry about that. We were down for approximately 5 minutes because of adding a new index to the DB.

This unusual for us, we had 100% uptime in February, according to pingdom (haven't gotten the email for March yet).

CircleCI (https://circleci.com/jobs) - SF or REMOTE fulltime (in the US)

At CircleCI we're building the next generation of developer automation: amazing Continuous Integration and Deployment. We have traction and revenue and funding and great customers. Our customers love us, because we move quickly, build great things, and provide amazing support. Everyone talks to customers a lot.

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, and have as flat a structure as we can. We're looking for frontend engineers (JS), designers (must be able to HTML+CSS), and backend engineers (Clojure). Being a mix of those is of course welcome! We lean towards senior experienced engineers, or junior engineers who can display great talent.

We're also looking for engineers for Developer Success and Developer Awareness positions. Since we have an incredibly technical product, and selling directly to developers, the dev-awareness positions (think marketing, but much more dev-oriented: dev evangelism, writing interesting blogs, CRO, analytics, etc - think a patio11-style engineer) require significant development experience. Dev-success positions are a good fit for engineers who like working with people and building relationships with customers.

Check out our jobs page at https://circleci.com/jobs.

> They'll accept payments in anything, as long as anything is US dollars.

Sometimes, not even then: "One dispensary owner told me about taking seven thousand dollars in cash to the Washington Department of Revenue, to pay his monthly tax bill. He was turned away, because the teller refused to deposit his “drug money.”"

http://www.newyorker.com/reporting/2013/11/18/131118fa_fact_...

[Disclaimer: I'm cofounders with OP]

One other thing to note is that office space, while expensive, is much cheaper than your developers. You can easily get 10-20% more productivity with a better working environment.

Also, that "collaboration" that people value? None of that is getting written down. Circle's team is already half remote, so placing a strong emphasis on 'library voices' means more communication happens over hipchat and email. More things get written down, and the remote employees are able to collaborate more, and there's a written record of "oh yeah, on Friday 2013/01/03, Paul and Allen thought it was a good idea to try X.

FYI, this update breaks GPGMail's plugin for Mail.app

[edit: re-installing GPGMail Works For Me]

CircleCI (https://circleci.com/jobs) - SF or REMOTE fulltime (in the US) At CircleCI we're building Heroku for Continuous Integration and Deployment. 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'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.

- Frontend Engineer: You'll work on improving the page responsiveness, adding new features and improving the out-of-the-box experience and UX. Our frontend is a single page javascript app, 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.

- Backend Engineer: Our entire server is written in Clojure. We're looking for candidates with experience in any "weird" language: Clojure, Scheme, CL, Haskell, OCaml, Erlang, Brainfuck, C. Experience w/ Linux & DevOps is also a plus.

> I need redis and elasticsearch installed to run my test suite. Will that run on CircleCI? What kind of browser support for my feature specs do you offer?

Yes. Redis and Elasticsearch are already installed. firefox, chrome, phantomjs, casperjs are already installed.

Build pipelines are coming. I guarantee you they'll look nothing like what is available on Jenkins. They might be more opinionated than you like, but for the people they do work for, they'll save a lot of time.

> Keeping the build green involves my team figuring out what we broke. Faster build times help, is that what you mean here?

That's part of it. The other part is that we are a high-touch CI service. This week, rubygems had tons of SSL problems. Debugging that, and bugging the #rubygems IRC guys was "outsourced" to me. Thousands of developers didn't have to individually debug sporadic rubygems failures because I was doing it for them.

We see common bugs and test failures often enough that we have in-app warning messages that say "hey, it looks like your selenium tests are failing because firefox auto-updated on you. If you upgrade your selenium gem/jar, that will probably help". Those are things that won't get added to Jenkins.

Thanks for the link! (founder of CircleCI here)

Before Circle, I led multiple engineering teams, building multiple products from "nothing" to "shipping, and making lots of money". I set up buildbot, hudson, bamboo, jenkins, and some other things I don't even remember the name of. I was always the build guy, I was always the one that said "yes, we will be testing, yes, the build will be green." Those were controversial statements back then.

I've been there, done that, and I didn't want to set up Bamboo again. I didn't want to debug why the tests failed. That's why I built Circle.

Our customers, most of whom switched from Jenkins, will tell you we are a steal.

Maybe your project is still simple. Maybe your platform is fairly stable. But for most professional developers, keeping CI running and green is a challenge. Even at Circle, I spend more time than I'd like debugging the test suite. But we're fixing that. Every day is spent making devs lives easier.

Jenkins costs you nothing per month, but your developers cost money, and Circle's hardware is faster than digital ocean, and the cost of keeping the build green on Circle is lower than the cost of keeping it green on Jenkins anywhere else. If you're running a startup, or a tech company, odds are very good that salary is the number one cost center. Optimizing your Digital Ocean bill is penny wise, pound foolish.

Global write lock. Abysmal performance when your data set doesn't fit in ram. Clustering with durability. Clustering in a way that isn't horribly complex and fragile.

Then where did the "Mongo is web scale", and sharding and performance come from?

The fact remains that Mongo just doesn't scale, and 10gen was never honest about that.

Depends on the app, and your use case, and the CPU, etc. YMMV.

For a long time though, the Linux kernel has been compiled to optimize code-size rather than 'performance' (according to GCC). Why? Because the kernel gets involved in every syscall the OS makes, so the kernel code gets paged in and out very frequently. Loading a little less code from RAM means everything goes faster.

That's one of those 'good problems'.

step 1) worry about how to get big enough that people even know who you are, and think that DDoSing is worth their time

step 2) worry about how to deal with the DDoS

completing step 1 is much, much harder :-)

That's definitely not true where I am. Probably half our devs care about the business side. My co-founder and I are both techies who care about business, so we spar often.

On the far reaching consequences side, I didn't realize how important the choices we made in the first month were. Some of those are still with us.

Yes, at least in clojure and CL. In Clojure, you use nrepl. Emacs (and several other IDEs) have clients which open a socket connection to your running clojure process. While editing a function, emacs will say "tell me about `my.namespace/foo`". It then shows arity and argument name info for the fn.

It's basically the same UX as you're used to in Java, except the info comes from asking the running process, rather than parsing statically.

That's changing soon! We're switching hardware to allow this. I expect that will be available in the next month. Let me know if you're interested in beta testing.

Thanks! It's great to hear you're enjoying it.

Not yet. We're github-only at the moment.

While a standard .build.yml file sounds nice, I'm not sure we understand the problem well enough to figure out what the optimal syntax would look like. This matters because the syntax has large implications for 1) how simple your build process is 2) how much overhead your CI system can take care of, for you.

For example, at Circle, we're still experimenting with yml syntax for user-specified parallelization commands. Each different syntax we've looked at has different implications for what kinds of problems are simple, and what kinds of problems are expressible, using the syntax.

So yes, standards, but not yet :-)

If you're interested having this kind of setup for your own team, without having to muck with servers, you can use something like https://circleci.com. We use LXC, and pay lots of attention to having fast I/O. [disclosure: I'm founder/CTO of circle]

These are the backlift guys, rebranding.

One thing I've noticed with my own Clojure service at scale, is that eventually, I want to significantly reduce my use of futures entirely.

When you're getting started with Clojure, it's easy to do everything that needs to happen "later" or "in the background" as a future. Once you go to production, you realize that about half of those futures should have been jobs going into a queue somewhere, with logging and guaranteed delivery, retrying on another machine, if necessary.

I haven't gotten to the point of writing that library, but I probably will, soon.

Not enough people say this anymore, but congrats!

That first $1/$1,000/$1,000,000 is the hardest. Good luck.

Very cool. Are there any publicly available options for non-AWS services?

No. Clojure's first public release was before Arc's first public release. Rich was also working on Clojure for two years before release.

On Lisp is great for learning about macros, and what is possible.

That being said, what is idiomatic in CL is not necessarily idiomatic clojure. For example, pg tends to like anaphoric macros, (http://en.wikipedia.org/wiki/Anaphoric_macro), while Clojure tends to eschew them.

Right, I didn't mean to imply that jfli and foil were new languages.

I didn't realize there was a CL version of the compiler, cool! Thanks for the link.

Mongo does have a global write lock. A per-db lock does me very little good when I only have one DB.

As to your linked doc, emphasis added:

> In some situations, read and write operations can yield their locks.

> Long running read and write operations, such as queries, updates, and deletes, yield under many conditions.

In practice, I've been bitten hard by this. A new feature rolls out, and users can't log in anymore, because a query is taking 2 minutes to run.

> whether [Mongo] does/doesn't scale efficiently

It doesn't. Three words: "global write lock". Writes block reads, reads block writes. Implications: if you run a query in production that doesn't hit an index, all traffic stops. The notablescan setting is a very, very good idea. This also means all queries must have an index, so Mongo ends up with more indexes than say, postgres would.

It's impossible to configure a clustered mongo environment to not lose data: http://aphyr.com/posts/284-call-me-maybe-mongodb

Sharding configuration is baroque, and limited.

One thing I always find interesting about these kinds of problems is that most DBs don't describe how they're implemented. It's easy to use the wrong tool, and then once you learn how e.g. Mongo is implemented, it's obvious, "oh, that's why things are slow".

I'd love to see http://eagain.net/articles/git-for-computer-scientists/, but for every DB technology.