skysight-inc/HackerNews huggingface dataset:
Evan and I worked together at IMVU, and at one point a senior engineer heard one of my (appallingly bad) ideas and replied "You're fired." and went back to work.

A few weeks later I, apparently, made a terrible joke. Seconds later this shows up in my inbox:

Dear Timothy,

After careful deliberation, it's been decided that you need to be fired.

Reason: telling not funny jokes

You may take one (1) Odwalla for the road.

Thanks,

The Firing Committee

Not only was it hilarious but while I suspected Evan, he hadn't had time to type that whole message! Over the next few weeks I received quite a few of these e-mails, but with different messages:

Reason: distracting Evan from his conversation with Luc

Reason: Asking too many questions

etc.

It turns out that not only did Evan find the need to write a formal you're fired letter; he wrote a web service to send formal you're fired letters. To me.
How Do I Get Meetings With Investors?
http://www.rosettacode.org/wiki/Sieve_of_Eratosthenes#Using_...

from numpy import bool_, nonzero, ones

def primes_upto(limit):
is_prime = ones(limit, dtype=bool_)
for n in xrange(2, int(limit**0.5) + 1):
if is_prime[n]:
is_prime[n*n::n] = 0
return nonzero(is_prime)[0][2:]
What Would Alan Cooper Do?
Twisten.fm: Beautiful Twitter-Grooveshark mashup
Neat. Does. Anyone know what impact this discovery could have? Is a harder-than-diamond substance useful? (The obvious use case is for diamond cutters.)
50% "overhead" for management and direction sounds pretty low. The only hopeless thing about that chart is the number of geographical sites.
I think this exactly illustrates my point... (sorry for calling you out twice moe, I very much appreciate you expressing your opinions even though I disagree with them)

You say "all lessons unlearned" implying that RSS is worse than previous incarnations of solving the same use case. This is a common opinion I really am railing against. RSS is EXTREMELY popular. Usenet is a dying architecture. It's a case where being worse in the "obvious" technical architecture allows you to be better in things that actually matter: ease of access, simplicity of use, lack of installing things and wide support. These are just some of the reasons RSS took off. Easier means more viral, because easier means a shorter viral loop.

Of course, I think RSS is better for syndication than notification, and would prefer more sites like twitter use Webhooks in addition to RSS.
Microsoft hires exec to build retail stores
I edited out a section where I talked about how it's NOT just port 80.

It turns out lots of ISPs and broken routers and terrible corporate proxies only allow HTTP. They do things like require HTTP headers, so they can check for whitelists/blacklists. It's stupid and it breaks TCP/IP in general, but most people only care about the internet so it just works for most people.
Gog.is Shortens Google Search URLs for Easy Sharing
The answer is "no". The question is "will key/value cloud computing data bases replace relational"? RDBs are very good at modeling your data, but have scaling problems. The cloud computing solutions scale well but are really poor at modeling data; you have to do it yourself. Example problem: you commit an update to a record. Subsequent reads may not see the change until the DB gets around to committing it some time later. Can't run your airlines or banks that way. The eventual solution will have RDB-like modeling with cloud-like scaling, replication, robustness, and all that good stuff. The real solution will allow you to request high data integrity along with I-dont-care-what-happens for storing your RSS feeds or slashdot comments.
The masterminds knew exactly how much each casher would be withdrawing. They might've also friends with the cashers. Also, if you were a casher, wouldn't you want the opportunity to participate in the next big scheme? But you wouldn't get that chance if you betrayed them.
Things like this make me sad, because I fear that the optimism of my own generation regarding things like space exploration, genetic engineering, nanotechnology, and other potential technological leaps forward are just as futile and fanciful as the last generation's were. Someone cheer me up :)

And also, how the hell did we put men on the moon in the 1960s?
Other than being unable to get the html snippets to work, I like it and will be trying it as a SnippetsEMU replacement (if I can get html files working).
Alright thanks... To be fair, I am really really bad at picking up humor online. I have some kind of internet autism or something.
pedantic: the urban dictionary example is voting not rating. that's what leads to the confusion of adding up all the positives and negatives.

amazone is rating. it's a scale and there is a clear mean, medium and standard deviation.

whether solution #2 is wrong kind of depends. some of this is a social problem on what items get the kind of followers who are likely to rate online. at the extreme case you could imagine a product where (not) liking it was caused by an inability to use html forms.
Google pulling plug on radio advertising service
Thats true. Maybe I'll venture further away from my safety zone in the future.

Problems get harder to diagnose in the engine, though. I find the diagnosing the problem is where the skill is.

