Hacker News Reader

Comment by gtsteve | Hacker News Reader

I was expecting to see two of my pet hates - returning a null array to represent no items, and returning a single object without an array to represent one item.

I also once worked with an API where you had to send the data in POST format - abc=123&def=456. After much pressure from their customers, they finally relented and added an XML version of their API... where your request could look like this: <request>abc=123&def=456</request>.

Even better, note the & is not an & - you can't even use a standard XML parser to interpret the result.

Also: APIs that have a mix of strongly and eventually consistent calls and no documentation about which is which. Or, an API that was at one point strongly consistent turns eventually consistent without warning.

View on HN

I had this happen with a vendor that was told that they needed to add REST support to their legacy Java app. They turned up with an API that encoded XML as base64 and put that in a POST variable on HTML page. Then they added their own crypto on top with hard-coded RSA keys. They helpfully included both the public and private keys in their documentation.

When they turned up for a meeting to present the fruits of their labour they got patted on the back by all the managers for a job well done. Record time too!

They faces fell when I told them that I'm flat out rejecting their API design and that they will have to start from the beginning.

Their excuse for the design was that ampersands are too hard to process, so base64 encoding made them "safe" to include in the REST API.

Sometimes you just have to put your foot down about this kind of idiocy.

Unfortunately I have vivid memories of one API I worked with (many years ago) that included entire encoded XML documents as attribute values within top level XML. At least there was only one level of recursion.

Still, perhaps not as bad as using XML documents as database keys...

I saw that in HTML. Not from a professional developer but it still blow my mind. That was the final straw that made me quit the project.

I've needed to do that for HTML. If you need to put part of a document inside an iFrame (perhaps because you don't trust it) you have your backend generate <iframe sandbox srcdoc="..."> and nest it.

A common misconception is that you can put anything in xml via CDATA so long as it doesn't have the ending delimiter embedded.

https://stackoverflow.com/questions/21087648/xml-invalid-cha...

I know about this because I received a file with illegal CDATA characters once.

Receiving XML that is almost valid can be a real pain - it certainly used to be that some XML parsers didn't report some weird errors in a particularly helpful way requiring manual scrutiny.

I have unpleasant memories of trying to work out why some SOAP web service was breaking and it turned out the WSDL was invalid in a subtle way.

There's often a semantic difference between null and empty.

Like, if I'm checking the result of a batch processing job, I want to know if the job finished & resulted in an empty set, or there is simply no result yet.

It's "the thing you're looking for doesn't exist" vs. "the thing you're looking for exists, but is empty."

That's fair to say I guess - but it should be accompanied by some other property to indicate a condition like that.

The API I'm thinking of though was effectively a wrapper around a database query which retrieved items.

That's what gets me about that decision you see. When you get nothing from a database, you get an empty set. The runtime was some version of .NET Framework, which by default would write an empty set as an empty array. So it wasn't even an accident - someone actually had to add extra logic to make it return null.

Perl's DBI module gets around this with a value "zero but true" aka 0E0.

It is useful in cases such as indicating an operation was successful, but zero rows were affected. Using it as a number resolves to zero, using it as a boolean results in true.

I think in the general sense under API though, a status flag is the best way to avoid confusion as you say. Null could just as easily mean 'error' as 'not yet finished'.

I've seen this happen due to system evolution. At first some entity may have a parent record or not. So when you ask for the parent, you either get it, or null.

But then the system evolves to not be many-to-one, but many-to-many. To avoid breaking old clients, they make it so the only difference is when they return multiple related records, in which case they're given in an array.

Thus you now have: null for empty, the record it self if there is only one related, and an array of records if there are more than one related.

there are still evolutionary justifications which I'm sympathetic to now and then, but mostly not. In many (most?) cases, understanding if something should be one-one or one-many is known up front. Or should be known. We have decades of examples of best practices with many common data structures. Hard coding a customer account to only ever have one address, for example - no. I don't buy that justification - a customer/address thing - for any size company/project - should just be modeled as one-many (at least). It may be slightly more 'work' up front, but that work avoids potentially major breaking changes and work later on.

I get countered with "YAGNI" now and then, but after 25+ years of doing this (and, again, decades of examples of your exact use cases already in google ready to learn from), I can usually tell when you ARE going to need it.

