skysight-inc/HackerNews huggingface dataset:
Probably worth bringing up Steve Yegge's 2006 "Execution in the Kingdom of the Nouns":
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

I don't think there is a single right answer that is applicable in all cases. But over time, I've come to believe that as a default, code works well when it resembles how you'd ideally explain the service to an extremely intelligent, non-technical person with domain experience. This makes for code that is easy to understand, collaborate around, and modify given changing objectives.

That means creating "Policy" and especially "Service" models--extra nouns--very sparingly. For example, an Elevator was once a nounification of a verb, but people understood it, so it makes sense as a class. ElevatorDoor's good too, but ElevatorDoorOpeningService is probably not good. This is absolutely at odds with strict application of the Single Responsibility Principle.
It'll be interesting to see what happens when Apple's TV is released. I suspect the resale value of all other televisions will crater as everyone tries to sell their old TV (and potential used purchasers instead purchase new Apple TVs).
Yup, it's perhaps a tough PR sell because it create the potential for misaligned incentives, but I don't think it is a totally crazy idea.

I'm pretty sure Microsoft waives the fee for their paid TechNet support if the problem was due to a legitimate bug or problem on their end.
Aside from starting at 8% instead of 0, what else is wrong with it?
Python.org Redesign Request For Proposals
http://www.cnbc.com/id/47537683
right. because starting with lowercase changes the meaning of what i wrote unlike loose <-> lose, which are totally, like, the same thing.
Human Beings Weren’t Designed To Bump Into Each Other In Hallways
How Apple Could Play the Bigger-Display iPhone Thing at WWDC
> So if your address is jsmith@gmail.com, you can send email to (or login with) j.smith@gmail.com or jsmit.h@gmail.com.... at least until someone registers jsmit.h@gmail.com!

Uh, if this is true it's a security abomination. I'm pretty sure Gmail doesn't allow registration with a login that would be considered the same as an already registered one (but I'm too lazy to check a few to confirm, just because I refuse to believe Google could be that dumb).
"some book some java dudes wrote 20 years ago" — If you're referring to "Design Patterns", the Gang of Four were writing about C++, it was 1994, and Java wasn't out yet.
And the winner is … State IT Awards
If you’re concerned about locating information quickly via Google, maybe thinking of how sites like the Stack Overflow family work, then having many pages is one possible idea. However, I would worry that this is restricting the design purely to accommodate today’s search engines. Using many small pages would surely reduce the usefulness for users who prefer browsing to searching.

Since HTML5 provides several new tags to help define the outline of a page and specify suitable headings to go with it, I’d probably look there first. The existing content looks fairly well structured, so hopefully it could be migrated with reasonable effort as a starting point, and any new/reorganised material to fit whatever new IA results from this exercise could then take full advantage. As HTML5 becomes more widespread, I suspect we’ll see both search engines and browsers take advantage of these outlines, just as search engines today have started to recognise site maps and present some results accordingly, so I think it makes sense to follow the presumptive standards unless there’s an obvious reason not to.

Given a clear outline one way or another, you could also do a lot to improve on the narrow, statically positioned tree on the left of each documentation page. That sort of navigation was probably sensible with the browsers and screen resolutions of the time when the current design was put together. Today, it wouldn’t be rocket science to use a wider nav area to take advantage of widescreen displays, and to have it fixed so it doesn’t disappear as you scroll down the page. You could provide some combination of top-level site navigation and navigating a possibly collapsible outline of the current page. However, perhaps you could also provide tools like navigating through search results as a separate list of excerpts like a SERP and/or by making the outline smart about say expanding and highlighting relevant sections when you first open the page. You could probably even do things like providing quick context-sensitive help for main page content, just as we use various interactive features to explore our code in editors/IDEs without leaving our current context.

