aseemk

.babelrc uses JSON5. ;)

https://github.com/babel/babel/blob/b1e73d6f961065c56427ffa8...

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!

FiftyThree / NYC & Seattle / Engineers

We're the company behind:

- Paper, an award-winning iPad app for capturing freeform ideas;

- Pencil, the best-selling Bluetooth stylus for thinking with your hands;

- Mix, our fast-growing collaboration service for bringing ideas together.

And we're working hard on some Next Big Things™. E.g.:

http://news.fiftythree.com/post/113866722218/carving-a-new-s...

This year, we're taking on our biggest and most ambitious challenges yet, and we're growing our engineering team to rise to the occasion.

Whatever your particular area of passion or expertise (e.g. web, backend, iOS, Android), reach out if you're interested.

http://www.fiftythree.com/about

http://www.fiftythree.com/jobs

jobs@fiftythree.com

Seattle, New York City. (Remote potentially okay, but we also offer relo. Visa transfers okay.)

FiftyThree - http://www.fiftythree.com/

Backend web engineers, devops engineers - http://www.fiftythree.com/jobs

==

FiftyThree makes tools for mobile creation.

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.

If this sounds interesting to you, please do reach out. http://www.fiftythree.com/jobs ==> jobs@fiftythree.com

We look forward to hearing from you!

Indeed! I have much respect for Max and company. We use and love Streamline.js ourselves -- works great with CoffeeScript.

https://github.com/Sage/streamlinejs

I'd love to talk on or write about Streamline at some point too.

Thanks for the great feedback. I think you're totally right.

I didn't intend to come across as so preachy in my post. I was just writing freely without (too) much worry.

Live and learn. =)

(I didn't downvote you.)

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.

Cheers.

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:

https://github.com/jashkenas/coffee-script/wiki/Web-framewor...

I don't know Rails personally. Both at FiftyThree and with Thingdom, we use CoffeeScript with Node, both on the server-side and client-side.

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. =)

Great, glad. Out of curiosity, did you automatically think to swipe on the iPad? Or did you try to tap the left/right buttons first?

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.

Corresponding blog post: http://aseemk.com/blog/neo4j-lessons-learned

New York, NY - {iOS, Frontend, Backend, DevOps} Engineers

http://www.fiftythree.com/

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:

http://www.fiftythree.com/jobs

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 jobs@fiftythree.com. 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:jobs@fiftythree.com. We look forward to hearing from you.

You can also learn more through our more general jobs page: http://www.fiftythree.com/jobs

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

Great lawyer.

Came here to mention this exact issue. (And related, e.g. cmd+clicking.)

Mislav wrote a great post on how to do this robustly: http://mislav.uniqpath.com/2011/03/click-hijack/

Hope that helps!

Great idea. I'm having trouble getting it to work ( https://github.com/vdemedes/joconut/issues/5 ), but I'm looking forward to trying it out!

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?")

Haha, I actually found that hilarious. Nice work.

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!

Certainly. I'm not advocating for a change to JSON -- this is explicitly a new format. (The test cases use a .json5 extension to illustrate this.)

FWIW, I'm not adding any new data types or functionality, just making the syntax more human-friendly. It also continues to be a strict subset of ECMAScript, but v5 now.

This was indeed a problem in the IE6 days. Every browser today (and ES5) supports reserved keywords as unquoted object keys. There are thus no reserved keywords for object keys in ES5, and by extension, JSON5.

You seem to be implying that making an effort to seek change in the format that npm uses is a bad idea. I'm not sure I understand why that is. Surely the status quo isn't always perfect?

In the software world in general, and in Node/npm land especially, code talks. I thought it'd be more productive to build and share a working ES5-style JSON parser than to simply ask Isaac if npm would support ES5-style JSON. =)

Yes, you're right about trailing commas. One motivation that such an approach couldn't address is documentation: I've frequently wanted comments in my package.json files, e.g. explaining a particular dependency version, or a script command.

Yes, I realize I didn't explain it as well in the README as I had in conversations and emails.

I find JSON tedious and error-prone to generate by hand. I also frequently wish I could document the data with comments.

Others have written about these same ideas, e.g. [1]; after feeling the frustration for over a year, I decided it might be productive to actually build a JS parser to get the conversation started.

My main use cases are Node/npm package.json files, and test case data.

[1] http://bolinfest.com/essays/json.html

Thanks for the feedback! I never considered YAML precisely because there doesn't seem to be much support for it. I'll definitely look into it. =)

JSON5 is also meant to be language-agnostic. It derives its syntax from ES5 in the same way that JSON derived its syntax from ES3.

I'm aware that JSON is final — it's my hope that a new format that's easier to write (whether this or something else) picks up steam — but thanks for the feedback on the name! I consciously used a different file extension (.json5) to avoid conflicts; hopefully that's a good start.

I already use (and love) CoffeeScript, but my motivation for building this was to have tools use it natively, so that sibling files in a different format wouldn't have to be maintained alongside the needed JSON.

I actually had no idea that YAML is a superset of JSON. Thanks! I'll look into it.

I'm actually a big fan of Douglas Crockford. And don't worry, my code uses semicolons. ;)

I'm not sure why you lump quoting keys with semicolons, though; his regular JS style guide doesn't discourage quoting object key (neither does JSLint).

Comments: yes, I read Douglas Crockford's post on the matter. I guess I'm not genuinely worried about that, though, and my hope is that shipping a JS parser that works on both the client and the server will help standardize implementations from the start.

Special characters: sorry I didn't write a formal spec =), but the intent is to be a pure subset of ES5 just like regular JSON is a pure subset of ES3. Unquoted object keys in ES5 can contain only letters/numbers/_/$, and only begin with letters/_/$. So yes, '1hello' would need to be quoted, just like regular ES5.

I'm not sure how to respond to your why other than what I've already written. I never claimed this was the biggest problem we have. =)

Thanks for the feedback. It certainly would be great if there existed tools to let me write and update JSON with nicer syntax like this; any ideas how that might be possible?

My motivation for this was actually hoping that this gets adopted in some environments that use JSON. Node relies on package.json files, for example, which frequently need to be hand-edited. Maintaining a sibling file in a different format feels equally wrong to me as it seems JSON5 seems to you. =)