My example was pretty contrived– I would also expect some sort of flag representing the state of the job in that case.

My point was just that the absence of a value is distinct from an empty value. And that intentionally modeling those 2 cases separately can remove a lot of ambiguity.

Right, which is why it's really confusing when an API returns null to mean empty.

Ehm you shouldn’t GET for the result, but for the job descriptor. If you really need to GET the result then you should expect an HTTP 4xx or 3xx response.

There is no justification for NULLs

If your API is RESTful. There are plenty of “rest” APIs out there that are really JSON-based RPC endpoints.

Of course there is, but generally speaking there's an infinite number of possible reasons for an empty or null value, not precisely two. That's why if you don't watch out they multiply.

> returning a null array to represent no items, and returning a single object without an array to represent one item.

This just reminded me of a long ago incident at a former employer. I worked in back-office at a hedge fund and was responsible for maintaining several APIs & services written in C++. The APIs were pretty straight forward query for object(s), get back a vector of objects. If nothing was found, you'd get back an empty vector.

The company also had a program where they'd hire grad students right out of school and immerse them in the trading desk, working on trading algorithms and such. One such kid sent in a "bug report" directly to me, CCing all of front office. The "bug"? We was querying for something that didn't exist, so he got back an empty vector. He didn't check that it wasn't empty, and immediately accessed the front of the vector. Boom, segfault.

Normally, I would have been kind to such a junior dev, but their original email was very condescending and went to an unnecessarily large audience - like hundreds of people that didn't have time for this. His email read something to the effect of "Your API is crashing my code. Fix your API."

Instead, this junior got a whole other lesson instead. I replied all, and included all of back-office on the email (so the rest of the team was aware to watch out for this clown). "The API is working perfectly fine and as designed. The fuck up is on your end. You queried for something that doesn't exist and proceeded to dereference and empty vector. Fix YOUR fucking code."

I really don't like your story. The junior is clearly behaving immaturely and inappropriately by CCing others and not using an appropriate tone, but your response is to... retaliate by doing the exact same thing to him? What lesson is the junior supposed to learn here? That acting that way is A-OK as long as you have seniority and are factually correct? At least the junior has the "excuse" of being a junior, but really as a more senior person you should have known better.

Surely there must have been a better way for you to handle this situation.

I'm not seeing anything wrong with what OP did. By CCing everyone, the junior is trying to make themselves look good by making OP look bad. The junior learned that if they act like an ass, especially an incorrect ass, the other employees won't tolerate it.

That's the DESIRE for what the junior learned. But is that what they actually learned? One could just as easily (or more easily) decide instead that this is the way business is done. It's literally all they've ever seen.

Responding politely could also teach the junior that it's ok to act like an asshole, because he'll get a polite response no matter what.

I suppose the ideal response would have been a polite correction, followed by a polite rebuke regarding the junior's tone and behavior, but I can't fault someone for responding to fire with fire on occasion.

A polite response does not have to be a meek response. You can be blunt, you can point out all the problems, while still being polite.

That also has the advantage of being 100% clear.

"You just told hundreds of people my code is poor. You attacked me, and my professional reputation, and you did it inaccurately. This gives me little reason to respect you or want to help you. Asking without copying the world and without assuming you were flawless would have done a lot to help your case. Because I AM professional and you are new to the profession, I'll hold back on the reflex to point out to every one of these hundreds of peers that influence your career how rude, presumptive, and WRONG you were. Instead, I'm pointing out in private that you are wrong and not behaving in a way someone looking to succeed is behaving. This tolerance is not something you should expect from me again, and you should be grateful to be getting it now because your behavior does NOT call for cooperation. If you do this again, the next person will likely not show this patience and understanding. Do you understand that you made the error in your code? Do you understand how your behavior invites people to think poorly of you? Do you understand how to change both your code and behavior for the future? "

This has the senior developer takes on more work instead of a sense of vindication. However, this is much more likely to get a positive result in the long term - there's no mystery hope that someone that clearly missed out on social repercussions will suddenly understand them when attacked.

Being a senior developer is not about winning battles, it's about learning to win without battles, and even more importantly, it's about TEACHING that.

I've gotta say, if I was a third party to the exchange that involved your suggested message I would think the senior developer was a pompous and condescending ass. In the UK we (or at least I) wouldn't consider what you wrote to be a polite response.

