Steve Jobs admired Zuckerberg too much to compete with him - <AUTHOR> http://news.cnet.com/8301-13579_3-57474388-37/steve-jobs-admired-zuckerberg-too-much-to-compete-with-him/ <comment><USER2> The quote from Isaacson seems to fly directly in the face of the rest of the article. Clearly Apple and Facebook were not on very good terms for a long time.

It seems a really long bow to draw to say that Apple didn't create a competing social network because Jobs admired Zuckerberg. It's like saying Apple don't make cars because Jobs admired Henry Ford. Mostly likely, they didn't come out with a competing social network because that's just not the business they're in.

</comment><comment><USER3> Let's not forget that apple really doesn't get the web or the cloud. They are ill equipped to build a Facebook.

Clients and hardware - nailed. Cloud and web - not so much.</comment>


Andrew Mason's Descript raises $15M and acquires Lyrebird - <AUTHOR> https://techcrunch.com/2019/09/18/descript-audio/ <comment><USER2> I used to be an engineer at a startup that Groupon was acquiring. One day we were at their Chicago HQ being interviewed by their leadership team. I was waiting outside the conference room, feeling super nervous, when this really tall guy with messy hair just sort of saunters over. He looked pretty aimless and carefree. It turned out to be Mason, and he came over to talk to me. I was super nervous, as he towered above me. But he turned out to be so nice, and had a very calming effect. He knew about our company and even knew who I was, I was so surprised. Since then, I've always wished the best for Andrew, as I really believe his heart is in the right place, and he wants to build great things. Glad to see he has a new project cooking up.

</comment><comment><USER3> Don't miss the overdub demo: [https://www.descript.com/overdub](https://www.descript.com/overdub) and the demo video: [https://www.descript.com/](https://www.descript.com/)

<comment><AUTHOR> People will be able to create some serious deep fakes of audio recordings with Overdub. Where it will get really wild is when you can change the voice of the original recording into your "voice of preference" for listening purposes. Ie- instead of Ira Glass narrating This American Life, think what it will be like when you can listen to TAL with Morgan Freeman narrating it!

<comment><USER4> As stated in the article, Overdub forces you to read random sentences so you can't just feed in hours of audio. That being said, this technology is quickly becoming commoditized and I suspect others won't be as scrupulous.

</comment></comment></comment><comment><USER5> Say what you want about Groupon overall, but Andrew was an amazing leader during my time there. I'd be excited to work on this team.

<comment><USER6> In between Groupon and Descript he was working on a product I loved called Detour. Our first time trying it, my wife and I lived at 24th and Valencia (San Francisco), and we walked over to Mission and 24th for a group tour they were launching. Detour was creating audio walking tours driven by GPS.

Keep in mind, at the time, Andrew was sitting on hundreds of millions of dollars from Groupon.

We walked up to do the tour and to test the product. There were like 4-6 people there, and I'm sure others had already started the tour. My wife had zero idea who he was, I vaguely knew what he looked like.

We get there and Andrew is standing there at the 24th street bart with a Detour t-shirt on. My wife's app doesn't work, and he helps her get it installed. He is annoyed that the software isn't working, but couldn't be nicer. He patiently figures it out and we were off.

I told her, I think that is Andrew Mason, the guy that started this company, and also the guy that started groupon. She laughed, and was like, no wonder he cared so much.

I guess the point of the story is that I have zero idea what he is like to work with from experience, but my moment meeting him, he came off as humble, smart and nice. Most importantly someone who cared deeply about his company. I like working for and with people like that.

<comment><AUTHOR> Thanks for sharing the story – love hearing early accounts of when companies start!

The key takeaway from the story is that Andrew, as a founder, was willing to roll up his sleeves, get in the dirt and talk directly with customers to get early feedback. He didn't use his liquidity and profile to hire someone else to do this – that would have been too easy. A good founder will always start at the foundation, and build from the ground up.

