Stripe: Open Source | Hacker News Reader

Stripe: Open Source

stripe.com

581 pointsbenjamindc64 comments

Usually it feels like companies open source projects are kind of lame or just to look fashionable. These projects are extensive and awesome. I love the personal projects section at the bottom of the page. You can see why Stripe is so successful. They truly have a dev culture and that's a lot more than most companies that just say they have a dev culture. At Stripes scale and size that's a big success.

> Usually it feels like companies open source projects are kind of lame or just to look fashionable.

I don't understand this. You think Netflix and Facebook's Open source projects are lame?

    I don't understand this. You think Netflix and Facebook's Open source projects are lame?

Whoah, I didn't notice that Netflix and Facebook became the only tech companies on Earth.

No, but from what I understand op saying is that most open source from companies are lame, and I haven't seen any lame open source projects from companies, even if in languages I don't like. So by saying "Usually it feels like companies open source projects are kind of lame or just to look fashionable." it comes off that op things that.

That's a loaded question. I don't think op means every company.

True. I just came across Rickshaw[0] from Shutterstock. I'd love to use it, but there hasn't been a commit in 8 months, pull requests are backlogged and there's a thread titled "Is Rickshaw dead?"[1] that hasn't had any response in months (either to shift maintenance to someone else or kill/fork the project).

It looks like a poster child of companies open source projects done wrong. I'm sure it was developed for internal use, made public with a prominent "Open Source! We're Hiring!"[2] and then mostly forgotten about. Not that maintenance is easy! It's a big commitment, which is why Stripe really shines here: not just for open sourcing their code, but for maintaining their projects continuously.

[0] https://github.com/shutterstock/rickshaw

[1] https://github.com/shutterstock/rickshaw/issues/517

[2] http://code.shutterstock.com/rickshaw/

I recently changed my website's donation page to a Stripe-powered system, and their API was a pleasure to work with. Having worked with horrible payment processors throughout my webdev career, I kept waiting for the other shoe to drop--but it's been a couple of months now, and so far it's still just the one shoe.

Stripe's API docs are absolutely gorgeous, also, for what it's worth:

https://stripe.com/docs/api#charges

Anybody wants to explain why fica was downvoted? My best guess is undisclosed relationship to gelato.

Edit: my bad, found dangs comment.

Love the logo! Did something similar here [1] for our blog's creative/digital arm [2] with actually a somewhat similar approach. Probably a few months ago. Their's is a little more elegant though :)

I just want to make a quick comment: Everything the Stripe's front-end guys touch is pure and magical perfection. They definitely have a killer front-end team - design, UI/UX, and more.

[1] http://codepen.io/ncerminara/pen/MYvELv

[2] https://digital.scotch.io

Glad you noticed the easter-egg on the logo :p

Had no idea you could animate SVG coordinates.

Edit: Or at least I think that's how it works...

Yup, you're right!

Hi, is there any library to get a similar SVG animation on any text? Possibly, input the text and get animated SVG. Though, I think your not using any external library.

Love Conway's Game of Life in the background.

Toally. I actually removed the <header> (id="intro") node to see more of it. Awesome touch.

That whole page is gorgeous, but GoL in the background is the icing on the cake

yeah it's awesome. I'd love to actually how they implemented it. It's gorgeous.

Any chance you could let me click on a cell in the game of life in the background to add another cell? That would surely result in lots more time wasted on that page :)

Check out the footer on http://www.dotjs.io/ to be able to do that :)

(I work at Stripe.) We're also accepting applications for our second Open-Source Retreat: https://stripe.com/blog/open-source-retreat-2016

Nice program! There seems to be a typo relating to start/end dates, though: It says the grant lasts for "three months", but the quoted period is "from January 15th until March 15th, 2016".

Good catch, we've updated the post. It does indeed end in April (3 months!)

I hope one day one of my pet projects is big enough for a program like this.

Some of the projects (e.g., jepsen) are quite impressive. I bet that displays like this one beat any office perk when it comes to hiring.

Make sure you check out https://aphyr.com/tags/jepsen if you have't seen these write-ups before. Truly on another level.

Aphyr's also given a bunch of great talks on Jepsen, well worth watching.

Would be interested to hear from the devs about the actual reasons they chose to write unilog (https://github.com/stripe/unilog) instead of using multilog (which ships with Daemontools).

Agreed that multilog is arcane and weird but what are the actual problems with it that unilog solves?

(I'm an infrastructure engineer at Stripe)

This actually took a fair amount of digging! We've been using some version of unilog for over 4 years now (longer than I've been at Stripe), and we'd mostly forgotten why we switched. What follows is more the result of historical exploration and guesswork than authoritative statement of original truth.

I'm fairly confident that the impetus for unilog was timestamp prefixes for our log lines. We wanted timestamps (so that we weren't dependent on all applications adding them). multilog is capable of doing writing out timestamps, but it formats them with TAI64N. We wanted something more human-parseable.

Once we had it, we started adding other features. These days, I'd say the most useful thing unilog does for us is buffer log lines in memory. We would occasionally see disk writes on EC2 hang for long enough that the in-kernel (64k) pipe buffer would fill up and cause applications to stall.

And an update! I talked with the engineer that wrote unilog originally.

