skysight-inc/HackerNews huggingface dataset:
I can't really say, but if you read The Clean Coder we might get on the same page.

fwiw, what I mean when I say "don't test the implementation," is that your test should not test "how" a function or object performs its task when called.

tldr; unit tests should test units -- the smallest amount of functionality possible

A trivial example might be an object that retrieves some data from a persistent store and prints it out. It might have a "fetch" method whose argument is a key in the data store.

You could easily write a test case that checks when "fetch" is called that the data is written to the standard output stream. It would pass and you could go home after a hard day of work.

But if the requirements change and you need it to write to a socket instead and format the data for a binary stream -- you'll have to modify the "fetch" method and the tests.

If we were clever though we'd realize that when we wrote the test to see that "fetch" output its result to standard out we were actually asking the object to do too much and our test was testing several different units of work that could be broken down.

Ideally our hypothetical object would take a couple of callable objects that handle things like printing data to streams and formatting it. Then our test for fetch only has to test one small "unit" of functionality -- not several units (retrieving data, formatting it, printing it to a stream).

hth
Cool, I might try this to give Git a second chance, for now I am resorting to hg-git whenever I have to touch a git project. Sometimes it gets confused when I'm rewriting history on the hg side and pull from the git upstream but overall having a sane UI I feel confident about without googling before every command (or worse, limiting myself to a "safe" subset and using it almost like Subversion, as some of my coworkers) outweighs the occasional snafu.
Download Data Journalism Developer Studio 2012LX From SUSE Gallery
Why Publishers Should Give Away eBooks
> being stuck in the 60's mindset could cause problems

Given that they went into space and landed on the moon in the 60's, that decade might not be a bad place for your mind to rest. It was, in many ways, much more visionary than the times in which we now live.

Not to mention that quite a few groundbreaking technologies were invented in the 60's.

With that said, I do agree that if someone doesn't fit into the culture, that can cause big problems. But, as has been mentioned elsewhere in this thread, the way to avoid that problem is by not hiring those people in the first place.
Stanford Online Courses Postponed, Not Cancelled
We want to ensure that these are high-quality offerings that provide value for students. Unfortunately, the logistics around doing that for so many classes are complex, and it’s taking longer than we expected.
We do expect to roll out all of the advertised classes within the next couple of months.
In case it helps anyone who is like me and isn't concerned about the most secure or optimal setup for all aspects of email and just wants the easiest way to be able to send mail on Ubuntu, what worked for me was this:

sudo apt-get install postfix

Then hit enter a few times to select the defaults.
It can seem that way if you haven't been on the receiving end of these kinds of comments.

For those of us that are somewhat north of 35, it can be a constant struggle to stay relevant in a culture that demands long hours and constant devotion to the company über alles. Once you pick up a wife and maybe some children, companies start to lose interest in you and you find your experience and relevance being downvoted if you ever have to change jobs.

Age discrimination is real and unfortunately, many feel that it's just dandy as long as it never touches anyone you might care about.
You are making a categorical error: One proves algorithms and tests programs.

You can prove programs too, not just algorithms. That's what the entire (exorbitantly expensive) field of verified applications lies upon. Even my college class on formal logic covered the basics of this, and there's billions of dollars worth of extremely high-reliability applications that have been developed using such formal proofs.

For example, Green Hills Software's INTEGRITY operating system has bounds on the runtime and behavior of system calls formally verified, so one can reasonably guarantee that a malicious user cannot DDOS the system by making system calls with unbounded duration.

There are even entire programming languages designed for the sole purpose of making formal, mathematical verification of programs easier.

A program is a representation of an algorithm.

Yes, which is why you have to prove it correct again, since real programming languages, e.g. C, have limitations not typically present in the original algorithm.
I'm going to put my grumpy old man hat on for a second and say that if you don't understand how git works, then you shouldn't be using it. Go use svn or hg or something that has a simpler internal model, and good luck to you.

