skysight-inc/HackerNews huggingface dataset:
Bulgaria didn't have as high a standard of living as Romania at the time, 2009, but Botosani county on Romania's Moldovan border was the poorest county in the EU. Whether or not it still is, I do not now.
> Is the Thoreau in the Thoreau 2.0 picture wearing Google Glass glasses? As I understand Thoreau, he would today look exactly as he looked then. He surrounded himself with vegetables, beans, trees, critters, and such. Maybe a t-shirt or other more casual clothing than the high-collared stuff in his photograph, but I don't see him using any latest technology. Rather I see him shunning it. I would expect Thoreau would look and act the same if her lived a thousand years from now or a thousand years ago -- connecting with and valuing bean fields, ponds, winter animals, farms, and other parts of nature where people live harmoniously with it.

I'm fairly confident that was a joke.
The only value a scientist gets from publishing a journal article is another publication they can add to their CV. A long list of publications is important for any scientist who wants to get funding, and even grad students need to have that long list of publications on their CV if they hope to get a research job later in life. What the journal provides is its name, and nothing else -- because as I said, everything else that goes into a journal is done by volunteers.

Now, once upon a time, journals served a secondary purpose, which was to distribute scientific results on a global scale. Back then, there was no Internet, and printing enough copies of a journal to satisfy the world's needs required industrial equipment. Fortunately those days are done and over with, but unfortunately we are still dealing with the relics of that bygone age in the form of academic publishing companies. Worse, in fact, since today's publishers are far greedier and for more profiteering than many of the publishers of the past.

Really, were it not for copyright, we could cut publishers out of the equation without any ill effects and have a net gain for society by removing all paywalls from scientific articles.
Google has an interesting way of setting goals for their employees, which is part of group motivation:

http://startuplab.googleventures.com/public-workshops-2013-0...
In Canada and the US, it is common to not payout in the case of suicide within two years of creating the contract (the same as Japan).
It's not true to say that TDD isn't agile. They are orthoganal - you can be agile and do TDD and you can do waterfall development and not do TDD. The fact that you need to change tests to change the software is the whole point - if you change the functionality, you change the tests. In fact, it's not wanting to change the tests that causes the problem here.

Perhaps you have been on bad projects where TDD has been used improperly. However every single agile development team I have worked with has used TDD, and it certainly does not limit things in the way you suggest.

Ironically, Extreme Programming [1], one of the first of the agile methodologies, and many other agile methodologies since, include TDD as a core tenet. So in fact by saying "TDD isn't agile" you are perhaps demonstrating a misunderstanding of what "agile" development was designed to be.

[1] https://en.wikipedia.org/wiki/Extreme_Programming
You need to get more benefit from the abstraction than the cost. I couldn't find it, in cs.

I've made thousands of mistakes (on a daily basis it feels like). In 17 years I don't think I have ever once forgotten to put 'var' in front of a variable declaration.
> TDD won't help you solve problems that you don't already know how to solve

So, those Sudoku testing article fails because the author is breaking rules of TDD. I mean, the first test: test_cells, does so much more than it needs to do to pass the test. He's designing first, and then testing. That's not how TDD works.

If you can't see why that first test is a bad test, you aren't qualified to judge the merits of TDD.

> Of course somebody is going to chip in here and say … you should be testing at the point where you can create a stable API that remains unchanged

That's not true. At least, not the way you phrase it. You are, of course, forgetting that TDD involves 3 steps. Writing a test, Passing that test, and then refactoring. That refactoring includes refactoring the test. API's can, and should change to evolve. That's part of refactoring.

You pretty much repeat the same arguments against TDD that I see time and time again. Arguments born out of misunderstandings. TDD isn't easy. It's challenging, it requires practice and effort. It does take time.

> TDD forces you to decide about one of the hardest parts of development (API design / where to place abstraction boundaries) up front before you have worked out how to solve the problem at all.

Yes, but nothing about TDD prevents you from easily making changes as needed. Again, Refactoring is apart of TDD. You say something like this multiple times, making it seem like refactoring or changing code is some painful process.

It's not. It's trivial. If it's not, your process has a serious problem.
Suicide is something that can never be fully controlled. It may be illegal to do it, but it's a literal inalienable right, no matter how strong the law against it.
Indeed, and it'll be grown increasingly into a platform for subscription-based consumption, when the Pinboard Reader is launched.

You can basically create your own reddit feed of tags, even if you don't intend to use the bookmark feature - which is quite excellent.
I thought this section was particularly good:

