skysight-inc/HackerNews huggingface dataset:
I'll venture a yes to both your questions.

Between selecting your data sources, methodology, hypothesis, outlier treatment, and even the choice of publishing or not your findings there is so much room for bias that the author identity can not be ignored.

Now, if other people go do different research on the same hypothesis, and still get the same result, and those people do publish everything they have, then you'll have an objective body of work you can just inspect and trust that it's real.
Fracking awesome advertising
The Art vs. Science of User Experience Design
Is there a term that can cover those consensus bullets in my post that is more suitable than agile? I personally may be ignorant on that part.
Optimize for two variables:

* User Validation or Knowing You Are Building The Right Thing: data flows, ui design, modes, triggers, and so on

* Tech Validation or Knowing You Are Building The Thing Right: unit tests, performance tests and so on.

Focus on selling the devs on this idea.

The rest of the process formalities can be negotiated.

EDIT2: Be careful to include all the dependencies required to fulfill the UV and TV, like scope management in UV. Every part of the process must be justified either as critical for UV or TV.
My first thought as well, even though I know little except the marketing about React. It's like if someone said "Foo: a new competitor to Rails", or "Bar: a new competitor to Vim".

That's not to say I wouldn't be interested in reading about a language that could somehow compete with Vim, if that was an accurate statement.
I would suggest making it an explicitly temporary experiment. Say you're going to do it for a couple weeks, and then see how people like it and ask which parts the team would like to keep.
Is there a glossary of annotations? For example, what is "RELCL?"
You don't have to write the unit tests up front for the full app - in fact doing that could be considered going against agility.

The way TDD is usually done is that the developer writes the tests for the feature she's currently working on, before actually working on the feature.
Unless your claim is that sneezing is classified as a "violent crime", the paper appears to refute this point.
Bread, ale, and wine sensitivity definitly exists. polymermers are really at the heart of the situation.
just like bacteria, fatty acids must be eliminated because the gas will make you toot!
Makes sense. Takeoff and landing are the most critical phases of flight (much less time to correct mistakes).
The unless keyword is very useful for when you're testing an exit condition, e.g., return unless...
Most definitely necessary.
There's one historic reason (it wasn't widely available when Imba was started). Another reason is performance: the last time we benchmarked this `defineProperty` was slower than regular function calls. Maybe it's improved now.

Semantically the biggest difference is that you don't need to do anything special for marking a method as a property:

class List
def length
# …

In this case `list.length` just works. The disadvantage of this is that if you want to get the function itself, there's a separate syntax (`list:length`). Other than that, this is mostly about taste/style.
The reason process annoys the talented is because it gets in their way. This is usually a result of having process for the sake of process and including things in your process that don't actually benefit anyone.

IMO, it's generally easier to start with minimal process and include things as needed to solve specific problems. What this requires is that you're able to identify problems as early as possible.

The last thing you want to do is come up with a 6 month plan and realize in the 5th month that things have veered far off course. This is why teams break things up into sprints. I'd suggest taking your 6 month plan, and as best as you can split all of the tasks into sprints up front. Focus on your end goal, but break it up into manageable pieces. Don't stick to these sprints either. Typically you'd re-evaluate this plan after every sprint, but there's flexibility for you to do what works.

Then there's transparency and communication among team members. This is why a lot of teams do standups, but don't think that means that your team needs to do standups. For some teams that are already good at communicating and keeping each other informed, a simple chat room may be all you need. This is more common with teams that have worked together in the past and are already comfortable with each other. If your team tends to keep to themselves then look into standup meetings. There's plenty of articles on how to run them, what's important is that everyone is brief to make them quick, and you push deeper discussions into a chat after the meeting so those not involved in those discussions can get back to work.
What's the difference between a billionaire and a king? The former "earned" the right to rule the rest of us? This is a sad state for an alleged democracy.
True... but React offers a lot in terms of client-side components, and being able to re-use components outweighs having to use a lesser templating system and/or having to manage two rendering paths for each component. Beyond that, virtual DOM nodes aren't too different from an abstraction of rendering against a compiled template.
World Science Festival: Infinity
It would be far more informative if you could tell us why he isn't making it work? Is he not making a living playing music?

Regardless, music is the ultimate free market. Regardless of how talented you are, if you don't make something that people will vote with their money to see, you won't make any money. This hasn't changed for 50 years and has absolutely nothing to do with the fall of record sales. 30 years ago talented musicians were still being ignored because their genre wasn't fashionable.

Do you really doubt that anyone can make it work as a professional musician? Really? Because I don't work anywhere near the music industry and I know a handful of professional musicians. Sure, there's far more people who play instruments and can't make it work professionally, but that's always been the case.
I read an article from the early 2K's about Oracle developing its 10g database line. It had development teams strategically positioned through the globe so that development could continue 24 hours/day.