The original headline feature of unilog was that it wouldn't block writes if the disk filled up. multilog does - if it can't write a line to disk, it stops ingesting data off of stdin, which eventually causes the application to hang writing to stdout.

unilog sends you an email and starts dropping log lines, which we decided better matched the tradeoffs we wanted to make - losing logs sucks, but not as much as blocking your application until you figure out how to free up disk.

Thanks for the follow up!

Wow--thanks for the update. Buffering to memory before writing to disk is definitely a great feature (especially when operating out of AWS) and could be enough for us to switch to unilog.

Regarding the timestamps. We've actually gotten quite used to TAI64N--it's definitely not human parseable but it is extremely specific :) We end up just piping logs through tai64nlocal or converting it at the logstash stage.

Some great stuff here! The 'personal projects' are a nice touch: I've been using Goji (https://github.com/zenazn/goji) for a while now as my 'go to' router+context combo for Go web services. Small, extensible and compatible with the other tools out there.

Stripe's front end game is on point so hard. Jezus!

OP (Benjamin de Cock) is one talented guy. Some of his work is phenomenal.

Wow, the "Personal projects" section is a really great idea.

On the subject of the jquery.payment lib, I remember noticing that the validation functions it provides for various credit cards are not exactly the same as the ones in stripe.js, and actually better.

I would have to look at my commit history to remember what exactly were the differences though. I think it could match the various credit card types with fewer digits entered or was better for cvv validation of amex cards.

I get the impression that stripe has abandoned jquery.payment (or at least it's a side project and not part of their core offering?). Because it does not actually work out of the box with the stripe.js library (see https://github.com/stripe/jquery.payment/issues/160 , which has a lot of "+1's" from other people but no response from stripe or whoever it is that maintains this library).

I never noticed because I'm actually using stripe.js to do the payment, and was only using the various validations from jquery.payment in a couple angular directives.

I realized stripe.js had validation functions built in one day looking into the source, and that's where I remember those validations acting differently from.

It's definitely not abandoned! We're using it in Stripe Checkout, we're aware that it needs some love, and we've got plans to that effect. Stay tuned!

(I'm an engineer at Stripe)

why did you guys invent mosql [1] ? you are clearly loving postgres and cannot get rid of it... but potentially with jsonb in 9.5 [2] you can get rid of mongodb.

With the kind of resources you have, you could fix the few things about postgres that you dont like.

[1] https://github.com/stripe/mosql/blob/master/README.md

[2] https://wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9....

Or use ToroDB (http://www.torodb.com) that speaks the MongoDB protocol but stores the data relationally, in PostgreSQL. Directly. No ETL, no mosql required :)

(ToroDB developer here)

I just checked out the page. This seems like an interesting project, but how would rewriting unstructured documents into relational form be faster to query than just retrieving the whole document as jsonb or whatever?

Pulling a document together back from its parts cannot be faster than jsonb or whatever. But it can be orders of magnitude faster if you are pulling a collection out of a query and you avoid scanning the whole thing. Let me elaborate.

When you search in MongoDB (or PostgreSQL with a single table with a jsonb column) the executor needs to visit every single document, every single key, to try to see whether that documents matches the query criteria. This means that in the absence of indexes (or inability to use them, as it happens in MongoDB, where they are not used under many circumstances) the whole db would be scan to answer every single query.

I contrast, ToroDB effectively is "partitioning" the data "by type" (being the type the shape of the documents). See this explanation for more detail: https://github.com/torodb/torodb/wiki/How-ToroDB-stores-json.... To answer a given query, ToroDB only reads those tables with potential documents involved in the result, which usually is a small % of the while database. And this, of course, leads to significantly less I/O and queries that can run up to orders of magnitude faster.

hey - this looks interesting. Quick question: why did you build it in Java rather than as a Postgresql extension - like mongres [1] or mogloid [2] ?

[1] https://github.com/umitanuki/mongres

[2] https://github.com/JerrySievert/mongolike

There are many reasons. The first is that Java is in our opinion the language with the biggest and greatest ecosystem of open source libraries on top of which we can build our software. And this is saving many man-years for us.

I contrast, PostgreSQL extensions need C, which doesn't have these advantages and becomes less productive.

But even more importantly: we don't want to tie it, as much as possible, to PostgreSQL. Maybe, tomorrow, ToroDB would run on other RDBMs :)

If run locally, there's barely performance hit. And it also enables you to run it remotely.

I really like the bottom section where they are highlighting individual projects from members of their team. I think that really helps instill a sense of ownership and would definitely me make me excited about working there if I was featured.

That game of life animation background is really mesmerizing to watch!

Wow! That logo and animation has scaringly close resemblance to the one on https://digital.scotch.io

I don't find them to be at all similar aside from the larger concept of having "large pixels convene to form pixelized text", which I'm sure has been done plenty of times before.

The text is different. The color is different. The animation is different. The code is different. It's a unique implementation.

Cool that you guys are show-casing your work. I've looked over mosql before. Cool stuff and worth checking out.

Very nice page & I like that they put employee's personal projects at the bottom!

Shit, Benjamin! So good. Every time. Great work :)

Beautiful website. Props!

I am very like UI :)

Reply on news.ycombinator.com