skysight-inc/HackerNews huggingface dataset:
I've been a TDD practitioner for a while now and I've lately started to question the value of doing the refactor step within the red/green cycle, even if the code to make the tests green is a horrible kludge. Sure it's going to add technical debt to your project, but I can't shake the feeling like it is usually premature optimization of the maintainability of the code. Especially if it is a new feature, the requirements of maintainability seem like they're probably pretty low at first since you could find out that the feature was completely unnecessary in the first place for example.

In a talk once, I heard an offhand remark that a good signal that a method needs refactored is if you're frequently fixing bugs in it because it signals you don't have a good grasp on what the method is supposed to be doing, and I've started trying to use that rule in side projects to optimize more for getting things done inthe few hours on nights and weekends I have to work on them.
Well, that certainly is better advice than mine! :P
FreeBSD 9.2 tagged in SVN
Speed is a byproduct of precision
Perl6 & Rebol are some other examples of dynamic languages which come with optional typing.

NB. And I believe Perl6 in certain cases will/can raise compile-time type errors.
See: http://www.skybert.net/emacs/java. With Java, Emacs can just talk to the Eclipse Java Compiler, since it exposes an API. Same thing with Clang--it exposes an API which is used by XCode to support interactive feedback, and Emacs can consume it too. The Open Dylan compiler was originally intended to interface tightly with the Open Dylan Windows IDE, and that interface has been repurposed to interface with Emacs.
Is TDD worth it?

Yes. It helps you code much faster. Tests run soooo much better than the brittle look-and-poke method of testing your implementation.

Also much more reliable.

TDD might not be worth it if you're working in a strictly typed language with no side-effects, or it might be a bit less worth it. But in a dynamic or non-typed language you have to do that half of the compiler's work in tests. Especially if there's more than one person touching your code.
FAA: smartphone and tablet use should be allowed during takeoff and landing
Game of Life News: Prime numbers (2010)
So, at my old job, we had 'TDD', but we weren't particularly good about it. Maybe it's because Python's testing frameworks aren't as worked out as Ruby, maybe it was because we were lazy. I genuinely don't know, I wasn't trying hard at the philosophy.