Also, as repairs become more complicated, I have discovered that the chances of needing to replace something that you don't have a spare for go up. It sucks to have to bike down to the auto parts store and retrieve 40 lbs of parts in my backpack.
Hong Kong is a working city and a great place.
Are Non-Baiting Titles Doomed?
When I posted my reply, the parent had 21 points. Now it has 16 points. That means it's received at least 5 downmods. Did he do something to deserve being downmodded?
The future is probably going to be a mix. RDBMS are good for data integrity. The non-relational databases are great for distributing queries. I've seen some apps which use a slow, asynchronous RDBMS to supply denormalized 'documents' for the non-relational stores.

Mind you, the RDBMS could still make a comeback. The world is looking to non-relational because since 1998 or so, throwing multiple pieces of hardware and network capacity at the problem is cheaper than solving it all in one giant node or cluster. But maybe one day an off-the-shelf computer (perhaps with better concurrent programming techniques for multicore) will be able to handle all the queries you would ever want and have the bandwidth to match.

Also, just wondering; exactly how many organizations really need a distributed database? There are some top websites, like LinkedIn, that do it all in one giant node, and my guess is that even sites like Facebook have only a few hundred database shards, maybe a few thousand at most.
And just as fast as the first populist post went up, up goes another one...
I recently implemented an event logging server, intended to process a massive, concurrent number of event messages from a large clusters of systems.

We choose to implement a CPU efficient binary protocol, automatic client-side queuing of outbound messages if a server failed, and automatic -client-side- fail-over to the next available server.

The initial implementation, with no time spent on profiling/optimization, was able to receive and process 25,000 event messages per second from a single client, and scale up clients/cores relatively linearly.

I can't even begin to fathom solving this problem with HTTP, or why the 'features' of HTTP listed (proxies, load balancers, web browsers, 'extensive hardware', etc) would be an improvement over the relatively simple and highly scalable single-tier implementation we created.

Clearly, HTTP works well for some things, but "just use HTTP, your life will be simpler" is a naive axiom.
I was a bit skeptical about how anyone could easily carry away that amount of cash from an ATM, but it's not so unbelievable:

$9,000,000 / 130 ATMS = $69,230.8 or roughly 692 $100 bills.

The US government requirement for currency paper is: "the thickness of the paper shall be 124 micrometers [...]."[1]

124 micrometers * 692 bills = 0.085808 meters or 3.38 inches thick. Not bad at all.

[1] https://www.fbo.gov/utils/view?id=ccca3ea58d649385700a9f20c9...
Actually, I think Amazon has it right, for several reasons:

1. The user can actually understand and predict the behavior.

2. The "problem" the OP identifies is partially self-correcting, because items with a few positive ratings get more attention as a result of their high ranking, and if they deserve more poor ratings, they'll get them.

3. As long as you tell users how many ratings there are, they can use their own judgment as to how important that is.
this starts to become as cryptic as the previously mentioned 'cryptic regex.'

cryptic is anything that can stay in the head 'ram' of a normal programmer. stuff that typically needs to be written down to make sense.

i went through the above code with pencil and paper and it made sense. now i can look at the code and it makes sense. the person who originally wrote the code had to go through those steps too (not necessarily on paper, but loading the process into head ram). same with regex.

no big deal. i know about slices, and if i didn't that's what mentors are for---oh, that symbol? search for python slices! or a python book. at least python doesn't has less than a handful nonsearchable crypticness.

the comment linking to the eratosthenes sieving explanation was helpful.
The author, Eric Ries, put this draft together quickly based on an email conversation. He bravely embraces the "release early and incorporate feedback mantra."

I probably would have revised it many more times.
Which approach has the highest benefit or the lowest cost, I don't know.

This is a long way of saying that we're looking for feedback. What do you think?
Thinking about twitter feeding facebook status
these are good points.

of course, what with classes i very rarely have deep lists anyway. in fact, copying lists is seldom an issue i run into (though i always run a few tests at the prompt to make sure my understanding is right because mutability bugs can be hard to track down later).
This article is fairly well-balanced, but the hype around these "hashes in the sky" is completely out of control. This article tries to be objective, but it's not doing enough to counter the rabid zeal that is gripping silver-bullet-seeking, Twitter-wannabe young web developers. My observations are that too many people are making the following mistakes:

* Overestimating their need to scale - a powerful box with a cache-backed site can serve a LOT of hits. The vast majority of apps will never need to scale beyond this, don't kid yourself.

* Underestimating the amount of work and the cost of failure in maintaining data integrity at the application level - for all but the most simplistic applications you will end up writing a ton of code that replicates what a RDBMS does, except slower, with more bugs, and less generality.

* Underestimating the importance of data integrity - When your massive database with billions of records has subtle data integrity issues, how hard will it be to fix? My guess is that some truly nasty situations will arise and over time the hype will be tempered by the horror stories.