This sounds like a fun project to work on. I’m almost sad that I don’t have a spare team and a half-year of free time to have a go! I certainly wish the organisers luck and hope a good development team lands the job.
See http://golang.org/doc/articles/gos_declaration_syntax.html
His argument wasn't that "it's just a tool for the job" but that JavaScript is actually a rather cool language. And it is. At any rate, I certainly like it more than most other "scripting" languages, except maybe for Lua.

I would never suggest using most of the languages on that list over JavaScript. In fact, the only ones I recommend are Lisp, Ocaml and Haskell. Maybe something like Ur/Web as well. Coffeescript is good too, but it's basically lightly improved JavaScript. I find JavaScript simpler, more expressive and generally nicer than most of the other languages listed (ignoring the ones I've never seen or used).

Ultimately, JavaScript is a nice language with some warts. But, for whatever reason, the warts are blown out of proportion compared to other languages--in my experience (out of the languages I've used significantly) Python, Perl and Java all have more significant shortcomings. I think the main reason is that JavaScript position in the browser forced a lot of people to use it against their will, which leads to more complaining.
I don't know 3 of the 5 mentioned and no links provided.
Some programmers passionately believe that contributing to OSS is status-increasing, perhaps enough to be a self-fulfilling prophecy. I have yet to meet a designer who believes this.

There exist UX paths by which contributing to OSS via code is easy, obviously wanted, and generates warm fuzzies. The fork-and-go experience of adding one marginal feature to a gem for Ruby then sending a pull request feels like ponies and sunshine every step of the way. By contrast, there exists no infrastructure or UX to support designers contributing in the same way. You probably have to send an email to a project maintainer. Try sending ten of those: report how sunny your ponies feel as a result.

OSS projects, in the main, very aggressively signal that they do not care about design. Just having a logo makes it look like you have super-anomalous levels of care relative to OSS. Designers pick up on hints like "your web presence is a default Github page" and "your logo was created by a programmer in MsPaint" to decide that their talents are probably better applied elsewhere, where they will be valued.

Also, 99designs will pay more designers more money today than entire communities of OSS developers will this year. Even starving artists can do the math.
"The question is whether or not MS has a responsibility as an underwriter to disclose that information to an audience broader than its own clients"

That is an interesting question and will be a good suit to watch. If the finding is that there was a responsibility to broadly disseminate such information, it will also be interesting to see what the impact is to the financial advisory industry.
I'm not sure that the author's reflection of the difference between Google and Facebook holds up. Google Search will get you other places while slurping up all your data, but every other Google property is more akin to Facebook.
Oh to be this guy: https://twitter.com/#!/better
the thing is, if you've marked up the semantic use of a type, it is no longer guaranteed that it meaningfully supports all the operations the "base type" did. in your 'type index uint' example, for instance, you would typically not divide an index by an int.
Why 'Game of Thrones: Ascent' may be the best Facebook game ever
"Get" in its present-tense for is very difficult to use to start a sentence. It sounds highly idiomatic ("wrong") not to precede it with either a subject ("I get six floppies for a dollar at the thrift store."), or to recede to the infinitive ("To get six floppies for a dollar is a very good deal."). Using a gerund makes it easier, but then you're not dealing with the plain "get" anymore.
The capitol in the capital on capitol hill, down the parkway past the park. No, the park park, not the car park. English is a fun language. No opinion on the English though.
You can move over slowly by building new components using objectify, and leaving the rest of your legacy app the way it is, if you like. It's designed specifically to be able to coexist with what you've got.
> It seems like the successful(popular) "NoSQL" engines will eventually reinvent many RDBMS wheels.

The wheels in question aren't RDBMS wheels, they're just generic database wheels. The backlash against RDBMSs wasn't because of implementation details like this, it was because of the baggage of relational structures in general, and SQL in particular.

The "reinvention" of these wheels is occurring now because non-relational databases are maturing now.
Build muscle with this supplement
> if you want support, you pay for it.

That's no excuse to provide a shitty service. For 99% of people GMail is not shitty and is infact quite awesome. That doesn't change the fact that with the amount of people Google has, not having even a queue for people to get minor issues fixed (Freaking MICROSOFT can get this right, for crying out loud!!) is ridiculous.
My response was probably a little harsher than it should've been. I still found the advise an interesting read, just very disappointed not to find the story. Looking forward to your next post.
Good video! Watch now
If you get involved in a venture involving GS and you're surprised you got screwed then you haven't paid much attention to the current events of the last 5 years.
Very interesting article

And they finish up saying "The used TV market is broken"

But actually I would say: "the TV market is broken"

One could say the price reductions are due to less demand (computers, internet, etc), or maybe because of improving technology

But really something that falls in value so fast has of course a value for the user (watching TV) but not a "market value"

Tvs are (more or less) fungible, there's basically no incentive of getting the latest model and if it breaks you just get another one.

So it's actually worse than the car market in some ways
The big idea space has become somewhat saturated. It is as simple as that. When this happens, all "Big Ideas" are only variations or combinations of previous ones. The rate will continue to slow until science opens a new frontier. After all, Science Fiction inspires science, and science inspires Science Fiction, It is sciences' turn.
Incredibly confusing picture
Just watch the picture in the middle for about 4-5 seconds and you will see the magic of the picture.
Flat panel HDTVs? I've seen plenty of good-as-new CRT TVs there -- right beside the perfectly good VCRs, record players, tape decks, and non-surround receivers.
I agree with many of the points in the article, however it is conflating two unrelated things. Using simple averages in isolation is almost always a mistake. The real story in a system almost always lies in it's variation and not in the average. There are many ways to look at that, one of them is a histogram, although I tend to prefer time series graphs with moving ranges. One of my favorites is the Xmr chart or any of a number of statistical process control charts. Using those you can get a much better understanding of systems over time.

The transition to Real User metrics is not at all related to using an average. All recording and instrumentation processes will benefit through using more sophisticated and nuanced tools than a simple average. Real user metrics are an important data point, but they lack certain information you can get from external monitoring systems. We use both pingdom and catchpoint, by far my favorite is Catchpoint because I can see things like what ISP is involved with a slow request, what geographic region, etc. I can also get scatter plots and nice statistical graphs around median, geometric mean, 75th, 95th, 99th percentile.

So in short the main points are good, simple averages are misleading. Capturing end user performance data is good. Not using external monitoring though isn't a good idea because there a number of things that you can identify if you have that insight.
To Close the Gender Gap, Focus on Assignments
A faster, simpler Google Search app for iPhone
It doesn't seem odd to me. In fact I think it might be a Good Thing.

Having the compiler take care of the safe cases for one makes one less likely to always blindly cast things and leave oneself open to the unsafe cases. For certain values of 'one', of course :)