Funnily enough, my last team worked with a software supplier from the UK, and I’m 99.99% sure the above text was copy-pasted from an email reply to one of my overzealous team members. We thought it was over the top, but chalked it down to British culture

There is also a difference between teaching and grandstanding; the reality of the situation is that there is no single correct response for this kind of situations: the junior maybe was zealous, maybe he was trying to shame the senior, maybe he just copied in CC the wrong mailing list.

Obviously the original answer was not appropriate in every situation, but also likely it was appropriate in some.

So what they've learned is, if someone makes an incorrect assumption, sends a nasty email, and CCs the entire department, I get to respond by sending an email back pointing out their error and CCing an even larger audience.

I don't think that's necessarily a bad thing to learn, even for the junior...

There's no way to know in advance what someone will learn from an experience. You also don't know what they learn 'now', and what they might reevaluate and relearn years from now about that same situation. Basing your response decision primarily around what someone might learn isn't a great way to decide how to respond.

Couple folks I'm working with right now, and I had thought a couple of times "well, this wasn't a great scenario, but at least they'll learn ABC from it". One did, one didn't, and keeps making the same moves (I hesitate to say 'mistakes', but in my view they are).

> There's no way to know in advance what someone will learn from an experience.

Correct. You can, however, improve the odds. Being explicit about what you want them to learn as opposed to expecting a certain degree of interpretation cannot hurt your odds, though it can't guarantee them.

> Basing your response decision primarily around what someone might learn isn't a great way to decide how to respond.

In this context, what else was the point of the response? I was comparing to the STFU tell-off of the above post and the defense of it that they would learn from the experience.

> what else was the point of the response?

some other public reaction/recognition for the OP, not for the benefit of the original sender.

emotional venting? that's sometimes its own reward.

It wasn't wrong, but it also betrays that OP wasn't really a senior either. Just an older junior.

>Surely there must have been a better way for you to handle this situation.

The junior was in the wrong, so I think you'd agree that a correction is in order. Replying-all is one way to do such a correction. The alternative would be to force him to issue a retraction himself.

There's no need to shame people who are wrong.

not unless they're being dicks about it, like in this example ;)

If they're trying to shame or chastise others, while being wrong, seems fair to me. Then again, I subscribe to the "play stupid games, win stupid prizes" school of dickish behavior correction.

Or, to defer to the ever-wise Gods of the Copybook Headings:

"What's good for the goose is good for the gander".

Ah, but that's the kinder, gentler version of "what's sauce for the goose is sauce for the gander"[1] which seems even more apropos.

1: https://en.wiktionary.org/wiki/what%27s_sauce_for_the_goose_...

I've noticed that if you stay strictly professional, folks think higher of you and they feel shame for having done this. You also appear way wiser and likeable - all of which gives you more clout. And if you're more often right than your peers, everyone benefits by your having more clout.

I've been in this situation before and I've found this approach beneficial.

http://www.basicinstructions.net/basic-instructions/2012/11/...

"I've noticed that if you stay strictly professional, folks think higher of you and they feel shame for having done this."

Some do, some think it is a sign of weakness and start behaving even more unreasonably.

And since the boss knows you are right because of your previous behaviour, all you need to do is ask the boss to take care of the disturbing element if it continues.

That's making a lot of assumptions about your 'boss'.

Yes I'm aware. I have been extrely lucky with my jobs so far.

Normally that would be true.

But it's necessary to shame people who work the trade desks, or else they will never learn.

I honestly think people learn better if you don't shame them.

I honestly think it depends on the entire context including the people and all this generalization is useless and a waste of precious Internet bits.

True. If the junior dev was simply wrong, but polite about it, it might (and should) have ended without a shaming.

While there is perhaps no need to shame someone who is acting in a shameful way, I find it hard to criticize someone for doing so. Sometimes an aggressive statement deserves an aggressive response.

It depends on the company. Often the best thing to do is fire back without escalating. With someone like that junior sending an email like that without first talking to someone is a good way to get fired or put on a PIP depending on how long they’d been with the company.

Live by the sword, die by the sword.

Everyone dies from trying to dereference empty vectors that are != nullptrs at some point in their life. It isn't only APIs that can set traps...

Many people don't see mailing everyone as self promotion for showing off, most often they just don't know whom to address with stuff like this so they try shotgun mailing.

