skysight-inc/HackerNews huggingface dataset:
I'm attempting to avoid engaging in your main point, because it would require taking notice of the accusation of fraud.

On the other hand, does an average small business outside the start-up world actually ask?

No. They don't ask for AR's continuity plan, for the same reason they don't ask for their accountant's continuity plan, or their lawyer's continuity plan, etc. Would the good doctor prefer to deal with the same accountant every year, to avoid having to re-explain every decision made in 6 years to a new accountant? Certainly. Are there accounting firms who they could purchase ongoing services with contractually guaranteed continuity from? Yes. Dr. Carter's Dental Office is welcome to call up the Big Five any time Dr. Carter gets worried about his good buddy Ralph closing up shop before tax season next year. He doesn't, partly because he prefers Ralph to the Big Five, and partly because the Big Five is way the heck out of his price range. Dr. Carter and his team of professionals are, in fact, actually in business, and they're fully capable of making decisions like this. If you're of the opinion that Appointment Reminder is the first time Dr. Carter got into a services relationship you're wildly mistaken.

(n.b. I spend about as much on accounting as a small dental practice, and have a great working relationship with my accountant. I also read my contract with him prior to signing. It has specific contractual language about termination which is effectively identical to AR's.)
Um, we're talking about regulators (i.e. law enforcement) and the people they regulate. If the former sees the latter as "a potential business lead" thing have already gotten way, way off track.
possibly apocryphal story, but...

During the recent radio coverage of the current Ashes tour, between England and Australia, I heard a great quote about Sir Donald Bradman, the famous Australian cricket player. It went as follows: In the 1980s, England's fast bowler Bob Willis had the fortune to meet Sir Donald Bradman, legend of cricket. Bradman had been the dominant player from the 1930s and 1940s and the Australian had amassed stats that are unlikely ever to be bettered. Willis was keen to get The Don's view on what he might have averaged if he had played in the modern game. Bradman looked at Willis and replied that he reckoned that he would have averaged about fifty runs per game. Willis expressed surprise, having thought that the great man might have expected to have averaged more. Bradman looked Willis in the eye and then responded along the lines of "Well, I am in my seventies now!".

from http://www.sportinglife360.com/index.php/donald-bradman-cric...
I hope this comment does not get me down voted into oblivion, but just to play the devils advocate here, the guy did sign the non-compete agreement, which, setting aside legal aspects, is kind of like giving your word. I agree, non-compete agreements are stupid, but you don't have to sign them, you can always take a different job that does not require one, probably for less money. What is your word worth?
It's not a question of moving noon around by hours, but moving noon around by minutes or seconds.

It's not sourced since it's what I remember off of navigational history. Whether solar noon is at 11:45 or 12:15 makes little difference for your personal life, but observing solar noon at 11:45 vs 12:15 is a difference of 1/48th the way around the globe longitudinally.
I used to use the latter, in both code and maths, but I have switched to the former. My main reason is that having the operators (logical and otherwise) at the start of the line means they're more likely to be in the same horizontal position, so it's easier to see which lines are continuations of the previous ones.
SEEKING WORK - Remote, possible in-house.

Technologies: HTML5, CSS3, PHP, mySQL, Wordpress, Bootstrap, git, Ruby on Rails, Javascript, Adobe suite.

Freelance UX design and web developer with startup experience. 13 years of experience, full time freelancer for 7 years. Bootstrapped startup, self motivated, quick learner, creative individual. Canadian/American citizenship.

ryan@liquidtrends.com

Links

- Portfolio: http://www.mobiledesignservices.com/resume

- Freelance: http://www.liquidtrends.com

- Dribbble: http://www.dribbble.com/ryanjanvier
The details are different, but s/Amazon/Microsoft and you have a headline from 2005: http://news.cnet.com/Microsoft-sues-over-Google-hire/2100-10...
> The website is pretty clearly operating across state lines. If the website is based in California (just made that up), runs on servers in Texas, and it allows users in Michigan to solicit sex from users in Florida, it's pretty clearly engaging in interstate commerce.

A web site has to police the addresses of user base for user to user interactions? Are their examples where ebay, amazon, or similar service has to proactively police its user or suffer criminal charges for user to user interactions?
one reason to purchase is if you want to download the MP3s (or support the artists directly).

The recommendations are really great, though.
I've never seen or heard of that in the UK: if the green man shows, no vehicle can cross the path. It's quite common for traffic to be moving while some part of the crossing is green, but they wouldn't be allowed to use that lane. Indeed, pedestrians will regularly cross at red man - that's allowed, and people know they need to look out in all directions.

All-red phases are a slightly different issue, and indeed, not all crossings have them
I think there's a lot of value in balancing this approach with smaller sized tests, especially around complex code.

The problem that the article doesn't address is if your test fails finding the failure point isn't as straightforward as it is with smaller units.

However the points made here and in the discussions linked are valid and I think this is the right approach to testing. But I think that there's still lots of value in writing and maintaining tests around smaller units of code. Balancing the two approaches brings us solid test coverage along with easy to debug test failures.
Believe it or not, regulators actually maintain some independence from the Executive. Were that not that case, this would be more of a scandal, as opposed to the standard sleaze that has become (ahem) par for the course in DC.
Probably Git? You know that's been around much longer than Github has, right.
Oh for sure. But it is funny thing to highlight the great goal he got in the last few minutes, when he didn't get a goal for the first 89 or so. Soccer is a funny game though.
Oh? http://files.chumby.com/blocked.html?27.32.227.98
This is a pattern for Amazon: I work for a competitor to Amazon, and they went after us for violating a non-compete after we hired an AWS engineer. Our counsel had reviewed the non-compete before we hired the engineer, and concluded that the non-compete didn't actually prevent an engineer from working for a competitor, but rather prevented much narrower activity like poaching customer lists or supplier relationships. We were somewhat surprised that Amazon aggressively pursued the matter because it seemed so obvious to us that they wouldn't prevail. After Amazon sent us (and, it must be said, the engineer personally) a very nasty letter claiming that the non-compete was being violated, we retained local counsel and sent them an even nastier one back, making clear that we had no intention of backing down. Ultimately, they backed off, but in this process, I learned that Amazon has pursued this particular non-compete "hundreds" of times, and has never (to the best of the knowledge of our local counsel in Seattle) prevailed once. In part this is because Washington allows non-competes, but also doesn't like to infringe on the free flow of labor -- temporary restraining orders preventing an individual from working for a company are extraordinarily rare. (This is in contrast to states like Texas and Massachusetts, where non-competes are infamously enforceable.)

So if Amazon never prevails, why do they do it? One of the peculiar attributes of Amazon's action against us is that it was well publicized within Amazon -- and was apparently a result of outrage by a high-ranking executive after he learned that the former AWS engineer not only was working for a competitor, but had the gumption to open source a technology that he developed here. (Ironically, the executive only learned of all of this when the technology itself became a top story here on HN.) My conclusion from this: this action wasn't actually directed at us -- Amazon is smart enough to know that nothing would come of it with respect to our actions -- but rather at their own employees. That is, Amazon's pursuit of the non-compete against our engineer was their way of shooting an escapee in the back -- and sending a sharp message to any other AWS inmates with similar ambitions.

In terms of an immediate effect, Amazon's move worked to a degree: our next few hires from AWS were slowed a little bit by fear of similar action. That said, the fact that we had prevailed against Amazon also gave these engineers the confidence that we could and would do so again -- and ultimately, it didn't prevent anyone from matriculating. It did, however, have one lasting effect: the engineer that was pursued went from thinking fondly of his years at AWS to hating AWS and Amazon with a white-hot passion that still burns today. In the end, enforcing a non-compete is like erecting a Berlin Wall: if you feel you need it, you have much deeper problems...
Google logins are the absolute worst, now you have to remember which of your accounts you logged in with (like many others here I have 5 active accounts - I really wish they could give me a single identity that would work with all of them).
Tracking this on GitHub: https://github.com/hut8labs/diffscuss/issues/36
eBay Inc tried this a few years ago when Osama Bedier left PayPal for Google's Wallet team. (http://www.wired.com/2011/05/paypal-sues-google-wallet)

I have no idea what the outcome of the case was, but Bedier spent almost 3 years at Google.
If you want that 3-5x multiplier your growth rate better be at least 70% YoY and stable. If, however, on the way to $1M/year in revenue your growth rates the last 4 years were 250%, 100%, 70%, and 55%, a realistic multiplier is more like 2-3x.
Your thinking that 'the effort needs to ring the bell or it doesn't count' is a little short sighted in my opinion. It'd be easy to make the scores higher if that was the big need of football. They could just make the goals larger. Sport is a fun mix of probabilities. The fact that goals are hard to score means that each goal is therefore valued higher, and celebrated a lot more. Do you experience the same thrill watching a goal in football vs a normal 2-pointer in basketball? Definitely not. In addition, goals being a rare event means that the underdogs have a higher chance of victory. If the scores were easy to make, the better team would much more frequently score and therefore win. Since goals are rare, with a combination of one lucky moment and some heroics from your keeper/ the better opponent having a bad day, underdogs frequently win the game- which makes it exciting for all kinds of fans.
As for leaving games on in the background - it's a lot more to do with personal preference than the absolute value of the sport. I watch all 90 mins of soccer but frequently leave american football on in the background as it has so many breaks.
Existential question of the day: If the answers are almost all lies or omissions, what's the point of asking the questions? To get good at spotting the rare honest answer among the PR? And how do you know what's a lie and what isn't? There's no way to verify anything they're telling you unless you know somebody working there.
Sick of Ruby, dynamic typing, side effects, and object-oriented programming
The protocol and the code is open. It doesn't matter who funds it, but let it be also clear that the US government is one of the funders. Also, the government is not one coherent entity that all of its bodies want to spy on people.
This! Yes, why does it even go to public press? In France 60% of programming jobs are through consulting companies, they constantly play the game of no-poaching, and those get solved after commission between the two employers. Either one is also customer of the first, either they pay.
Hasn't been around _that_ long. Wikipedia puts the release date in 2005.
Proposed solution in a picture: http://imgur.com/BEMNXUq
One plus of the former is that you can add a new clause without needing to edit an existing line, makes for cleaner diffs during reviews and makes it such that you wouldn't show up as the last person who touched the existing line in git blame or any other source control equivalent.
Maradona and Messi are two different kind of players from two different eras. Maradona is a mid fielder who can control the game from the centre, whereas Messi is forward who excels in striking and last minute opportunity creation. Perhaps greatness of Maradona may be compared to Zidane. It will not be fair to judge a midfielder on the number of goals scored - midfielder is a strategist - which Maradona was.
The author suggests redirecting the scope of "TDD" to testing his app's public API endpoints, rather than internal functions. His logic is that public API endpoints represent the contracts for business logic with customers, and therefore are the highest level that can be accurately tested.

I am not convinced of this argument. Obviously, it's important to heavily test the endpoints of any API you make public. In fact, that's a situation where you want 100% coverage. However, testing the endpoints of an API does not allow you to forego testing its internals. At best, a passing suite of API endpoints should give you reasonable confidence that the internals are functioning properly.

An API is an abstraction over many moving parts. Any good API will consolidate thousands of lines of business logic into a few endpoints. There is a lot of room for error in the layer of abstraction between API and internal logic. It's entirely possible that a API endpoints could appear to be functioning properly, but actually be relying on broken internal code.

For example, consider a fruit basket API. You can insert fruit into the basket, and check what fruit is in the basket. A suite of tests for the API endpoints could insert fruit, and then check that it's there. In this case, the API is hiding a lot of internal logic. Storage mechanisms, data persistence, fault tolerance, and a slew of other logic decisions are completely opaque to the API consumer.

What if the internal code incorrectly stores the fruit in a temporary file? The API test will pass if it inserts fruit and then checks that it's there. But it is not going to check for that same fruit in an hour. What if it's gone?

Internal logic like data persistence is (rightfully) opaque to API consumers. That means that no testing of API endpoints can validate all internal logic. Therefore, you cannot ignore testing the internal logic in favor of only testing API endpoints.
Git was released in 2005. Git is only 3 years older than Github
Oversight Board Finds Little Wrong With NSA Surveillance Program
I think there's a little bit off in your summary of the post-demise events, but not much. After Chumby closed its doors someone (anonymous investor?) kept paying the server bills for quite a while, presumably as they attempted to find a buyer for the remains including the customer base. Meanwhile one or more former staff (Duane) kept things going on the forums and could deal with a few things on a volunteer basis as his time allowed.

Once it became clear that a purchase wasn't going to happen, Duane was able to purchase it for what I suspect was a fairly small amount of money. That's the point where the change over to "Space Clock" happened, because as it turned out there were some international addresses chewing down amazing amounts of bandwidth, etc. some of them for no clear reason.

I haven't kept track, but at one point there was a USB-bootable local version of the Chumby software available for download, though apps were problematic. I don't know if it improved beyond the level of "choose your apps by putting the files in the right place and editing GUID-like values in a config file" or not.

My wife still uses her Chumby as a clock, but I was actually thinking about stealing it from her so I can use it as a simple streaming audio alarm clock - that functionality is built right in.
When you have a service-oriented architecture with small, atomic services ("microservices"), unit tests are indistinguishable from functional tests: each test suite covers exactly one unit, which performs exactly one function, which maps to exactly one service with exactly one API. (Handily, in such a scenario, the service-registry also doubles as your mocking framework.)

I think unit tests do have one important use: testing library functions, e.g. cryptographic primitives. Most people aren't writing "library code", though; they're employing it.
It seems to be about giving timely advise given the recent take down of of myredbook.com

https://www.eff.org/deeplinks/2014/07/whose-redbook-why-ever...

hackernews thread:
https://news.ycombinator.com/item?id=7974203
Good point. My thoughts:
- Email is not the only option to deliver tokens. You could also go for SMS, or both
- For most registrations such emails are anyway commonplace. Combined with long sessions (where possible), I think the risks of delayed emails are low (compared to guys getting frustrated with the password)
- I'm so far happy with Mandrill. But as you say: random b.s. can happen
Would a site hosted in a country outside the FBI's jurisdiction help?
What if it were a Tor hidden service?
Do you know how to use Tor or Tails? Do you believe your peers do? (Obviously, I'm not in a position to do that myself; I'm asking in the general case.)
The duplication there in each AST node kinda hurts the eyes :)