But when we finally got to work at my new job, our lead made TDD a requirement. Every time. Red. Green. Refactor. I still screw it up sometimes(as he'll attest), but God, it's like a relevation.

Probably the nicest part, is simply being able to just know every time that you don't need to be scared of a bad git merge. Scared of hunting down a bug that was made 3 weeks ago but no one noticed till now. Scared of deploys.

All of that is mindless for us. Pull down master, merge it in, run the tests, be happy. Pull Request, code review, merge to master, let Travis-CI handle the deploy.

It helps keep code more simple, makes the API more useful, and to me, I don't know that I can go back. The moment you're past week 2 or 3 of building with it, it's invaluable.
I've done Extreme Programming (cf. _Extreme Programming Explained_ et al) approaches on a team of about that size and it worked okay, but the deadlines weren't as hard. The pair-programming aspects helped keep everyone informed about what sort of implementation decisions and tools were being made (quite useful on a team of eight) without bogging things down with meetings, and it also helped keep people very focused... and also honest about actually being TDD, as in "don't write a single line of code which isn't necessary to make some test pass", which helps keep you from overengineering some part of the code and helps you meet deadlines.

But it's hard to say whether it'd work, because (a) your problem is described very vaguely, and (b) your team might not be up for it (the classic problem), and (c) even if they were up for it, it's a process they likely haven't practiced much, so that makes it harder
There is no parallel between "works funded by American taxpayers" and "works funded by EU taxpayers". The un-copyright of works funded by American taxpayers comes from a specific exception in USA laws - there is no such statement in European legislation; so while ethically the situations may seem the same, legally they are very different.
I can't wait for presbyopia to hit Jony Ive. The clock on the lock screen was nearly unreadable without my glasses until I found the bold text setting.
10 People Who Won’t Be Happy As Entrepreneurs
Somehow, I feel it is within people's right to self-determination to be free to choose suicide. And yet, I think I'd be very sad if a close friend committed suicide.
Well, in my opinion, the advices are practical.

Some of them require a little bit more of research by the user, but the advices are practical all of them.
TDD won't help you solve problems that you don't already know how to solve: http://ravimohan.blogspot.co.uk/2007/04/learning-from-sudoku...

In fact it only gets in your way. Solving problems that are new (to you) involves writing code to find out if a certain approach works, then throwing it away and trying something else. TDD makes that process a lot slower, and makes people more reluctant to throw away incorrect models of the problem that they have codified into tests without even realising it.

Of course somebody is going to chip in here and say that if the above is happening then you are writing your tests at the wrong level of abstraction and that you should be testing at the point where you can create a stable API that remains unchanged while you throw away the speculative implementations underneath. But if you are tacking a new problem you have no idea where those boundaries lie. It's hard enough to determine that for problems that you already understand and have working solutions for, never mind ones you don't. 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. Either that or you just write vast vast numbers of trivial tests for every single function that you write (which does seem to be what some TDD tutorials advocate), but then you are creating a huge maintenance burden for the future where any change to the code is going to necessitate rewriting dozens of tests.

I would argue that TDD only works if you are solving problems that you are very familiar with. By the time you are writing your 5th CRUD web app you probably have decent mental model of the parts you need before you start. I feel that a lot of the love for TDD comes from people who spend most of their time working on problems they already solved dozens of times before, but they learned how to solve them before they discovered TDD.

For people first learning how to code it is absolute death. It discourages people from doing the most important thing they need to learn: throwing code away.
don't agree. your edge case is very edge. most 'guests' of people in nyc are out of town friends/family that highly respect and treat the place as their own.
airbnb people are not incentivized to treat it like their own unless they are that kind of person. they will litter in the hall ways, make loud noise, etc etc.
1. I'm still relatively new to git, so haven't looked into branching, etc., yet. Worst case scenario, add other branches to the post-commit file. 2. It really is intended as a "backup", if I was looking to interact with more machines, I'd setup a central repository that everybody could commit to, and individuals could still use this to backup their local repos.
It should be pointed out that what's actually being discussed is whether TDD is better than not writing tests. What's not being discussed is whether, if you commit to writing tests, there are more effective ways of doing it.
An article like this reminds me of some of my own roots in consumer behavior research and classic market research. Formal models of finding feature-to-market fit are not particularly new. One that comes to mind is the Kano Model. I tracked down an article that I co-authored back in 1998. http://www.quirks.com/articles/a1998/19981002.aspx In that article we gave an overview of the model. I find the model conceptually helpful but I was less enamored with the measurement methods.
What I find shocking is life insurance companies paying out the family of the insured if he/she commits suicide. As far as I know, there is no such clause on life insurance contracts in the Europe (and I believe the U.S. as well).

Surely , as one of the first steps towards reducing the suicide rate in Japan, insurance companies should stop incentivizing suicide.
This guy is a little too souped on optional type-checking. This has existed in erlang for years, in the form of dialyzer (which allows for compile time validation of complex nested data structures), and in any dynamic language a good developer is using pre-checks & post-checks (in the case of js) or a combination of tagged values and pattern matching to ensure type-checking at runtime.

It's a nice feature, but calling it "one of the biggest advancements to dynamic programming languages in the last few decades" is ignorant.
Senator Feinstein Admits the NSA Taps the Internet Backbone
Yes, this is the fallacy that TDD advocates use every time (even after it gets pointed out to them repeatedly). They pretend that anybody who doesn't use TDD isn't writing tests at all. It's incredibly frustrating.
Not unpopular at all. I've been considering this precise thought myself. So far haven't bailed yet, but still looking into it.

Concerns are that once I make my own, I will make the same mistakes, and in the end it would have been fruitless.
AFNetworking is one of those libraries that is if I were to remake it, I'd make similar mistakes and end up hating what I made.
I'd argue that from the perspective of an operating system vetting security, a good microkernel implementation with userspace drivers would be a great win. Even when you can vet the entire linux code base (for the most part) and use only the free drivers, you still have multiple attack vectors available to possibly get code running in kernel space. Which is bad.

A lot of people (myself included) probably don't think Linux is the last kernel to rule them all, ever. It doesn't distribute itself well, it is quite large, and its speed is derived from its massive developer staff. Simplifying your kernel doesn't really matter when it has hundreds of active contributors, but what about in a hundred years when all the current Linux devs are gone, and you have to try to get new generations to adopt the code base and maintain it?
my first thought was getting 6 months of his time for 20K seems like an incredible bargain.
The Internet is Broken....
What if I fail?
Working on my application to YC, I thought of this little post I wrote last year, and I thought it might inspire and encourage someone to take the decision of pursuing a life-changing dream. :)
Cool, are these APIs buffer based or area based? I mean, when you make a change, do you get the message: the buffer has changed, or is there an area-based damage-repair cycle as in Eclipse or Visual Studio?
Great copywriting! Go for it dude!
Good luck there...
Yes, this is what I've been saying all along. CS does not alter the semantics of JS, it is just a different syntax for the same language. A PL is not just its syntax. I sometimes hear new programmers say something like "it's easy to learn more programming languages once you know one, it's just syntax" and I'm not sure where they're getting this idea from :(
I do love CS and I don't think people should answer js questions writing CS code. This is just rude. If you write your blog in CS, it's your choice, it just limits your audience.

Seeing such an angry reaction about CS is a good news, it just means that it is popular.