That alone can still be bad though, since it gives every recipient an opportunity to be distracted if they want to be.

I had a similar situation where a certain person would blame my API for all of his problems in a very public manner. First few times I responded quietly pointing out the mistakes but then I started responding publicly pointing out that the person should first learn the programming language before blaming others with examples from previous interactions. The behavior stopped immediately. Sometimes you have to bully the bully and make clear that being new is not an excuse for bad behavior.

I fundamentally disagree with the idea that it's a virtue to act politely and "professionally" in all circumstances, no matter what the provocation. I think it can be entirely reasonable (depending on specific circumstances) to publicly shame someone who has been publicly acting like an asshole.

Simply being wrong in public deserves a gentle correction (possibly in private, again, depending on the circumstances), but often I don't really care to be nice to people who aren't being nice. It's certainly possible that being nice all the time in situations like this gets you better outcomes overall, but we all have a limited amount of patience to dole out, and some people just don't deserve it sometimes.

And on the other hand, some people don't get the message when you respond politely. Responding politely in this case could just as easily teach the junior that his debugging strategy (blame anyone but himself) and dickish tone were completely ok. There's certainly a polite way to inform the junior that his behavior won't be tolerated, but I can't fault someone for simply responding in kind.

Really, there are many reasons to run internal mailing/distribution lists and designate emails from them in some manner, such as a subject prefix. One of which is that people are less likely to sent an email to the "Staff" list if most the correspondence there is from management and about company level things, and then it's also very appropriate to reply to the email with content that addresses the request (in this case, you're wrong, don't do that) and also a rider about how this is not the appropriate place for this, and they should submit to the appropriate list/form.

How did your API endpoint signal internal errors or parameter errors to the client?

I had the pleasure of working with the API of a customer that wanted to expose a JSON/REST API to their existing XML/SOAP backend. Instead of going the sane rout and re-use the XSDs to serve as the structure for the JSON, they just made the JSON structure up on the go.

One child node? That would be one JSON object / value for you sir. Multiple child nodes? That would be on JSON array for you sir. No child node? No JSON type for you sir.

So what happened when the amount of child nodes was dynamic? You would either get: nothing, an object, or an array of objects. Oh the fun times we had!

I bet $50 there was a junior dev promoted too high too fast proud of that technical feat.

That sounds like absolute nightmare - at least keep a convention.

That reminds me of a vendor who wraps SAP Business One in their own webservice. This webservice has two business methods.

The first one, ExecuteXML, takes an <XmlBody> representing a regular SAP B1 XML request and passes it on to one of the real SAP services. We have to find our own XSDs for the inner part, because they sure as hell don't have those.

The second one is ExecuteSQL. It lets us run raw SQL against the SAP database. It doesn't have any support for prepared parameters. What it does have is a blacklist to prevent DDL and other funny business, such as semicolons. This blacklist runs on the raw string you send, and doesn't understand any escape characters. To send a string containing a literal semicolon, I had to turn it into CONVERT(VARCHAR(MAX), 0x...).

For those Gophers reading this and sobbing silently, there may be hope: https://github.com/golang/go/issues/27589

Why would you want to marshal a nil slice to json as non-null? That just hides the fact that you had a nil slice. In fact, that's the exact opposite problem; representing nulls as empty arrays.

As explained in the thread, that is because Go best practice is to treat `nil` and `[]T{}` as the same thing in every API. If you want an explicit `null` in your JSON you can use `*[]T` as your field type, and then it makes more sense.

The very idea of allowing the nil value for slices seems to be very strange and inconsistent, as slices are struct types, not pointer types in Go (they contain a pointer and other members). Just one of the many ways that builtin types in Go are fundamentally different from user-creatable types, I guess...

It is admittedly very weird that Go supports nil slices/maps instead of just having the nil value be an empty slice/map that points to constant storage. But as long as Go has a semantic difference internally, representing that as null externally makes sense. Though I suppose as long as the conversion from null to empty array/object is opt-in it's fine.

For context, we recently had a bug where backend forgot to initialize their map, so they were sending us a null where we expected an object, and it would have gone undetected for much longer if the JSON didn't contain a literal null there.

The nil value for a slice is an empty slice that points to constant storage: Data=0, Len=0, Cap=0. That's just not the same as Data=somethingelse, ... which you get if you allocate something.