I never saw a followup article about the effect on the database quality or issues around handing off a code base from team-to-team multiple times a day. I also have to wonder if Oracle still develops its software that way.
Can you give some details about Imba's diffing?
That's not specific to 'unless' – it's the general postcondition style that's is derived from Ruby. Indeed, for single-line if statement bodies in Ruby, it's the recommended style.

It fits the style of Ruby to try and cut down on syntax noise where it's not needed. Contrast:

save! if !record.persisted? && !record.invalid?
save! unless record.persisted? || record.invalid?

Though I do appreciate it's a bit unusual compared with most other languages – CoffeeScript does owe a lot to Ruby's syntax.
> Configuration bugs, not code bugs, are the most common cause I’ve seen of really bad outages, and nothing else even seems close.

The funny thing about this conclusion is that configuration and code are not dramatically different concepts when you think about it. One of them is "data" and the other "code", but both affect the global behavior of the system. Config variables are often played up as being simpler to manage, but it's actually more complicated from an engineering standpoint, since we know there is code required to support said configuration.

The process is what's dramatically different. "Write a story with acceptance criteria, get it estimated by engineers, get it prioritized by management, wait two weeks for the sprint to be over, wait for QA acceptance, deploy in the middle of the night," vs. "Just change this field located right here in the YAML file..."
Machine Learning: The High Interest Credit Card of Technical Debt
Federal incarcerations are slanted largely because of their limited criminal jurisdiction. 90% of prisoners are ultimately state prisoners. This from the paper's argument.
The main problem with the paper is that it keeps discussing from the "War on Drugs" angle, even though it acknowledges early (from its very title onward) that this is not the main contributor to the huge prison population. It's hard to find an answer to the question which immediately follows, "OK, what is the cause, then?" And then it turns out that through indirect effects, in fact WOD might be a primary driver all the same. Confusing.
On the other hand, the risk of driving from New York to Boston is drastically different from the disk of driving New York to LA. So if you want to make a safety comparison between different transit systems, looking at deaths per passenger mile makes sense for the big picture.

But if all you're looking at is the risk per flight like this, it's like you said, takeoff and landing are where crashes happen regardless of distance.
Thanks for the list.

I asked on purpose again for a couple of reasons: most of the answers were over 1 year old, most focus on why people shouldn't ask and not why they do ask or why they do sign.
Hi, I am currently ScrumMaster + Developer, we adopted "Scrum" as we needed it and the process took us more or less one year.
So I try to give you some ideas from my point of view.

"A week is a sprint", I think it is to short because of the overhead you gain with Planning, Retro and Review.

"developer and designer achieve at least one goal by the end of Friday" I hardly believe tasks and/or stories can be exactly planned like this, a task with lasts exactly one week suited for the experience of the dev is hardly planable.
Also a team commits to the Stories and Features not a single team member, be it a dev or designer

"The one responsible for this task is also appointed to update our weekly change log and schedule board. A single entity/manager comparing the planned schedule with actual development for 6 months is therefore discouraged"
We had various ProductOwner in the beginning, it didn't work out, here I think the principle "Design is not a democracy" applies. Let one keep track of it.

"Stories should be prioritized and categorized by their importance and estimated development time" hardly possible because of dependencies.
I know some Scrumdefenitions say that Tasks and Stories should be independent but in reality they just aren't.

One more tip, don't forget the review and retro and to put the outcome in the feedbackloop.
How do you know it's going to be six months if you're doing an agile cycle, and the scope may change? I mean, I assume you're doing agile because the scope isn't defined - but how you can then know when it'll be delivered I'm unsure.

If it's a predefined project with a defined scope, do waterfall. No, it's not sexy, but it works if you're delivering a defined product, and gives you clear interdependency mapping and critical checkpoints to know if you're on track.
Endowment Spending and Bank Earnings
The specific argument is made that if you decriminalize marijuana, it won't make a difference because there aren't that many incarcerations for marijuana specifically.
It's interesting, for sure, but it doesn't take trick sentences to confuse it. This somewhat opaque but totally realistic sentence:

http://spacy.io/displacy/?full=super%20llamas%20find%20a%20w...

caused it to get all the parts of speech correct, but miss pretty hard on how they are applied (ie, the arrows are pointing to the wrong objects or in some cases even in the wrong direction).
Again that mistake with ASI - I wonder how much people like stepping on the same rake.
The man who drove us into our national ditch
Originally, our plugin just used the Python bundled with Sublime Text. Only after discovering these bugs did we add work-arounds that used the system Python.
Ford built tenements for his factory workers so they would live close to work, and he originated some of the research that 50+ hour weeks are damaging to productivity.
W2016 Applications
Does anyone know when they are opening up the applications for the winter 2016 batch?
Gartner Says Worldwide Smartphone Sales Recorded Slowest Growth Rate Since 2013
Deadlines don't work in software, "Waterfall" is a straw man that no one intentionally does, and "Agile" without alienating talented people is impossible because talented people want to set their own course, not haggle for story points.

