
Stripe: Open Source - benjamindc
https://stripe.com/open-source
======
LukeHoersten
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.

~~~
Killswitch
> 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?

~~~
rnovak

        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.

~~~
Killswitch
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.

------
scotchio
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](http://codepen.io/ncerminara/pen/MYvELv)

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

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

~~~
scotchio
Had no idea you could animate SVG coordinates.

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

~~~
benjamindc
Yup, you're right!

------
aquilaFiera
Love Conway's Game of Life in the background.

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

------
jtchang
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 :)

~~~
sylvinus
Check out the footer on [http://www.dotjs.io/](http://www.dotjs.io/) to be
able to do that :)

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

~~~
mauricioc
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".

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

------
sbensu
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.

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

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

------
jaryd
Would be interested to hear from the devs about the actual reasons they chose
to write unilog
([https://github.com/stripe/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?

~~~
ebroder
(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.

~~~
ebroder
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.

~~~
jaryd
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.

------
elithrar
Some great stuff here! The 'personal projects' are a nice touch: I've been
using Goji ([https://github.com/zenazn/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.

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

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

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

------
mcorrand
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.

~~~
jordanlev
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](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).

~~~
oakwise
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)

------
sandGorgon
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](https://github.com/stripe/mosql/blob/master/README.md)

[2]
[https://wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9....](https://wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.5#JSONB-
modifying_operators_and_functions)

~~~
ahachete
Or use ToroDB ([http://www.torodb.com](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)

~~~
Alex3917
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?

~~~
ahachete
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...](https://github.com/torodb/torodb/wiki/How-ToroDB-stores-json-
documents-internally). 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.

------
joeblau
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.

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

------
thecodemonkey
Wow! That logo and animation has scaringly close resemblance to the one on
[https://digital.scotch.io](https://digital.scotch.io)

~~~
brandon272
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.

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

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

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

------
ijones16
Beautiful website. Props!

------
nikolenkoanton
I am very like UI :)