(And all Go zero values are exactly what you get with the relevant RAM filled with the zero byte.)

If the nil value for a slice is the empty slice, then why do the following two variable definitions differ in behavior?

  var x []int;
  y := []int{};

Both produce a slice of capacity zero, except `x` serializes to null and `y` serializes to an empty array.

returning a null array to represent no items

To be honest, that's what I'd expect. What do you dislike about that result, and what would you prefer to see returned? Jump straight to 404?

returning a single object without an array to represent one item.

So an array if there's multiple results, and a bare object for a single result? That's unpleasant.

> What do you dislike about that result, and what would you prefer to see returned?

It’s inconsistent and means I need to write special case code to check for it, when before I could choose to. It should return an empty array.

null array sounds like it's an array (presumably an empty one), it would have been clearer if OP had said null instead.

Not sure why you're getting downvoted - that was how I read it as well.

Presumably they would prefer an array always be returned. If zero items, an empty array; if one item, an array of length one; if more items, a longer array.

If an API is expected to return an array, but the data set is empty, I expect an empty array. I should be able to go straight from the request to a for-each loop without checking for null.

> Jump straight to 404?

That's my pet peeve. I completely understand the logic - using the HTTP status code to show the result of interaction with the resource is very RESTful - but my complaint is that unless you provide more context, a 404 doesn't tell me if I'm getting a response of "that resource doesn't exist" vs "you're accessing a url pattern that will never work".

So if you want this random internet user to be pleased, never return a 404 response unless the caller is able to see this difference. (Usually having SOME form of body unique to the API is sufficient to prove the 404 is not because of a bad API call).

Giving me the HTML to your site 404 page when I called a non-HTML API is likewise sad-inducing.

We have only one pattern like this... when there's a client resource (containing personal information for contacting them) that the client has asked to be private... we return an empty JSON object (versus an object with the contact information keys)

>> returning a null array to represent no items

> To be honest, that's what I'd expect. What do you dislike about that result, and what would you prefer to see returned? Jump straight to 404?

I'd expect an empty array to represent no items. It's the difference between "" and "[]".

404 indicates an error, if the result is just empty but not erroneous 204 "no content" may be better.

+1, 204 is underutilized for no-result cases.

In the browser it will also do no page refresh as there is nothing to render.

“returning a single object without an array to represent one item.”

I saw the same thing when working with PHP consuming data from a SOAP endpoint. First I thought PHP is stupid. But then I realized that XML can’t model single item arrays versus single objects. They look the same. JSON is better that way. You can model empty arrays and single item arrays.

> XML can’t model single item arrays versus single objects. They look the same.

    <results>
      <result>
        <property>value</property>
        ...
      </result>
    </results>

I don't really see the problem.

You need to know that “results” is an array so you need the schema. In JSON an array is an array without doubt.

I mean, sure, but if you're creating an XML API, you've almost certainly defined the schema. If I take JSON like

    [
      { "fruit": "banana" },
      { "color": "yellow" },
      [ 1 ]
    ]

...and turn it into XML like...

    <document>
      <fruit>banana</fruit>
      <color>yellow</color>
      <ids>
        <id>1</id>
      </ids>
    </document>

It's going to be fairly clear what's going on.

I'd generally prefer to work with JSON, too. But the silver lining of XML is that you can define virtually any schema you want, and there are times that's conceivably going to be clearer or even more concise than the equivalent JSON.

If you don't know that "results" is an array... how do you handle the uncontroversial case of getting back an array of two results?

I know that but the PHP deserializer doesn’t know and gives me back an object instead of an array of one. If it’s two it detects an array.

But it's always a single object. If it has two parallel nodes at the document root, it isn't valid XML.

So an array of two results looks like this:

    <results>
      <result></result>
      <result></result>
    </results>

and PHP automatically treats results as a two-element array, but for the one-element array

    <results>
      <result></result>
    </results>

you just get a parse error?

Not a parse error but a single “result” object, not an array of length 1. With two elements it recognizes an array.

If you can parse

    <results>
      <result></result>
    </results>