* Underestimating the constraints this puts on future development - Sure greenfield apps may seem like a great candidate for a document-oriented DB, but how often do apps look like the original version 1 year later, 2 years later, 5 years later. With a relational database your bets are hedged automatically. You can go in a million different directions with your data. The relational model gives you orders of magnitude more flexibility than complex algorithms designed for map-reduce-style scalability. If you don't need the scalability you are throwing an awful lot of flexibility out the window for nothing.

* Underestimating how relational their data really is - It's not just that developers understand the relational model, it's the fact that it's a rigorous theoretical model that actually models relationships in an academically complete way. Sure, real life RDBMSs don't live up to the theory, and sometimes things are too slow to be practical, in which case you fudge things as necessary or add layers of caching. But at the end of the day, the relational model can cover pretty much anything, where these hash-databases give you a small set of scalable functionality and some clever algorithms to accomplish a bunch of different things. The things you can accomplish are not comprehensive in a theoretical sense, they are just techniques that have proven useful for a number of applications recently. However the limitations are not as well defined as a RDBMS.
From the submitted article: "But in making your decision, remember the database's limitations and the risks you face by branching off the relational path.

"For all other requirements, you are probably best off with the good old RDBMS. So, is the relational database doomed? Clearly not. Well, not yet at least."

So the answer is no. The article doesn't do justice to the theoretical rigor of the relational database model. An online posting with some interesting discussion of technical trade-offs in popular terms and links to other posts can be found at

http://highscalability.com/paper-dynamo-amazon-s-highly-avai...
yes

(i meant to say that i hope one word answers are doomed as well)
There are some money managers who are truly brilliant and have consistently had great returns.

Who, for example?
I do wonder how many people on EC2 use SimpleDB because they need (or think they will need) the scalability, as opposed to thinking it's easier to code for, or simply just so they can avoid the drudgery of running their own RDBMS.
It's also very important to note that the terms of the H1B would disallow an "immigrant" from quitting his job and starting a company, because his legal presence in the US is contingent on remaining in the good graces of his employer. The H1B says "we'll allow you to come here to work for Google, but we won't allow you to come here to start a company that competes with Google." That said, it sounds like you don't like this aspect of the H1B visa either - you would probably support a system that preserves more freedom for the guest worker.

Lastly, I think you are using "smart, hard-working people" ambiguously. We don't allow hundreds of thousands of foreign lawyers into the US every year. While health care does award some H1B's, Medicine and Dentistry also act as gatekeepers that ensure Americans who pursue these fields are not replaced en masse with foreign nationals. Of course, real estate agents, mortgage brokers, flight attendants, plumbers, meter maids, and almost every other sector of the economy isn't targeted with a work visa.

Now, there's so much work to do in high tech that we still may get some Americans in the field. But we still create a relative disincentive to Americans when we allow targeted visas in science and engineering. After all, an American who pursues a law degree doesn't have to compete with foreign lawyers for jobs and clients. But an American who pursues a graduate degree in engineering most definitely does. Do we really want to discourage our citizens from engineering degrees and direct them toward law and other non-technical fields?

The answer may actually be "yes." We can get engineers more cheaply from overseas, so we have decided, as a nation, to staff these positions with non us-citizens, and encourage our own citizens to pursue other degree paths and professions. But I think this would be a terrible idea, since a robust, home grown engineering and science profession is crucial to the economic health and security of the United States.
Off the top of my head, I would say it's because the atoms are small and they form lots of bonds, carbon in particular. Diamond is a tetrahedral structure and I think the other really hard substances are also,
To tell the truth engine problems fall into two categories...serious ones, like engine knock which you really can't do anything about to something simple like a heat shield rattle or a loose gasket. There is really no middle ground. And for the "serious" problems, its usually cheaper to replace the whole motor, than to do the repairs.

Granted that mostly applies to japanese cars. You drive a BMW and to replace an engine will cost you 10 grand. While even the most rare JDM swaps will run you at most 5K.

For example, one guy I know never changes the oil on his daily driver civic. Why? Because he figured out that its cheaper for him to replace an engine every 80K miles, than it is to spend the money on an oil change.
And that depends on if regular expressions are a basic language feature. The proper way to "explain" or "comment" a complex regular expression is not to include a single line comment near it, but to use the /x modifier that allows you to "extend your pattern’s legibility by permitting whitespace and comments". That is, of course, assuming you're using a language where regular expressions are first class types and has syntax to support regular expressions as literals (if you have to include your regular expression in a quoted string, your language doesn't), and uses PCRE.
ATMs have $100 bills? Only certain ones?
Given their tight time-window they probably couldn't hang around until the ATM was free. I wonder how many people got to stand in line behind someone who was repeatedly withdrawing large amounts of cash?

(I suppose it was probably done at night when things were quiet; makes you think what you would have done though!)
I agree. Simply disabling an account that was used at more than one ATM within a certain timeframe, based on geographic area, would have limited the damage. Similar to how cell phone cloning is detectable.
"Housing prices were not artificially inflated."

