Hacker Newsnew | comments | show | ask | jobs | submit | mikeknoop's commentslogin

Hey Dhruv! The cool thing is if you expose some triggers and actions via an app, your users can decide how to hook it into other apps (like Salesforce, etc.)

Perhaps things like:

- Trigger when a message is opened

- Trigger when a message is sent

- Trigger when a new contact is added (if you have lists)

etc. Happy to answer any questions, you can also shoot me an email. https://zapier.com/developer


That does seem cool. It's a convenient wrapper on our API. I'll check it out.


If you read the original article and wanted the rest (not in annoying transcript form) here it is:


The short version is that over time, Martin slowly regained some control of his body. By the time he was in his mid-20s, he could squeeze your hand on occasion. And he was getting better and better at holding himself upright in his chair. Now, the doctors told his parents that he still had the intelligence level of a 3-month-old baby.

But one nurse, one nurse named Verna, was convinced that there was something there. And so she eventually convinced his parents to get Martin reassessed at another medical center, where he was given a test where he had to identify different objects by pointing at them with his eyes. And he passed, not with flying colors, but he passed.

Joan, Martin's mom, who came home to care for Martin, helped him with his physical therapy and most important, purchase this kind of joystick for the computer. A proximity switch, which is just something that you knocked. And though it took him about a year to get the hang of it...

Martin had like school - if you want to call it - four hours in the morning every single day. Once he did, everything changed because suddenly he had a way to select the words he wanted to say. "I am cold. I am hungry. I want toast." And as words came back, gradually, so did other things.

Martin started moving his eyes and moving his head and almost nodding, asking for coffee by stirring his hands around and things like that. Noone couldn't really explain it, but... when Martin gets the tools to communicate, he forges ahead.

So wherever you are standing in your life, prepare to be lapped. Within two years of passing that assessment test, Martin gets a job filing papers at a local government office. "I wanted to prove that I could do more than just speak words via a laptop."

Around this time, his nurse savior Verna mentioned she's having trouble with her computer. And Martin, who has not tinkered with electronics since he was 12 years old fixes it. Repairing a computer is a bit like going into a maze. You might go down dead ends. But eventually, you find your way through. It was absolutely flabbergasting.

After that he scraps the government job...

...Starts a web design company...

...Gets into college.

In computer science.

He writes a book.

He's learning to drive. He always wanted to drive.

Martin achieves everything he wants to do.

So how is it that Martin has been able to achieve all this? Now, I don't want it oversimplify it because it was many things - Martin's naturally strong will, flukes of electricity in the brain, a really dedicated family. But I do think that his decision to lean back into those thoughts way back when, instead of just spending his life detaching, in some way helped him, in part because it probably kept his mind occupied and allowed him to emerge this kind of well-oiled machine of mental ability, but also because I think his leaning into those dark thoughts in particular gave him a kind of self-understanding and humor about the human condition that allowed him to snag the very best thing in his life.

"My wife, Joanna." -Martin

"When Martin talks about me or types about me, he always starts smiling."

Joanna was a friend of Martin's sister. And the two of them first met over Skype. She was a manager for the social work team for a hospital social work team. She says the thing that drew her to Martin... "I turned around, and it was just this guy with this big smile. And it's such a warm personality." ... that was the way he began to interact with her.

"Unfortunately, I'm one of those people, I say something and then I, more often, need to say sorry I said it."

But not with Martin. When she asked him how things work in the bathroom or what people do around you when they think you are not there...

"If I ask Margin anything, he'll give me an honest answer." And that perked her ears. There's no pretend. That first night, they talked for hours.

She would speak, and Martgin would type my response. The sister and the other friends drifted away, and Joanna just stayed there in front of the screen. "I just really liked him." After that, she just kept wanting to Skype with him.

"Yeah. OK, well, he's in a wheelchair, and he doesn't speak. But I love this guy. He's amazing. It just so quickly turned into love."

