OpenSSL Security Advisory - <AUTHOR> http://openssl.org/news/secadv_20150709.txt <comment><USER2> _> OpenSSL will attempt to find an alternative certificate chain if the first attempt to build such a chain fails_

I think the latest big thing I've learned in my career is that trying to fix broken input data silently is always bad. Fixing stuff silently isn't helpful for the callers, it's very difficult to do and it produces additional code which also isn't running in the normal case, so it's much more likely to be broken.

Additionally, your callers will start to depend on your behaviour and suddenly you have what amounts to two separate implementations in your code.

I learned that while blowing up (though don't call exit if you're a library. Please.) is initially annoying for callers, in the end, it will be better for you and your callers because code will be testable, correct and more secure (because there's less of it)

<comment><USER3> This seems to be a common opinion recently, see [https://tools.ietf.org/html/draft-thomson-postel-was- wrong-0...](https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00)

<comment><USER4> But Jon Postel didn't mean what people now think he did.

His famous principle is about border cases, when the spec is vague, handwavy or thought by some to be vague. It's not about the other cases.

Remember that Jon Postel was _the_ RFC editor. He didn't want anyone to ignore the RFCs, he wanted the RFCs to be readable and pleasant, and he wanted implementers to do the right thing when when an RFC erred on the side of readability.

FWIW I wrote a blog post about this a few years ago, [http://rant.gulbrandsen.priv.no/postel- principle](http://rant.gulbrandsen.priv.no/postel-principle)

<comment><USER5> Here's an example of the problem with that though: a mailing[0] by someone in February of _this year_ asking if there's a formal grammar for the DNS zone (master) file format. This is a format that was first loosely specified in a RFC almost _32 years ago_ and there still isn't a rigorous definition. BIND now specifies a defacto interpretation with lots of liberal "treat this as a warning" options[1] and new gTLDs registries now insist on a subset of the original specification.

HTTP also has corner cases that widely-used implementations simply aren't handling _consistently_ because the original RFCs are vague or the ideas being conveyed are buried in even older RFCs that nobody has the incentive to drill in to, or simply aren't known to them.

IMHO the IETF really should move to a wiki format, where information and wording changes on a particular protocol can be seen in one place. Plaintext snapshots of particular versions could still be published.

[0] [https://www.ietf.org/mail- archive/web/dnsop/current/msg13349...](https://www.ietf.org/mail- archive/web/dnsop/current/msg13349.html)

[1] [https://kea.isc.org/wiki/ZoneLoadingRequirements#a3.3RFCimpl...](https://kea.isc.org/wiki/ZoneLoadingRequirements#a3.3RFCimplementationrequirements:parsing)

<comment><USER4> BTW there's a reason for that. The IETF decided (it must be a couple of decades ago) to restrict itself to matters of the internet. Things like file formats are thus out of scope for RFCs. There have been exceptions, RFC5952 is a good example and I know at least two others, but by and large RFCs are about the internet now, not about file formats or other worthy subjects.

<comment><USER6> RFC 6120 and 6121 are for XMPP (chat), and define XML is to be used, and even goes into the exact structure of the XML "packets".

<comment><USER7> Bad example. XML is the wire format in XMPP RFCs, not a file format.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I am hardly astonished that a 319-line function that opens by declaring x, xtmp, xtmp2, chain_ss, bad_chain, param, depth, i, ok, num, j, retry, cb, and sktmp variables had a bug.

Before someone provides the standard "submit a patch" retort, I'll note that the variable naming is in full compliance with [https://www.openssl.org/about/codingstyle.txt](https://www.openssl.org/about/codingstyle.txt) even if the function length isn't. A quick sample of other files suggests the function length matches actual practice elsewhere, too.

<comment><USER9> You seriously have trouble reading "i", "j", "param" and "num"? Hell, "ok", "depth" and "retry" are already in your English-language dictionary!

I'll grant that having variables named with "tmp" is confusing out of context, I guess. But if you're trying to start a Java-style war over this stuff, just recognize that most of the world has moved on and views names like those as perfectly fine when used within standard idioms.

<comment><USER8> I have trouble understanding what they're meant to signify, yes. I am a regular human with finite intellect; I admit it.

To actually comprehend this function requires storing those 14 names in short- term memory, reading through the over 300 lines of remaining code, filling in bits of the meaning of those names as they become clear, and only then reading the code again with that mental map. That's the case where none of the 14 have slipped my mind by the time I get back around. That just seems like an awful lot of overhead to net something that could be as easy as reading names if they were better chosen.

Just as a demonstration, why don't you time how long it takes you to figure out what j actually is and then report back?

<comment><USER10> I don't know the codebase, but if for example, there's a project wide standard or convention for what the variable _j_ means, then it could be OK. Or at least not as bad as it first appears. Not all code has to be written for an assumed stranger on the street trying to sight-read it.

<comment><USER11> This is _OpenSSL_ we're talking aboot here.

</comment></comment></comment></comment></comment><comment><USER12> Interesting part is that the bug was introduced in the latest versions and has been fixed by the person who inserted it :-)

Bug added: [https://github.com/openssl/openssl/commit/da084a5ec6cebd67ae...](https://github.com/openssl/openssl/commit/da084a5ec6cebd67ae27f2463ebe4a50bb840fa5)

Bug removed: [https://github.com/openssl/openssl/commit/2aacec8f4a5ba1b365...](https://github.com/openssl/openssl/commit/2aacec8f4a5ba1b365620a7b17fcce311ada93ad)

Although that's just the committer: [https://twitter.com/agl__/status/619129579580469248](https://twitter.com/agl__/status/619129579580469248)

<comment><USER13> Looking at the changes that introduced the bug, it's obvious that the nature of the problems being solved is too complex for the changes to be only "visually" reviewed. There must be enough external tests to "uncover" the potential issues. And the tests of course can have the bugs too, not covering what needed to be covered. That's why for so sensitive code the testers should be the best programmers with additional preference to search for the combinations that don't work as intended.

<comment><USER14> You're confused. This thread is about OpenSSL. OpenSSL doesn't have tests.

<comment><USER13> Even if doesn't have tests at the moment that doesn't mean that it should always remain that way.

</comment></comment></comment></comment><comment><USER13> We probably don't need to worry this time:

[https://ma.ttias.be/openssl-cve-2015-1793-man-middle- attack/](https://ma.ttias.be/openssl-cve-2015-1793-man-middle-attack/)

"The vulnerability appears to _exist only in OpenSSL releases that happened in June 2015 and later._ That leaves a lot of Linux distributions relatively safe, since they haven't gotten an OpenSSL update in a while.

Red Hat, CentOS and Ubuntu appear to be _entirely unaffected_ by this vulnerability, since they had no OpenSSL updates since June 2015."

<comment><USER15> Christ, what a mess of a project. They inserted this after their big promise to do better after heartbleed?

No wonder distros take their time moving to a new version. I really hope one of the alternative SSL libraries get picked up by the major distros. This is embarrassing, especially for those of us who have to justify FOSS in our environment.

LibreSSL looks promising. Hopefully competition will mean better outcomes for such critical libraries.

<comment><USER6> You can't be serious here? Bugs are introduced into software all the time. It's a sign of active development.

It's not the number of bugs that matters, or even the fact that new bugs get introduced over time - rather it's the severity of the bugs, how rapidly the bugs are realized, and ultimately how fast they are dealt with.

In this case, it appears to have been a pretty rapid resolution - ie. about 1 month from it being introduced, realized, and fixed.

A lot of folks like to lean on LibreSSL and cite "supposed problems" with OpenSSL, just as you have done now. This is a naive approach -- LibreSSL took OpenSSL, cannibalized and gutted it, and all sorts of new, untested, un-vetted code injected. OpenSSL was written largely by crypto specialists, where LibreSSL is mostly a bunch of grumbling developers, with little to no prior crypto experience.

There's a reason the world is not jumping on LibreSSL just yet. There's a reason foundations outside of the LibreSSL home (OpenBSD) such as the Core Infrastructure Foundation have not backed it -- it's simply not ready, is very unproven, and won't be for a long, long time, if ever.

Give OpenSSL a break. It works far better than nay-sayers want to let on, and has done so for almost 2 decades.

<comment><USER16> The OpenBSD guys have little to no prior crypto experience? Can you prove this?

<comment><USER17> I mean, OpenSSH is such a piece of buggy garbage... /s

<comment><USER18> I once worked with some Linux admins who told me that SSH public key authentication wasn't secure.

<comment><USER19> While that's certainly possible, it's an extraordinary claim because it flies in the face of generally accepted beliefs. If your coworker was Bruce Schneier, I would pay close attention to his explanation. If they were your standard issue sysadmin types, then I'd want to know:

1) Why they believe so,

2) Why they haven't filed security advisories to advise the rest of us, and

3) Why you don't hear about banks being wiped clean because crackers were able to bypass SSH's security measures.

It's possible they're right, but as with all extraordinary claims, the onus of proof is on the ones making them.

<comment><USER18> 1) Wouldn't tell us

2) I tried to explain millions of people around the world rely on it and use it. I argue it's probably safe (within reason - obviously the weak point is the private key file).

These were also the guys who refused to install packages we asked for from the community RedHat repository claiming security vulnerabilities but then they just admitted they installed some packages from there for their own use for puppet and other things they do.

<comment><USER19> So... the standard issue sysadmin types. Sigh. :-(

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> from test/verify_extra_test.c:

        Test for CVE-2015-1793 (Alternate Chains Certificate Forgery)

        Chain is as follows:

        rootCA (self-signed)
          |
        interCA
          |
        subinterCA       subinterCA (self-signed)
          |                   |
        leaf </comment><comment></comment><comment></comment><comment>
          |
        bad

        rootCA, interCA, subinterCA, subinterCA (ss) all have CA=TRUE
        leaf and bad have CA=FALSE

        subinterCA and subinterCA (ss) have the same subject name and keys

        interCA (but not rootCA) and subinterCA (ss) are in the trusted store
        (roots.pem)
        leaf and subinterCA are in the untrusted list (untrusted.pem)
        bad is the certificate being verified (bad.pem)

        Versions vulnerable to CVE-2015-1793 will fail to detect that leaf has
        CA=FALSE, and will therefore incorrectly verify bad

<comment><USER21> So, bad certificate HAS to be signed by leaf certificate, and leaf certificate HAS to be trusted. (And you need two CAs with the same keys)

openssl would accept certs that have been issued by a non-ca cert (which is trusted).

So if you have control over the leaf cert, you can just use it for contacting openssl.

If you don't have control over the leaf cert, you can't issue a bad cert.

Am I missing something?

<comment><USER22> The leaf cert is signed for evil-bastard.net, but the "bad" cert can be for mail.google.com.

</comment></comment></comment><comment><USER23> So, updating server side OpenSSL will not close this vulnerability (for servers offering https-protected websites)? Is that correct?

If I understand the advisory correctly then this means that somebody could set up a webserver with a specially-crafted certificate and pretend to be somebody else, assuming that the client is running a vulnerable version of OpenSSL.

Is that right? I wish they would write these advisories in a slightly more helpful fashion.

<comment><USER24> Yes, this is a client side bug.

<comment><USER25> And servers that are authenticating client certs?

(clearly there are far fewer of those around but they do exist)

<comment><USER24> Good point.

</comment></comment></comment></comment><comment><USER26> In case it's slow:

OpenSSL Security Advisory [9 Jul 2015]

</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>===

Alternative chains certificate forgery (CVE-2015-1793)

</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>

Severity: High

During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and "issue" an invalid certificate.

This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication.

This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o.

OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p

This issue was reported to OpenSSL on 24th June 2015 by Adam Langley/David Benjamin (Google/BoringSSL). The fix was developed by the BoringSSL project.

Note

====

As per our previous announcements and our Release Strategy ([https://www.openssl.org/about/releasestrat.html](https://www.openssl.org/about/releasestrat.html)), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these releases will be provided after that date. Users of these releases are advised to upgrade.

References

</comment><comment>====

URL for this Security Advisory: [https://www.openssl.org/news/secadv_20150709.txt](https://www.openssl.org/news/secadv_20150709.txt)

Note: the online version of the advisory may be updated with additional details over time.

For details of OpenSSL severity classifications please see: [https://www.openssl.org/about/secpolicy.html](https://www.openssl.org/about/secpolicy.html)

</comment><comment><USER27> "No Red Hat products are affected by this flaw (CVE-2015-1793), so no actions need to be performed to fix or mitigate this issue in any way." [https://access.redhat.com/solutions/1523323](https://access.redhat.com/solutions/1523323)

<comment><USER28> Well there goes my long laborious afternoon of sysadmin work that I wasn't looking forward to! :-)

</comment></comment><comment><USER29> Why has the adoption of alternative SSL software been so low. We have libressl, boringssl, something from Amazon? Very few Linux distributions seem interested in shipping alternative SSL software.

<comment><USER30> Probably because once you wrap your code around one SSL stack it's hard to migrate it to another. So you stick to the one you use first. OpenSSL, for instance, isn't just an SSL library... since C has no standardized "stream" functionality, it's a whole big generic streaming library with pluggable modules for various streams and the ability to write your own... once you're stuck to that you can get stuck pretty hard if you don't properly wrap it with abstraction, which C is not, ahhh... let's say it's not really the best at that sort of thing anymore, which is of course partially because every language since C has known that it needs to be better than C at this to even be considered by anybody.

<comment> glass- LibreSSL is a drop-in replacement for OpenSSL.

<comment><USER10> Well that's the intention... is it really in practice? They have deliberately removed a lot of support for rare architectures and features.

Distributions such as CentOS/RHEL which are focused on stability are not going to replace OpenSSL in any existing releases.

<comment><USER31> I can confirm that it currently just "drops in" when linked against nginx. This initially took a few small patches, but these have been merged into LibreSSL mainline.

I've been testing this against each release for some time and I'm very happy with it.

</comment></comment></comment></comment></comment><comment><USER32> This appears to be the actual code fix: [https://github.com/openssl/openssl/commit/aae41f8c54257d9fa6...](https://github.com/openssl/openssl/commit/aae41f8c54257d9fa6904d3a9aa09c5db6cefd0d)

Some more details & patching guide here: [https://ma.ttias.be/openssl- cve-2015-1793-man-middle-attack/](https://ma.ttias.be/openssl- cve-2015-1793-man-middle-attack/)

<comment><USER33> This is relevant too: [https://github.com/openssl/openssl/commit/2aacec8f4a5ba1b365...](https://github.com/openssl/openssl/commit/2aacec8f4a5ba1b365620a7b17fcce311ada93ad)

</comment></comment><comment><USER34> Debian stable/oldstable is not affected. Only in unstable: [https://security- tracker.debian.org/tracker/CVE-2015-1793](https://security- tracker.debian.org/tracker/CVE-2015-1793)

<comment><USER35> Well on Ubuntu I see nothing yet... [http://www.ubuntu.com/usn/trusty/](http://www.ubuntu.com/usn/trusty/) I do not know if this is good or bad :(

<comment><USER36> [http://people.canonical.com/~ubuntu- security/cve/2015/CVE-20...](http://people.canonical.com/~ubuntu- security/cve/2015/CVE-2015-1793.html)

<comment><USER35> Thanks for the link +1

</comment></comment></comment></comment><comment><USER37> AWS response: [http://aws.amazon.com/security/security-bulletins/openssl- se...](http://aws.amazon.com/security/security-bulletins/openssl-security- advisory---july-2015/)

<comment><USER38> Welp, you saved me some work today!

I was considering using the `ec2.py` script from Vagrant's dynamic inventory docs and then running SSH command execution over all our instances to upgrade the packages for both Ubuntu and AWS AMIs (yum), just to be safe. Guess I don't need to after all!

</comment></comment><comment><USER20> Changes between 1.0.2c and 1.0.2d [9 Jul 2015]

      *) Alternate chains certificate forgery

         During certificate verfification, OpenSSL will attempt to find an
         alternative certificate chain if the first attempt to build such a chain
         fails. An error in the implementation of this logic can mean that an
         attacker could cause certain checks on untrusted certificates to be
         bypassed, such as the CA flag, enabling them to use a valid leaf
         certificate to act as a CA and "issue" an invalid certificate.

         This issue was reported to OpenSSL by Adam Langley/David Benjamin
         (Google/BoringSSL).
         [Matt Caswell]

</comment><comment><AUTHOR> It's worth noting that only releases since June 2015 are affected

<comment><USER39> That means, only releases that have no other known high severity bugs...

</comment></comment><comment><USER40> An interesting coincidence is I noticed what I thought (and maybe is) a similar bug in the elixir hex module on the same day that this bug report was submitted to openssl. If you look at the hex partial chain method ([https://github.com/hexpm/hex/blob/master/lib/hex/api.ex#L59-...](https://github.com/hexpm/hex/blob/master/lib/hex/api.ex#L59-L81)) you can see it goes through all the certificates the other party supplied starting from the first one and tries to find one that is signed by a certificate in the trust store. it then explicitly returns it as the trusted_ca which effectively means the certificate has the CA bit set on it.

in order to exploit the attack in hex you need find a CA that will directly issue certificates off of a certificate in a trust store. apparently, this is not the recommended policy for CAs. so I made this tweet: ([https://twitter.com/benmmurphy/status/613733887211139072](https://twitter.com/benmmurphy/status/613733887211139072))

'does anyone know a CA that signs directly from their root certs or has intermediate certs in trust stores? asking for a friend.'

and apparently there are some CAs that will do this. in the case of hex i think the chain you need to create looks something like this:

        RANDOM CERT SIGNED BY ISSUER NOT IN TRUST STORE
        |
        V
        VALID_CERT_SIGNED_BY_CERT_IN_TRUST_STORE (effectively treated as CA bit set)
        |
        V
        EVIL CERTIFICATE SIGNED BY PREVIOUS CERT

<comment><USER41> AFAIK the Baseline Requirements don't allow it but old certs that are not expired may still exist. It was one of the reasons why the e-Guven root was removed from Mozilla.

</comment></comment><comment><USER42> The latest version (2.3.7) of the official OpenVPN client is vulnerable, as is Tunnelblick for OSX. No fix has been published yet. The OpenVPN clients for Android and iOS are not affected.

See [https://mullvad.net/en/v2/news](https://mullvad.net/en/v2/news) for more details.

<comment><USER43> OpenVPN already updated: [http://article.gmane.org/gmane.network.openvpn.devel/9900](http://article.gmane.org/gmane.network.openvpn.devel/9900)

</comment></comment><comment><USER34> This sounds really familiar to the old IE bug that didn't check the CA flag - [http://www.thoughtcrime.org/ie-ssl-chain.txt](http://www.thoughtcrime.org/ie- ssl-chain.txt)

</comment><comment><USER44> A lot of these SSL vulnerabilities show that complexity is an inherently bad thing for security. In general, bugs in a system are exponentially not linearly proportional to system complexity. With security that means that the addition of a feature, option, or extension to the security layer of a system exponentially _decreases_ its trustworthiness.

</comment><comment><USER36> Seems to be OK for anyone using non beta versions of Ubuntu as well:

[http://people.canonical.com/~ubuntu- security/cve/2015/CVE-20...](http://people.canonical.com/~ubuntu- security/cve/2015/CVE-2015-1793.html)

</comment><comment><USER45> I've got a few sites using OpenSSL certs; do I need to do anything?

<comment><USER39> Unless you are using client side certificates, this one is not your problem.

But everybody must upgrade their browsers ASAP.

<comment><USER46> Is that right? My reading of it is that this affects all cases where you verify the certificate

<comment><USER47> Yes and most web servers do not use client certificates and do not have any need to validate certificates.

<comment><USER46> Yes but in practice a lot of them do, for example, when they download a library from PyPI or rubygems...? Unless we're talking just about when people use client certificates as authentication?

<comment><USER47> > PyPI or rubygems

These are not activities which a web server does though.

These are activities usually triggered by developers or administrators, not by web servers remotely and they have to do with a web application, not a web server.

And even then, for this attack to be meaningful you'd need to have active MITM between the server and PyPI or rubygems at the time when the developer or administrator was updating this. In a good datacenter, this should not be possible. Employees of the DC and national security agencies, which may be able to perform active attacks in such datacenters would probably be the biggest risk.

<comment><USER23> >And even then, for this attack to be meaningful you'd need to have active MITM between the server and PyPI or rubygems

Yeah. Which is pretty much the thing (or one of the things anyway) that TLS is supposed to prevent!

>These are activities usually triggered by developers or administrators, not by web servers remotely and they have to do with a web application, not a web server.

Some strange distinctions. A server running a web application may well want to make requests to PyPI when being provisioned.

<comment><USER48> This should only be the case for the build server that creates the packages that get installed on production.

<comment><USER23> Maybe that's how you do it, but I guarantee that there are loads of production webservers out there grabbing stuff from all over the web and building it in situ.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER49> Nothing I can find in yum for CentOS 6 or 7

<comment><USER50> They aren't affected.

</comment></comment><comment><USER51> At first I thought this was the result of that Hacking Team dump, but it seems this was reported prior to that.

</comment><comment><USER52> Good work on finding and fixing the bug to those involved. I don't think this is said often enough.

</comment><comment><USER53> It´s for old version. For example actual debian not affected. [https://security-tracker.debian.org/tracker/CVE-2015-1793](https://security- tracker.debian.org/tracker/CVE-2015-1793)

<comment><USER54> 'actual debian' made me smile .)

all quibbling aside, most people would probably need an explanation to understand your post, as the recent version of debian is indeed affected, as in debian-unstable (sid)'s openssl.

</comment></comment><comment><USER55> Well this isn't how I wanted to start my morning

</comment><comment><USER56> How is it that we still depend on something so broken?

<comment><USER57> If you think you can write a better implementation then put your hands where your keyboard is. Show us the code.

If not, submit patches.

An OpenSSL team member said, "If you're in a position to offer technical criticism you're in a position to offer technical help." While it sounds like their pleading for help, its because WE ARE. There are 3 full time maintainers, 1 is a dog :P and only ~10-16 regular patch submitters.

<comment><USER58> The bit you don't cover is where you repeatedly submit patches (in my case, for example, to fix documentation and improve testing) which are ignored.

<comment><USER6> This is not true anymore. At the time, OpenSSL had really a single maintainer, and was only receiving $2,000 a year in "donations". Not exactly something to keep someone working full time on the project with.

A lot of that has now changed with the Core Infrastructure Initiative.

<comment><USER59> I do agree the situation is now better, but personally I've still found contributing to be a lot harder than it should be even for trivial fixes.

</comment></comment></comment></comment></comment><comment><USER60> agl++;

<comment><USER43> [https://twitter.com/agl__/status/619129579580469248](https://twitter.com/agl__/status/619129579580469248)</comment></comment>


React tiles: Multiple routes at the same time - <AUTHOR> https://react-tiles.firebaseapp.com/ <comment><AUTHOR> Hey there,

This is part of a frontend CMS app I've been working on for a while. I have stopped working on it, but I thought that react-tiles deserved to be open to the community for anyone that may think it's useful, so I decide to write some docs and a demo and share it with the world.

Since frontend apps know how to load any app route, there is nothing that block us from load more than one route at the same time. That's the idea behind react-routes, a simple React component that divide your app in tiles, loading different routes in them.

This is one of the projects I have that I don't have much time to work on it, so every little help is much appreciated :)

Hope you like it.</comment>


Ask HN: During startup phase, what lead managment software you use? - <AUTHOR>

During startup phase, how do you manage all your contacts?
During initial phase when as a founder you are doing everything including sales as well, what tool is best for managing all your leads.
There are many sales lead management softwares but I am not sure whether they are a good fit for an entrepreneur (who is primarily not a sales person). HINT: They might be too complicated. Another HINT: I have never used them so I might be wrong.
Do you use any tool which is an obvious choice currently? <comment><USER2> The project I'm working on (<http://www.musubimail.com>) was originally meant to help keep in touch with professional contacts, but I've been using it for beta-user follow ups to some good success.

I made groups based on how soon I need to follow up (this week, next quarter, etc) and have them track certain labels in my Gmail inbox. If someone needs to move groups, I just flag their email with the right label and wait for the reminders.

Let me know if this is something that interests you!

</comment><comment><USER3> I use a trello board with the following cards:

|new| |no close follow-up| |follow-up| |dormant/recycle |

New is for new prospects

no close follow-up is for people who I have not closed.

follow up is for people I have closed, but waiting to be moved further along the sales ladder

dormant/recycle is for people who never respond but I still keep trying to close.

Note that I don't waste any leads.

</comment><comment><USER4> I'd recommend using Pipedrive <https://www.pipedrive.com/en/features>

It is straightforward to use and lets you separate different flows and stages.

<comment><USER5> Whoa, very cool. I've never seen this before and its value prop is very apparent.

</comment></comment><comment><USER6> I dig Nutshell, it's configurable enough to not just be for classic sales I just removed all the defaults and started from scratch).</comment>


G-CORE: The LDBC Graph Query Language Proposal - <AUTHOR> https://www.youtube.com/watch?v=z6HqcHjeuQ4 <comment><AUTHOR> [https://arxiv.org/abs/1712.01550](https://arxiv.org/abs/1712.01550)</comment>


Ask HN: Reasons why software projects get ugly - <AUTHOR> I'm interested in your opinions on why bigger projects seem to inevitably get messy.
Is it changing requirements, codebase getting too big to fit in one person's mind, lack of communication between developers? Maybe features of a particular language in use?
What's your experience? <comment><USER2> It's all of those things, especially when paired with many business' myopic desire to enforce arbitrary delivery deadlines, especially during the fundamental scope framing period.

Once a project has set the precedent, early, important decisions are made with an eye on the "easiest" route from A -> B, rather than decided with an eye on building a stable base to work from. This does not mean all decisions are made to build the most extensible, adaptive codebase possible--as this in itself can lead to massively complex, abstracted, and messy projects--rather to understand _why_ the project's requirements are what they are and then to select what aspects are (relatively) safe to take short-cuts in versus what absolutely must be bullet-proof and done correctly.

You rightfully wouldn't decide to build your own car without wheels, if your goal was to use it to get to places, but I'm constantly astounded by the number of commercial software projects which forgo major security items, back- end administration and monitoring tools, and end-user support resources, in an effort to "release by the end of May". You don't need to have a massively parallel, fully-enabled telemetry, and over-built redundant server farm for v1, but you should have an idea of how your v1 product will eventually become your v10 product.

Spend more time as a team thinking and collaborating on the design to reach a shared understanding of what and why you are building, and you'll find that in all but the most unique case your development is significantly faster (and with less re-work) once it begins. The people using your software will thank you for it.

</comment><comment><USER3> It's changing requirements without taking time to clean up technical debt.

Also, poor design decisions early on can really influence things later.</comment>


Ineligible Bachelors: Indian Men Living in U.S. Strike Out - <AUTHOR> http://online.wsj.com/article/SB123896998996190775.html <comment><USER2> A more sensible interpretation is that marriage and courtship rituals ("courtship" extended to include "casual" relationships) have a heavy culture specific component to them.

I had a Canadian manager (tall handsome intelligent guy) who tried applying his knowledge of how "dating" worked when he was posted to Bangalore for a year and "struck out" all the time until one day, at a party, he got drunk and asked me "Dude, how the [expletive] do you get laid hereabouts? I've been trying to get a date for 6 months and every girl says "No Thanks". I am going crazy! ".

So I gave him a 20 minute crash lecture in how these things worked in India (and specifically Urban India) and the appropriate moves and counter moves and what they mean and how to interpret and act on them. Needless to say these "rules" are very different from the Western "dating". To his credit he picked up the 'rules of the game' very fast and soon managed to get what he wanted.

When any bunch of people get dumped into a new culture, it is fair to expect that a few of them never quite pick up these nuances. Whether that is worth an article in the wsj is a different matter ;-). I could conclude (if had never been in a Western country) "These Canadians strike out all the time hyuk hyuk",and it might even make a popular article in the local paper, but then I'd still be the idiot.

To summarize, the Indian "dating game" has very different rules, and they don't work in the USA (and vice versa). For Hackers an analogy that works is submitting perfectly valid Haskell code to the javac compiler ;-)

Due Disclosure: I am Indian, have lived in the USA and had no problems "decoding" how courtship, sex and marriage worked there.

<comment><USER3> Please share the rules you are talking about. I think a lot of us Westerners would be interested to read about this foreign world.

<comment><USER2> "Please share the rules you are talking about."

When I have the time I'll probably write it up as a blog post (or a series of posts! 20 minutes of conversation is a lot of writing!) and submit the link here.

</comment></comment></comment><comment><USER4> If I have learned one thing about arranged marriages from my close-knit extended family of 100+, it is that no two arranged marriages are same.

The ONE element that almost all arranged marriages I've seen do have in common is SOME strong referral or existing friendship between the two families. In that sense, they work a lot like VC referrals:)

The type of arranged marriage most common to my larger family is a love marriage. Oxymoron you say? Well, not really. What happens is the girl and guy meet(usually at school) and gradually word starts spreading. When the news makes its way to the parents, if the parents know the other family and approve of it, you are _usually_ good to go. The "love marriage" is smoothly converted into an "arranged marriage". All my uncles(and my father) got married through this route.

I guess I am just not sure of how common the stereotype arranged marriage where a dude is forcefully dumped on a girl is. Notice all the negative connotation that is assumed by the stereotype.

All the while I have a few aunts who got married without having seen the guy until wedding day. This was may be 30 years ago. They are all still married and pretty happy. Lastly, with 50+ couples in my extended family in last 40 years, there have been fewer than five divorces(credit to Geni for handy stats).

So does this process seem weird? Hell yes. Could it result in happy marriages? Seems like it, at least for one family.

<comment><USER5> "All my uncles(including my Dad)"

I think the statement is mathematically incorrect.

<comment><USER6> Not necessarily. If his parents were brother and sister, his dad would also be his uncle.

But the OP most likely meant "All my uncles AND my dad"

</comment></comment></comment><comment><USER7> Or, maybe, here's a radical thought--the next time one of these men meets someone he likes, he could ask her out.

The whole arranged marriage nonsense is a blight on the Indian community. Needless to say, it often leads to loveless marriages; further, the fact that you're making life decisions based on scant information results in bizarre situations like the consultant in the article who can't find a wife because they all think consultant means unemployed.

I can only welcome any development that forces people to change.

//Indian person. Fortunately distanced from the absurdity.

<comment><USER8> I think you generalized a lot of things there. I personally am arranged married, and I couldn't be happier. I have a lot of friends who are in the same situation (even ones who are 10+ years into marriage). I also know people who married in 'love' that are not so happy today.

Additionally, arranged marriages need not be 'see someone for 10 mins and say yes or no'. There is a large variation in how the whole thing can potentially be set up. See [http://en.wikipedia.org/wiki/Arranged_marriage#Arguments_for...](http://en.wikipedia.org/wiki/Arranged_marriage#Arguments_for_and_against_Arranged_Marriage) for a list of pros and cons that gives you both sides of the story.

<comment><USER9> "I think you generalized a lot of things there. I personally am arranged married, and I couldn't be happier. I have a lot of friends who are in the same situation (even ones who are 10+ years into marriage). I also know people who married in 'love' that are not so happy today."

Of course. If you didn't have the choice of who to marry then you resign yourself to the notion. But if you made the decision yourself then you'll always wonder if maybe you could have chosen someone way better for you. There was a TED presentation about this some time ago...

(Not saying it's not possible that the particular arranged marriage may have matched you with the best person for you anyway)

<comment><USER10> You're right; nobody would ever suffer long-term anger and resentment at decisions that somebody else made for them; it doesn't make sense. It was out of my hands, so I'm totally okay with it! That's why teenagers and their parents get along so well, why women didn't really want the vote, and why working in a bureaucracy is so good for your mental health.

<comment><USER9> No no, seriously. There was a TED presentation about this unintuitive phenomenon. It was posted here a while ago.

[http://www.ted.com/index.php/talks/dan_gilbert_asks_why_are_...](http://www.ted.com/index.php/talks/dan_gilbert_asks_why_are_we_happy.html)

edit: Fixed the link, it wasn't the one I meant to link to.

<comment><USER10> Yeah, I know you're serious. I'm just pointing out that there's a difference (and evidently one that is important psychologically) between a situation where there is only one possibility and a situation where there are many possibilities, but somebody else chooses for you. I know people who stayed angry for years because their parents made them go to a certain college or their boss canceled a product line they created.

</comment></comment></comment></comment></comment></comment><comment><USER11> I don't quite understand this attitude I've often found here of people to dissect, "try to understand", and take a swipe at what's wrong about other cultures, point out how some attributes of other cultures are so deviant and then take a higher stand, a higher ground on those issues.

Frankly, if you haven't been born and/or brought up in a certain culture, you simply will not be able to understand some peculiar aspects about it. Yes, there are good and the not-so-good aspects and takeaways about every culture on this planet. But I sometimes find the tone of such articles and some of the comments in this discussion not only mildly condescending but also biased. I was born and brought up in India by fairly open-minded and unorthodox parents. And so were many of my friends.

Correct me if I'm wrong. This is not an intelligent article, or discussion. It's in fact a very superficial look at the best. This is just an informative article and in no way representative of the large group of "Indian Men" living in the states. It beats me how the writer takes a few examples and on a respected daily as the WSJ blatantly labels it as "Indian Men Living in US Strike Out.

Why are we even discussing this here?

<comment><USER12> > Frankly, if you haven't been born and/or brought up in a certain culture, > you simply will not be able to understand some peculiar aspects about it.

A true statement, but not necessarily relevant. For instance, I cannot understand Aztec culture, because I have not experienced it. I condemn it nonetheless.

<comment><USER11> Your condemnation does not really have any place in the scheme of things, history, or a bearing on that culture for that matter. I'm not trying to be harsh here. I hope you understand my fundamental point. A culture is a culture, it's a consequence of history, time, and innumerable subtle things and relationships. Just as the American culture is, many aspects of which people outside America condemn. But it doesn't matter.

Outsiders attempting to generalize, analyze, dissect, and fix things about cultures they barely understand more often than not cause historical and irreversible damage.

<comment><USER12> > Outsiders attempting to generalize, analyze, dissect, and fix things about > cultures they barely understand more often than not cause historical and > irreversible damage.

Maybe it can also cause progress? For instance, the condemnation of Apartheid by the western world probably helped end it.

(I don't mean to say arranged marriage is the same as Apartheid, obviously.)

<comment><USER11> The concept and system of arranged marriages is not something that needs fixing. It has evolved and will continue to evolve to adapt to changing conditions and attitudes among the youth and parents in India. A marriage is much larger than whether it was arranged or born out of (fleeting/puppy/divine/heavenly) love.

<comment><USER12> The concept and system of _Apartheid_ is not something that needs fixing. It has evolved and will continue to evolve to adapt to changing conditions and attitudes.

<comment><USER11> Well, obviously I didn't mean that Apartheid was a concept or system. And you know that.

<comment><USER12> My point is that your argument validly defends Apartheid. It is a standard (if somewhat impolite) rhetorical technique to parrot your opponent's arguments in a way that makes them seem obviously flawed.

<comment><USER13> I should probably be downvoted into oblivion for this but...

Is this actually a valid use of "Reductio Ad Hitlerum"? Surely such a thing is rare and beautiful.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> I live in the South Indian state of Kerala. Here 'arranged marriage' means parents and relatives get a chance to background-check the future partner before you do. So for a girl, this means your parents check on the boy's character , his earning potential , the way his parents made money and other related aspects. If parents are happy, a meeting is arranged.If the girl and boy likes to go forward with a relationship, they can take time to know each other.If everything goes well, proceed to marriage.

In short, its like dating with the fittest. All marriages in my family happened this way, and we dont have even a single case of divorce in my family.

<comment><USER15> poda pulle nayinte mone. The sick orthodox views of the people of Kerala is debilitating to the modern man. One is expected to stay celibate till the age pf marriage which tends to be around age 25. Suppression of hormonal urges has a crippling effect on the mind. College life in Kerala is the worst all over India. Apart from the impossibility to have sex thanks to the conservative views of the mallu girls, there's also a phenomenon called ragging which makes life even worse. I for one hate Kerala and call it the Devil's own country.To MGreen, you need some introspection; the culuture of Kerala is one that I despise beyond all. patti chetteh kazhidhe thendi

<comment><USER14> I was just trying to explain how 'arranged marriages' work in my family and that the success rate of the system is pretty good in my experience.

Sex at college is a different aspect. Its true that the social setup doesn't encourage sex while you are at college. But i think the reason is not just an 'orthodox view' of Keralaites. Males mostly stay with parents until they finish college(&& get a job) and are fully dependent on parents financially.'Work while you study' is almost non-existant here. Perhaps girls just dont want to take the risk of hanging out with someone who doesn't have any proven earning potential(yet). At the end of the day, getting a girl depends on how you approach the girl !

Sorry to hear that you had bad experiences with 'ragging' at college. I never had any such issues. Infact, my seniors were very helpful throughout my college life.

I see that you created an account just to make that comment with personal insults against me. Try sticking on to the guidelines and keep HN a nice place: <http://ycombinator.com/newsguidelines.html>

<comment><USER16> I know a few guys who have a lot of sex in college - all of them are already making more money than one usually makes working for one of those so-called tech giants (HCL, Wipro, blah).

Earning potential = sex. No, seriously.

</comment></comment></comment></comment><comment><USER17> _In contrast, in the U.S., "people have to even clean their own toilets,"_

You know, I could easily afford to have someone clean my toilet. In fact, our receptionist offered to be my housekeeper, at good terms. But...I don't know...I just don't want 3rd parties involved in the matter. I guess it's my lower-middle class heritage thing.

<comment><USER18> Partially a cultural thing, too. Americans don't do "servants", for certain values of "servant".

Similarly, if you come to Japan and try to explain babysitting, you get looks of total horror.

"Yes, I think its perfectly normal to talk to a mother I know, get the name of a 13 year old girl who lives in the neighborhood, pay her $20 so that I can have an evening out with my wife, and entrust my home and infant child to her within 5 minutes of meeting her. You find this odd?"

<comment><USER2> "if you come to Japan and try to explain babysitting, you get looks of total horror."

My (Indian) mother was horrified when an American woman told her she(the American) was paid by her daughter to babysit her grand kids. The idea of turning baby sitting grandchildren into a "commercial transaction" was a horrifying thought to her.

just another example of "different folks, different strokes".

<comment><USER19> it is

</comment></comment></comment></comment><comment><USER20> A lot of people forget how recently westerns imported brides of their own. My family arrived in San Francisco from Quebec in the mid 1840s, but my grandfather (married in the late 1930s) was the first to stop importing french speaking brides. It went on for generations. Sheesh.

That said, I'm really, really, really glad he put an end to this little tradition of ours.

</comment><comment><USER21> I find it shocking that some Indian men have such attitudes, despite having spent time in places like the US.

<quote> Given the difficulty in finding matches for Indians abroad, some matchmakers are now charging them more. Mr. Dave of Klassic Match charges a minimum fee of $100, versus $50 for candidates living in India. He charges more for specific requirements. For instance, he says some overseas Indians want a bride who is smart, fluent in English, and "simultaneously, docile in the house." He says such women are now harder to find, so he bumps up his fees for some searches. </quote>

<comment><USER22> Another explanation could be that the Indians in the US are mostly engineers, who skew towards being introverted. I'm guessing wildly here, but my point is that it could be more than cultural factors at play.

</comment></comment><comment><USER23> India has some weird cultural aspects that I do not find appealing personally.

I had an Indian friend on a H1-B who talked a lot about getting a wife that cooked and cleaned and stuff and I always asked him, "Why not just hire a maid? Probably be cheaper." He could never come up with a good response.

I guess these attitudes come from being raised in a culture where it's the norm. I've got another few friends who are first generation and they never talked about anything like that at all. Makes me wonder what fundamental change in Indian society will disrupt those attitudes; will a simple increase in per capita income and an equalization of the labor pool do it, or is it at a more ingrained level?

<comment><USER24> _I guess these attitudes come from being raised in a culture where it's the norm._

I don't know where you live but the "woman as homekeeper" thing is the norm in most Western societies too. Women have, of course, worked throughout history but, culturally, it's been more the norm so far that women have taken housemaker and child raising roles. My mom left her job when she met my father and she has never been employed since. The same applies for about half, I'd say, of my friends' family situations.

It is not unrealistic or old fashioned for people who agree on their roles to settle into those roles. There is nothing wrong with anyone looking for someone who complements them as long as the intentions are good. Indeed, finding someone who doesn't complement you is more likely to result in disastrous relations.

<comment><USER21> It is an interesting point you raise. It is perfectly acceptable to agree on roles and settle into them.

But in this case, my guess is that these attitudes have more to do with holding onto a traditional belief in male-dominance than with any concerns for having different roles in marriage. And if I am guessing correct, such beliefs should not be encouraged and nor is it in the interest of any woman to seek out such a partner for herself.

<comment><USER24> Oh, totally. The issue, for me, is when society _demands_ people act in a certain way. If my mom, my wife, or whoever, _wants_ to be a house wife, I'm all for that. But if they wanted to be an artist, rock star, or whatever, no- one should stop them (well, except in my wife's case because she's tone deaf).

All that said, I don't see a problem in people specifying a "docile" housewife as a preference, no more than someone might want a "blonde" wife, a "nymphomaniac", or any such thing. Just because you prefer something doesn't mean you have the right to get it but nor does it mean you're "wrong" for having that preference as long as you don't force it on anyone else.

</comment></comment></comment></comment><comment><USER25> The article is full of typical stereotypes attributed to Indians.

</comment><comment><USER26> The submitted article mentioned an ad describing one prospect as a "brahmin boy." How pervasive is caste as a selection criterion for arranged marriages?

</comment><comment><USER27> Coincidentally, the _Boston Globe Magazine_ 's "Coupling" feature just ran an essay by an Indian attorney living in DC, who has been ashamed to admit that her parents bought a newspaper ad and arranged an introduction to the man whom she will marry this summer.

[http://www.boston.com/bostonglobe/magazine/articles/2009/04/...](http://www.boston.com/bostonglobe/magazine/articles/2009/04/05/help_wanted_after_all/)

</comment><comment><USER28> Anybody have more stories to share about this? I am wondering how difficult a problem this is. Most of the Indians I have met in the US are all extremely competent with very good looks to match; this article was very surprising.

<comment><USER29> It doesn't necessarily have anything to do with a guy's looks or competence. In an arranged marriage the practical factors take precedence. Marrying a guy who is supposed to support you and your future family, but only makes $80K-$100K a year in the Bay Area simply isn't very practical.

</comment></comment><comment><USER28> Fascinating article. I read a report about Chinese brides recently that found a huge dip in interest of marrying overseas. Something like 20% or 40%. I'll dig up the article if anybody is interested.</comment>


Update to VMware's Per-CPU Pricing Model - <AUTHOR> https://www.vmware.com/company/news/updates/cpu-pricing-model-update-feb-2020.html <comment><USER2> Another story was posted on Monday about this (no comments though) for anyone who'd like additional context:

[https://www.tomshardware.com/news/vmware-caps-per-cpu- fees-a...](https://www.tomshardware.com/news/vmware-caps-per-cpu-fees- at-32-cores-amds-epyc-rome-impacted)

</comment><comment><USER3> So is it a scheme VMware and Intel planned together to sack AMD in the dark corners once again?

<comment><USER4> It wouldn't surprise me at all if this was a quid pro quo for Dell(VMware owner) to get the highest tier of Intel availability & discounts.

</comment></comment><comment><USER5> So its a suggestion to try openshift or proxmox..

</comment><comment><USER6> Tldr: VMware charged before per cpu. Now a cpu license only includes 32 cores so you may have to buy multiple licenses. This will get really expensive very fast with AMDs permanent increasing core counts.

<comment><USER7> Makes me wonder if there is any roll-over with the additional cores. If you have a dual processor machine, with 34 cores in each processor, you would have to get 4 licenses, 2 of which only cover a combined 4 cores. It seems less than ideal.

<comment><USER8> As it is written now, yes you would need 2 CPU licenses. I suspect over time this will be refined to something more core count based. I think most people in the VMWare universe have been expecting a change like this.</comment></comment></comment>


Why the world's leading AI charity decided to take billions from investors - <AUTHOR> https://www.vox.com/future-perfect/2019/4/17/18301070/openai-greg-brockman-ilya-sutskever <comment><USER2> Have your non profit cake and eat 100x returns on your good graces. Then you get to be top dog in a world of "useless human beings". I don't know much about the next world but it probably won't have air conditioning for these people.</comment>


Amsterdam Conscripts Homeless in the War on Cash - <AUTHOR> http://bitcoinist.com/amsterdam-homeless-war-cash/ <comment><USER2> So, the beggar is out on the streets with a card reader that sends money to an account run by a shelter, which allows them to purchase services from this shelter?

Sounds more like they're being asked to fundraise for what I hope is a charity and being paid with benefits in kind than being given freedom from depending on cash.

</comment><comment><USER3> I don't think visibly marking Homeless people is ethical. They did that to Jewish people way back when. Am I looking at the wrong photo, or is it really a visible homeless badge?

Yeah, it really is a giant homeless badge: [http://www.gizmodo.co.uk/2017/01/contactless-payment- jacket-...](http://www.gizmodo.co.uk/2017/01/contactless-payment-jacket- created-for-homeless-people/)

<comment><USER4> Why not make it a sticker or just something to hold...

I'd also like to know from someone who has been in that situation, maybe even an addict, what he thinks of the limitation on what he can spend the money on. I guess it's good because people will spend more and it can't fuel an addiction, but it also strips you from some more freedom.

I also wonder if registration is somewhat anonymous with no questions asked for illegals, minors etc.

<comment><USER5> > illegals

I'm sure it's not your intention, but you further dehumanize individuals when you use that word to describe their immigration status. Please consider "the undocumented" instead.

[http://youtu.be/vehgRK3ieVM](http://youtu.be/vehgRK3ieVM)

<comment><USER3> >dehumanize

I'm sure it's not your intention, but you further dehumanize individuals when you use that word to describe how they're being treated when called their common nickname. Please consider that when you try to force people to use your words to push an agenda, you harm the plight of those you are trying to help.

Further, that video was terrible. Humans create abbreviations and nicknames for tons of things without regard to legal validity. Do you have any other lists of common nicknames we're not allowed to use?

Like can I still call Green Bay Packers fans cheeseheads?

<comment><USER6> > Like can I still call Green Bay Packers fans cheeseheads?

No, because you are a grown up person and you don't need derogatory terms to appear cool or hip.

<comment><USER3> "The term, however, was quickly embraced by Wisconsinites and is now a point of pride" [https://en.wikipedia.org/wiki/Cheesehead](https://en.wikipedia.org/wiki/Cheesehead)

I'm ok with a substitute example for an acceptable group nickname if you have one on offer.

<comment><USER6> Haha, I got owned :D. Not living in the US, not from the US and cheesehead sounded like an insult to my ears.

Still I believe that not every nicknames or abbreviations is a good thing.

<comment><USER7> It probably was originally an insult by an opposing side's fans.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> It's very important to enable the homeless to take cashless payments. But I don't like this particular scheme at all.

It is horribly patronising to tell people what to spend their money on or what jacket to wear.

<comment><USER9> Homeless people have the choice to wear this jacket and accept donations with it or not; if they believe that the guarantees offered by the charity drive more donation, that gives them more agency, not less.

It feels less offensive to me to do it that way than to have someone ask them how they are going to spend that money.

</comment></comment><comment><USER10> Absolutely disgusting. Abusing a "feel-good" impulse to get people hooked on cashless payments.

I've said it before (and was naturally downvoted), but The Netherlands is devolving into a totalitarian society -- not Orwellian, but Huxley-style.

<comment><USER11> This is an outrageous claim, not at all supported by facts. Hence the downvotes.

</comment></comment><comment><USER12> >"This demonstrates that even if demonetization could actually curb corruption and the black market, it may change the lives of many ordinary citizens for the worse both in the developing and developed world."

I am all for the consumer convenience aspect of crypto currencies but is it actually being sold as an anti-corruption strategy?

You would have to look no further than ransomware to see that crypto currency just like regular fiat currency can be used in illicit contexts. You might even be able to argue it would become preferable to cash for bribes and corruption since it remove the burden of physically transferring and storing large amounts of cash.

</comment><comment><USER13> Though not a believer in the Christian sense, this sounds awfully like we're heading towards the number of the beast here. I'm not about to stockpile gold and coins, but if electronic currency is forced upon me, the less I'd want to use it.

On one fortunate side, at least for now, in the US there are enough people far more vocal than I am about this if removing physical currency were ever genuinely proposed/pushed.

</comment><comment><USER14> Why is it always assumed beggars and homeless are two of the same? Disclosure: I have been homeless and would never resort to asking strangers for money.

<comment><USER6> > Why is it always assumed beggars and homeless are two of the same?

Don't know, let's see.. hmmm... maybe because the two often go together ?

<comment><USER15> There are plenty of beggars who are not homeless or vulnerably housed.

<comment><USER6> Plenty as in the majority ?

<comment><USER15> In England, probably yes the majority of people who beg are not homeless.

Of course, we need to define what we mean by homeless. And I'd like to try to avoid some of the unpleasant and stigmatising messages sometimes made by English councils who are trying to stop people giving money to beggars.

</comment></comment></comment></comment></comment><comment><USER16> Guess what happens when "cash is dead" ? Long live the cash!

We need more competitors in the business of issuing money; What are they going to do about all the gold coins ?

</comment><comment><USER17> Next they will be tattooing numbers on homeless peoples arms.. then low paid workers then middle income then...

</comment><comment><USER18> I imagine that technology like this would be really useful for fundraising by municipalities. It's hard to watch police and fire fighting personnel raise funds by collecting loose change from passers by.

<comment><USER19> > watch police and fire fighting personnel raise funds...

What? Where does that happen? Isn't policing a primary responsibility for the government, to be paid from taxes by everyone? Fundraising seems very misplaced for them, no matter how.

<comment><USER9> It does sound misplaced, but it is often the case especially at the end of the year. I've seen calendar sales used in that fashion quite a lot.

</comment></comment></comment><comment><USER20> Most homeless people are insane (i.e. suffering from an intense mental illness). This comes up on HN all the time -- for these people, the only hope is immediate, thorough medical care (involuntary if need be).

For the non-mental-ill homeless...

Why give them money? Serious replies please.

One becomes homeless because one cannot manage money effectively. IMO it's cruel to just give a homeless person a money -- they're going to spend it unwisely again. It's better to provide the essentials (food, water, shelter, _basic_ healthcare, hygiene) then money.

The transition out of homelessness requires a re-learning responsibility. Our solutions to dealing with homeless people should focus on the fact that, fundamentally, homeless people fail in our society. We have to re-educate them so that they are productive and serve as a net positive for society.

<comment><USER21> No doubt your intentions are good but the solutions you propose are scary. You say that mentally ill without a home should get medical care. Alright, I agree. And they will get that medical care in Amsterdam if they ask for it. But then you say, they should get the treatment involuntary if need be. But suppose I am a homeless person living on the street, who will determine that I am mentally ill and should get forced treatment? What if it is my personal choice to live on the street? Or does that already qualify me as mentally ill, in somebody's eyes?

Actually it is possible in Amsterdam for people to be forced to get treatment, but that is only if they are a clear danger to themselves or the people around them.

Then at the end you say "homeless people fail in our society. We have to re- educate them so that they are productive and serve as a net positive for society."

I hope this will not be a forced re-education as well? And who will determine what 'our' society is? I find it really scary when a group of people defines society to be 'theirs' and that anybody who does not wish to live along their lines should be re-educated. History provides plenty of examples where this idea was put into practice, most of the time with all the good intentions, and every time the outcome was horrible.</comment></comment>


Every item distributed to police by Pentagon's 1033 program over 2 years - <AUTHOR> https://www.muckrock.com/news/archives/2014/aug/15/we-have-pentagon-1033-program-data/

<comment><USER2> Great work, I'm sure, but this web page is unusable. I'm just getting a progress spinner as (I guess) it tries to load and reload the embedded document. This is even after going away and doing other stuff for half an hour while the page was in the foreground.

<comment><AUTHOR> We're workin on better embeds for large data sets: Google Sheets is wrecking the page. In the meantime, the data can be downloaded directly from the individual requests' pages:

[https://www.muckrock.com/foi/united-states-of- america-10/pro...](https://www.muckrock.com/foi/united-states-of- america-10/program-1033-roster-or-applications-7018/) [https://www.muckrock.com/foi/united-states-of- america-10/pro...](https://www.muckrock.com/foi/united-states-of- america-10/program-1033-aircraft-armored-vehicle-and-weapons-requests-7019/)</comment></comment>


How to choose your video media engine - <AUTHOR> https://blog.streamroot.io/how-to-choose-your-media-engine/ <comment><USER2> Great post. Glad to see open-source media frameworks gaining traction. Html5 adoption is good for the industry and good for viewers!

</comment><comment><USER3> well done! I like the list of open source tools</comment>


Futuristic Startup Ideas - <AUTHOR> http://www.jacobsheehy.com/2013/03/living-in-the-future-startup-ideas/?l

<comment><USER2> Figure out where the puck is going. Head there.

Trite, yes, but exactly what I've seen many big winners do. I first noticed it with iD Software, where Carmack wrote his awesome games for where the hardware was going to be when he finished it. Google was so pretentious with that name, AFAIK implying it was going to operate on a vast scale of knowing everything to, well, 10^100 things...and now it searches the Internet _as you type the query_ right down to ground-level imagery. Plot the rate of network bandwidth, and the prediction that you'd get multi-T1 data rates _wireless in your pocket_ was hysterically absurd. Ditto image resolution and data storage. I once wondered what kind of user interface could be achieved if one threw an entire supercomputer at a GUI...and now we know.

Plot where the curves are going. See what the numbers predict for 10 years down the road. They will look hysterically absurd - believe them, develop for them. Converge that with following the much-trodden path to its end...then keep going.

Oh, and that old prediction that every home would have a dozen or more TVs? That was ridiculous. That happened too. Took a little longer than expected, but I've got (in essence) 5 on my desk alone.</comment>


Some People Understand REST and HTTP - <AUTHOR> http://blog.steveklabnik.com/2011/08/07/some-people-understand-rest-and-http.html

<comment><USER2> So there are some parts of REST that make perfect sense to me. In particular, the preference for nouns w/ CRUD over verbs has many great side effects: easier caching, better logging, easier discoverability, etc. And I also get the Content-Type and Content-Language stuff, especially in terms of avoiding ".json" or ".xml" so that you can compare resource identity via a simple string compare.

But I simply do not see any value in HATEOAS outside of largely read-only datasets and generic dataset explorer type applications. Maybe it makes sense for someone like Freebase, but it's completely useless for pretty much every other API out there.

You simply _cannot_ build a useful API client application without deep knowledge of the problem domain and the _interface_ part of API. You're going to have API documentation and you're going to have to read it.

Now, I understand the desire to avoid IDs and manual URL construction. That's a valuable goal. And I'll admit that I never thought of using 201 and the Location header on create; clever. But just knowing the list of relative URLs from a resource is useless. It's not like a Link rel="newcomment" header is going to show up and magically you'll have comment form. Besides, you need to know which "rel" to lookup, so you might as well just append "/comments" and avoid the indirection.

And this all breaks down yet again when you get to offline support. If you've got a web app which is going to deal with not-yet-saved objects, you're back to being unable to compare URLs, or constructing them.

Lastly, while I like working with clean URLs and GET/POST over RPC calls. I dislike the ad-hoc specifications necessary to build real applications. We've got a "RESTful" API for our app, but we keep running into situations where different views need subtly different data. For example, decorating a resource with relationship to the current user (eg. isAdmin) or joining data when returning a list of related objects (eg. members vs memberships). The query param spaghetti is growing unwieldy, subtle authorized data leak problems are an inevitability, client-side models get confusing and easily create bugs if passed around.

The only solutions to these problems are excessive discipline. Discipline is something that compilers are great at providing, which is why you see things like ProtoBufs and Thift. There's no arguing over HATEOAS or RESTfulness or GET/POST or Content-Type or any of that. The message definition files act as a baseline API documentation, which are enforced programmatically. The designers of these tools had things to do and didn't have time to deal with this nonsense.

Stop the pontificating and get back to work.

<comment><USER3> > You simply cannot build a useful API client application without deep > knowledge of the problem domain and the interface part of API. You're going > to have API documentation and you're going to have to read it.

That has nothing to do with HATEOAS. Of course you have to know the interface part of the API, but the interface part is the content types. Not the Content- Type, though they can match, but the content types: the shape and structure of the documents you get from the service, and send to it. And those content types tell you, among other things, where to get or send other types.

> Besides, you need to know which "rel" to lookup

Sure, see above, that's part of the content types _which the consumer needs to know in any case_.

> And this all breaks down yet again when you get to offline support. If > you've got a web app which is going to deal with not-yet-saved objects, > you're back to being unable to compare URLs, or constructing them.

I fail to see the issue. You know the data you need to send to the service, and you know the content types to traverse in order to reach where to send your data in the service. What is the issue?

> Lastly, while I like working with clean URLs

URL shape has nothing whatsoever to do with REST.

> I dislike the ad-hoc specifications necessary to build real applications.

Why would they be any more ad-hoc than with any other interface standard?

> Stop the pontificating and get back to work.

Oh irony, you're so delicious.

<comment><USER2> I'm not following anything you've said about "content types". The well- defined, well-known content types in typical applications are images and other "attachment" type resources, as well as the occasional RSS feed or something like that.

In domain-specific APIs (ie. nearly all the ones that matter), every single resource type has a unique schema. Ignoring versioning, I can request resources with a specific URL pattern and parse them with specific logic. That's all there is to it. It's not complicated. The Content-Type is entirely irrelevant, unless I decide to use it for versioning or waste my time supporting both XML and JSON.

> > Stop the pontificating and get back to work. > Oh irony, you're so > delicious.

My point was directed at the whole "What is RESTful?" debate, including all the versioning, content types, URLs, headers, verbs, etc. Discussions of approaches and problems is not pontification. Discussion of "Which approach is more RESTful?" is pontification.

<comment><USER3> > I'm not following anything you've said about "content types".

Which amply demonstrates your complete lack of understanding of the subject "pontificate" about.

edit: you can downvote me all you want, does not change that fact. Here's what Fieldings has to say on the subject:

> A REST API should spend almost all of its descriptive effort in defining the > media type(s) used for representing resources and driving application state, > or in defining extended relation names and/or hypertext-enabled mark-up for > existing standard media types. Any effort spent describing what methods to > use on what URIs of interest should be entirely defined within the scope of > the processing rules for a media type (and, in most cases, already defined > by existing media types).

(I used "content types" for his "media types", that's about it).

</comment></comment></comment></comment><comment><USER4>
        The good

        GitHub uses custom MIME types for all of their responses. They're using the vendor extensions that I talked about in my post, too. For example:

            application/vnd.github-issue.text+json

        Super cool.

Hmm, I wouldn't call that "good." It's definitively better than sending 'application/json' or 'application/xml', which tell us nothing about the structure of the data, and it's probably inevitable in their context, but "good" would be to use an actual _standard_ mimetype instead.

The problem with using mimetypes tied to the service is that it undermines the concept of Uniform Interface, by forcing developers to write clients specifically for that service. Imagine if instead of standardizing on (X)HTML, CSS, JS and a couple of image formats, each website used their own format.

<comment><USER5> That is actually an interesting point. I can't pull up the HTTP spec or Dr. Fielding's dissertation right now, but what precisely is the mimetype supposed to signify?

It seems that that the _encoding_ of the response (html/xml/json/etc) is being conflated with a content specification for the response. XML already allows you declare a schema for validation purposes. There have been a few attempts to standardize this on the JSON side, but that will never be a first-class citizen in JSON (nor do I think they should be).

It appears to me, if you really care about the content of your resource, then you should use the schema facilities provided by your encoding, rather than imposing it universally on the architecture side, as the article implies.

Historically, mimetypes (afaik) have never made any assumptions about the content of a resource, other than it adheres structurally to whatever the mimetype declares. Should be kept that way.

<comment><USER4> That limits the number of XML representations of any given resource to one, which can be a problem. In the context of a geographical object, XML might mean a KML file or an SVG image of the location, for example.

There are plenty of IANA approved mimetypes which define a schema - in fact, HTML itself provides plenty of semantic information about the data.

<comment><USER5> You could narrow it down using _standard_ mimetypes even if the alternate representation is a xml derivative. application/svg or whatever the mimetype for that is. The encoding for svg is well defined; SVG tags merely lend structure to the content. The same goes for HTML and any other markup.

I'm undecided now though.

It's a slippery slope with custom representations. With generic XML or JSON, you still need a priori knowledge of the content to parse the reprentation manually. Then the benefit of a nonstandard mimetype is simply to be absolutely explicit about your content. Whether that should be canonical, I'm not sure.

</comment></comment></comment></comment><comment><USER6> Any notion of HATEOAS in the GitHub API is purely experimentation. With the exception of the pagination links, the rest of them could change format or be removed at any time (until something is properly documented at <http://developer.github.com/>). I don't think the Link header is descriptive enough, so most of them will probably go away.

</comment><comment><USER7> REST is a style, not a pattern. The application of this manner of classification to application architectures on the web was the broader goal of Fielding's dissertation, titled "Architectural Styles and the Design of Network-based Software Architectures".

See chapter 1 [http://www.ics.uci.edu/~fielding/pubs/dissertation/software_...](http://www.ics.uci.edu/~fielding/pubs/dissertation/software_arch.htm#sec_1_5)

</comment><comment><USER8> Another interesting post by Steve. What are your thoughts on twilio's date prefix in the URI versus using "v1" for example? Does discovery appease the purists qualms about versioning? But if using HATEOS enables discovery (which twilio is doing), why put a date there in the first place? I am thinking they're future-proofing their top-level resource discovery, but maybe I'm missing something.

<comment><USER9> [Disclaimer: I work for Twilio.]

It's actually not future-proofing, in that today we have different version of the API: 2008-08-01 and 2010-04-01. Some sort of versioning is necessary so that we can improve our API without breaking current clients or forcing all of our users to update their code. And while the goal of a completely discoverable API is laudable, I've never seen it work well in practice. We have a real service with real users, and we need something that works well and is simple to consume.

And I don't see how date-based versioning is any better than version numbers from a HATEOS perspective, since it's not really any more discoverable. There is however an argument to be made that version numbers are simpler, clearer and easier to remember.

<comment><USER10> Isn't it simpler to infer backwards compatibility from proper major.minor version number bumps? A major version number bump indicates API(/ABI) breakage, plain and simple. A minor version bump is simply a backwards- compatible change to the existing major.

Version numbers for marketing purposes are not really that useful, but if they are strictly used to indicate compatibility, they are very helpful. No one cares if the API is at, say, version 1023.301 as long as they know that 1023.200 is compatible with the latest version and 1022.499 isn't.

<comment><USER11> (I'm also from Twilio)

We historically have not done version bumps for minor improvements to the API that do not break existing applications. 2010-04-01 has been updated a couple times since it was first released with new features (like subaccounts, applications and short codes) but all of those were additive there was no reason to change the version.

</comment></comment></comment></comment><comment><USER12> Well, I for one don't understand REST. In particular, how to implement it in current HTML with current browsers.

There's all this nice, theoretical stuff about URI design, HTTP verbs and stuff. So I went to actually implement this the other day, only to find that you can't actually do it properly without hacks, because HTML and browsers only support the GET and POST methods for FORMs. WTF?

Can you actually implement a set of CRUD pages for an entity without resorting to hacks like hidden _method fields?

Surely REST is intended to be used for more than AJAXy APIs?

<comment><USER4> You're confusing REST (an architectural style) with HTTP (which defines the verbs/methods). REST isn't only HTTP, and HTTP clients are not only general browsers.

But it's true, you can't use the full range of HTTP verbs using normal HTML, and that's a shame. Apparently HTML5 was supposed to support them, but it was removed.

</comment></comment><comment><USER13> Recently I decided to use the ASP.Net MVC framework for a project and tried to combine the API into the web site project for ease.

It became quick to me all the mentions of REST within the framework where fictitious. What it actually is an object API exposed via HTTP, its not REST at all.

Thinking I mis-understood what REST was I started doing some research only to discover than no I was correct in my understanding (from white papers) and secondly almost ever single developer article I read (blogs) was wrong. There is a fundamental misunderstanding of what REST is out there. Its kind of disheartening to see how many people just don't get it, and are perpetuating falsehoods :/

ASP.net's main problem is technical. (and I assume this is the same for many languages) You can't have functions with the same parameters. You can't have a separate endpoint methods for POST, GET, PUT, DELETE etc... So if you try to shunt data objects around using it you can't just put them back where you got, of do smart discovery, to things i like from REST. So the whole framework falls to pieces, its designed to mimic REST, but not be REST.

For .net devs reading this I'd avoid the MVC framework for REST. But if you have to for what ever reason you will have to build your own "verb" dispatchers, and drop the use of "action" functions in your controller classes, only have one public method, the standard Index() one, expose nothing else. I may float my samples online at some point but I'm to busy at the moment so I hope this is enough to help.

<comment><USER14> You can't have functions with the same parameters, but ASP.NET MVC gives you a way around this using attributes. See this SO question. <http://goo.gl/wJ4jE>

Does that solve what you were talking about?

<comment><USER15> You can also use [HttpGet], [HttpDelete], [HttpPost], [HttpGet] attributes. Personal preference.

<comment><USER14> yeah but the problem he is having is that you'd need to have different a different method signature for each of these otherwise it won't compile, and he wants to have the same path/parameters for each, which is why you need to rename your method and then add the different attribute.

If your methods already have different parameters or a different name, you can just use the attributes like you state.

</comment></comment></comment></comment><comment><USER16> Can clients of your API talk to other people's APIs using the same interface? If not, then the client is obviously coupled to your server and you definitely do not have a REST application. You have a thick client application. REST is the antithesis of this -- the client is generic and _doesn't need to change along with the server_.

Putting links in your proprietary data format does not make it hypermedia, it just makes your API easy to reverse engineer. Maybe it also allows you to change your URLs, but it doesn't allow you to change the structure of your data. Hypermedia does. Hypermedia comes in generic media formats that clients know what to do with.

If your API is called "The [company] API" then it is almost certainly not RESTful. If your API is called "[generic type of data] interchange protocol" then it might be RESTful. But we don't usually call that kind of thing an API, we call it a protocol or a format. Really, I don't see how an API, as they are commonly understood, can possibly be RESTful. The main big important point of REST is to not have APIs.

<comment><USER17> REST known by everyone and what Roy Fielding described are quite different beasts. There should be a different name for "plain old HTTP APIs" using JSON or XML.

[http://roy.gbiv.com/untangled/2008/rest-apis-must-be- hyperte...](http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext- driven)

</comment></comment><comment><USER18> Vendor mimetypes are bad. They defeat the purpose of REST.

I should be able to request from Github the content-type(s) I am willing to accept, and Github serves them to me.

It's ironic that a blog post about people understanding REST highlights their misunderstanding of it.

What Github does isn't bad, but you shouldn't praise it for being RESTful.

<comment><USER3> > Vendor mimetypes are bad. They defeat the purpose of REST.

No they don't. Most standard mimetypes are far too broad and completely useless as an actual content type. "application/json" for instance does not tell you _anything_ about the content you're getting, apart from the meta- format in which that content is expressed.

Useless.

<comment><USER7> It tells you it's not HTML. That's useful if you hope to parse the message body.

<comment><USER19> Ok, so you can "parse" it, which is just a way of saying you can transform a bunch of bytes to a nested structure consisting of a few basic types (dicts, lists, strings, floats, etc). Now what? What can you (or actually your program, not you as a human) do with it without some sort of schema, explicit or implicit?

<comment><USER20> Nothing. Exactly!

REST is not for machine-driven interactions. It's for humans browsing websites.

<comment><USER3> Uh... no.

<comment> j-g-faustus

        The REST interface is designed to be efficient for large-
        grain hypermedia data transfer, optimizing for the common
        case of the Web, but resulting in an interface that is
        not optimal for other forms of architectural interaction.

[http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch...](http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1) (Section 5.1.5)

        When a link is selected, information needs to be moved
        from the location where it is stored to the location
        where it will be used by, in most cases, a human reader.

[http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch...](http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2) (Section 5.2.1)

It certainly sounds like "human browsing" was the primary use case. Unless I missed something?

<comment><USER4> Yes, it's obviously the primary use case, since REST is modeled after HTTP. But the keyword is _primary_ \- it doesn't mean it can't or shouldn't be used for machine-driven workflows.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> I don't hate to be the guy to point this out, but I absolutely hated the layout of that website. I am on a 1440x900 screen. I do not want a website to be the god of my computer while I'm reading. This website absolutely did not support scaling on screen. It did not resize when I moved it to half of my screen, and it did not provide me with a scroll-bar at the bottom so that I could adjust my viewing window of the screen to see all of the text per line.</comment>


Real world feedback from a Java dev using Scala - <AUTHOR> http://capecoder.wordpress.com/2012/05/01/my-real-world-impressions-from-using-scala/

<comment><USER2> I'm in the same shoes with OP. Here's how my Scala skill progresses:

In the beginning, I wrote Scala "the Java way", sans semi-colons. Then I omit dots and parenthesis whenever possible ( _foo.do(bar) - > foo do bar_). Then I learn to use immutable declaration ( _var - > val_) and learn that expressions like this:

      var i = 0
      if (something) {
        // Additional logic
        i = 1
      }

Can be made immutable like this:

      val i = {
        if (something) {
          // Additional logic
          1
        } else 0
      }

Then I try to make use its functional goodies like map and fold, and so on. I use IntelliJ with Scala and JRebel (free for Scala!) plugin. JRebel allows you to "hot reload" Scala classes to avoid server restarts.

I admit I'm a frequent lurker in SO when using Scala, as its API doc sucks, and I also dislike its integration with Java, although it's not Scala's fault. For API doc, I think it'd be better if it has examples, which reminds me of ActionScript API docs.

<comment><USER3> Re. SSA, I used to use it by default in Java when I still worked with that language, you don't have to switch to java to have it. Although it _is_ significantly more verbose than in Scala (let alone in e.g. Erlang). Even for the shape you show here it can be done, Java has basic initialization guarantees so you can write:

        final int i;
        if (condition) {
            // logic
            i = 1;
        } else {
            i = 0;
        }

and javac will produce an error if you forget the second branch of the conditional as this would allow an uninitialized `i`.

Although for clarity's sake I'd probably invert the condition so the "default" case is easier to see.

That also works for instance members, javac will allow setting them in a constructor or an initialization block, and will verify that they are set (and not set twice so you can't set the member in a constructor _and_ an initialization block)

<comment><USER3> s/switch to java/switch to scala/ of course.

</comment></comment></comment><comment><USER4> Scala is quite complex, not just the base language, but the standard libraries, the ability to comprehend code by just looking at the lines (implicits!), and the eventual full implications of features as carried out to the logical conclusion by std libs, etc.

I wrote a lengthy email describing a year's worth of experience to scala, and here is an excerpt:

If we think that one of the goals of our developers (jr, mid and even sr) is to fully understand as much of their execution environment and stack as possible, the sheer bulk of the language and its standard libraries becomes worrysome. I could probably re-write java.util.concurrent and java collections from whole cloth if necessary, but I could NOT re-write the Scala collection libraries.

<comment><USER5> Perhaps consider raising your hiring bar. Even young girls still in School in India didn't have trouble using Scala: <http://www.scala-lang.org/node/10714>

</comment></comment><comment><USER6> Api docs do tend to merely provide method signatures, which is great when you know what you are doing, but when you come upon a bunch of generics, implicit parameters, and thats in the docs for the first time, you end up combing through a lot of stuff. In many cases, a simple example use case embedded in the document with console output of the use case would admittedly be very helpful.

</comment><comment><USER7> That's quite similar to how it is with C# and F#. Writing C# code just feels _so_ verbose and cumbersome to do even the most trivial tasks.

And yes, the F# compiler is around 1/8th the speed of the C# compiler, at best - possibly much worse.

<comment><USER8> Does F# have live compilation like C# right now? (If I type invalid C# code, then it tells me right away by underlining the invalid code.)

<comment><USER9> Yes, and a REPL, available both inside VS, and as a command line environment with fsi.exe

</comment></comment></comment><comment><USER10> Doc continues to be a challenge, but there's a lot of good stuff at <http://docs.scala-lang.org/> including an in-depth guide to collections that the author might find helpful.

<comment><USER11> I think being able to community add to the API docs would be very helpful.

For beginners [http://dcsobral.blogspot.com/2011/12/using-scala-api- documen...](http://dcsobral.blogspot.com/2011/12/using-scala-api- documentation.html) may be helpful in learning how to navigate the docs buuut what really helps are examples especially with scala's sometimes long and hard to parse type signatures.

In general I think a site for language docs where people can add comments/examples/content would be extremely useful. Like the php docs but for all languages in the same place. I never use php but comment-able docs are a win.

<comment><USER12> APIdock (<http://apidock.com/>) already has the "commentable multi-project documentation" infrastructure in place, though it only has the Ruby language and two Ruby libraries on it right now.

</comment></comment></comment><comment><USER13> Very interesting comment about the notation for package-level scoping. When I worked with Java, most of the devs I worked alongside also used package-level access for more complicated private methods in order to unit test, but I've never seen that pattern used in Scala.

How do you generally test private methods in Scala? Would an inner class work? Path-dependent types in Scala seem to make this approach more elegant than in Java.

<comment><USER14> I use ScalaTest's PrivateMethodTester for testing private methods.

<comment><AUTHOR> Thanks. Will definitely check it out.</comment></comment></comment>


The Trouble with Counting Aliens - <AUTHOR> https://www.wired.com/story/the-trouble-with-counting-aliens/ <comment><USER2> Sorry but this looks pretty much a BS.</comment>


Review my startup: A tool to force yourself to waste less time on HN - <AUTHOR>

Beeminder (the me-binder!)
This is by me and Bethany Soule (bsoule on HN). It started as a side project to help friends and family track goals like weight loss. A year ago we quit our day jobs, finally launching publicly in October, and yesterday redesigned the front page so that you can actually tell what it's about. (Hopefully. Hence this soliciting of feedback.)
If you already know about StickK ("put a contract out on yourself") then you should adore us. By having the commitment contracts tied to your data you can be far more flexible about what you're committing to.
If you don't know about StickK (and things like akrasia and commitment devices) then it's going to sound like the most ridiculous business plan ever:
You define your goal as a Yellow Brick Road on a graph and report your data every day to the Beeminder bot. If you ever deviate from your yellow brick road, we freeze your graph and you have to pledge (by which we mean pledge actual money) to stay on track on your next attempt. If you go off track again, we charge your credit card. Each additional reset requires an exponentially greater pledge. The idea is that you'll soon reach a motivating amount and actually stay on your yellow brick road from then on. <comment><AUTHOR> This post on LessWrong explains why we think we're better than StickK: [http://lesswrong.com/lw/7z1/antiakrasia_tool_like_stickkcom_...](http://lesswrong.com/lw/7z1/antiakrasia_tool_like_stickkcom_for_data_nerds/)

Excerpt:

StickK is just about the contracts -- Beeminder links it to your data. That has some big advantages:

1\. You don't have to know what you're committing to when you commit, which sounds completely (oxy)moronic but what we mean is that you're committing to keeping your datapoints on a "yellow brick road" which you have control over as you go. You commit to something general like "work out more" or "lose weight" and then decide as you go what that means based on your data.

2\. You have the flexibility to change your contract in light of new information (like, 40 hours of actual focused work per week is damn hard!). ...

</comment><comment><USER2> Link: <http://beeminder.com>

For more on the background philosophy, check out our inaugural blog post, "How to do what you want: Akrasia and self-binding": <http://blog.beeminder.com/akrasia>

<comment><USER3> I like it, really. I just want to give you some feedback from my experience. When I was a lot younger, I used to keep track of a lot data points to reach goals. It usually worked well. but at some point I stopped because most of these goals were not critical and the time spent tracking them would have been better invested doing those things. (But all of this was with pen and paper).

What I'd like would be to know that such a service would be in autopilot mode and how it take care of itself (ideally in a short video) before I sign up,

Hope it helps !!

<comment><AUTHOR> Yeah, I personally really love the graphs that I don't have to manually enter data for, like my weight (we integrate with the Withings scale) or any time- based goal [<http://tagti.me>] or pushups (sort of, thanks to an Android app that Bethany wrote [1]).

Thanks so much for the feedback!

[1] It counts pushups by touching your nose to your phone. You still have to enter on Beeminder but it's an odometer-style goal so no need to enter every day. It would actually be pretty easy to connect it to Beeminder so no data entry is needed at all, if there's demand for that...

</comment></comment></comment><comment><USER4> I just wanted to say I think what you guys are doing is great.

I've found that attaching monetary pledges to my goals is extremely motivating. Even when they're small ($5).

Daniel and Bethany have taken a hard look at the problem of akrasia (failing to do what you want to do) and have created an elegant life-hack to overcome it.</comment>


GitHub Actions and Homebrew = love - <AUTHOR> https://medium.com/@Extrawurst/github-actions-homebrew-%EF%B8%8F-2789ae5023fd <comment><USER2> Right. I'm pretty sure you must have thought about what happens when GitHub goes down when using GitHub Actions.

In the long term, it makes no sense for large orgs to rely solely on a third- party git hosting service like Github to do everything for them. They should use an alternative service that allows self-hosting instead.</comment>