As for your point about Fahrenheit, the real solution is

type DegreesF float64;
type DegreesC float64;

so that the units cannot be accidentally mixed.

Note to self: It might not be a bad idea to have alias-style types deliberately not participate in automatic numeric conversions, although I think it is a mistake they don't currently always auto-convert to their own aliased type.
The y axis increments by 8%, instead of by a round number (10% would be better).
UK Government Digital Service's Tech Stack
Train Your Brain for Monk-Like Focus
To prevent this problem you exercise your options and sell stock at the same time.

Lets say you have 10,000 options with a strike price of $1 and the stock is trading at $11.

Instead of sending a check for $10,000 to the broker and receiving the stock, you tell them to sell 3,000 options for $33,000, have them keep $10,000 to pay for the options and send $23,000 to the IRS.
A paleontologist discusses the problem of dinosaur poaching
It's cute. It builds easily (albeit with cmake, sigh...). It's a single binary. The usage is straightforward if a little primitive (run it in a directory and it will sync that directory to the cloud).

It's very much not dropbox, but it's not bad.
>I imagine the customer to employee ratio is a billion to one, so even if they had a ticket system, it'd be overwhelmed in a short amount of time.

If their system is locking out enough people who shouldn't be that they would become overwhelmed, google is doing something very, very wrong.
It depends. You argument is very narrow. There are LOTS of ways to avoid paying your fair share of taxes, it depends on the situation and where the cash flows are coming from.