"""
He was obsessed with how complexity can creep into unexpected corners of your life, disguised as necessity. He gives the example of a farmer who convinces himself he must eat meat in order to stay strong. Since meat is expensive, the farmer tills more land in order to afford it. And the harder he works, the hungrier he gets, in a vicious spiral.

[...] What I had thought was a convenience had actually been the foundation for a little pyramid of anxieties.

[...] I'm intrigued by this idea of complexity being something adversarial, that sneaks into your life, like a cockroach, and you have to fight to eradicate.
"""

Doesn't just apply to life, but also to software and startups.

I've been running a tech startup about as long as Maciej (though with a very different path / business), and I sometimes wonder about the complexities we now take for granted, 4 years in.

Not just complexities of our business, but also the infrastructure we've re-built, re-factored, re-architected, etc. over the years and our own understanding of the problem space we've "mastered".

We've assembled this tapestry of tools, technologies, processes, cultural practices, customers, partners, etc. And as software engineers, we have "simply accepted" a certain level of complexity.

When the company first started in 2009, it was just two guys sending keystrokes into a fresh vim buffer. No "funding", no "process", no "brand" -- just creation. I think this is what creates nostalgia for the early days of a company's life -- it's the purity and simplicity of it.

I wish I had gotten Maciej's advice earlier and kept a journal.
Nokia Elop Bonus Scandal: Elop refuses smaller bonus, cites divorce
If you are trying to do 14 different things, I don't know why you'd expect TDD to solve that for you. That's a different problem.
Yes, if you can't solve a problem, you certainly can't solve a problem in a supportable manner.

Agile has the concept of Spikes (http://www.scaledagileframework.com/spikes/) for researching new problems. The key point that code is thrown away after completion -- this gives you the freedom to ignore normal methodologies and not have to worry about technical debt.

Presumably, you then go back with this new knowledge and only now concern yourself with writing supportable code.
What i've never understood about coffeescript is, since it compiles to javascript, why not just learn to write javascript in the idioms that coffeescript generates?

No one would have a problem suggesting that a developer who only used jQuery actually learn how to code in standard js without the syntactic sugar. CS doesn't compile to bytecode, it compiles to an actual, human-readable and editable language.

So why not just learn that style of javascript and save yourself the hassle of pretending there's a second scripting language for the web?
Hmm, this is very interesting - a web page that you commonly use can also easily track large amounts of what you type on your computer, and use it as the training data to correlate with the accelometer on your phone; and if you use that web page often, then you're somewhat likely to have their app installed on your phone.
I have never been able to watch or play any 3d games since Wolfenstein 3D.

I would love to join the fun, but after 3 or 4 minutes I become very pale, sweaty and nautious.
Monoamine Oxidase Inhibitor(s). Many antidepressants fall into this category. MAOI's inhibit the enzyme that cleans up several endogenous molecules, like serotonin, and some drugs, like the amphetamines.
>Bringing a drug to market involves many years of careful study and clinical trials that are utterly boring to most researchers in academia.

This sounds like an excellent argument for doing away with medical patents and replacing them with financial incentives (like a percentage of revenue tax on anyone who sells the new drug for a few years) with proceeds going to whoever paid for the clinical trials.
I couldn't help but notice an apparent contradiction. You complain about racism and chauvinism, and yet, you identify the murderer as a "Greek student" instead of as a "deranged student".
Show HN: A template for organizing color palettes
Something's wrong with your setup I think. I have an iPad mini with much less power than an iPad 3 and there is never any lag to speak of with the ios7 animations. Parallax works exactly as it would in real physics to my eyes. Maybe take it in to the apple store and say it's performing slower than it should?
You can already disable the effects; go into accessibility settings and select "Reduce Motion".
> It either relies on a waterfall-like process where the full design is known before-hand and therefore what tests have to be written,

This is that fuzzy line between behavior driven development and test driven development. Sure, you may not be able to write cukes to test how that your social mortgage site is going to work, but you probably should be writing tests to ensure that your internal compound interest code is correct.
Not 14 different things. 14 different approaches to solve the same image recognition problem. Please do not jump to conclusions. I did not say TDD is not useful at a _later_ stage, but at the research phase it is simply more of a burden than help, because the "refactor" step ends up as "drop everything".
IANAL, but one possibility is that Lessig might try to find others auto-threatened by "Liberation Music" (as another poster put it: ha!), and make the case that they are abusing the law and should have an injunction against filing DMCA notices. A bit of a stretch, I know, but one can dream :)
Some info about Henry David Thoreau, including how to correctly pronounce his last name.

http://www.walden.org/thoreau
What designer? The front end guy? The PM? What are you talking about? Have you got an architect making edicts from high?

That in itself sounds like it is fundamentally not agile.

I'm not especially a fan of TDD, but this comment makes no sense to me, it doesn't marry with my experience creating software.