Also, the type-switch on interface {} is ugly.

Consider how an AST looks like in Haskell:

data AST
= LiteralInt Int
| LiteralFloat Float
| List [AST]
...

And then an eval looks like:

case ast of
LiteralInt int -> ...
LiteralFloat float -> ...
List nodes -> ...

and it is safe, rather than interface{}, you get the AST type and you get exhaustiveness checking that you covered all cases.

Also, if you add an annotation to each AST element (e.g: inferred types), you can very easily and safely map over them, etc.
This, a million times. If nothing else, testing internal logic allows you to more quickly do things like refactor and fix bugs, because you'll know exactly what part of the code is broken (otherwise you'll be shooting in the dark).
I realize you may discount this, coming from HN staff, but I'd like to try to ease your worries a little.

> there are people with knowledge who do this all the time and can get away with it because they know how it works.

I believe you that people say they know, but unless I'm extremely mistaken, most really don't. We see evidence all the time of people trying (but failing) to sneak around HN's anti-ring systems. That's not to say some don't succeed. Some probably do. I'd like very much to get better at catching them.

> And I see these people always show up on the front page.

When you see that, we'd like to know about it. There is a lot that we can (and will) do to investigate those cases. Don't forget that even when the ring detector misses something, there's still a lot of data we can look at if we know to. So please, everyone, email hn@ycombinator.com when someone is gaming HN.