For me, gits internal model is simply not that hard, and I'm a run of the mill twenty-something year old developer who feels vaguely guilty about not knowing how fundamental data structures and algorithms work. It's a directed acyclic graph that points to items in a content addressable database. Between the progit book and the man pages, I had a pretty good conceptual model of it in an afternoon. I encourage anyone who actually wants to learn it to spend a little time with TFM and get it out of the way.

Otherwise, seriously, quit your whining. The CLI makes intuitive sense to me and I can manipulate the DAG without much mental effort. The worst case scenario is that you rebase public history, and `git help rebase` will tell you how to get yourself out of that mess.
A SOPA you can get behind
Open source has contributed to this. As a business owner, why would I pay for someone to engineer an app when there are so many apps already engineered. I really only need a code mechanic (someone that will get paid less, makes changes to an existing design), a freelancer, or a temporary worker.

Lawyers and doctors don't do this. They might give some freebies, but not to the extent of the open source community.
China: Apple's Land of iPhone Opportunity
How do you get rid of an employee that doesn't fit in with the culture if they're old? Having an employee that doesn't work well with everyone else is absolutely terrible for a company in it's early stages.

Generally if someone doesn't fit with the culture you just fire them. Doesn't matter, old, young, black, gay, or muslim.

how do you handle firing someone that doesn't fit in with the company culture without them claiming age discrimination?

You don't "try to get them to quit" by making the workplace hostile. There is a great talk on this that one of Google's legal contractors gives which basically explains that if you don't think someone is a good fit, in Calfornia at least, you just fire them. It's common that firing someone is unpleasant, the mistake is "trying to make them uncomfortable so they just quit."

That last bit is where people make the big mistakes. It should never be the case where you (as a manager) are thinking "I just wish they would figure it out and leave."
Yahoo! Labs is using it too.

At the beginning I disliked it. Now at my own project I promote this technique and enjoy using it.
Changelog

* Creating and destroying models with create and destroy are now optimistic by default. Pass {wait: true} as an option if you'd like them to wait for a successful server response to proceed.

* Two new properties on views: $el — a cached jQuery (or Zepto) reference to the view's element, and setElement, which should be used instead of manually setting a view's el. It will both set view.el and view.$el correctly, as well as re-delegating events on the new DOM element.

* When you don't know the key in advance, you may now call model.set(key, value) as well as save.

* Multiple models with the same id are no longer allowed in a single collection.

* Added a "sync" event, which triggers whenever a model's state has been successfully synced with the server (create, save, destroy).

* bind and unbind have been renamed to on and off for clarity, following jQuery's lead. The old names are also still supported.

* A Backbone collection's comparator function may now behave either like a sortBy (pass a function that takes a single argument), or like a sort (pass a comparator function that expects two arguments). The comparator function is also now bound by default to the collection — so you can refer to this within it.

* A view's events hash may now also contain direct function values as well as the string names of existing view methods.

* Added shuffle and initial to collections, proxied from Underscore.

* Model#urlRoot may now be defined as a function as well as a value.

* View#attributes may now be defined as a function as well as a value.

* Calling fetch on a collection will now cause all fetched JSON to be run through the collection's model's parse function, if one is defined.

* You may now tell a router to navigate(fragment, {replace: true}), which will either use history.replaceState or location.hash.replace, in order to change the URL without adding a history entry.

* Within a collection's add and remove events, the index of the model being added or removed is now available as options.index.

* Added an undelegateEvents to views, allowing you to manually remove all configured event delegations.

* Although you shouldn't be writing your routes with them in any case — leading slashes (/) are now stripped from routes.
It's interesting to see how few integration tests there are in Basecamp Next. I used to use functional (controller) tests heavily, but in the last year I've switched over to integration tests (plus Capybara) for controllers and views. (I still use unit tests for models.) I really like their power and flexibility, and I've found it convenient and intuitive to test, e.g., a web form by visiting the page and (virtually) clicking "Submit". These are the stats for the current Rails Tutorial sample application (taken from the in-progress book at http://railstutorial.org/book?version=3.2):