And for the ones who think CS is just pretty js, I suggest this reading http://aseemk.com/talks/intro-to-coffeescript
If you were to ask anyone in my office, you'd hear how much I praise TDD as a software development practice. However, when I'm absolutely clueless as to how to even begin to tackle a technical problem (usually due to not enough understanding of the overall system requirements), then I start by spiking the problem - trying to get a feel as to everything that's required. This initial spiking I wouldn't test-drive, as it's a learning process and not production-ready code.

After I've got a strong enough grasp as to the overall requirements, then I throw away this spiked code to start fresh, working along similar lines to 'programming by wishful thinking' whilst keeping the original spiked out structure in mind.

By following a strong TDD philosophy, it's easier for me to throw away my initial 'spiked out' code base for a couple of reasons:

1. Personal experience of how much better a test-driven code base can be than ones I've later tried to wrap tests around/dismantled in the process.
2. Having the understanding from the get-go that this code is not 'production-ready', and should not be considered reliable, but as a very fast learning experience.
3. Knowing that I've spent a small time prototyping as preparation, and having this laid out as an overall part of the process means I'm not considering this time 'wasted'.
I've been grieving two years now. She was "brutally murdered" by a Greek student, in Hamburg, Germany.

I had nightmares for 3 months. Insomnia and loss of love for code ensued, as I created barriers with the world.

All my community could say is "it happens to anyone." And I take things too literally, perchance. I doubt I could live through this again, in a world where we are killing everyone from autistics to Jewish peoples to student tourists with cameras.

But what is more I am now hyperaware. I long for sincere eyes. Some see it, others simply attack. Others notice this of me as well, and they must discover the mystery...with all sorts of tests. Yes, so I have sensitive hearing and I rock when hungry. Does that make me a predator? I want the staring to stop. But the basic fear: it could happen to anyone. Now I am reminded quite frequently here in Austin that random and bad people are simply picked up off of the street and killed, randomly, when all I have is a broken heart.

Until they run me off with that one last death or racist joke that makes upper society's configurable moral compass quite unappealing, and its fascination with tastelessness and unchecked chauvenism as the lingua franca of capability.

People are often too ugly inside to warrant participation in this "fear market."
Vote for this girl and help her fight for equality in education
Please vote this video and share it
Html5 canvas plasma particles
Ask HN: How to do auto-renewal properly?
I was wondering if there are any best-practices for doing auto-renewal (i.e. roll into subscription) after a trial. Anyone has done any testing on this? It seams that in many cases customers are simply not aware that they will be billed automatically at the end of their trial even-though they are reminded several times. Has anyone tested this?
> ... says Corynne McSherry, an attorney with the Electronic Frontier Foundation, a nonprofit digital rights group, who is representing Lessig

Wow, not even the top legal scholars in a field, pursuing a case in their own field, are willing to represent themselves. Why is that? I'd think that Lessig would feel safe representing himself in this case.
Minimalist - Gesture Based Reminders
Tarsnap logo contest
What I think's going to ultimately stop these sorts of shenanigans is that enough people are going to get wise to it and start exploiting them. We'll be a nation of extreme couponers.

Then it just won't be profitable to try to dupe people anymore.
I use Coffee everyday, and I think the features most worth looking at are that every statement is an expression, list comprehensions and the "do" statement (for closing over variables in loops).

And I'm a seasoned JavaScripter. Not a hater either. I just truly believe the benefit is there, and I urge you to take a second look. The syntax won't take you long if you put your mind to it.
I couldn't help but think, would Stallman have used something like Kickstarter?, had it existed back then. Or would he have perhaps added a bitcoin address for donations, if it existed?
As long as the name is unique and not offensive, what does it matter?
What happens if they lose their default usage on reddit, just like quickmeme did? I'm not saying that will happen or that imgur hasn't reached the point where it isn't solely reliant on reddit, but it surely is a big risk to any valuation.
I've found a good approach to resolving the last issue is to write the documentation for the method. This forces you to think about what you want it to do outside of the implementation.
My problem with TDD is that it, fundamentally, isn't agile. It either relies on a waterfall-like process where the full design is known before-hand and therefore what tests have to be written, or it locks a programmer (and designer) into a position where to iterate and/or backtrack would require not only new code to be written but new tests.

It it is very hard for a designer to ask for changes once tests are written.

I much prefer a looser arrangement where code (and design) are gradually locked down after prototyping, backtracking and iteration. Code gets thrown away and rewritten but tests are only created once — after the implementation (and by definition the design) is locked-down. It is the very generation of the tests that tells the world that this design is unlikely to change and documentation is safe to create, performance tests & optimisation passes are able to be made.

Of course, after tests are created, a programmer is free to refactor safely and replace all the code as long as the tests continue to pass.