Our goal is to have the best stories on the front page [1]. We don't all agree about what the best stories are, but I think we can agree that they're usually not ones that are only here because someone is promoting something. When we say we want people to vote for things they're interested in, that's not the kind of interest we're talking about.

> Do you just let their posts stay buried or do you give them a second chance?

Good question. We occasionally override the ring penalty when a story has clear merit for HN. (I've commented to that effect in perhaps a dozen of those threads.) But that goes for any story, not just a YC co's. And we're pretty stingy about it.

[1] That's also, by the way, our primary idea of how HN as a forum can help YC's business interests. If HN has the best quality content, the best quality people will want to be here, and some of them will start startups that YC funds. I'm not saying we do have the best quality content—there's a lot to be desired. I'm saying that this is HN's global optimum and we're not interested in trading that away for something less.
Solar system's solid planets and moons rendered as a single continent
When I started working on gcc 1.36 (company I was working for was designing Unix workstations and we were fixing the backend for MC680x0) we used RCS. But I'm not sure it was the original SCM, we didn't even have Internet access then :-) And we got gcc 1.35-36-37 "smuggled" to us on the 1/4" tape.
I'm not saying that at all, my comment was addressed at the parent commenter who said that the federal government couldn't regulate prostitution unless it was part of interstate commerce.

