I'm biased here since I know Ray, but I thought this post was super informative & helpful! I love how short & sweet it is yet so chock full of meaningful points. Thanks Ray!
Our first product was Paper for iPad, an app to let you capture your freeform ideas. It won both an Apple Design Award and App of the Year (2012).
Our second product was Pencil, an active stylus that works especially well with Paper. It too has received critical acclaim (e.g. "the best iPad stylus yet" —The Verge).
We're hard at work on our third major product, a sharing and collaboration service to bring your ideas together. And we'd love your help in shipping it.
We're looking for experienced back-end web engineers, both on the purely programming side and on the operations side. Our jobs page has all the details, but the highlights are:
- We run our app on Node.js (w/ CoffeeScript) deployed to Heroku.
- We run our non-app infrastructure (e.g. our Neo4j database) on AWS, e.g. EC2 and Route 53.
- We automate with Ansible and bash (moving over to Node.js).
Experience with most/all of these isn't expected, but at this stage, we are looking for existing experience somewhere. Show us what you've built.
It's not every day you find a startup that's building both software and hardware, that's making multiple things people love, that's making significant revenue from day one even as a consumer company, and that strongly values a maker culture at the same time.
It's great that you tried CoffeeScript and prefer JS. Your opinion is well-formed.
With my statement, I was referring to the many developers I've encountered who haven't tried it, yet actively dislike it and argue against it. Hence the (subjective) "most" in my first sentence that you quote.
Thanks for the compliment! The viewer doesn't quite look and feel right on the iPhone, but glad you didn't think so. =)
I don't know what your stack is, but FYI on Node we use Connect/Express middleware that automatically compiles CoffeeScript files to JS -- and in production, caches the results -- before serving them. No manual building/compiling/packaging needed at any point. You might find something similar for your stack if you haven't already looked:
Not that I'm biased or anything ;), but I can confirm this is an awesome place to work! We're building some really great stuff, our vision is nothing short of enabling people to create more effectively, and our team of engineers and designers truly is world-class. Keep on creating. =)
Author here. These are the slides and transcript of a talk I've given detailing my experiences building a startup on Neo4j, a graph database. Hope you guys find it educational.
Technical note: the presentation is built with Hakim El Hattab's excellent Reveal.js, but this combo slides+notes viewer is handbuilt, so apologies if it doesn't work perfectly. If you can, view it in Chrome on desktop or laptop.
Hello, we are FiftyThree. We're the startup behind Paper, an iPad app for freeform writing/sketching/drawing.
Paper has done well so far. Among other things, it won this year's Apple Design Award for iPad, it's had nearly 3 million downloads, and it's used and loved by creatives at top-notch companies everywhere, including Apple, Nike, Pixar, and more.
But Paper is just the beginning for us. Our goal is to bring creation tools into the post-PC era, and we think there's a huge opportunity there. Mobile and tablets are changing everything.
We like to say that Paper is “where ideas begin”; we're now building a service to “bring ideas together”. Think something like a GitHub for ideas and creations. We have a small team of great developers and designers spanning iOS and web, but we’re looking for 2-3 more developers to join us. That’s where we hope you’ll come in.
The role is flexible depending on your passions and expertise. Check out our jobs page for full details:
You'll be just our fifth engineer, so you'll help set the tone for our culture, process, and workflow. And if we succeed, you'll help shape our company's future, too.
If this sounds interesting to you and you think you fit the bill, send us an email to [email protected]. We look forward to hearing from you!
New York, NY - {Backend || DevOps} Engineers - Node.js, Neo4j, Heroku, EC2
---- About us ----
Hello, we are FiftyThree (http://www.fiftythree.com/). We're the company behind Paper, an iPad app for freeform writing/sketching/drawing.
Paper has done well: among other things, it won this year's Apple Design Award for iPad, it's had nearly 3 million downloads, and it's used and loved by creatives at top-notch companies everywhere, including Apple, Nike, Pixar, and more.
But Paper is just the beginning for us. Our goal is to bring creation tools into the post-PC era, and we think there's a huge opportunity there. Mobile and tablets are changing everything.
We like to say that Paper is “where ideas begin”; we're now building a service to “bring ideas together”. Think something like a GitHub for ideas and creations. We have a great team of developers and designers spanning iOS and web, but we’re looking for 2-3 more developers to join us. That’s where we hope you’ll come in.
---- About you ----
We're looking for great backend or devops engineers to help us build this service. The role is flexible depending on your prior experience, passion, and expertise.
E.g. perhaps you love algorithms and performance engineering. Great — let's design an efficient activity feed for our users. (It's a fun graph problem.)
E.g. or perhaps you love devops and infrastructure. Perfect — help us setup a high-availability database cluster with master-slave replication.
E.g. or perhaps you love data and metrics. Right on — help us get great instrumentation and analytics in place so we can monitor early and monitor often.
Whatever your specifics, you'll work across a diverse set of tools. We currently use Node.js (and we write primarily CoffeeScript) with Neo4j (a graph database). We deploy on a mix of Heroku and Amazon EC2. And we use GitHub and Trello to keep track of it all.
You don't need prior experience with any of these directly, but you should have some history of building or scaling websites or services like ours. Even better if you can show depth and passion somewhere. Of course, strong engineering skills and an ability to learn quickly are a must.
You'll be just our second backend engineer, so you'll help set the tone for culture, process, and workflow. And if we succeed, you'll certainly help shape the company's future and direction, as well.
---- Sound good? ----
If this sounds interesting to you and you think you fit the bill, drop us a line at mailto:[email protected]. We look forward to hearing from you.
This is amazingly and impressively thorough. He cites relevant caselaw left and right; the two that particularly struck me were:
- "FunnyJunk also alleges The Oatmeal's statements constitute false advertising under the Lanham Act. However, the statements made by The Oatmeal do not constitute commercial advertising or promotion, and therefore section 1125(a)(1)(B) of the Lanham Act is inapplicable."
- "Even assuming that all of the content on FunnyJunk is uploaded by users and FunnyJunk otherwise qualifies for DMCA immunity, it’s possible that The Oatmeal may be able to satisfy the “red flag” exception for DMCA immunity. See Viacom Int’l, Inc. v. YouTube, Inc., 676 F.3d 19, 41 (2d Cir. 2012) (discussing “red flag” test and reversing grant of summary judgment in favor of YouTube). It is also possible that FunnyJunk hasn’t complied with the requirements of the DMCA and thus cannot take advantage of its protections. Among other things, the DMCA requires a service provider to designate an agent, provide contact information, and file a notice of designation with the Copyright Office. Without taking a position on the other issues, I’ll note simply that FunnyJunk does not appear to have a notice of designation on file with the Copyright Office. This alone would be enough to undermine anydefense of immunity to claims of infringement that The Oatmeal (or third parties) may assert."
One thought came to mind for a potential leaky abstraction: unlike HTML and CSS that can be "undone" and are idempotent, JS has side effects that can't be undone, and isn't always idempotent. Are there JS patterns we need to embrace or avoid to ensure Joconut always "just works"?
Thanks for stating so eloquently what I've been struggling to communicate. The heart of the matter to me really does boil down to the fact that JSON is meant for humans, too, not just machines. You nailed this sentiment.
(As a friend pointed out, "Do you not comment your code just because it's meant for machines?")
I'd love to understand what benefits this removes and what drawbacks this introduces, aside from the chicken-and-egg problem of having any new format. Apologies if I've missed that in the discussion so far.
You're definitely right that some of the hand-editing problems could in theory be solved by tools, but it unfortunately doesn't address documentation/comments.
I've heard the chorus on YAML though, and I'll definitely be looking into it. Thanks for the feedback!
https://github.com/babel/babel/blob/b1e73d6f961065c56427ffa8...