Well, considering that during the time that housing prices increased there was a large mortgage interest deduction, an implicit bailout of Fannie/Freddie, a huge capital gains tax loophole on selected home sales, as well as a variety of programs designed to allow people who wouldn't normally have been able to afford a house to buy one, I'd beg to differ.

The above are all demand stimulating laws. For some reason people believe that paying interest to a bank (instead of rent to a landlord) is the American dream, and significant government revenue was allocated to creating home ownership.

Why wouldn't any smart speculator double down on the idea that by betting on home prices increasing he's got the government on his side and stands to make a mint?

Now, those speculators (and in this group I include anyone who bought a house expecting it to increase faster than twice the rate of inflation) are being bailed out by the policymakers who made their gambles possible!
Pylons provides similar capabilities outside of Firebug, but I do think the firebug approach is clean, familiar, and attractive. I'm all for it.
Only to override the default implementation.
You mean most people only care about the web, right?
There is an audio interview with one of these "cashiers" who explains it all (you have to fast forward a bit): http://smallworldpodcast.com/mp3/smallworld051906.mp3

It's fascinating. Basically, the cashiers are working on the honor system. They get to keep a percentage (this guy gets 40%), and they send the rest to the "boss" through e-gold. The percentage you get increases as you earn their trust. I guess that this keeps most people honest, as they want to get a higher percentage the next time.
Whoever solves the "scalability or consistency: choose one" problem will make a boatload of money. From what I can tell this is a very hard problem, so software that makes it seamless to operate at multiple levels of this tradeoff curve -- perhaps at the same time, for different parts of your data -- would also be a big win.
RDBMSs are not doomed, but people are beginning to realize that they are not the Solution To Every Problem. I don't know why people ever started treating them like that; they really only handle one (small) problem space well -- modeling relational data. If that's the problem space you're working in, there's no better tool. If that's not the problem space you're working in, then now we have some better options.

The reality is that 99% of web apps don't really want a RDBMS. There are no arbitrary queries to run, they just need to extract some objects from the database, interact with them, and render a web page. As of late, people have been using ORMs to make their relational database look like an object database. The problem is that the objects you get from an ORM don't work like real objects (try making a cyclical structure, or try `change-class`-ing the objects; doesn't work). This usually means you need to map the objects from your ORM into a better model of your app, adding complexity. (Some ORMs also screw up the relational part, making the data in the database nearly useless to any other apps. Oops.)

People are starting to realize that this model is a waste of their time, and they are using object databases instead. Now there is no ORM, they write their objects that the app interacts with, and those are persisted as needed. Suddenly half your app's code is gone, and it runs faster. That is why people are excited. Less code is always exciting.

This article is really heavy on key/value databases, probably because they are easy to understand. But really, key/value databases are like the assembly language of databases. You will have to do a lot of work to run your app on a key/value database. It is better to use something higher-level, like CouchDB or an object database. (For an OODB, I recommend KiokuDB. It has indexing (stolen from Postgres), and can store your data to BDB, a directory on disk, a RDBMS, Amazon SimpleDB, or CouchDB. This gives you a lot of flexibility.)
And also, how the hell did we put men on the moon in the 1960s?

And it was for mere $135 billion (in 2005 dollars). [1]

That's less than $20 for every person currently alive on Earth (6.8 billion). [2]

Or about $170 for every citizen of US+EU combined (~800 million).

Amazing what we can achieve when we focus.

[1] http://en.wikipedia.org/wiki/Project_Apollo#Program_costs_an...

[2] http://en.wikipedia.org/wiki/World_population
25 things about Linus Torvalds
Wharton Entrepreneurship Conference Tomorrow. 25 Cool Start-Ups.
The Pizza Box One Is Awesome...
Context: So, why are relational databases going to die? Because only key-value hash lookups are fast enough. Wait, can't RDBMs do hash-based lookups too? Yes they can. So what's the problem? Well, if you want to take advantage of the relations, you have to use joins and such. Why is that bad? The query plans the RDBMs uses end up being slow. Putative solution? Throw out RDBMs, replace them with key/value DBs (which are strict and severely impoverished subsets of RDBMs), and implement your own relations.

My comment: This makes me wonder if the solution shouldn't be looked for in a different direction. Instead of throwing out the RDBMs, why not give me one that gives me complete control of the query plan? That's the real stickler here, not the relations themselves, which are there whether you maintain them or not. If the DB can't guess up a good query plan, why not let me simply feed one to it?

Is there any DB that lets me have complete control over the query plan? (And even if there is, it's probably a half-hearted, unoptimized feature with little design effort poured behind it.)

Yes, even so you may have to give up 40-table joins, but it seems to me RDBMs, with more control given to the user, could still provide a lot of value without throwing out the baby too.
Did anyone else not know that Google did radio advertising?