Use open allocation instead, but be honest with everyone about the constraints on the project and the ramifications (e.g. project failure and possible harm to the business) if the project isn't done right. It may surprise you, but people will do what you need them to do.

Under open allocation, people are generally looser around man-struation deadlines (i.e. some executive will man-struate if this deadline is missed) but they're more likely to dig deep and hit hard deadlines that actually matter, because they're empowered to work on the important stuff without having to haggle for story points or justify it in some interminable backlog grooming meeting.
Well just don't use the unless keyword then. I've used CS for years and I don't use it.
Being a senior dev doesn't mean 20 years of experience on every part of the stack. It means you deliver value even when things get tough. MVC is so ridiculously simple compared to WebForms I don't even know why you wouldn't sell yourself as top of the bill senior for projects that are MVC based.
"Since the Erlang unit tests are in the same files as the implementation, it’s hard to know exactly how many lines long it is. It gets worse since it implements most of MQTT, the D implementation essentially only implements what’s necessary to run the benchmarks."

Benchmarking the entire spec versus only the minimal set is almost certainly part of the problem here. If you want to benchmark implementations against each other, you should probably make sure they implement the same thing!
What I see the author doing as I read his work is finding a lot of ways to use different definitions of terms to determine which offenders count as "drug offenders". His assumptions are notably different from the assumptions of some other researchers. It seems possible to me, at least on first skimming of these articles, that a lot of the differences in the data that Pfaff uses can be accounted for by these alternative definitions of terms.

For instance, I grant that a "violent offender" who is in jail on a principal charge of shooting a police officer while in the process of being arrested on a drug charge or during a drug raid was indeed violent, and is rightly viewed differently than a "non-violent drug offender".

But we still have to acknowledge that if there were no War On Drugs, then there wouldn't be as many of those drug raids and drug arrests to begin with. The circumstances for many of those violent crimes simply would not occur.

So, the process by which you sort the offenders into batches seems to have a strong impact on the conclusions you make.
Want diverse applicants? Post your job openings here
Minimum Wage Machine
> Plus, people have a tendency to test things at far too low a level.

That's usually what drives people away from TDD. A very good approach for this is described at this article by Dave Hunt: https://medium.com/@davidihunt/tdd-and-complexity-1bbd5ca51e...
>The burden of proof usually lies on the person suggesting a change to an existing process. What arguments would you give to try to convince someone to do TDD?

Arguments don't work. You need to build the tools that let your developers actually write sensible tests (i.e. tests which mimic user stories).

Once the tools are there the process becomes fairly natural and the upsides become obvious.

Some people call this BDD. It doesn't really matter what it's called, but it's generally a faster and less risky approach to programming.
Backing Up Linux with Duply and Duplicity to Openstack Swift
If ever a paper needed a proper appendix its this one.

As a minimum I'd want to see the orientation of the town against it's topographical features and the orientation of the Roman roads connecting the town with its neighbours which would seem like the obvious alternate hypotheses to explain towns' orientations.
First time I heard about it, they were explicit in saying it was an acqui-hire. In terms of what they've accomplished (at least publicly), DeepMind is less of a company and more a consortium of preeminent collection of AI experts.
> I don't think such an abstract idea could possibly be the primary opposition to any policy.

Then why have a big, green statue on an island off the shore of New Jersey? What does that stand for?
And Akamai's is inspired by http://http2.golang.org/gophertiles (which they acknowledge).
This lets you run the images under KVM: https://github.com/lentinj/ie-vm
How is web2py doing?
Page 194/22 makes an interesting point:

Drug inmates’ share of unique offenders is basically the same as their share of inmates: about 20%, or 26% if we count those convicted of both drug and non-drug offenses as
“drug offenders,” compared to 17% of the total stock

When you look at state and local prison statistics, or at least the ones I've looked at during message board arguments, you quickly see that drug crimes do not dominate; in the midwest, the dominating crime appears to be domestic violence.

A common rebuttal to that point is that at any point in time, there may be more domestic violence inmates in prison, but the overall flow of drug offenders is greater: they serve shorter but more frequent sentences; the "installment plan", as the author puts it.

The statistics don't appear to bear that out. The tables that precede this point are interesting, too. To the extent that prison is a "revolving door" for inmates, that too does not appear to be the explaining factor for mass incarceration.
There is also dimple.js [0] that is built on top of d3 and very easy to use, or TauChart [0], that was submitted 3 weeks ago on HN. I never used TauChart but I will give it a shot next time I need to do some graph because it looks really great.