$ rake stats
+----------------------+-------+-------+---------+---------+-----+-------+
| Name | Lines | LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Controllers | 164 | 139 | 6 | 23 | 3 | 4 |
| Helpers | 81 | 62 | 0 | 13 | 0 | 2 |
| Models | 102 | 58 | 3 | 6 | 2 | 7 |
| Libraries | 0 | 0 | 0 | 0 | 0 | 0 |
| Model specs | 256 | 198 | 0 | 0 | 0 | 0 |
| Controller specs | 29 | 22 | 0 | 0 | 0 | 0 |
| Request specs | 555 | 424 | 0 | 3 | 0 | 139 |
| Cucumber features | 87 | 34 | 0 | 0 | 0 | 0 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total | 1274 | 937 | 9 | 45 | 5 | 18 |
+----------------------+-------+-------+---------+---------+-----+-------+
Code LOC: 259 Test LOC: 678 Code to Test Ratio: 1:2.6

(Note that "Request specs" is RSpec-speak for "Integration tests".) This is probably a little heavier on the test code side than I would have in an app designed for production rather than pedagogy, but it gives you the basic idea.

Even though there's some minor controversy about testing frameworks in the Ruby community (you can see that I use—gasp!—RSpec), I think it's great that the only way to cause major testing controversy is not to do it.

P.S. I have some reservations about Cucumber, and the Cucumber features are there mainly for Rails Tutorial readers who want a quick introduction to the subject. I don't use Cucumber much myself, although I do have a better appreciation of its virtues than I used to.
Status reports aren't a sign of a broken company. Micro-management, over communication, and unnecessary process are.

Turns out that many broken businesses utilize status reports as a weapon of oppression. However some small tweaks, like reminders, team-level sharing, company-wide search index, and a sane managerial attitude make Snippets popular with many teams at Google.

Just like any tool, status reports can be misused. However, many non-broken businesses are fueled by them. You just might not always call it a status report.

The abstraction over these various tools is that they represent a (1) communication medium, (2) audience, (3) cadence, and (4) similar content structure.

Snippets are (1) emails, sent to (2) everyone on your team, (3) weekly, and contain (4) last week's accomplishments and this week's goals.

Standups are (1) in person meetings, (2) with the whole team, (3) daily, (4) discussing yesterday's accomplishments, today's goals, and identifying opportunities for offline collaboration.

Managerial status reports are (1) emails, (2) to your boss, sent at (3) some frequency, (4) discussing accomplishments, goals, blockers, etc.

You shouldn't do snippets because Google does them. You should figure out a communication medium, cadence, and agenda/template, which works for you and your team.

Disclaimer: I'm a co-founder of http://www.thinkfuse.com

Our project was in part inspired by Google's snippets (which some teams love and some teams hate; we loved them) and also inspired in part by the various enterprise-consumerization startups that are popping up left and right.

Shameless plug: We've got a much grander vision. The most common phrase we hear in meetings is "How the hell did you get me excited about status reports?" We've got top-tier investors and real traction. If you're a talented engineer in Seattle: We're hiring and would love to buy you a beer and get you excited too.
I feel incredibly sorry for Isaac. First he fell into maintaining NPM, now he gets to deal with Node too.

Best of luck to him, he's sure gonna need it!
Sounds like terrible stuff--I had to go to the article to be reminded what Yelp is.
It generally takes multiple offenses before we do something like that. From a comment you made elsewhere on this thread it sounds like you've noticed multiple instances of VB baiting HN, but this is the first I can remember.
"fmt2" is supposed to contain a format string. It's supposed to contain the format string from "fmt". That's how it prints the args from "ap".