TDD is around individual methods, trying to make them decoupled. It is around unit tests. Changing the design simply means deleting those methods and throwing away those unit tests.

Which you would do anyway.
When tackling a new problem, you still need to build a lot of utility functions that you know how to write. Tests help here.

For example, I'm building a statistical model. I need to load a bunch of data from files, transform it in straightforward ways, then run my model against it. TDD doesn't help me come up with the right model, but it does help me not screw up while loading the files. When my model fails to be predictive, I know the model (rather than the loader) is at fault.
Coverage isn't the same as enumeration of all possible modes. 100% test coverage might mean that all of your "wiring" fits together, but with dynamic languages it may not as runtime information may affect your types and break things.

100% enumeration of runtime behaviors is another property, far stronger than any non-dependent static types today, but also exponentially more difficult than 100% test coverage.

Good static types are a cheap way to get probably halfway between those two on a log scale.
There might or might not be - we still have some our distant evolutionary ancestors; but the nice name for it ("lizard brain") is false.
This is ridiculous. If he had said that the murderer was a male student, would you be complaining about sexism? Identifying someone's race is not racism. He didn't imply anything about Greeks in general.
> I suspect Apple will either want to release an update which gets rid of the [crap] or face an ADA class-action lawsuit.

That would be terrific, and it wouldn't be the first time that regular users got a great boost from efforts to help the disabled. OS X sucked in all sorts of ways too, until they really got their Accessibility story dialed in.

To be one of those awesome guys who quotes himself, back in 2008 when a third-party utility finally was able to leverage the accessibility features to fix OS X's broken, decades-out-of-date window resizing, I said in a blog post[1]:

> That seems to me to be an entirely legitimate use of
> the Mac's Universal Access capabilities, albeit a
> little backwards: in this case, it's the computer that's
> crippled, not the user.

Apple, of course, eventually fixed window-resizing (in 10.7 I believe), and I suspect that they will eventually fix some of these iOS 7 issues, too. But sooner would be better. You don't have to get physically sick to be really sick of seeing some of these too-long/jarring/useless animation effects.

[1]: http://masonmark.com/power-windows-for-your-mac
I think it depends on your development environment. If you're writing something small and it's just you, you'll understand everything that you're doing (hopefully). If you're building a complex system with multiple parties and you're practicing separation and rotation of duties (no one owns any piece of code), then YES. I've gotten to the point that even for interviews where I'm asked to write code, I'll add test cases into whatever I'm building.

I've worked on projects where code isn't tested and I've made a simple change thinking that's all I had to do to fix some "bug" only to find out by the QA team that I've broken three other features. Features which test cases would have been able to spot at build/test time. This took an hour fix and turned it into a week long back and forth with QA and the original developer.

On the other side, I just wrote an iOS game and it has 0 test cases. I pretty much know what's going on, I'm the only developer on the project and I don't see it getting much bigger (famous last words right?).
Though some of you are waxing nostalgic at that simulated CRT display, my first impression was "Good Riddance!". I still have a headache from reading that page.
Start unique and drop the “the” – some thoughts on URLs
It's Django. There wasn't much around when I started it (I think there was only Django CMS).

In similar in some ways to FeinCMS in philosophy and I borrowed a small amount of code from Fein. It's not quite as cleverly coded but actually simpler in some respects (in a good way).

And there are
That's what I thought, but the Wikipedia article states:

"GNU Hurd (usually referred to as the Hurd) is a computer operating system using the GNU Mach kernel designed as a replacement for Unix..."

So it looks like GNU Mach is the kernel.
Well, why not a concept of 'soft' and 'hard' commits (or sub commits, or major and minor)? Let people do what they must, let the logic behind it stand, and give a nice clean history by ignoring the soft commits unless you explicitly access them?
Repectfully, no, you cannot charitably call Taco Bell 'Tex-Mex'. This is easy to remember, because Taco Bell is from Southern California, and Tex-Mex is from... Texas.

A cursory Google or Wikipedia search could clear up your misunderstanding, but if you really want to dig deeper into the topic, I strongly recommend Gustavo Arellano's Taco USA, which is a fine popular history of regional Mexican cuisines in the United States.
> ...with icons apparently floating above subtly animating wallpaper

Now I'm wondering if I have a vision problem I didn't previously know about. I've been unimpressed with the upgrade myself, and one of my biggest complaints is that everything looks so flat that I have a hard time telling text and icons from the background.
Throw her in a federal prison for "hurting national security" and for being a "spy and traitor". Fortunately, she didn't manage to "defect" to some of US' enemies - like Russia - so it should be easy enough to arrest her and keep her there for a year before we come up with a solid list of charges.