and you end up with a single "result" object, you must have identified "results" as being an array of one element so that you could discard it. (You didn't get a single "results" object.)

That's not a problem in what XML is able to model, it's a problem with you throwing the information you got away and then pretending you didn't receive it.

On the other hand, if you meant that you get a single "results" object, then you're saying that your code is written to require invalid XML and fall down when valid XML is provided. Again, that sounds more like a problem with your code than with the modeling capabilities of XML. There's an argument to be made for accepting invalid input; rejecting valid input is ridiculous.

You do understand that php and quite a few other languages provide pre-built serialization and de-serialization from XML, right? The OP was talking about the out of box behaviour for those. Your answer seems to predicate on having written a custom deserializer.

My answer is predicated on the idea that you should be using a deserializer that doesn't rely on receiving invalid input, regardless of whether that deserializer comes from a standard library.

A sample output (either XML or JSON) is not a substitute for a specification.

Looking at the XML when a list has only a single element, you wouldn't know if there could be more. You need an XSD to accompany the XML, which is what is typically provided.

When looking at a JSON document you might run into the same situation where the document you received doesn't contain all possible elements, and you wouldn't be the wiser. You'd still need a proper JSON schema to accompany the document.

You can force PHP to handle sngle-element arrays consistently, with the SOAP_SINGLE_ELEMENT_ARRAYS option, the behaviour is much saner when enabled.

Good to know! Unfortunately I have a call to a “FixSoapArray” all over the code already :(

What would we do without ten different ways to represent nothing?

  if ismissing(x) then
       x = empty
  end if

  if isempty(x) then
       x = ""
  end if

  if x is nothing then
       x = new foo
  end if

  if right(typename(x), 2) <> "()" then
       x = Array(x)
  end if

I worked with a product for natural language processing that wanted the text in a query string. This led to 100+ page documents begin sent as a string in the request. My usual REST testing app would freeze up if I wanted to test some of the largest documents in the data set.

> This led to 100+ page documents begin sent as a string in the request

How were you able to do this when the standard maximum length of a query string is 1024 bytes? I guess you could flaunt the standard as you were responsible for the backend

Except that standard...isn't. It's what some ancient version of MSIE did and that used to count for a standard in Triassic; nowadays, it gets passed around as cargo cult advice. (The relevant RFC recommends no more than 8000 bytes, sure.)

https://stackoverflow.com/questions/417142/what-is-the-maxim...

It's not cargo-cult: anyone who's worked on cross-browser front-end development probably encountered this at least once. I ran into this personally a few years back when I was trying to be too clever by half with base64-encoded queries. It's not just ancient IE that has limits - in my case it was a corporate proxy that was truncating the query (which is why only that customer was getting that bug). A year or 2 before that, I ran into the MSIE limit (must have been IE8 or 9: don't know if that counts as the Triassic period, because I don't know what we'd call the IE4-6 era)

I did encounter this multiple times...not in the last decade though.

Late response, but maybe you'll still read it...

We had some issues because there was no real security on the API of our NLP tooling. So we put NGINX in front of it to create a from of API key auth. NGINX would deny the larger messages by default, so we had to increase some parameter so it would pass the large documents. And indeed, since this was only relevant in the backend, it didn't matter. For the front-end we built our own API that was a lot more sensible.

> returning a null array to represent no items, and returning a single object without an array to represent one item

this happens when you add JSON version for old XML-based APIs (seen this multiple times)

> this happens when you add JSON version for old XML-based APIs (seen this multiple times)

...without using an XSD schema. With a schema,not an issue

What would you suggest instead of an empty array for a 0 item return?

The person you replied to doesn't like returning "null". He/she would probably prefer returning an array that contains 0 items.

This makes sense now. If I did a GET to posts and got a "null", I would think I made some kind of error. If I get an empty array, I would (correctly) assume there are no posts yet.

Basically, GET to posts would always return an array of posts. Whether there are 0 (empty array), 1 (just one object in the array), or many (array with n length). This makes API logic way easier to handle without having to check what structure I received even with a 200 status code

Also makes a lot of iteration easier... just a for loop over the array to dump something on the page with no edge cases.

You can add a warning by just checking the length against that array blindly.

He called it a "null array" which I interpret as an array containing zero items. If it was just a plain old null then yeah, that's super annoying.

If you return an empty array, I can always process the result by looping through the array.

If it's sometimes an array and sometimes null, I need branched logic for each call.

I actually really like POST format. Very easy, very standard, very readily available.

I also like that it encourages flatter data models.

Reply on news.ycombinator.com