The bug is when getprogname() also returns a string containing a format specifier (e.g. "%s"), which is not expected.

Clearly the fix is:

fprintf(stderr, "%s: ", getprogname());
va_start(ap, fmt);
vfprintf(stderr, fmt, ap);
va_end(ap);
fprintf(stderr, "\n");

(Edit for formatting, clarity)
I agree. That is actually why I was so interested in the article. I love going to a physical bookstore, specially B&N.

I really hope whatever replaces the experience is not fully digital.
when there is no forward-history, the user wouldn't be looking for it

The only way I can tell whether or not I have any forward-history is by checking whether or not the forward button is disabled. If the button is altogether missing, I'm going to wonder for a split second if I did something wrong the last time I tried to customize my toolbar.

Well, I guess I'll get used to it after a few days.

Still, I wonder if there's some usability testing data comparing the lack of a button with a disabled button. A disabled button conveys different information from the lack of a button. Every web browser is trying to be minimalistic these days, but there's got to be a point where any further minimalization hurts usability rather than helping it.
That's fascinating, thanks. But has this technology reduced the need for orthodontists? Does it mean that orthodontists now need to learn how to program? I think this is just another example of humans using more software.
If the user needs the prompt to be able to set up user/email, then they're probably not qualified to diagnose what went wrong with their setup if something does go wrong. This way they can get help and fix whatever actually went wrong, rather than just re-setting their username/email and then discovering later that they lost all of their other configuration too.

Users that are capable of diagnosing what went wrong with their repo are also comfortable setting username/email in the config.
>Given that they went into space and landed on the moon in the 60's, that decade might not be a bad place for your mind to rest.

I didn't mean that from a visionary perspective as much as a practical one. For instance, stick someone who's programmed in FORTRAN and COBOL all their life and then set them loose on a newer OO language. The mindset is completely different there. I'm not saying it's impossible, but it's certainly a great deal harder than having a blank slate - and the age makes this a greater problem. The person this article references would be 60+ by now. Entire pillars of programming have shifted since the 60's and now.. that's a lot of damn time in the tech world.

>the way to avoid that problem is by not hiring those people in the first place.

Some things you can't find out until you've actually got someone working with you day by day. You can minimize this somewhat with a decent interview process, but i'd say "culture fit" is one of those concepts that you can't really twig in an interview or two.
This is exactly what happen in my previous company.

The story goes like this:

* one of engineers started sugarcoating his reports to look better than others

* then other engineers notice that they now look bad in eyes of the manager because they were blunt in then assessments, so they started sugarcoating their reports

* quickly the point of these reports is lost (they become garbage with no useful information about problems, challenges, what is actually done, etc.)
Many people write bad tests. So stop doing that, but don't stop writing tests. The reason why every public method should be tested is because changing how a public methods works is going to break everything using that public method. If you must make a change, fix the test along with the method. It broke to remind you to fix the consumers of your API.

Good tests don't depend on implementation. Your tests should tests interfaces instead of objects and anything implementing the interface should pass the tests. If it doesn't, your interface is wrong or your test is wrong.
In python you would use random.choice and fill it with your desired faces, e.g. for one of the dice in the awesome video: random.choice([3,3,3,3,3,6])
Agreed.

I clicked the link, started reading down the landing page while forming the thought "this sounds exactly like what $girlfiend was asking for a few weeks back", until I got down to the $10/month, and just hit close.

She would even _consider_ that sort of price as reasonable.
Ask HN: What are your best productivity hacks?
Time is our most valuable resource, what do you do to get the most utility out of your time? Are there any tools, frameworks, scripts, or websites you would recommend to get things done faster? Any tips or tricks that could help would be appreciated.
> Now we have a single file with the same hash, but two pointers, one legal and one illegal.

That's a good point. The legal principle that bits have colour[1] works -- or ought to work -- equally when it's against the MPAA as for them.