Oh - what say you? She's a Senator that has immunity and can't be imprisoned for leaking NSA's classified information? Well, that's great news! I expect a lot more senators to come forward with other juicy classified NSA information then...
If you double click the background it should prompt up a file picker, I'm not really sure if that solves your problem though.
An attacker with that access can also DoS a program that doesn't slurp using the same technique. Also, on a 64-bit system, a DoS is all you can realistically get from this vector anyway. I don't know what happens if you actually fill Python's available address space (it seems pretty difficult), but I'd be shocked if it were a crash, and not an exception.
Please learn the difference between racialism and racism.

Greece's economy has been crumbling, and many all over the world are succumbing to madness. This feels like another test, but how am I to know if someone is deranged?

Don't force me to accept some verdict by law. I don't deserve that...
What I see is that in part the transition from MZscheme to Racket has meant that a new generation of Lisp oriented academics are in PLT leadership roles - this is something Felleisen has long promoted in his own work (e.g. listing junior authors first on joint papers since everyone already knows who he is).

In other words, Racket is now being driven by research into computation and the earlier generation's area of emphasis - the pedagogy of computation - is being treated as a largely solved problem. This is not to say that PLT is no longer pursuing pedagogical projects or that in the past there wasn't significant discovery and invention within computation, only that the How to Design Programs project offers a mature and battle tested framework for teaching introductory programming and there is not a lot of reason to revisit it.

One of the things that attracts me to Racket - beyond the fact that it is a Lisp - is that the documentation is full stack. I was aware of the paper because there is a link within the Racket documentation of the contract system. The payoff from reading a paper that is specifically organized around the language at hand is intellectual continuity and when the language is a Lisp that continuity extends all the way from implementation to the lambda calculus.
One small problem I have with TDD advocacy (as distinct from just TDD) is that it can make it seem like an all-or-nothing proposition.

Either you start all projects and do TDD all the way or you eschew automated testing altogether. And the former is the "right" way to do it and the latter the "wrong" way, ignoring that in practice a little bit of testing goes a long way.

Imagine this. You have just been asked to work on a project with a very short deadline, on a codebase you aren't that familiar with, in a language you aren't that keen on. You are capable with it, but you aren't a big fan. You are going to have to go and add features to this already reasonably large codebase and it has no tests at all because it was hacked together.

What do you do to ensure you don't break it? If it is a web app, write yourself a simple set of automated integration tests that use a ghostdriver-style API like PhantomJS. There's WATIR in Ruby, there's Splinter in Python etc. etc.

You then have some emergency guard rails in place. They won't be the best guard rails. They won't be as good as if you'd been doing testing from day one. But they help you get your head around the application in the large while you are tweaking away with stuff in the small. And because it's not your code, you need some guarantee that it's not breaking.

TDD advocacy is fine but a bit too perfectionist. In the real world, there's lots of untested code. Don't make the perfect the enemy of the good. Apply the Pareto principle: write the simplest test code you can to cover 80% of the existing features. Prioritise by importance ("how many people would the client want to murder if this went wrong when being tested by the end user?"), don't let theology get in the way of you getting shit done.
This makes the front page whereas google being tried for wiretapping does not. No pro google bias here. Move along.
Right, I'm only using descriptions garnered from articles on the homicide, which are written in internationalese.

"Deranged" is baseless opinion. "Deranged or whatever" is arguing for argument's sake. "Anything but racialism" is post-colonial guilt.

I have no reason to engage in any of these practices on the matter.
And just to cut in with a quick response to all those who automatically use this as a call to tort reform:

1) The lady didn't ask for that much; the judge awarded it, after much shenanigans by McDonalds';

2) In the end, it wasn't a couple million, it was reduced by the judge to under $500k.

The case is more complex than most people want to believe.
Inside the fall of BlackBerry: How the smartphone inventor failed to adapt
I've invested in more than one ETF that has closed.

It would be hard to recommend volatility selling to anybody who you've got a fiducial responsibility for. People really don't like drawdowns.
I'm sure a lot will say now that "It was inevitable. Android is made up of multiple OEM's, yadda, yadda...".

But I seem to remember not too long ago that "iPad was the iPod of tablets" or something, and therefore will always have 80+ percent market share. I guess that didn't turn out true.
I think testing is very much something that follows a Pareto curve. You want to be at the right place on the curve, or else you are either missing a lot of relatively easy coverage, or you are spending a lot of time and money for small gains in coverage.

On a tangent, one of my current projects involves a hardware system that interacts with people. That makes testing things much harder than a simple Rails app where there is an abundance of helpful tools to use. Any ideas?

I was looking into this: http://quviq.com/index.html - and it looks interesting. It's quite expensive, but it might be worth it if it can significantly increase and automate test coverage.
"Japan suicide rate is an enigma"

Not so much.