There are occasions where it makes good sense though. For instance, if you are writing a Maths library or the core business logic of an accounting app. However, these are both essentially examples of a waterfall-like development process.
From my experience, I've found that TDD is mostly valuable where writing the test will make writing the code more efficient. A lot of the times its because manually testing it to get the code right will add significant amount of time and then you will still need to unit test anyways. If I don't know exactly what I need to do, sometimes I will write the code to get a proof-of-concept working then just comment it out. Then I write the tests and uncomment the code as the tests are written to make sure I have proper coverage and I haven't missed anything.

I hate writing tests that require me to do any kind of boilerplate code. Tests should (theoretically) only set up and exercise whatever is needed for that test. I think if you are able to do that (I've had success with AutoFixture for .NET as an example) then you'll feel a lot less bad about throwing away tests and they will also be much much faster to write. When writing tests is tedious or brittle, then I feel they are a chore and am less likely to write them to begin with.
If you liked Maciej's talk, you should definitely check out his blog: http://idlewords.com

Warning: kiss the next several hours goodbye because he's simply an outstandingly interesting and funny writer - imagine something like a cross between Bill Bryson and Douglas Adams and you wouldn't be too far off the mark.
wow your in for treat, pinboard is fantastic
sometimes you can't even really express what the problem is, until you've taken a stab a solving it. The problem might be something like 'This feature is awkward and doesn't feel quite right.' When I'm doing exploratory coding, I need to be able to feel my way through a problem. I have yet to learn to do that from the vantage of tests, and am somewhat skeptical that I ever will.
Absolutely! In the past I worked on an image recognition project where I implemented, tried and thrown away 14 distinct algorithms/approaches (not counting variants!) for a particular problem. TDD is unfit for this because you tend to commit yourself to the set of tests instead of throwing all of them out (all of the approaches were fundamentally different and I had soft real requirements -- so optimized representations were a must). Of course we had some unit tests, but not written in TDD style since the goal was to find the correct approach -- not the correct implementation.
It seems like there are a sea of absolute assertions with few facts backing them up - people seem to love either saying that TDD is better or TDD is worse, and it seems that the only data ever really offered on the subject is anecdotal opinion.

We can do better than this. This study[1] at Microsoft reveals that TDD results in a defect reduction rate of between 40% and 90%, at a cost of 15%-35% increased development time. So, what's the best approach? It now becomes a business question. If speed of delivery is crucial and quality less so, don't use TDD. If quality is more important that speed, use TDD.

And finally, everyone involved in building software owes it to themselves to take an hour to go and watch this excellent video by Greg Wilson entitled "What We Actually Know About Software Development, and Why We Believe It's True" [2], and then perhaps dive in to the list of references from it [3], because you will find yourself more actually informed than anecdote and opinion will ever get you.

[1] http://research.microsoft.com/en-us/groups/ese/nagappan_tdd....
[2] http://vimeo.com/9270320
[3] http://www.gdb.me/computing/citations-greg-wilson-cusec.html
This made me install an Android app (Seismograph) to test to see how my Nexus 4 picked up my key presses. I had it set to the maximum sample rate, with my phone on the desk as close to my laptop as possible whilst not touching it, and it couldn't pick up anything. I suspect therefore this is more of an issue for to-the-desk peripheral keyboards.

It does make me wonder though if the sound of each individual key press is subtle and unique enough to be identified.
I find the inclusion of the quote from Bob Cronin the remix maker smells of false hope.

Suppose Lessig wins the case. The greatest impact to record labels I could foresee is they would have to be more careful about their takedown requests.

It sounds like a favorable outcome for Lessig isn't going to turn the world of youtube copyright upside down and automatically grant an umbrella to legitimize works in a legal grey area. They're still going to receive takedown requests, and they're still going to have no recourse.
The point of refactoring is to make the code cleaner and easier to understand.
> TDD won't help you solve problems that you don't already know how to solve:

I talk a lot about web application security. The following line from flesh and blood developers on multiple occasions:

"Shouldn't your tests catch security vulnerabilities?"

To which I always respond:

"Yeah sure, they'll catch the vulnerabilities that you already thought of"

I've personally seen codebases with test suites that cost (even with the most conservative estimates of time spent and day rate) upwards of 300,000 USD with 100% coverage that allowed an anonymous client to drop the users table.

If a lack of security bugs (and therefore bugs in general) is any indicator of software quality, TDD has yet to impress me in the wild.

My development process has always been to prototype out three or four implementations, evaluate them against the known use cases and then settle on a final API design. Then I'm ready to do TDD. Glad to know I'm not the only one who works roughly this way.

It also bugs me a little that many otherwise intelligent developers use TDD as their sole software design tool much of the time. The exact term they use for this is using tests to "drive out" a design. While I understand this may work in textbook examples, in real life I've seen the concept being used to justify designs that clearly aren't fit for purpose.