As for the Zuckerburg situation, what he did is pretty common. Though I have heard of an alternative to selling those shares, someone in his position could use a portion of his facebook shares as leverage and get a loan to pay the tax man, then said person could pay back the loan with the cash flows generated by the stock. Though in that scenario the interest on the loan and the cash flows of the shares would have to be favorable (i e, a finance question). Additionally, I have heard that getting a loan like that is difficult (something to do with eligibility and/or regulation), but don't quote me on that last part I am not that familiar with it myself.
As someone who lives outside of the US (I live in Israel), I would very much like to buy a new 32" LCD TV for $200. Too bad it's about $400 here.
While you are right that the arguments are pre-existing, I think emotionally there is a discrete change with the IPO. It is one thing to feel like you are surrendering your privacy in order to stay in touch with your friends; it is not entirely another thing to surrender your privacy for the geeks providing the platform to make money to support and extend the platform.

Surrendering your privacy so that an institutional shareholder can make money is, emotionally, a different proposition and this is what the OP demonstrates. It's not that people didn't willingly surrender privacy before the Internet; but then, like now, it was done in a two-way transaction. The classic example is building intimacy with, say, your spouse, by telling them something that nobody else knows.

It is entirely possible that with Facebook a public company, some people (who were previously content) will re-evaluate whether they like the other side of the transaction.
Someone has to say it: Damn, this looks fucking ridiculous!

First we have the false modularity. You see a bunch of separate stuff (classes, methods, whatever) and think "Wow, nice, now we can reuse this all over the place!" The truth is that these policies/services/renderers are going to be complected; you're going to create them in triplets as you implement your application. Moving things around doesn't make them modular. They can only be modular if the author actually implements them in a modular way (and you can do that in Rails today).

The DI-framework can't handle change at all:

class CurrentUserResolver
def initialize(user_finder = User)
@user_finder = user_finder
end

# note that resolvers themselves get injected
def call(session)
@user_finder.find_by_id(session[:current_user_id])
end
end

What if I later need the cookies/params to detect user session? If I changes the #call method, every single test breaks.

And then there's the added complexity. Now I need to keep track of the route-mapping, default policy, route policies, the route service and the route renderer. Which are now in several different files. And there's not even a clean class-to-file mapping to help me locate it.

Oh, and the premise of testability. Well, this makes it very easy to test units itself, but the more you split your projects into smaller units, the more bugs occur when you mix the units. Sure, you can get your precious fast test runs (and a nice green test), but in reality you're only testing a single unit of a complected app.

EDIT: This reminds my of Rick Hickey's quote from keynote at RailsConf2012:

""We can make the same exact software we are making today with dramatically simpler stuff—dramatically simpler languages, tools, techniques, approaches. Like really radically simpler—radically simpler than Ruby which seems simple.""
Well, that's why I qualified my response - there was no way to tell from your original submission. I've had a variety of problems with Google products over the years, and have in general found them to be responsive but not communicative. They could be more accessible (though I have always found an avenue to raise issues within a couple of minutes), but I'm also aware that full-service customer support is a labor-intensive experience. I'd rather they be mysterious and efficient than 'because it is my pleasure to assist you today, can you first verify that your computer is switched on?'
Amazon is a little better, but not by much. They send you an automated email, but sign it with a real name. I wonder if they just have a program on the other side that cycles through names.
it doesn't "compile from a url", the package name is just the url address. You still have a directory of downloaded packages analogous to Python's site-packages, and they don't update unless you explicitly update them. The difference is that if you say `go get github.com/whatever/foo` the package source will be downloaded to a location such as `/usr/local/go/src/pkg/github.com/whatever/foo`.
Civic Start-Ups That Can, Should, and Must Exist
And here I thought I was really beginning to understand how and when to engage in the discussion, yet the HN demigods seem to be proving me wrong more often than not lately...
I don't claim that it is easy, especially with an RDBMS. Actually, given the few courses I took in university on database design, I know its very non-trivial.