[0] http://dimplejs.org/

[1] http://blog.taucharts.com/taucharts-data-focused-charting-li...
Imba supports the syntax for IDs and classes:

<label#foo.bar .baz=isBaz> "Label"

compiles to:

ti$('label','foo').flag('bar').flag('baz',this.isBaz()).setText("Label").end()

where `flag` is a method which adds to the class list (unless the second argument is falsey).
Anti-immigration Sweden Democrats become country’s largest party
6 months defines the ultimate release date. What we are planning is having a product ready in less than 5 with almost all major features and to add as much as we can (without rushing and breaking everything) until the release date.

The good thing is, almost all major features are the ones the team already had previous experiences before. We depend on a good analysis and our experience to be honest.
I find the mental image of this happening on the Martian surface quite amusing. Imagine an alien ship landing in your backyard, slowly extending an ominous robotic appendage and then... taking a 50 selfies.
A thousand times this. The retrospective blows all the other elements of $YOUR_FAVOURITE_PROCESS out of the water.

3 things about it: if you do sprints, and they have busy beginnings and endings, then there's no harm in planning the retrospective halfway the sprint instead of at the end. Improvements can be made at any time. Also, if your sprints are weeks, consider making the retrospective bi-weekly, that's usually enough.

Second, don't skip the retrospective. It's never urgent, but it's very important. Every team is different and every situation is different, and no agile book can cover all cases. The retrospective makes you own your process, makes the entire team feel like their opinion matters. It improves both effectiveness and morale. Give it time - especially in the beginning it might last 2 hours easily. It's worth that.

Finally, do the retrospective right. You want actionable results out of it. If it's just a complaining session, you're missing out on its value.

What I usually do is this: I make a poster with 3 columns, :-), :-/ and !. Every team member has to make at least 2 green and 2 red sticky notes, on which great stuff and improvement points are written, respectively. More is OK, less is not. This forces them to really think about what could be better even if on first thought they think things are going pretty OK.

Make every team member put the sticky note on the board in the left two columns and explain what it's about and why it matters. Have people group sticky notes that are about roughly the same thing. Finally, and this is the part people tend to forget, distill a bunch of action points for the third column that will help tackle the problems in the 2nd column. Make these actionable, assignable. You might want to make them tasks in your scrum process, just like programming tasks. Without action points, a retrospective is mostly a waste of time.

If a discussion about one action point is long or very technical (discussions about how to use source control come to mind), ask the people who care about it to discuss it amongst each other present the solution a day later. This works great for distributed teams too ("Problem: the git is becoming a mess. Solution: $NAME makes a Slack channel and presents the outcome tomorrow"). Everybody who doesn't involve himself in that discussion is expected to agree automatically.

You can't improve the process super much in a short amount of time. If you make too many action points, half of them will not get done - people need to make software, too! So if there's, say, >4 real decent problems in column 2, ask the team to score problems and pick the ones with the highest score. One good way is to give everyone 3 votes that they can arbitrarily spread across the problem stickies (multiple votes per sticky allowed). Pick the 4 problems with the most points.

Consider using real stickies and not computer stuff, even if your team is partly remote. Tangible things that you move across a board somehow makes things seem more real, like they matter more.

Good luck!
Define "good conditions", it's a judgement of value, based on subjective perception.

I find it quite hard to work 70 hours/week even if my work is very well organized (my main productivity drain) and I'm working at home, with my own setup in an environment I crafted for being distraction-free and really comfortable.

I can work for at most a week at the pace of 70 hours/week, after that I know I'll really drop my productivity even when I'm liking what I'm doing and truly motivated...

That's my personal experience after my first 9 years in the industry, having worked on open plan offices, team-rooms offices and at home for a couple of years.
Crappy data, as the author points out.
It may not be representative of the average page, but there are certainly ones that id does. When you load into our HTML5 game, you download over 1,000 PNG images on your first load. HTTP/2 is pretty exciting for us in that regard since we should see a significant improvement in load times.
Mithril author here.

It does appear to have a React-like engine here: https://github.com/somebee/imba/blob/master/src/imba/dom.sta..., but from a quick glance, I can't tell if the quality of the engine is any good (e.g. whether it supports lifecycle methods, efficient sorts, jQuery plugins, etc) because there are no docs and I don't really have time to read the whole codebase right now. Same goes for the speed claim: can't tell if it's actual speed or "cheating" by batching multiple redraws on rAF while not batching them in the React demo. I'm guessing the latter.

Also, I'm not sure I agree with claim of readable output js: http://somebee.github.io/todomvc-render-benchmark/todomvc/im... (look at tag.prototype.render). It's not exactly clean, although it's not terrible either.

With that being said, the language does look like it has some improvements over Coffeescript. The lack of docs is a showstopper for me, however.