[1]: What Colour Are Your Bits? http://ansuz.sooke.bc.ca/entry/23
If anyone is looking for a tech (or online marketing) internship at an early stage startup in DC, send me an email. Address is in my profile.
This is an odd thing to complain about. Sure it's a UI faux pas, but it's nothing compared the the creative placement of cancel buttons that's been introduced in 4+. It took me a full day to figure out why 90% of the files I downloaded were nowhere to be found.
I think it's also "really easy to get yourself pigeonholed in the '_way_ too expensive' category, where people don't even _consider_ buying from you" (think "Photoshop")
The main point of the NY Times article dude was provoked by was actually "silicon valley no longer makes silicon (hardware)", not that there's age discrimination. The correlation with age is just because hardware used to be the big thing, and thus people who were working here back then did hardware.

Younger people who are unwilling to move away from hardware are often going to be unemployed in Silicon Valley; older designers and software engineers won't be.
envoy looks a lot more verbose than this though . . . if you're really trying to replace shell scripting, having envoy.run(foo) on every line is going to get annoying.

Also, it's not clear on what basis you make this assertion:

> FWIW, re-replaying the stack trace to figure out what was imported and re-implementing it is a horrible idea.

Does it not work?
His attempts to use jurisdiction stripping to remove the First Amendment/Fourteenth Amendment restrictions on establishment of religion from applying to state and local government says otherwise.
CreateSpace wiping out user account - no explanation given.
For instance we had a rule at a place I worked, where we needed to have 80% unit test coverage. And what is described in this article happened. Anytime we'd make a small refactor, we'd have to go update 3-4 test libraries. And if it was a big one, then you have a lot of tests to update. And since some were complex (or since there were a lot of them) people didn't dig into that much. When people finally did it sometimes showed the test wasn't even testing what it was supposed to anymore.

This just means your tests are bad. Write good tests and you won't have this problem.

Integration and functional tests are good, but only as a quick sanity check. The nitty gritty details need to be handled by good unit tests; the functional tests only tell you things like "did the RPC protocol change" or "does the database cache actually cache something".
On (Not) Learning to Code
Feds: Megaupload files may be deleted this week
22-year-old entrepreneur kickstarts ServedBy the Net
I just remember some of my friends and I in high school, sitting around and realizing that we should be more mature than we were, but we were just getting no support from anyone. We matured very slowly in school and we could feel it.
Israel tops cyber-readiness poll but China lags behind
I interned at Apple in 2006 and it was a blast. I worked on the short-lived clickwheel iPod videogames team, one floor below Steve Jobs on the main campus. Apple has a great tradition of having all of its executives give informal hour-long talks with open Q&As to each summer's crop of interns.

It was one of my favorite work experiences, having been an Apple fan since childhood. But it also taught me that I wasn't super interested in working my way up in a huge company as a longterm career, at least at this point in my life.
One problem of that thought it that it will make git commands even more obscure. I.e. when a user will have to use the real git cli, they will be totally lost. I'm not saying it's a bad idea, just something to think about when designing the new cli. Maybe try to stay consistent with the commands while still making them easier to remember and understand. For instance:

git diff STAGE HEAD

seems a bit unconventional to me.
The import hack is the only thing I don't really like (I'd prefer the `from pbs import sh` syntax proposed elsewhere) -- and without reading the code... is piping really piping, or will the function composition example actually consume the first command result fully first?

Anyway, this is a great idea. :)
Yeah that's a good breakdown of the different approaches.

We started using DI, and then had a rule that all unit tests need to be isolated. Which means mocking everything they touch.

For small methods it makes them very fragile, although the other way you end up getting a lot of intertwined tests that can wreak havoc after a lot of tests are made if you're not careful.

I've found that picking what you want to isolate seems to work the best. Our unit tests isolated everything, integration isolated any connections (i.e. DB/Services/etc) which made the tests much less fragile (and much more valuable), but made the errors harder to track down.