</comment></comment></comment><comment><USER7> More information: [https://medium.com/descript/introducing-descript-podcast- stu...](https://medium.com/descript/introducing-descript-podcast- studio-13b8da53311b)

</comment><comment><USER8> Revolutionary stuff</comment>


Creating Your Own Perl (extending Perl via CPAN modules) - <AUTHOR> http://www.perladvent.org/2012/2012-12-16.html <comment><AUTHOR> Not mentioned in this post but one of my favourite CPAN modules for extending/fixing Perl is _perl5i_ \- <https://metacpan.org/module/perl5i></comment>


Factyle - look for meaning, not keywords - <AUTHOR> http://factyle.com/speedread <comment><AUTHOR> Hey all, What do you think of this as a summarizer/speedreader? What in your opinion would be good applications to such speedreading?</comment>


Npm security post-mortem - <AUTHOR> http://blog.npmjs.org/post/80277229932/newly-paranoid-maintainers <comment><USER2> > * Before they could start, we had a very serious security vulnerability > responsibly disclosed by Will Farrington and Charlie Somerville

> * We fixed it on February 17th

the fix scares the shit out of me:

[https://github.com/isaacs/st/commit/5a0c1886737a20d78ae00b61...](https://github.com/isaacs/st/commit/5a0c1886737a20d78ae00b61e4724ae3095f4ddd)

         Properly escape all relevant html entities
         Avoid problems with files named things like '<img>' and so on.

         -      var name = f.replace(/"/g, '"')
         +      var name = f
         +          .replace(/"/g, '"')
         +          .replace(/>/g, '<')
         +          .replace(/</g, '>')
         +          .replace(/'/g, ''')

<comment><USER3> It looks like this change has more to do with XSS than the "big" exploit.

The more serious fix occurred here: [https://github.com/isaacs/st/commit/6b54ce2d2fb912eadd31e2c2...](https://github.com/isaacs/st/commit/6b54ce2d2fb912eadd31e2c25c65456d2c8666e1)

And here: [https://github.com/isaacs/st/commit/6d6100eec8b19e2774a6f2bb...](https://github.com/isaacs/st/commit/6d6100eec8b19e2774a6f2bb5c9b54fa9e1f9e72#diff-02be450bd9337a4b4e26c2139550120bR160)

With some icing on the cake here: [https://github.com/isaacs/st/commit/8b2f212f64b762e351f311f4...](https://github.com/isaacs/st/commit/8b2f212f64b762e351f311f4bbfcb291aa997838)

<comment><USER2> not much more encouraging. it looks to me like patch work. ive had this in the past. would give a PoC to a client along with a recommended design change to the questionable methods of the code. they would send back a new version with a patch much like all of those linked here. in the end those patches address the PoC but not the problem. then i just rework the PoC to go around the patch. This cat-mouse game goes on until they go back, do the f'ing work, and implement the original design change suggested. I say all that just to point out that this looks like patch work and is a scary behaviour. Then again, maybe this is the nature of nodejs (omg).

Also, as a general rule:

        ANY SECURITY PATCH THAT IS A REGEX IS NOT A SECURITY PATCH

<comment><USER4> >ANY SECURITY PATCH THAT IS A REGEX IS NOT A SECURITY PATCH

Not true. Regex works well for forcing integers.

</comment></comment></comment></comment><comment><USER5> It's worth noting that the XSS vulnerability ("A user could inject scripts into the npm website via the README and license fields") assuredly exposed a whole slew of easy-to-exploit vulnerabilities, and the community should feel very lucky that such an obvious vulnerability was in the wild for so long without being exploited.

TL;DR always use a templating engine that makes you think about XSS and don't allow unsanitized user-provided HTML through raw.

<comment><USER6> > don't allow unsanitized user-provided HTML through raw.

It's sad that you even need to say this, both for the fact that Javascript sandboxing is so terrible and the fact that developers aren't aware of the hazards of just blindly taking user-provided HTML.

<comment><USER7> As a point of honor, I feel obligated to mention that @rockbot and I are _very_ aware of these hazards, but our website was put together in somebody's spare time when Node had like 100 users in total :-)

<comment><USER8> I read that 'as a point of horror'.

</comment></comment></comment></comment><comment><USER9> Why do they have to apologize for that? Almost every piece of software has security vulnerabilities.

Do people now really believe that there are definitely no security vulnerabilities related to the npm registry? Or any other type of registry, or website or application for that matter?

People have completely unrealistic expectations about security. Every time you had a significant amount of new functionality, or even a very insignificant amount, you could have introduced a new security vulnerability.

Basically this other company Lift or whatever could have two full time engineers doing security audits for npm from here until npm is done, and you could still have some other hacker who was thinking differently come up with a vulnerability in some new feature that they missed.

Its great to have the attitude that you are going to make a serious effort, but totally unrealistic to think that you are going to do one security audit and then there will be no more vulnerabilities. And also really makes no sense to make a big deal about it or give them grief or for them to even feel bad. If you think that way then you don't understand security.

You see all of these large projects having security issues not because they are full of negligent or sloppy engineers, but because security takes a lot of resources and is very difficult. The security firms will certainly suggest that engineers are negligent, of course. That ensures that they will continue to get new clients. But the reality is even with a lot of resources dedicated to just security, projects can easily have new vulnerabilities.

So that's great that they are getting regular security audits now. They are ahead of the curve.

EDIT: I notice I have been buried without anyone bothering to even respond. If you disagree, say why you disagree.

<comment><USER10> "Why do they have to apologize for that?"

It's just the sad state of the 'industry'. As soon as some armchair warrior finds something remotely wrong with whatever, they'll go _nuts_ on you and you need this sort of touchy-feely PR nonsense to placate the comic book shop types. Hats off to these guys for being level-headed enough to be able to play the game this way - I couldn't do it any more, I'd go bonkers over overhead like this.

<comment><USER11> If anyone needs placating, it's those developers, managers and executives who pushed hard for the use of Node.js in business settings, not expecting a serious security incident like this one to happen.

For those who are especially serious about their careers, reputations, budgets and power, incidents like this involving the technologies they hyped and pushed through can be disastrous. Now they're seen as being very wrong about something very important, and this in turn makes them extremely angry.

They know that their competitors within the business will use this incident against them. Their next initiative will surely face comment like, "Why should we listen to you after the npm disaster?", and they will face a much harder battle if their decision involves any controversy or doubt at all.

<comment><USER9> Every technology is going to have an "incident" like this. Experienced developers expect security "incidents". There are quite a few managers and executives who do not understand security and don't. And many people who will use this sort of "incident" politically. Politics is the problem there, not the technology.

Just because they found one significant security issue with npm does not mean they were "very wrong" about using Node. Its just a reality of security with any technology.

This isn't a disaster, this is a demonstration of maturity, responsibility and transparency.

</comment></comment></comment></comment><comment><USER12> Nice write-up and good on them for fixing that quickly, but it's a serious bummer they unnecessarily bring in the RubyGems incident as some sort of awkward "Well at least we didn't screw up that badly!" swipe. It's not relevant to anything else they said.

<comment><USER5> I think what they're trying to say is that the bug is exactly as bad as the Rubygems incident, but they got lucky and it wasn't exploited.

<comment><USER13> How I took it as well.

<comment><USER7> That was certainly the intention.

</comment></comment></comment></comment><comment><USER14> The world would be a little better if every software company could inform its users of security vulnerabilities and bugs as these guys did.

<comment><USER11> They can, and many do or have done so in the past.

Let's not pretend that security incident post-mortems are anything new; they aren't. There's not really even anything special about this one.

I don't really see much point in applauding these guys for doing what's perhaps the minimum we should expect from them in this situation.

</comment></comment><comment><USER15> The 'we fixed it' link points to four new lines including these:

          .replace(/>/g, '<')
          .replace(/</g, '>')

I can't really tell without more background and context, but I'm surprised this doesn't turn > into > and < into <. Is this a mistake? The same code's still in the HEAD.

<comment> dav- Yeah, that is very weird. Shouldn't it this?

        .replace(/>/g, '>')
        .replace(/</g, '<')

<comment> dav- Actually, someone submitted a pull request to fix this 4 hours before my original comment: [https://github.com/isaacs/st/pull/37/files](https://github.com/isaacs/st/pull/37/files)

</comment></comment></comment><comment><USER16> Its great to finally have full time folks managing npm and to finally have the resources to do things right (eg. hire ^lift).

Thanks for doing!

</comment><comment><USER17> Nice disclosure, and can't fault the npmjs team given that they commissioned a security audit as soon as they possibly could.

I wonder if the npm, Inc. team told ^Lift about the disclosed vulns before ^Lift's own audit completed. I can imagine being tempted to see whether they'd discover it themselves, to gain more evidence on how comprehensive the audit was.

<comment><USER7> We told them as soon as we found out, because we needed them to go looking for the same hole in all of our code bases :-)

As part of the audit, ^Lift audited a lot of the third-party modules we use, and notified the authors of those packages separately (I'm not aware of the details, but I don't think there was anything major).

</comment></comment><comment><USER18> Y'all might want to limit the number of characters in a user's name...

[https://www.npmjs.org/~maxj](https://www.npmjs.org/~maxj)

</comment><comment><USER19> can anybody disclose some figures on how much ^lift (or competitors) costs, e.g.: for a 100K-line Python codebase? A rough ballpark would help a lot.

<comment><USER20> Thomas could give you better numbers here, but in general, appsec reviews cost as much as getting software development done. (i.e. For a security review worth the paper you print the report on, you're looking at $5k at the lower end if your application is simple or if someone wants to really do you a favor, and they get _substantially_ more expensive than that. You can get someone to run an automated scan for $500 and give you a CSV file, but that is not maximally in your interests.)

I'd turn away any client who asked me to do appsec work, because I don't think I'd produce work of a sufficient quality to justify the sort of rates I charge, but I do think I'm probably good enough to roughly scope appsec projects on technologies I understand well. Example: Appointment Reminder is an architecturally simple Rails application. I think an audit of the marketing site, application, and architecture would reasonably require probably 1 to 2 billable weeks depending on how much I asked you to plumb e.g. line-by-line HIPAA requirements, and that would probably run in the $4k to $12k region based on my understanding of prevailing rates for appsec work. (I'm sure that if I had $25k budgeted for that audit many firms could find a way to get me my money's worth for every penny of that budget, by the way.)

<comment><USER21> A $4k billable week is incredibly cheap, so much so that I'd worry about the team delivering it. Our rates are high because big firms bid them up. Why are the cheap teams turning down free money?

If someone offers you a $4k week, make sure they know they're cutting you a deal.

<comment><USER22> > Why are the cheap teams turning down free money?

Hi, i double that. Also I understood your advice better now. Undercharging = making it worse for everyone (consultant profit, work quality, dumping).

<comment><USER21> Hey, just to be clear: I don't think it's _wrong_ to charge less than the market rate, and while I'm more likely to do a project _gratis_ than at 1/2 or 1/3 my rate, we've given people breaks before.

</comment></comment></comment></comment></comment><comment><USER23> So the audit was mostly about nom the website and the service for maintaining npm packages? That's a good first step.

Has there been any talk within the node community about auditing node modules themselves? Maybe start with the most popular? I could see this being popular with enterprise development, etc.

I want to say that Strong Loop made noise about doing something like this, but I haven't seen much on it of late.

<comment><USER24> One of the Node Security Project ([https://nodesecurity.io/](https://nodesecurity.io/)) main efforts is to audit all the npm modules in a community driven way.

We are accepting contributions from the community to build the tools that get the job done efficiently and to audit modules, disclosing vulnerabilities in a responsible manner.

<comment><USER23> I'll take a look, thanks. Some reviews will, of course, be manual in nature -- implementation correctness of digest auth, for instance, is one that comes to mind (I need to contribute that back to a particular module).

</comment></comment></comment><comment><USER25> Is this why npm made the changes with self signed certificates [http://blog.npmjs.org/post/78085451721/npms-self-signed- cert...](http://blog.npmjs.org/post/78085451721/npms-self-signed-certificate- is-no-more) or is that unrelated?

<comment><USER7> The original abandoning of the self-signed cert was because self-signed certs were a bad idea.

The issue that post refers to (it is a little unclear, because we ourselves were a little unclear what had gone wrong at that point) is when we broke older clients by moving to a non-GlobalSign cert. We cleared that up here: [http://blog.npmjs.org/post/78165272245/more-help-with- self-s...](http://blog.npmjs.org/post/78165272245/more-help-with-self-signed- cert-in-chain-and-npm)

We had already planned to move to a new cert before the security disclosure, and hadn't anticipated the size of the problem with a non-GlobalSign cert, so although the two happened pretty much simultaneously, they weren't really related.

</comment></comment><comment><USER26> One of the things I love about Isaac is his empathy. Reading his blog posts, listening to his podcasts on Nodeup, looks like he is writing/talking to me, and since I'm a developer, this makes a huge difference in my motivation.

Great job guys and very responsible choices.

</comment><comment><USER27> Security postmortems are a great idea. Until time machines happen.

</comment><comment><USER28> Great read!

</comment><comment><USER29> Nearly Paid Muppets?</comment>


Stop Writing REST API Clients - <AUTHOR> http://ttezel.github.com/ <comment><USER3> Substitute "XML" for "JSON" and we've now come full circle.

The point about REST is that it is self-describing. And ideally should be using the same URIs as the version people clicking around in Firefox or Chrome see. The API is just the XML or JSON or whatever is flavour of the week version of the HTML version.

(Or we could use embedded data—microformats, microdata, RDFa—and get rid of that distinction.)

<comment><AUTHOR> Yes my argument is simply that we publish API specs in a machine-readable format to avoid wasting time implementing clients repeatedly. WSDL and WADL had good intentions at heart, but XML is ugly. JSON is nice since it's human- readable and light. Why not publish JSON versions openly for REST APIs, reducing implementation cost for clients?

<comment><USER4> XML is more human readable than JSON, to my eyes.

<comment><USER5> Really? Let's write a shopping list on a piece of paper in JSON and XML. Which one would be more similar to the way we write down lists in real life?

<comment><USER4> _Really? Let's write a shopping list on a piece of paper in JSON and XML. Which one would be more similar to the way we write down lists in real life?_

XML:

       <list>
        <items>
           <item>Milk</item>
           <item>Eggs</item>
           <item>Bread</item>
           <item>Butter</item>
         </items>
       </list>

JSON:

        {
           "list": {
             "items": [
                "Milk",
                "Eggs",
                "Bread",
                "Butter"
            ]
          }
        }

I don't know that either one is particularly close to the way I'd write down a list in real life, to be honest. This is a pretty trivial sample, and neither is especially hard to read/parse by a human. But the JSON still looks closer to line-noise to me. :-)

</comment></comment></comment></comment></comment><comment><USER6> Sigh. This is optimizing for the wrong problem.

Stop creating REST APIs that are only level 1 or 2 (see [http://martinfowler.com/articles/richardsonMaturityModel.htm...](http://martinfowler.com/articles/richardsonMaturityModel.html) ).

Start writing HATEOS systems where the client is coupled to the semantic rather than the syntax.

Machine parseable interface descriptions might get rid of some boilerplate but it doesn't make for a more robust client-server relationship.

<comment><USER7> Yes, URIs in the response sounds amazingly cool, but it won't change anything.

The inline URLs of the web work because the consumers are humans who can deal with changes (more than just trivial URL changes, like added, removed features) and now click on this button or that button.

Software isn't that flexible, so it will be just as coupled as it is today-- you're just moving the coupling around.

So this idea of a "robust client-server relationship" is a pipe dream IMO.

<comment><USER8> I've built these kinds of things before: [http://words.steveklabnik.com/i-invented-hypermedia-apis- by-...](http://words.steveklabnik.com/i-invented-hypermedia-apis-by-accident)

<comment><USER7> Not saying that system doesn't sound cool, but my point about hypermedia APIs is that when you serve back:

<link href="<http://example.com/low.rss> rel="podcast_url" />

You've moved the coupling from "look at URL xyz" to "look for rel podcast_url". Okay, yes, you can now change the URL, that's cool, but I assert that's relatively trivial. You can't truly add/remove new functionality (or break existing contracts, like "look for rel=podcast_url") that some omnipotent client would suddenly start taking advantage of.

IMO this omnipotent realization/utilization of new/changed features is what hypermedia advocates get all excited about, without realizing that humans are really the only ones that can deal with that level of (true) decoupling.

<comment><USER8> The important part is that this is all documented in the media type. Of course, computers aren't able to just figure out what's up, that's why it's agreed upon beforehand.

> You can't truly add/remove new functionality

You can absolutely add new functionality, because rule #1 of clients that work this way is 'ignore things you don't understand.' Removal will obviously break things, so it's important to handle this in the appropriate way.

I guess ultimately my point is that these kinds of APIs are significantly different, and come with a very different set of constraints/goals/implementation details. It's like you're saying "well, I don't have a full list of function calls I can make!" because you're used to SOAP where there's a WSDL and 'RESTful' APIs don't have description documents. Of course! It's a different architecture!

</comment></comment></comment></comment></comment><comment><USER9> We could give a name to the language we use to define such files. It's a language that defines Web services, so perhaps Web Services Description Language? :-) [http://en.wikipedia.org/wiki/Web_Services_Description_Langua...](http://en.wikipedia.org/wiki/Web_Services_Description_Language)

Flippancy aside, maybe there's a need for a next generation of this that skips all the XML headaches after all.

<comment><USER10> [http://en.wikipedia.org/wiki/Web_Application_Description_Lan...](http://en.wikipedia.org/wiki/Web_Application_Description_Language) ?

<comment><USER9> It's still XML but that does look closer. I thought the other commenter was joking that this existed.. :-)

</comment></comment></comment><comment><USER11> I don't see how writing JSON REST API descriptions isn't practically the same as writing REST API clients anyway: they're still clients, just written declaratively rather than procedurally.

If the point is "stop writing procedural REST API clients and write them declaratively instead" then that advice is by no means restricted to REST API clients.

If the point is "hey, I noticed that REST API clients are another thing that we can now comfortably write declaratively" then OK.

</comment><comment><USER12> Am I the only one who doesn't like receiving direct orders from article titles?

<comment><USER13> Would it help if he prefixed it with "In this article, I argue for why I believe that you should"?

<comment><USER14> "A way to stop reinventing REST API clients."

</comment></comment></comment><comment><USER15> This article is not at all about REST, it is about RPC and its shortcomings. These shortcoming were fixed by REST, and the author of the article rediscovers these fixes.

A key features of a REST API is that is self describable, in a sense, that it has a single entry point from which a generic client can automatically discover available resources and actions. APIs in the given examples are not like this, they require custom clients that are strongly coupled with an application. These are not REST APIs but RPC APIs.

<comment><USER16> > A key features of a REST API is that is self describable

How practical is that, in reality?

I know I've added the whole HATEOAS thing to my API and I am not sure if it just makes my IDs longer. Customers seem to hard-code the API entry points anyway. Everyone of course says "Oh, yeah this is cool" but when it comes to doing it given performance constraints, they don't want to start generating 10s of extra GET requests on startup to rediscover the API.

Now I can say "well not my problem" and that is what I say, except that looking back and I just don't see the practice match with the supposed theoretical advantages of the REST-ful interface.

Another issue I see happening, is the return of message bus like interface brought about by Websockets and server push optimizations it makes possible. I think REST and Websocket's channels/message bus architectures will have a battle at some point -- and one will end up dominating.

Just like AMQP is becoming a standard for message brokers, I think at some point that will be extended to the browser. Kind of like RabbitMQ has the web- STOMP plugins. I can see future hotness being just that -- message broker architecture all the way to the web client and everyone will laugh at REST-ful hype just like we are laughing at SOAP now.

<comment><USER15> It of course depends on the problem, no architecture is good for everything. REST has its cost, it usually requires more work and careful design then going RPC way, but for some kind of problems it can be really beneficial when done right.

Imagine you have a company that does custom mobile apps for external customers. A very popular topic, a lot of companies today want to have their own apps in addition to standard web pages.

Most of these apps are very similar (you can browse come content, purchase some service, etc.). Your company can go RPC way and create a custom interface and a custom client for each customer, with a lot of duplication and substantial maintenance cost. Or your can make larger upfront investment and create a generic REST client and then only design resources and representations for each new customer.

</comment></comment></comment><comment><USER17> All that these sorts of description produce is a low-level API. That can be useful, but what's really needed are high-level APIs that provide meaningful semnatics:

        my $me = Facebook->new( username => 'autarch' );
        $me->post_status("I'm on Hacker News writing this comment");

        my $friend = Facebook->new( username => 'imaginary' );
        $me->post_on_wall( $friend, "Hey buddy, I am on Hacker News writing this comment" );

<comment><USER18> Exactly. And this is what clients can provide over generic, one-size-fits-all solutions: fluent, idiomatic, and terse access to APIs.

<comment><USER17> Here's another way to phrase it. A good API is based on the data and actions related to a specific domain of knowledge. Generic solutions produce APIs that are oriented around the communications protocol (REST).

On the client side, I don't really care (too much) if something is a POST or PUT, I want to send a message or update a repository's metadata or share a photo.

</comment></comment></comment><comment><USER19> swagger (<http://developers.helloreverb.com/swagger/>) has been doing whats proposed here. By describing your APIs with swagger-spec you get a beautifully documented APIs, code generation of client libraries and some more stuff: <https://github.com/wordnik/swagger-core/wiki/Downloads>

</comment><comment><USER20> While this has some benefits, it seems like a slippery slope leading back to SOAP.

<comment> St-Clock Exactly. But to be precise, REST would be the equivalent of SOAP and the format described in this post would be equivalent to WSDL [1].

And then, we'll need a central location to store all of these API descriptors and UDDI [2] will be back with a vengeance.

[1] <http://www.w3.org/TR/wsdl>

[2] [http://en.wikipedia.org/wiki/Universal_Description_Discovery...](http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration)

<comment><USER21> When I see this post, the first thing to pop up is SOAP as well. Just that SOAP is not human-readable. Then I suddenly remembered that it wasn't SOAP itself that include the schema but the SOAP providers would generate WSDL alongside a SOAP endpoint.

</comment></comment></comment><comment><USER22> Hmmm....JSON documents (jsonSpec) describing the restful services is the new WSDL, feels like 2002 all over again.

I think too many people consume REST APIs in different manners, utilizing different data in unique relations. This is the beauty of it.

<comment><USER23> Well, to be fair, JSON is at least a lot less verbose than WSDL. So there's that.

<comment><USER24> WSDL describes a pact between a client and a server so they can't screw it up. Comparing WSDL to WADL would make sense. JSON just describes objects in compact notation. Comparing JSON to XML would make sense when XML is only used to describe objects and nothing more. WSDL and WADL and HTML are all XML derivatives. WSDL and WADL could never exist or HTML for that matter if trying to use JSON to describe them since that's not what JSON was designed for.

<comment><USER23> WSDL is an object notation for objects that describe what a web service should do. This could just as well be done in JSON. It would be marginally less verbose, too :-)

Oh, and it's perfectly feasible to translate a well formed HTML document into some sort of JSON object. After all, HTML is just a set of tags with values, no?

</comment></comment></comment></comment><comment><USER25> Hypermedia APIs are an approach to solve this problem. It essentially does what you did, and add some other benefits like de-coupling URIs.

<comment><USER7> Really? Seems to me like Hypermedia APIs should move the problem from the wire protocol to the application protocol?

Hypermedia says "oh yeah, here's some markup, look there are URIs in it". For a human user, we're like "cool, I'll try and click these, see what they do".

But software is going to want "um...okay, how to I parse this markup, and how do I generate the submissions you want? And, okay, you can change URIs, but please don't change anything else about that operation, or I will break completely. That's right, we're not really decoupled."

So, even with hypermedia APIs, AFAIK you're still going to want some marshaling to/from host language. ...and so you're back to having a spec, and coupling, you've just moved it around.

(Rant on coupling, people seem to think it's always bad and you can make it go away. Reality: you can't make it go away, and sometimes just accepting it directly is a whole lot simpler than deceiving ourselves about it's existence by over-applying abstractions.)

<comment><USER8> You're forgetting form-style affordance. For example, if you were using HTML as your media type, the equivalent of the first example would be

      <form method="get" action="/me">
        <input type="text" name="access_token" />
        <input type="text" name="fields" />
      </form>

> AFAIK you're still going to want some marshaling to/from host language.

Actually, you explicitly _don't_ want this. That's what hypermedia APIs are trying to remove.

<comment><USER7> We're replying to each other in separate comment threads :-), but this input form is still coupling--you can't add/remove/change the access_tokens/fields without clients breaking. Humans can handle that. Software can't.

That's why I think hypermedia makes all sorts of sense for explaining why the www is awesome--it change deal, users will adapt. But IMO it falls flat as some new paradigm for building client/server systems.

> Actually, you explicitly _don't_ want this. That's what hypermedia APIs are > trying to remove.

Hm? I am skeptical...any links/explanations?

<comment><USER8> Haha! Ping-pong!

> But IMO it falls flat as some new paradigm for building client/server > systems.

I know of one company which you've absolutely heard of who has a 30-person team building a hypermedia API. They haven't talked about it publicly because they see it as a strategic advantage.

This year will be the year of code and examples; last time I was in San Fransisco, 5 different startups came up to me and told me that hypermedia is solving their problems. Expect to see more of this going on soon.

> Hm? I am skeptical...any links/explanations?

Mike Amundsen's "Building Hypermedia APIs in HTML5 and Node" has a pretty big section on this, and my book has a section entitled "APIs should expose workflows."

I previously commented more about it here: <http://news.ycombinator.com/item?id=4951477>

RPC APIs expose functions, SOAP/"REST" APIs expose objects, hypermedia APIs expose processes.

</comment></comment></comment></comment></comment><comment><USER26> We've been experimenting with this at my office. We use yaml descriptions of all of our routes to generate test coverage. We plan to later generate our documentation and client libraries with the same docs.

Document-generated server behavior is something we're researching as well, to possibly represent business logic. We're hoping that patterns can be found and condensed into notations, like Regular Expressions do for string-parsing. We'll post about anything that we come up with.

One of my side projects us an Ajax library which allows javascript to respond to requests (LinkJS [1]). It has a helper object called the Navigator, which is like a miniature Web Agent. It retains a context, and uses the Link header from the response to populate the navigator with relations. It works out like this:

      var nav = Link.navigator('http://mysite.com');
      nav.collection('users').item('pfraze').getJson()
        .then(function(res) {
          console.log(res.body); // => { name:'pfraze', role:'admin' ...}
        })
        .except(function(err) {
          console.log(err.message); // => 404: not found
          console.log(err.response.status); // => 404
        });

The advantage is that the link header is a relatively condensed representation of the resource graph. As a result, it's not a problem to send it and process it every time. You do gain latency, but the internet is only getting faster, and caching can be used. Meanwhile, the server can rewire links without interrupting their clients.

1 <https://github.com/pfraze/linkjs>

</comment><comment><USER27> > This doesn't scale.

Most overused phrase right there.

</comment><comment><USER28> Isn't this what <http://json-schema.org> aims to provide? Or am I missing something. It's a solid spec.

<comment><USER7> Personally I'm partial to <http://jschema.org/> (also see <http://jschema.org/rpc.html>) because it seems simpler.

My naive impression is that JSON-Schema is trying to be just like XML Schema, but in JSON. Which doesn't seem like a good thing.

<comment><USER29> But neither of these are geared towards a RESTful implementation, unless I'm missing something.

</comment></comment></comment><comment><USER30> While I agree with the title, I am not so sure about the solution presented. HATEOAS, whether encoded in JSON or XML, can only give you so much information about the semantics of links.

IMHO, what's needed is better support for "generic" REST in programming languages and/or libraries. Objective-Smalltalk (<http://objective.st>) features "Polymorphic Identifiers", which make it possible to both interact directly and abstract over web interfaces.

To reference a URL, just write it down:

       news := http://news.ycombinator.com

Arguments can be added without string processing:

       #!/usr/local/bin/stsh
       #-zip:zipCode
       ref:http://zip.elevenbasetwo.com getWithArgs zip:zipCode

This is a file downloader, similar to curl:

       #!/usr/local/bin/stsh
       #-<void>scurl:<ref>urlref
       fileComponent := urlref url path lastPathComponent.
       file:{fileComponent} := urlref value.

For abstraction, you can build your own schemes, either directly in code or by composing/modifying other schemes. For example, if I want to look up RFCs, I can define the rfc scheme:

       scheme:rfc := ref:http://datatracker.ietf.org/doc asScheme

Or I can compose schemes so the rfc scheme looks in a bunch of different places (memory, local directoy, several http/ftp servers).

</comment><comment><USER31> Stop writing self-documenting API specs and settle on a hypermedia spec, like Hal or Siren! reply

<comment><USER32> I actually have no idea why the hal people aren't writing hal specifications for existing services right now--it's not quite as nice as "native" support, but the format supports it, and it would be useful to see what a hal version of the Twitter API looked like, for example.

<comment><USER8> hal is currently going through the ID -> RFC process, once it's an RFC, I'm sure you'll see stuff like this.

</comment></comment></comment><comment><USER33> This is essentially trying to solve the same problem as Swagger. Swagger is "a specification and complete framework implementation for describing, producing, consuming, and visualizing RESTful web services" [1]. Check out the spec on GitHub here [2].

[1]: <http://developers.helloreverb.com/swagger/>

[2]: <https://github.com/wordnik/swagger-core/wiki>

</comment><comment><USER34> There is a lot of talk about this idea being SOAP-like, but I disagree.

SOAP was insane and its counterpart, WSDL (which is really the part that is most comparable to this idea), was even more insane.

But, the basic premise was not bad. It was the execution which sucked by trying to account for every situation, adding namespaces, etc. And if you ever worked with language libs designed to interface with SOAP/WSDL, it would make you slap a bunny.

With this idea, however, adding an optional JSON-based descriptor language could be helpful. Key would be to keep it simple, allowing the bare mnimum number of data types, with one simple array structure for collections. Allow object definitions with an infinite number of nesting levels, and that would be it. I wouldn't even get into optional vs required stuff, validation, etc. That stuff should stay at the application level. Why stuff it into the interface layer?

From there, it would be easy to develop libraries to generate clients in any language for any API just by feeding it the JSON descriptor. Or (as I think the author intended) just use one universal client that any app can use. For languages that aren't strongly typed anyway, the latter would be fine.

Someone mentioned that it would require the server side devs to keep the descriptor in sync with the code. No biggie for apps that already offer client libs in different languages and must keep them up to date anyway. Not to mention there should be some doc that needs to be kept in sync (REST is not typically self documenting in reality).

In any event it wouldn't be required. What would be the harm in creating a standard for those apps that choose to use it?

</comment><comment><USER35> Can't we just stop writing clients for specific REST API:s period and rather just build one good API client that can easily be extended and adapted to any API?

That's the path I've been using in all projects lately - because frankly - <USER2> don't want to deal with a bunch of different API clients for Twitter, Facebook, Soundcloud, Instagram or whatever sites it is that I integrate with - all those different syntaxes and all that duplicated code etc doesn't help me - I want all of their individual differences hidden away for me and colleagues behind a single well known syntax which I myself can extend to expose the resources and methods that I need - like if I need it a method for posting a photo for the API:s that support that and so on.

My advice today would be: Pick a good HTTP client, preferably with good OAuth support, and then build your own extendable API-client on top of that and integrate all the different API-resources you need with that client whenever you need them.

</comment><comment><USER36> A client template library for REST API need to be Turing complete, otherwise it will be too weak to be able to handle complex services or complex client- side tasks, such as caching, dependency relations, data that span multiple services etc. Even if you make the template library simple, you'll need to wrap that with a layer of complex code. All you've done will be adding another layer on your code. You could re-design your code to fit a manageable design, but server side of the REST APIs are usually design by others whose priority is the code on the server side. So, by definition of the very task, the REST API client code have to be a complex soup where the client considerations mix up with those of the servers'.

</comment><comment><USER18> While I understand the allure of writing specs and using a unified library, good API clients are more terse, as they're written to take advantage of the programming language you're using, and understand the particulars and idioms of the API they're written against. For example, the client might pick up the correct environment variables for your API credentials, or reduce certain repetitive code.

Another example: I wrote a client that returns a queue message. Attached to that message are some helper methods for deleting, releasing, and touching the message. It makes your code cleaner and easier to understand.

</comment><comment><USER37> I think Google is already doing this using a form of JSON-Schema: <https://developers.google.com/discovery/>

</comment><comment><USER38> Given that the prevailing sentiment is that REST is self-describing and the API description doc is unnecessary, are there any examples of client generators that work directly off of a REST service?

I'm curious how this works in practice. What about authorization and parts of the API that are only available to certain users, does the client generator need to be authenticated? Are there standards for describing the meta-data associated with URLs (validation, optional parameters, etc.)?

</comment><comment><USER39> The article fails to mention the existing JSON Schema and JSON Hyper-Schema standards that he is advocating: <http://json-schema.org/>

Both are currently used by Google's public APIs to auto-generate clients. Ruby/Python clients load the schema docs at runtime and do method_missing magic, Java/.NET clients generate static typed libraries periodically.

</comment><comment><USER40> How about stop calling REST something that is not. You'll be surprised how many things it will solve.

</comment><comment><USER41> There is for example RestTemplate from Spring for Java/Android apps, which solves this problem.

[http://static.springsource.org/spring- android/docs/1.0.x/ref...](http://static.springsource.org/spring- android/docs/1.0.x/reference/html/rest-template.html)

</comment><comment><USER42> I've gone a step further and converted the JSON definition into JavaScript method calls: <https://github.com/olegp/restwrapper>

RPC FTW ;)

</comment><comment><USER43> Can someone please explain me why it doesn't scale ? True question.

<comment><USER44> The author means, "It is a lot of work", I think.

</comment></comment><comment><USER45> So we solve the problem of too many REST clients via another REST client? I agree with ttezel, and unio does look pretty cool, but I got a chuckle out of this :)

</comment><comment><USER46> I wrote a quick port to PHP that is installable via Composer. <https://github.com/andruu/unio-php>

</comment><comment><USER47> Yay, SOAP in JSON!

</comment><comment><USER48> Yeah, let's do CORBA once again. No thanks.

<comment><USER49> Well, it wouldn't be so bad if it were _universal_ enough, but we'd probably have to wrap it in some sort of inter-ORB protocol for the internet or something...

<comment><USER23> Yes it would. Because making it _universal_ enough makes it incredibly verbose and nasty to work with. JSON became popular because it was simpler than Web Services which became popular because it was simpler than CORBA which became popular because it was simpler than just talking over raw sockets using some sort of protocol ... oh, wait.

Actually _not_ having a "universal" spec helps: it forces every provider to give some thought to how to make his API as lean as possible. Hopefully.

</comment></comment></comment><comment><USER50> <https://github.com/dstufft/slumber>

</comment><comment><USER51> We need WSDL for REST to solve this problem. Then we could code generate clients.

</comment><comment><USER52> I like the idea. This is useful to generate stubs.

</comment><comment><USER53> so, define web services as a json file. JSON-SOAP?

</comment><comment><USER54> Ha. So, now we're back to SOAP and WSDL's.

</comment><comment><USER55> There it is: Zombie SOAP again!

</comment><comment><USER56> skeptical programmer is skeptical this could ever work.

</comment><comment><USER57> <http://xkcd.com/927/>

</comment><comment><USER58> I want to give you an idea of how bad things are with REST Api Client . This is a Maven POM for Google APIs for java web project that uses Google APIs for Profile, Drive and Oauth2. Its insane:

      <project xmlns="http://maven.apache.org/POM/4.0.0"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
      <modelVersion>4.0.0</modelVersion>
      <parent>
        <groupId>com.google</groupId>
        <artifactId>google</artifactId>
        <version>5</version>
      </parent>
      <groupId>com.google.api.client</groupId>
      <artifactId>google-plus-java-webapp-starter</artifactId>
      <packaging>war</packaging>
      <version>1.0.0</version>
      <name>google-plus-java-webapp-starter</name>
      <description>
        Web application example for the Google+ platform using JSON and OAuth 2
      </description>

      <url>https://code.google.com/p/google-plus-java-starter</url>

      <issueManagement>
        <system>code.google.com</system>
        <url>https://code.google.com/p/google-plus-java-starter/issues</url>
      </issueManagement>

      <inceptionYear>2011</inceptionYear>

      <prerequisites>
        <maven>2.0.9</maven>
      </prerequisites>

      <scm>
        <connection>
          scm:hg:https://hg.codespot.com/p/google-plus-java-starter/
        </connection>
        <developerConnection>
          scm:hg:https://hg.codespot.com/p/google-plus-java-starter/
        </developerConnection>
        <url>
          https://code.google.com/p/google-plus-java-starter/source/browse/
        </url>
      </scm>

      <developers>
        <developer>
          <id>jennymurphy</id>
          <name>Jennifer Murphy</name>
          <organization>Google</organization>
          <organizationUrl>http://www.google.com</organizationUrl>
          <roles>
            <role>owner</role>
            <role>developer</role>
          </roles>
          <timezone>-8</timezone>
        </developer>
      </developers>

      <repositories>
        <!--
            The repository for service specific Google client libraries. See
            http://code.google.com/p/google-api-java-client/wiki/APIs#Maven_support
            for more information
        -->
        <repository>
          <id>google-api-services</id>
          <url>http://mavenrepo.google-api-java-client.googlecode.com/hg</url>
        </repository>
        <repository>
          <id>google-api-services-drive</id>
          <url>http://google-api-client-libraries.appspot.com/mavenrepo</url>
        </repository>
      </repositories>

      <build>
        <plugins>
          <plugin>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>2.3.2</version>
            <configuration>
              <source>1.6</source>
              <target>1.6</target>
            </configuration>
          </plugin>
          <plugin>
            <groupId>org.mortbay.jetty</groupId>
            <artifactId>maven-jetty-plugin</artifactId>
            <configuration>
              <contextPath>/</contextPath>
              <systemProperties>
                <systemProperty>
                  <name>configurationPath</name>
                  <value>./src/main/resources/config.properties</value>
                </systemProperty>
              </systemProperties>
            </configuration>
          </plugin>
        </plugins>
        <finalName>${project.artifactId}-${project.version}</finalName>
      </build>
      <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <netbeans.hint.deploy.server>gfv3ee6</netbeans.hint.deploy.server>
        <project.http.version>1.13.1-beta</project.http.version>
        <project.oauth.version>1.13.1-beta</project.oauth.version>
        <webapi.version>6.0</webapi.version>
      </properties>
      <dependencies>
        <dependency>
          <groupId>com.google.guava</groupId>
          <artifactId>guava</artifactId>
          <version>13.0.1</version>
        </dependency>

     <dependency>
          <groupId>com.google.apis</groupId>
          <artifactId>google-api-services-drive</artifactId>
          <version>v2-rev53-1.13.2-beta</version>
        </dependency>
      <dependency>
          <!-- A generated library for Google+ APIs. Visit here for more info:
              http://code.google.com/p/google-api-java-client/wiki/APIs#Google+_API
          -->
          <groupId>com.google.apis</groupId>
          <artifactId>google-api-services-plus</artifactId>
          <version>v1-rev22-1.8.0-beta</version>
        </dependency>

       <dependency>
          <groupId>com.google.api-client</groupId>
          <artifactId>google-api-client</artifactId>
          <version>1.13.2-beta</version>
        </dependency>

      <dependency>
          <groupId>com.google.api-client</groupId>
          <artifactId>google-api-client-servlet</artifactId>
          <version>1.13.1-beta</version>
        </dependency>

        <dependency>

          <!-- The Google OAuth Java client. Visit here for more  info:
              http://code.google.com/p/google-oauth-java-client/
          -->

          <groupId>com.google.oauth-client</groupId>
          <artifactId>google-oauth-client</artifactId>
          <version>1.13.1-beta</version>
        </dependency>

        <dependency>
        	<groupId>com.google.oauth-client</groupId>
        	<artifactId>google-oauth-client-servlet</artifactId>
        	<version>1.13.1-beta</version>
        </dependency>

        <dependency>
        	<groupId>com.google.http-client</groupId>
        	<artifactId>google-http-client-gson</artifactId>
        	<version>1.13.1-beta</version>
        </dependency>

        <dependency>
        	<groupId>com.google.code.gson</groupId>
        	<artifactId>gson</artifactId>
        	<version>2.1</version>
        </dependency>

      <dependency>
         <groupId>com.google.http-client</groupId>
         <artifactId>google-http-client</artifactId>
         <version>1.13.1-beta</version>
       </dependency>

      <!-- Third party dependencies -->
        <dependency>
          <groupId>com.google.http-client</groupId>
          <artifactId>google-http-client-jackson2</artifactId>
          <version>1.13.1-beta</version>
        </dependency>

      <dependency>
            <groupId>javax</groupId>
            <artifactId>javaee-web-api</artifactId>
            <version>${webapi.version}</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
          <groupId>org.apache.commons</groupId>
          <artifactId>commons-lang3</artifactId>
          <version>3.0.1</version>
        </dependency>

      <dependency>
    	<groupId>commons-logging</groupId>
    	<artifactId>commons-logging</artifactId>
    	<version>1.1.1</version>
      </dependency>

     <dependency>
    	<groupId>org.apache.httpcomponents</groupId>
    	<artifactId>httpclient</artifactId>
    	<version>4.0.3</version>
      </dependency>

      <dependency>
    	<groupId>org.apache.httpcomponents</groupId>
    	<artifactId>httpcore</artifactId>
    	<version>4.0.1</version>
      </dependency>

      <dependency>
    	<groupId>org.codehaus.jackson</groupId>
    	<artifactId>jackson-core-asl</artifactId>
    	<version>1.9.4</version>
      </dependency>

      <dependency>
    	<groupId>javax.jdo</groupId>
    	<artifactId>jdo2-api</artifactId>
    	<version>2.3-eb</version>
      </dependency>

      <dependency>
    	<groupId>com.google.code.findbugs</groupId>
    	<artifactId>jsr305</artifactId>
    	<version>1.3.9</version>
      </dependency>

      <dependency>
    	<groupId>com.google.protobuf</groupId>
    	<artifactId>protobuf-java</artifactId>
    	<version>2.2.0</version>
      </dependency>

      <dependency>
    	<groupId>javax.transaction</groupId>
    	<artifactId>jta</artifactId>
    	<version>1.1</version>
      </dependency>

      <dependency>
    	<groupId>xpp3</groupId>
    	<artifactId>xpp3</artifactId>
    	<version>1.1.4c</version>
      </dependency>

      </dependencies>

      </project>

<comment><USER59> Can you stick that in a gist[1] so as to not mess up the HN comments?

[1] <https://gist.github.com/>

<comment><USER58> I realize now that cut-paste from my code into comment was a bad idea ; I wish I could edit this post -- but i am unable to do ( no edit link). Lesson learnt for next time.

</comment></comment></comment><comment><USER60> Nice idea!</comment>


Show HN: Tofu Growth (Deck Optimiser for Pitches) - <AUTHOR> http://tofugrowth.com/ <comment><AUTHOR> Side project I'm working on. Beta version with probably some bugs.

You upload a pdf You get a share link You get an analytics dashboard

Immediately which slides cause people to stop reading and which slides hold the most attention.

Looking for feedback firstname.lastname@example.com</comment>


Process kills developer passion - <AUTHOR> http://radar.oreilly.com/2011/05/process-kills-developer-passion.html

<comment><USER2> The sad thing is that he's right. I see it every day.

I work in a process-heavy shop in a process heavy industry and more and more, our developers are getting sick of it. But at the same time, our bug counts are dropping and our schedule accuracy is improving.

It would be an easy decision if all the process didn't accomplish anything, but the data shows that it does. The difficult part is isolating _which_ parts of the various processes are contributing the most, and scaling back the parts that don't. Unfortunately, if your management doesn't realize how irritated the developers are with all the data gathering and paperwork necessary to track the process, these drawbacks remain hidden until your best people start to leave in disgust.

Of course, you can ask the question if passion should even be relevant in software dev. and what its relationship is to product quality. A fantastically intuitive UI requires one type of personality and a "Can Never Fail" aircraft braking controller requires a different type. Should they use the same type of process?

</comment><comment><USER3> no, what kills developer's passion is not having a say in what/how processes are implemented/evolved. The other thing that kills developer's passion is being tangled into a web of improvisation, contradictions and general confusion because the processes were forgotten.

</comment><comment><USER4> The TV-series The Wire nailed this pretty well. In each season, members Baltimore's police department, school system, government are looking for ways to "juke the stats". Highly recommended as an analogy for process heavy software companies.</comment>


Show HN: Rely – Order your philz coffee using this bot - <AUTHOR> Hey Guys, We just launched a bot that pre-orders your coffee drinks for you. Would appreciate your feedback on this. You can use Rely here: https://m.me/relyai<p>Demo here: https://www.youtube.com/watch?v=IZGhDXMEY5I&t=1s <comment><USER2> Cool bot. I am Philz lover and love this idea.

<comment><AUTHOR> Thank you !</comment></comment>


To reduce inequality, abolish [subsidies to] Ivy League - <AUTHOR> http://www.usatoday.com/story/opinion/2015/11/01/glenn-reynolds-reduce-inequality-abolish-ivy-league-elitist-discrimination-column/74998648/ <comment><USER2> Totally one sided.

Talks about the "Obama administration", but doesn't bother to mention that Barack Obama himself graduated from Columbia University and from Harvard Law. Both Ivy League. He didn't pay his way, nor was he a "legacy" admission.</comment>


Introduction to Algorithms, Third Edition - <AUTHOR> http://mitpress.mit.edu/catalog/item/default.asp?ttype=2&tid=11866

<comment><USER2> I love this book. I bring it with me everywhere. Still it lacks a few things, for instance the compression algorithms are not cover well enough, and IMHO not including skip lists is a too big mistake as most of the times skip lists are as good as balanced trees but with a smaller memory footprint and simpler implementations.

Also bloom filters are not covered. There are too little real world hints. For instance things like collisions resolutions algorithms in the real world (with real CPUs): is chaining better than double hashing? And so forth.

</comment><comment><USER3> Same book for $30 less brand new at Amazon - [http://www.amazon.com/Introduction-Algorithms-Third- Thomas-C...](http://www.amazon.com/Introduction-Algorithms-Third-Thomas- Cormen/dp/0262033844/ref=sr_1_1?ie=UTF8&s=books&qid=1258419328&sr=8-1)

</comment><comment><USER4> I have read the changes in the available Preface PDF ([ _1_ ]), and wondered about the authors using MacDraw Pro for creating illustrations. What does HN use?

I used to create drawings using Visual Thought. Now for my technical TeX- documents I use InkScape. I would very well like to know if there are better tools out there...

[ _1_ ]: <http://mitpress.mit.edu/books/chapters/0262033844pref1.pdf>

<comment><USER5> I've been using OmniGraffle to prepare DFDs, flow charts, and UML diagrams for my thesis. The UI is very polished and easy to learn.

</comment></comment><comment><AUTHOR> Links to explanations of the professor jokes in the new edition here:

<http://mitpress.mit.edu/algorithms/profjokes3e.asp>

<comment><USER6> thanks for sharing. Those jokes also seem to apply to some of the homework problems encountered in the 2nd edition. I had no clue that Professor Bunyan was a reference to Paul Bunyan (<http://en.wikipedia.org/wiki/Paul_Bunyan>).

</comment></comment><comment><USER7> If I remember correctly, a big change is that the pseudocode more closely resembles syntax of modern languages.

<comment><USER8> Really? that sounds great. I've been working through the book in one of my classes this semester, and the pseudo-code drives me crazy sometimes: [http://blog.samwarmuth.com/post/246208606/in-what-cases- do-y...](http://blog.samwarmuth.com/post/246208606/in-what-cases-do-you-run- line-17)

overall, however, the book is great.

</comment></comment><comment><USER9> First AIMA, now this.

Today seems like the "3rd Edition of a computing classic" day: someone please post a link to new Essentials of Programming Languages, in its 3rd Edition :-)

<comment><USER10> <http://www.eopl3.com/>

</comment></comment><comment><USER11> I found Skiena's: [http://www.amazon.com/Algorithm-Design-Manual-Steve- Skiena/d...](http://www.amazon.com/Algorithm-Design-Manual-Steve- Skiena/dp/0387948600) to be much more readable, but Cormen's is still considered THE bible algorithms anyway.

</comment><comment><USER12> It's a great reference book, but I don't think it's a good text book. I had a lot of trouble trying to treat it as one and learn anything truly new from it -- for that, I turned to the book by Dasgupta et al and found it much more helpful.</comment>


For those late night hacking sessions. - <AUTHOR> http://www.soundintroversion.com/

<comment><AUTHOR> The 2014 Adelaide Festival presents Sound Introversion Radio.

During the entire festival you can seek sonic down-time and quiet listening experiences with your hosts Jason Sweeney and Yuri Tománek.

From the makers of Stereopublic: Crowdsourcing the Quiet (2013 Adelaide Festival; TEDPrize winner) Sound Introversion Radio is the second in a trilogy of 'quiet seeking' projects and is for lovers of ambient, glitch and slow- tronica.

This is your special calming sound portal during the frantic festival season.

Visit the custom-built radiophonic console designed by Dale Wright, listen online 24/7, attend live sets, download shows, contribute your own ambient music, discover 'pod satellites' around the city and tune in using your mobile device.

Slow motion listening for quiet minds.

Online from Monday 24 February www.soundintroversion.com

Visit the radiophonic console onsite at 'Level One' from Friday 28 February - 16 March 2014 260a Rundle Street, Adelaide

Discover the satellite pods from Friday 28 February: including Queen's Theatre, Adelaide Festival Centre foyer, Lola's Pergola, Urban Retreat (Adelaide City Council, Pirie Street) and the State Library of SA.

*Submit your ambient music to email@example.com

Director/Producer: Jason Sweeney Composers/Sound Artists: Jason Sweeney and Yuri Tománek Architect/Designer: Dale Wright Soundpond.net co-directors: Adam Daze and Todd Skipper

</comment><comment><USER2> Am I the only one who listens to dumb shit while I work?

0: [http://en.wikipedia.org/wiki/Based_on_a_T.R.U._Story](http://en.wikipedia.org/wiki/Based_on_a_T.R.U._Story)

</comment><comment><AUTHOR> If you prefer to listen in a dedicated app the stream link is [http://stream.soundintroversion.com:8000/stream_192](http://stream.soundintroversion.com:8000/stream_192)</comment>


Growth of Unpaid Internships May Be Illegal, Officials Say - <AUTHOR> http://www.nytimes.com/2010/04/03/business/03intern.html <comment><USER3> Federal law for unpaid interns in for-profit organizations requires that six criteria be met: (1) the work or training should function as an extension of the intern's educational training; (2) it should be provided primarily for the benefit of the intern; (3) it does not replace the work performed by regular employees; (4) it does not provide the employer with any immediate benefit; (5) it does not entitle the intern to employment at the end of the internship; and (6) there is no expectation by employer or intern that compensation will be paid for the work or training. To have a bona fide intern, _all six_ of the criteria need to be met.

State law may also impose additional requirements, as for example in California where the training must be part of an official educational curriculum at an accredited school - California imposes other restrictions as well.

All in all, the rules may be well-meaning but they effectively kill opportunities for students to get training in many situations where the employer would otherwise normally be glad to make the opportunities available. In practical terms, it means that an employer wanting to open opportunities to students needs to pay minimum wage at least. Of course, the idea of the regulations is to prevent employers from circumventing minimum wage rules by dressing up what is really a job as an "internship" and in this sense they serve a protective function.

Mark Cuban once did a piece entitled "Want an Unpaid Internship So You Can Get Valuable Experience - Screw You" ([http://blogmaverick.com/2009/09/05/want-an- unpaid-internship...](http://blogmaverick.com/2009/09/05/want-an-unpaid- internship-so-you-can-get-valuable-experience-screw-you/)) in which he recounted his frustrations in dealing with the federal regulations, and this in turn elicited an interesting and lively thread here at HN (<http://news.ycombinator.com/item?id=806563>).

<comment><USER4> In tech at least, I've always found the "valuable experience" argument to be a bit of a scam. There are plenty of companies that will be happy to pay you a _good_ stipend (not even anywhere near minimum wage) for an internship. If you want something less job-like, you can work informally with lots of smaller companies, visiting their office and doing odd jobs, essentially as an unpaid freelancer (e.g. find something crappy about their site and offer to fix it). But if they want someone coming in to the office 40 hrs/wk, with a boss and deliverables, they should be prepared to pay them in something more than vague promises of "valuable experience".

<comment><USER5> I, too, believe that most technology internships are a total scam. The usual phrase from a small company is that they want a 'rock star' ( insert your synonym here ) intern. I'm fairly certain that any 'rock star' intern can replace many hours of labor spent by an FTE.

To put it in some perspective, and this is all personal point of view, I believe that a company in three to four months of a full time internship should be able to teach a computer science student ruby, rails to a working knowledge extent, the why's and how's of why rails is the way it is (the ups and downs of MVC, convention over configuration, etc), limited database knowledge, and some basic UI/UX considerations.

Deeper knowledge into any of those (especially databases with CAP and the whole sql/nosql argument) would be valuable if there were any time remaining. And, obviously, the previous paragraph can be replaced by the equivalents in your specific niche.

EDIT: spelling

</comment></comment></comment><comment><USER6> There's a really good ('selfish') reason to properly put interns on payroll. A tech company that has an unpaid intern working on something 'useful' - <USER2> writing code - is in a terrible position. If the intern is ignorant, sure no problem. But what if that code makes it into a shipping product, or some other asset that's sold? And suddenly that person feels like they were screwed over because they were not paid? Or what if they get hurt at work, or are harassed and want to bring suit? Its already a risk with proper employees on payroll but at least you have insurances for that. Or perals - they file for unemployment and put your company down as their last employer with $0 pay. (Have any of you had to -really- deal with your local DoL? You'll -wish- it was the IRS!) This is a very bad position to be in. Isn't $10/hr worth it to avoid these problems?

</comment><comment><USER7> I was in the job market for the past few months and stumbled across postings where even certain well-known tech companies (startups can be considered as exceptions) were looking for unpaid interns. You could see smell their BS from a mile.

</comment><comment><USER8> This is an interesting turn of events.

Just 2 weeks ago when this story popped up on HN recommending unpaid interns (<http://news.ycombinator.com/item?id=1202168>) I thought it may have been legal, but now we know where the lawmakers stand.

<comment><USER9> When I was a student the first year of a UK law graduate's work in a practice (articles) was unpaid. This was necessary to keep the wrong sort of people out of the legal profession after they started letting anybody go to university in the 60s and 70s.

<comment><USER4> Yeah, this allegedly happens in some areas in the U.S. too, especially business and law--- unpaid internships as a way to filter out the poor, who can't afford to work unpaid internships.

<comment><USER10> It's not just business and law in the US. When I was a CS student in college (not very long ago), during the summer students had to make a choice to go do low-paying internships for brand-name companies like MS, Google, and Amazon or take real summer jobs that would pay better but not look as good on a resume. Poorer students with more debt would take the short-term better paying jobs while students whose parents were footing the bills would take the internships that would give them better future prospects.

<comment><USER11> What are you talking about? I interned at Microsoft for a summer 3 years ago and was compensated almost 20k... Low paying my ass.

<comment><USER4> Yeah, in my experience it's always been the opposite: internships from companies like Google, Microsoft, and Intel are about the highest-paying summer jobs (~$30-50/hr) any college student is likely to find, versus "normal" summer jobs that pay more like ~$15/hr at best. When I decided to do a $5k-stipend research internship instead of working somewhere like that, it was turning down a good deal of money.

<comment><USER12> My upcoming Microsoft internship is more than $5k a month. My summer NSF REU last year was $3k _total_.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> No problem, register the internships as training courses and charge the little idiots/candidates for working there

<comment><USER13> In our town someone made a business of that, starting a technical and vocational training school many years ago. They're doing quite well trading knowledge and experience for money.

</comment></comment><comment><USER14> Ugh. What possible good could it do to outlaw unpaid internships? Do people actually think the result will be companies deciding to pay interns rather than just not offering internships?

Just put yourself in the position of a manager making the hiring decision - suddenly you get word that you may be sued for offering unpaid positions, is your reaction going to be "wow, we'd better pay them" or "ok, no more interns."

Who does this kind of crap benefit, other than self-serving politicians masquerading as defenders of the public good?

Something about laws explicitly framed to protect people from themselves (i.e. students from accepting unpaid positions) drive me insane.

<comment><USER15> _rather than just not offering internships?_

And then, after a little while, it becomes impractical to insist on prior experience for entry-level positions.

</comment></comment><comment><USER16> The problem is that large, macroscopically psychopathic corporations (including universities) have complete control over access to most of the jobs out there, and so they can dangle "experience" (access) as a carrot that can be offered as a sole reward to the desperate masses.

</comment><comment><USER17> Doesn't "Growth of Unpaid Internships May Be Illegal" mean it's legal not to pay interns, but illegal for them to grow up?

<comment><USER18> If anything, I'd say it technically means "it was legal when they were rarer, but now that they're becoming more common, it's illegal" as it's the growth of unpaid intern _ships_ , not of unpaid _interns_ , that may be illegal.

They were trying to fit the fact that unpaid internships may be illegal and the fact that they've been growing all into one title, and it didn't work so well.

But splitting hairs a) is kind of annoying, and b) doesn't add anything to the conversation about the content of the piece.</comment></comment>


Using OAuth for a simple command line script to access Google's data - <AUTHOR> https://martinfowler.com/articles/command-line-google.html <comment><USER2> The next time you need to do something like this, take a look at [https://github.com/openid/AppAuth-JS](https://github.com/openid/AppAuth-JS).

Here is an example which uses Node, and obtains your access tokens. ([https://github.com/openid/AppAuth- JS/blob/master/src/node_ap...](https://github.com/openid/AppAuth- JS/blob/master/src/node_app/index.ts))

Once you have that - you can make any API requests by using the correct Authorization headers.

<comment><USER3> The author wanted to use Ruby. JS is out of context here

<comment><USER4> I think he meant as existing code you can pattern off of, not for direct inclusion.

The OAuth 2.0 Playground at [https://developers.google.com/oauthplayground/](https://developers.google.com/oauthplayground/) is another good resource for understanding refresh tokens and access tokens and how to get / exchange them.</comment></comment></comment>


Try RethinkDB: How we did it - <AUTHOR> http://nick.stinemat.es/#rethink-docker-technology

<comment><USER2> There are a lot of really cool tricks in this post for deploying Docker in a "real-life" installation, including disk quota, service orchestration, and dynamically routing traffic to your containers. A great example of how to take advantage of Docker's flexibility.

The rest of Nick's blog is worth a look too! Great stuff.

</comment><comment><AUTHOR> Hello, blog author here. I'm here to answer any questions or to address anything ambiguous in the post.

<comment><USER3> What sort of experience do you have with RethinkDB? Have you used it in production?

<comment><USER4> I'd also like to hear someone's experience with RethinkDB. The admin interface is fantastic.

<comment><USER5> slava @ rethink here. There are dozens of production projects built on top of Rethink. We're in the process of working with the customers to publish case studies (rough ETA on this is end of summer).

FYI, here's a list of things to do before we label Rethink production-ready: [https://github.com/rethinkdb/rethinkdb/issues/1174](https://github.com/rethinkdb/rethinkdb/issues/1174) (though Rethink is already really good for doing real work).

</comment></comment></comment></comment><comment><USER5> slava @ rethink here. Nick @ dotcloud did phenomenal work with getting this project off the ground, so I'm here to answer any questions about RethinkDB while Nick will be covering Docker questions.

<comment><USER6> Is RethinkDB suitable for CRUD applications?

<comment><USER7> RethinkDB has an API that's very capable of doing CRUD operations (and a lot more). Probably the only way it could not fill your CRUD needs is if you didn't like the ways you can access it. We have official drivers for Python, Ruby and Javascript and community drivers for a whole bunch of other languages.</comment></comment></comment>


Google stands up for Gmail users, requires cops to get a warrant - <AUTHOR> http://arstechnica.com/tech-policy/2013/01/google-stands-up-for-gmail-users-requires-cops-to-get-a-warrant/ <comment><USER2> I wonder if Microsoft does the same with Skype, but I wouldn't bet on it. It would be great if they tried to be as open with government requests as Google is, though.</comment>


PostgreSQL: Linux VS Windows [Benchmark] - <AUTHOR> http://www.sqig.net/2016/01/postgresql-linux-vs-windows.html <comment><USER2> Skipping to the end:

> Moreover, the differences aren't statistically significant IMHO, but you > could always debate.

> With those results, I won't say that PostgreSQL on one OS is faster than on > the other.

And, to answer my own request, I won't advise my client to migrate to Linux because of PostgreSQL performance. (You could argue that there are more tools for PostgreSQL on Linux than on Windows but that was not the point here)

> For me, PostgreSQL performance on Windows is not better nor worst, it's at > par with Linux !

> All the results are available on my github.

<comment><USER3> There are a lot debates about this and from my experience the biggest issue with running PostgreSQL on Windows is the "Windows Tax": background processes and services you don't need on a DB server soaking up resources. Windows Update comes to mind.

</comment></comment><comment><USER4> "Well the brilliant PostgreSQL developer created a system for windows that emulates the fork ... with threads !"

Err, no. Backends/sessions in postgres are their own processes, even on windows. There's a signal handling emulation thread for each of those, but that's a fairly minor detail.

The benchmark is also for a very small table, and performs only trivial queries. To me it looks it's mainly bemcharking the OS's context switch behaviour.</comment>


Dash adds DIY widgets to free accounts - <AUTHOR> https://www.thedash.com/news/2014-01-27-do-it-yourself

<comment><USER2> What's Dash's pricing like?

<comment><AUTHOR> The free account gives you one private dashboard and unlimited public dashboards. Pro accounts are $10 per month for unlimited private and public dashboards.</comment></comment>


Is Silicon valley is loosing its mojo? - <AUTHOR> http://www.kernelmag.com/comment/column/2423/eating-silicon-valleys-lunch/

<comment><USER2> I haven't lived/worked in the Bay Area for two years so hard to gauge mojo levels though I'll take the writer's word for it. However, I'm not convinced on Europe at least from my perspective as a self-funding entrepreneur living in Spain. There are a lot of incubators but funding still remains tight while funding in Silicon Valley is flowing. So what? The writer is talking about innovation. True, though without funding I believe most innovative companies that are taking big risk in Europe will die from funding starvation while in Silicon Valley, superstar innovative companies will find funding even if it is among a hundred copycats.

</comment><comment><USER3> I don´t know how is Silicon Valley because I never have the opportunity but I really think that in Spain or England is doing a great job and there is a really talented but lack the most important: investors (at least in Spain). Great Article!</comment>


Minefold (YC W12) Launches Affordable, On-Demand Platform For Game Hosting - <AUTHOR> http://techcrunch.com/2012/03/12/minefold-launch/

<comment><USER2> I've run servers for friends and I only see one huge problem: 90% of my friends wouldn't pay for a Minecraft server. They play, but it's just not how my servers ran. I paid for it, and a few others who understood what I did and what it cost, would help as well.

But 90-95% of my players were not paying members. They were great people and I loved having them on my server. I wouldn't kick them or demand they pay in an instant. But they weren't paying players. They were casual players, friends and friends of friends.

This model forces all of your friends to pay, instead of just a few.

If I sent this server to my friends, and they found out they had to sign up to play (or only get 10 hours free a month), they likely wouldn't make my server their home. They might come and play, but they won't make it their home. They're not paying players.

I wish these guys luck and the best but I will tell you right now, most servers don't have an everyone-pays system. Even the big servers and themed servers, the 100+ servers, most of them have rewards and incentives for paying, but few require payment up front.

This seems to fly in the face of the realities of this industry. I wish them the best but I imagine that this is going to be a constant source of background issues until they open up an option to let one person subsidize the cost of a single game world so there can be free players (unlimited hours) on it.

EDIT: No bukkit support? Only vanilla servers? That's rough, all of the big and popular servers run Bukkit, and every server I've run uses Bukkit. There's not even any coherent anti-griefing or administration tools in vanilla! Hopefully this is a huge priority.

<comment><USER3> We recognized that problem pretty early on. Some of our favorite customers have been teachers using Minecraft in their classrooms and in cases like that having one person paying makes total sense. Working on it! We decided to launch with individual accounts first because that's what made most sense for us and our friends.

Regarding Bukkit, we've been holding off support because of this: <http://www.mojang.com/2012/02/minecraft-team-strengthened> It's running in beta but the real value of Bukkit is being able to use mods. We're working on an experience that lets people enjoy mods without having to handcraft massive YAML files or run up SQL databases.

<comment><USER4> This looks great, I'm really excited for what the future holds for Minefold. I am all too familiar with difficulty of setup and maintenance of Minecraft servers, and if you guys can make it painless I think a lot of people will be interested.

However, I must caution against going to far on the side of simplicity. There are plenty of server hosts out there which lock you in to fixed configurations and do not support all the possibilities of what can be achieved with Minecraft. Most hosts have an option for Bukkit, but those that do occasionally limit the plugins you can run or do not allow modifications to the CraftBukkit server itself.

I recently ran into this problem when setting up my own experimental hardcore post-apocalyptic server, heavily modded to significantly enhance the gameplay experience. I looked around at several hosts, but not all of them could support the server I wanted to run. For example, Multiplay supports Bukkit but doesn't let you run a "modded" Bukkit server. To run exphc I needed to mod the CraftBukkit jar file itself, installing the required ModLoaderMP and MinecraftForge APIs to support Buildcraft, IndustrialCraft^2, RedPower2, and the handful of other mods depending on these APIs. Not all gaming-specific hosts allow this, so I went with a VDS.

Furthermore, there are other modded CraftBukkit servers out there like CraftBukkit++, and I hear the fine folks behind MC Port Central (who brought the BC/IC2/RP2 mods to Bukkit, among others) are working on their own fork, incorporating ML and Forge into the server itself. Hosts that only let you run CraftBukkit "recommended builds" miss out on all these interesting and powerful new Minecraft server configurations, pushing the limit of what is possible in Minecraft, beyond what can be achieved using Bukkit plugins alone.

Not to mention, plugins like Hawkeye require the use of a MySQL database, and are widely considered essential for any public server, in order to have a record of and rollback malicious player actions, from cheating or other rule violations. And some of the best and most innovative servers in my opinion, such as hcsmp, have their own website tightly integrated with the Minecraft server, providing real-time updates: logging player statistics, processing donation payments, or even displaying a dynamic map of the world and all player locations.

Of course, if you are targeting small servers, setup amongst friends, much of this is less important. But I'd still argue support for "mods" proper is crucial, as opposed to mere Bukkit plugins. Once I started playing with jetpacks and quarries and airplanes and other advanced technology, I realized, I couldn't go back to vanilla Minecraft. If you guys can crack the nut of setting up an optimally-configured modded Minecraft server, taking out the tedium of resolving block ID conflicts and world protection and backups and updates and incompatibilities, of messing with confusing YAML configuration files or executing SQL or console or shell commands, of downloading mods from adfly and unzipping and extracting and reorganizing the files properly, just to get up and running before you can play the game – I believe you will succeed. Getting set up properly is the biggest impediment for gamers to experience what Minecraft truly has to offer, but it is a completely solvable problem. I wish you the best of luck.

<comment><AUTHOR> Hey, I'd love to talk more about this in detail if you're interested!

Mind sending an email to email@example.com?

</comment></comment></comment></comment><comment><USER5> This is a wonderful business and I really think they will go places. Minecraft servers are a huge part of the game, looking at our statistics for the servers section on the Minecraft forum it's clear there are _millions_ of people trying to find a place to play every month, if Minefold can convert 10% of those to paying players they're going to do extremely well.

I was at Minecon (Minecraft Convention, Vegas November 2011) and while sat at a table with one of the Mojang employees I listened to a father and his son explain how managing a Minecraft server was hard work and they wish that Minecraft would have some sort of "simple" system for it; login and play. No screwing around with finding a company then managing a server and dealing with issues, just pay -> play. Minefold is what he described.

congrats on the (full) launch, marketed properly this service could easily capture 90% of the casual Minecraft players market. There will always be people who want full control over their Multiplayer experience and they are catered to by (quite literally) hundreds of companies, Minefold is the first company I've seen that that properly caters to casual players.

</comment><comment><USER6> I wish these guys could become Official Trusted Server Providers for games like Battlefield 3 -- there's a (commercial and technical) process required to get approved.

I'd host my own servers otherwise, but I'm obviously in the minority. I _can't_ host my own BF3 servers, so I'd love a service which let me do so.

Figuring out how to do in-game server creation and signup would be even better, maybe as a revshare partnership with the game publishers or developers.

In general focusing on games where the server is needed for fair play, and people who play with strangers, seems like it could be viable. I'd be unlikely to trust someone else's server to not be hacked (although most hacks are client side, there's stuff you can do on the server too).

Maybe integrating some nice voting, voice chat (STILL a weak area on pc gaming vs. xbox360), ladders/ranking, training/clan servers, etc. would make sense, as soon as you leave the Minecraft specific world.

The next step after that is making MMO-type persistence and maybe selling items even easier for small game developers; an alternative to EA or Steam for self-distributed games? Or things which Steam doesn't provide.

<comment><USER7> I'm actually working on my Senior Project right now that aims (no pun intended) to do this. Minefold may venture outwards from Minecraft but I'm targeting CS:GO and BF3 directly. :)

</comment></comment><comment><USER8> Wow. This is great. You guys make it so easy! The business model itself is quite interesting. Considering that each person pays for hours, are there any features down the line to add features that enhance community features?

I play on a small server with friends (which is cheaper than minefold atm), so at the moment I'm primarily looking at what value you can add by adding onto the ability for you guys to easily connect people, create maps, etc.

A few examples: Make it easier to categorise worlds that I might to join. For example, some servers are just creative, others are PvP, some can be survival, or others flat. Another option could be to be able to 'block' worlds (no more destroying/creation) so that anyone can jump in and run around words that people have created without asking for permission (thinking about the massive lotr one). Or, for example, making it easy to find spleef arenas for the occasional fun.

Being able to tag worlds is a simple start.

Best of luck guys. You guys have got something good going!

<comment><USER3> Tags are a great suggestion. I was originally thinking of just showing individual properties (creative, flat etc.) but tags are much flexible. We've been thinking a lot about "discovery" of Minecraft worlds and tags seem like a great Web 2.0 solution!

I've also been working for the last little while on "public" worlds where anybody can join. Spleef arenas are coming soon!

</comment></comment><comment><AUTHOR> Hey HN, dave from Minefold here. Would love any feedback and happy to answer any questions about our service you might have.

<comment><USER9> Based on the FAQ, I'm going to guess that you might be thinking about this already, but you need gift cards! I would throw $100 at this right now to allow my broke college student brother and I to play for the next year without having to convince him to pay.

Secondly, can you export your world data if you chose to leave?

<comment><USER3> $100? Send an email to email@example.com and we'll work something out :P

Re data export: absolutely. It's not automated at the moment but shoot us an email anytime you want a data snapshot.

<comment><USER9> That's awesome. Not sure if you were serious, emailed you anyway.

</comment></comment></comment></comment><comment><USER10> A friend (at BioWare) and I are cracking up, because we had considered the idea of doing EC2-based hosting of Minecraft (and Terraria) servers about 6 months ago. We ran an SMP server for a while, doing lots of performance testing and profiling.

However, we just couldn't see how we could get our margins to where they'd be worthwhile without raising the price of a hosted server to the point where it'd scare off potential customers. Low margins + a fair amount of customer support = something I didn't want to consider.

Kudos to someone putting the thought into that and solving the margin issue, spreading the per EC2-instance income over a much larger pool of people and raising the overall revenue-per-server.

In the meantime, I have other crazy ideas I'm working on while I try to line up a new day job. Good luck with this one!

<comment><USER11> I remember sitting with Chris at a SydJS meetup nearly a year ago and overhearing his plans for minefold. At the time they'd already written a bunch of code but were still very much in "stealth mode". At the time I was blown away by how much thought they'd put into the idea and have eagerly followed the development of it since.

</comment></comment><comment><USER12> So has the pay by the hour model been completely replaced by Minefold PRO? The reason I am asking is that I see <https://twitter.com/#!/qrush/status/117244523083595776> on the pricing page and I remember seeing this in the past here on HN and the pricing model was different.

<comment><AUTHOR> Paying by the hour was proving to be too confusing. We'd rather get people to pay for features and added value, so we moved to a much simpler pricing model!

</comment></comment><comment><USER13> At first I frowned a bit at the no Bukkit support, until I remembered that all of those guys have recently been hired by Mojang :) Eventually the stock server should be just as awesome with super modding support.

Until then, I'm way too tweak-happy and authoritarian to give up my own server.

Looks like a great service for people who just want click and go simplicity though.

<comment><USER3> We hear you dogg! Plugins are a priority. We're working on an way for people to install and configure plugins that doesn't involve hand editing YAML. The Bukkit team moving to Mojang is only going to make this easier!

</comment></comment><comment><USER14> This is awesome. I ran my own server for several months for a bunch of 10 year olds. But it was a pain in the butt. Keeping it up, paying the bills and so forth. Minefold solves the problem brilliantly.

The kids (or their parents) each pay their own way, they can choose to pay (and play) as much, or as little as they want. Dave and Chris have been fantastic and the service is continually improving.

I wish them well, it's solving a real problem for me and every parent I've introduced to the service has had no problems paying for their kids to use it.

The other thing I've noticed is that the kids love cloning servers too, so they can easily find maps they like, clone it then blow it up without needing to be invited.

I discovered the service here a few weeks back and I've been using it ever since, great to see them launch now into the "wild" as well.

</comment><comment><USER15> Very nice! I built a demo of simple, pay-by-the-hour minecraft servers about a year ago but never launched. Lately I've been thinking about resurrecting that project. I guess now there's some competition.

Its pretty clear that previous solutions weren't simple enough for casual users. There are plenty of people who have no idea what RAM is but who would love to have their own worlds that their friends can join. I think the world sharing aspect is a big part of this and you guys have hit the nail on the head. Well done and good luck!

</comment><comment><USER16> Looks pretty cool!

Are the prices missing from the pricing page, <https://minefold.com/pricing>? Based on the Upgrade to Pro page I think it is $25 for 6 months for unlimited access.

I like the idea, and the distributed pricing mechanism is definitely interesting.

I'll be uploading my latest world shortly after I get off work :)

<comment><USER16> The pricing not showing up appears to be a Chrome issue (at least for me).

<comment><USER17> I'm also not seeing the pricing in Chrome 17 on Windows 7.

</comment></comment></comment><comment><USER18> Is this really a problem? I mean ... there are tons of gaming-server providers out there offering minecraft hosting (with unlimtied playtime ofcourse). the only new thing i see is the forced bill split. am i missing something?

</comment><comment><USER19> I am not a regular minecraft player, but I tried it because it took me 10 seconds to sign up. I think Minefold could cause a big jump in the number of people playing these online multiplayer games.

</comment><comment><USER20> This is actually a great idea, many gamers I know who don't work in IT are dumbfounded by all the hoops they have to go through just to get a server up and running, let alone maintenance.

</comment><comment><USER21> Your service looks very cool, but your logo is fantastic! Did you guys design it yourselves, or did you hire someone?

<comment><USER3> Thanks! The very awesome @themaninblue (<http://fluent.io>) made it as a surprise gift to us one night :)

</comment></comment><comment><USER22> Excellent idea and love the brand. Always great to hear about fellow aussies kicking butt.

</comment><comment><USER23> Loving this... has made playing Minecraft so much easier! The site is hot too!</comment>