Therefore, the assumption is that the website was engaged in facilitating prostitution. The website may not have been engaged in facilitating prostitution, I have no idea.

There are likely plenty of arguments to be made here (the website is just a meeting place for users, it doesn't promote prostitution etc...)--that the federal government doesn't have the power to regulate a website facilitating prostitution is not one of them.
I'm trying to offer constructive, if harsh, criticism based on my own experience which includes recruiting for similar positions and working with large and small 501(c)(3)'s.

I don't mean to come off as dismissive but to suggest that your write up is vague to the point of being easily dismissed and provide feedback on how someone from outside your local peer group might read this.

And there are organizations out there with great IT and clean data but I and most people in this field have lost months writing hideous combinations of NLP and regular expression to pull data out of old medical records and things and hand validate it or correct for batch effect in supposedly clean data.

I think that fleshing out the projects and areas of investigation you guys already have lined up would go a long ways towards addressing my concerns and making the program more appealing to the typical analytical folks i've worked with. I'd also suggest focusing the intensive course on analytical methods not the tools, this is what will intrigue people with expertise. At the moment it reads like it is focused at people new the the field with no programing experience.

What data sets/types are you using for the Parkinson's thing? My main focus is on analysis methods that resist the noise, imbalance, heterogeneity and other issues typical in extremely wide/multivariate genetic+clinical+proteomic studies...a few sentences about the study in the write up would have told me a lot about if my skills could be useful. (I'm not looking to relocate but I am always open to collaborations and correspondence with people working on similar things.)
I'm not sure why the author attempts to redefine "unit testing" at a higher level of testing. It seems pretty well-accepted that most API tests are, in fact, integration tests. There's no need to use the term "unit test" in this case.

Otherwise, I quite agree. I don't write unit tests. A complete set of integration tests gives me about 80% confidence in the correctness of code. Unit tests might bump that up to 90%, but you'll never get to 100% from testing alone and the substantial effort necessary to get there just isn't worth it.

Testing follows the classic 80/20 rule. Integration tests only take 20% of the effort required for full unit test coverage, but can give you the bulk (80%) of the benefits. For all but the most sensitive of applications, it's probably not worth it to put in the additional 80% effort for a mere 20% gain.