But MongoDB is not an RDBMS. There are no joins, so a query can only touch one collection (table) at a time anyways, so at least in that regards its much easier than an RDBMS.
>The whole point of objectify is that it actually makes it pretty reasonable to work this way right off the jump. I would have a hard time believing that it's really any more work to build an objectify app than it is to build a vanilla rails app - at least once you become accustomed to the paradigm.

Sure. I wasn't saying otherwise. What I meant was, in a general sense (prior to really seeing the benefits first hand), it can be hard for people to justify the trade off when they feel like they can just "get it done faster" with a more ad-hoc approach to things. I didn't mean to imply Objectify was some how more difficult (I haven't used it, so I wouldn't dare comment on it in such a way).

>I don't buy that. My project has hundreds of single method classes and it's by far the best factored non-trivial application I've ever seen (anecdotal, obviously, but so it goes).

Agree to disagree, with a caveat. I'm not against having a large amount of "Helper" or in the case of what I'm most familiar with, "Extension" classes (godbless you, .NET Extension classes), but I think if you have so many that they comprise most of your code base, maybe you could consolidate some of them (and maybe you couldn't).

Personally, I try to keep 100% of my core business logic inside of "Service" style classes, and then anything that is more of a helper (in that it performs some work, but not "business logic", and does not require or alter internal state) in either a static helper, or an Extension on the type itself.

For example, I usually end up adding a .ToStart/EndOfDay/Week/Month suite of methods to the datetime object of most of my projects. A "DateTime Service" would be overkill, but an extension method (which is just veneer over a static helper) fits the model perfectly, in that it returns a new copy of the existing datetime, leaving the original intact.

But at this point we're getting pretty deep into the comment tree, so feel free to email me from my profile if you want to go more into the issue - I love shooting the shit over this kind of stuff. Regardless of any minor difference of opinions, I think what you're trying to bring to the rails community is to be commended.
False. It is not possible to register multiple variants of the same address. The reason you get misdirected email is because people are entering the wrong address in forms. You should see all the email that goes to paul@gmail.com :)
Show HN: ShelvAR - Augmented Reality app to sort books
Jury Rules that Google Did Not Infringe on Oracle Java Patents
Waiting for link. Saw on Bloomberg TV.

EDIT:
Verdict was unanimous. No infringement of either patent.

First link: http://www.businessinsider.com/verdict-is-in-for-oracle-google-2012-5
A colleague who are not really friends with you and don't share the same ideals as you sends you a Friend request. What would one do?

Accept the friend request, hide all their updates from showing on your news feed, and put them on limited profile view is one possible option.
The problem is that people will buy the overpriced used TV. Honestly, I sold my 4 year old 720p for $300 last fall and went out and bought a brand new 1080p for $350! I couldn't believe it. But if people will buy, the price isn't going to change.
Didn't our estimated writer predict the death of genre to e-book marketplaces anyway? I've loved his work in the Merchant Princes series (Fantasy/SF/Economics/Steampunk), but also his take on the difficult and rewarding exercise of making stories in a near-future society of interconnected and realistic predictions (hard sf/futurism/sociology, Halting State and Rule 34). If I can enjoy an author despite apparent genre schizophrenia, I'll probably continue to enjoy SF even if no consensus is built to address future shock.

However, he has a point that there is a risk that the aesthetic of SF is being co-opted by what are essentially fantasy works which don't really engage with science, technology, the present, or the big what-ifs. I hope the good stuff of SF can survive that.
Microsoft probably has a much higher ARPU than Google does.