As for Martin - after over a decade convinced that he would be alone forever, he was pretty happy. "My face would hurt from smiling so much." They were married in 2009. Martin was 33 years old.



And Stephen Hawking has a Pius XI gold medal for science. That first thing might not be all that related to the second.


For one, he's accomplished. Girls dig that.


I'm kind of cheating here, but one of my favorite set of Zaps is brand monitoring.

Basically, get notified whenever your company is mentioned in RSS feeds, Reddit, Hacker News (ahem), etc...

We actually did a pretty long write up on this exact use case here: https://zapier.com/blog/monitor-brand-mentions/


Good catch, looks like maybe Github removed this feature (I know for sure it used to work with `.json` extensions.

Updating the post, thank you!


From what I can tell, it is very well known in security circles.

Even so, we as a team of 8 didn't catch the problem for some time because we weren't aware of it. That's part of my rational for giving an easy-to-test-yourself POC.


While I have little experience with it, I know the goal of the defusedxml package (see https://pypi.python.org/pypi/defusedxml ) is to make it so that teams like yours can worry less about these details.

It has a module which "acts as an example how you could protect code that uses lxml.etree. It implements a custom Element class that filters out Entity instances, a custom parser factory and a thread local storage for parser instances. It also has a check_docinfo() function which inspects a tree for internal or external DTDs and entity declarations."

It sounds like it would have defused your example of lxml, and perhaps a few others you haven't considered.


But how do you know to use defusedxml instead of the regular one? I've never even heard of it.


The base problem is that XML is not secure by default.

Every solution requires either figuring out the problems yourself (which is impossible, given the number of problems that exist), or learning about it from elsewhere. No matter what, there will be people asking the same question you did.

I found out about defusedxml because I read planet.python.org where http://blog.python.org/2013/02/announcing-defusedxml-fixes-f... came up, and because I had enough general understanding of the security problems with XML to recognize why it was created.


Note: I submitted this last night to HN but it didn't get picked up. I thought it worthwhile to re-post given that the visibility of a similar HN thread was what clued me into this security problem in the first place.


This thread reminded me of a draft post I've been sitting on for a while, related to ENTITY tags in XML and XXE exploits.

Basically, it's really easy to leave default XML parsing settings (for things like consuming RSS feeds) and accidentally open yourself up to reading files off the filesystem.

I did a full write-up and POC here: http://mikeknoop.com/lxml-xxe-exploit


I bet if you asked any of the founders mentioned in the post, this would be their explicit answer.

Launching 4 divergent products a year means you're 4x as likely to find a hit in that time frame.


The thing you're competing against in terms of performance and efficiency is:

1. JSON.stringify()

2. Diff-match-patch: https://code.google.com/p/google-diff-match-patch/

3. JSON.parse()

There are several short-comings to the above approach though, specifically, you have to explicitly trade off performance vs. efficiency depending on the JSON you're dealing with.

JSON Patch is going to give you a consistent performance vs. efficiency curve which is desirable in a lot of circumstances.


It is my understanding that the JSON encoding of objects is not specified canonically because the order of keys can be arbitrary. That is, JSON.stringify() is free to return different strings for the same JSON object.

Is my understanding correct? If it is, that would totally break your suggestion.


You are correct, but if you control the environment enough to be doing this at all, then you control the environment enough to get the serialization consistent: either by having ordered dictionaries in the language a la Python and PHP, or implementing your own, or by sorting the keys lexicographically a la bencode.

That is, `diff(sorted_json_stringify(json_parse(p)))` will be adequate if `diff(p)` is not.


Your proposed algorithm is a particularly poor solution in terms of correctness if nothing else. For text, DMP performs quite well- patches can typically be applied in arbitrary order with the same result. For complex data formats, you very quickly arrive at invalid (JSON).


This is about sending a diff over the network without having to either have the full json document on hand, or worrying about other concurrent changes that might wreck the diff-match-patch. It's also json-aware versus operating on pure text which might lead to invalid json documents.


1. Errr, to apply any delta, including these, you need the document on hand. If your goal is to store deltas, this is no better than anything else.

2. This is in no way better at handling concurrent changes than anything other diff format. In fact, the extra operations it has do nothing to help you here (it is as good and bad as copy/add, or insert/delete diffs). I'd love to know why you seem to think otherwise.

JSON awareness only helps when trying to apply partial patches. At that point, the only thing it can possibly buy you is syntactic correctness, which is worthless without semantic correctness (and in fact, sometimes worse)


> Errr, to apply any delta, including these, you need the document on hand. If your goal is to store deltas, this is no better than anything else.

Doesn't this allow the sender to send updates without knowledge of the existing values, though? With a string diff, the existing value would have to be known.

> This is in no way better at handling concurrent changes than anything other diff format. In fact, the extra operations it has do nothing to help you here (it is as good and bad as copy/add, or insert/delete diffs). I'd love to know why you seem to think otherwise.

If you're sending a regular diff, you would clobber changes to other parts of the object if they were updated between your initial retrieval and subsequent change. But yeah, it doesn't seem to help with applying concurrent changes to the same part of an object, though I don't know if the patch format should shoulder that responsibility.


> Doesn't this allow the sender to send updates without knowledge of the existing values, though?

This system requires knowledge of existing values/nodes to create the diff/patch document.

However for JSON data, it does have the advantage of not clobbering data unlike a string diff as you mentioned.


You can know keys/paths but nothing else. Or you might have user-specific parts that won't be concurrently modified, but the base JSON doc might be modified by others. You'd have to have the latest version to do a text-based patch.

A text-based diff doesn't really gain much for what it loses in use cases.


I don't see why you need to know values. The operations don't require the sender to supply them.


JSON data is not always stored as texts.


How else would you store it? Javascript Object Notation is text. Other formats such as BSON are different.

Or are you simply talking about javascript style object literals?


JSON is external representation of objects. You can store the actual data on server in any form you like. Doesn't mean you have to store them in text.


But its Javascript Object Notation - Notation in this case implies text - if your storing it in something other than text it's not JSON.

From Wikipedia: JavaScript Object Notation, is an open standard format that uses human-readable text to transmit data objects consisting of attribute–value pairs.


Like you pointed out JSON is used to transmit data objects, but storage of data objects on the server or local file is entirely different story. I hope I don't have to explain further.


Yes, then its no longer json...


I think you're missing the point. If I want to patch just one node and don't care what the rest of the document is, I cannot just use a text diff.


Can you explain why?

This seems like a trivial application of any copy/add delta format, which are easily expressed in text diff format.


A simple example: if the order of the keys is different, say because of a different json implementation, semantically the document is identical, but you can't apply the patch anymore.


There are plenty of textual tree delta formats too.


That's why you use a canonicalizing JSON serializer, which you'd also want to use if you were tracking changes to JSON in git, for example.


The OP was talking about the current incumbent, and the solution proposed does not work for web applications, since the JSON.stringify in most browsers do not sort keys. Sure, you could implement your own javascript version, but it will be at least a couple of orders of magnitude slower.


That's very limiting. So I'm suppose to use the same Json library on various platforms for client as well as server? And what have you really gained?


Because you may not want to serialise your data. Because the order of a json dictionary key is undefined.


Text diff is based on surrounding lines, specifically, siblings, parents, and children in this case. In JSON Patch, only the parents matter.


So then it's a bad implementation of a textual tree diff algorithm .... which again, is a standard copy/add delta format (with a small amount of metadata).


Reach out if you need any help on the Zapier front :)


Thanks! Will do. Been using Zapier personally for some misc personal workflow (receipts=>evernote=>email to our accountant). Love it!


Not sure what kind of back-end is accessible to users, but I bet Airtable could fit into this flow nicely: https://zapier.com/engineering/database-query-automation/



Applications are open for YC Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact