gmjoe

Oh I know. :) That part's only semi-automated, though, I bring the new data in, in manual batches. If the overall artist popularities in the new data don't match the existing data to within a certain degree (and also watching IP addresses and submission time patterns), then that data won't get counted.

New data comes in through http://ifyoudig.net/page/contribute

To incentivize people to keep contributing, the plan is to build a notification service around your favorite artists, so you'll find out about new artists/albums/songs that are related to your tastes.

So the more popular the site gets, the more data there will be :)

If anyone's looking for music recommendations, there's a site I recently launched, "If You Dig": http://ifyoudig.net .

I don't mean to hijack the thread, but thought it might be of interest, since we've got musically inclined HN'ers here...

I've never used Mongo... but if the author is adding support for this in the Node.js driver, then this CANNOT be real join support.

Because the whole point of a join is that it's on the server, not the client. In other words, if we need to retrieve 10,000 rows from table A joined to B, the join to B will add only a tiny speed penalty, because the data's all right there, ideally in memory.

But if the server has to send all 10,000 rows back to the client, who then has to send a second request back to the server for rows that match any of 10,000 ID's, that's horribly inefficient and not really a join at all!

I wouldn't worry too much, since MariaDB is out there.

I'd love to make the switch from MySQL, except Amazon RDS doesn't support MariaDB yet. But since they just added PostgreSQL, maybe there's hope? Presumably MariaDB support would be vastly easier, as easy as a new version of MySQL?

I'm sure there are going to be plenty of places which refuse to accept anything but an actual credit or debit card.

I mean, there's no signature to check. What do you do when 10% or more of the places you go refuse to take this?

Heck, a lot of places used to require the cashier to type in the last 4 digits of the card visually, to make sure the physical card matched the stripe. I haven't seen that in a while, but that would also be impossible with this.

Are the credit-card companies on board with this, instructing retailers to accept these?

This article is ridiculous and doesn't even have anything to do with Coin.

The first half isn't even criticizing Coin at all -- it's just saying the author wishing there were even better things. The author says "The problem with these technologies is vendor adoption. It’s not here yet, but it’s on the way." Yeah, it's been on the way for the past 10 years, but nothing's changed yet! I don't see RFID/NFC anywhere I shop. But that's not any reason for Coin not to improve things in the here-and-now.

And the second half has nothing to do with Coin itself either, but is about Kickstarter charging in general.

Oh boy. I can't wait to see what someone else can do with 60 lines of JS, and two libraries used!!

[Note: not being sarcastic. Think this is a genuinely awesome way to respond to first post!]

This is specifically "for the legal defence campaign of Mr Edward Snowden". The page doesn't mention any of it going to support Snowden himself.

And that might be an important distinction -- IANAL, but contributing to someone's defense fund seems like a perfectly legal thing to do; financially supporting someone on the run from the US government, I'm not sure quite how legal that is. I'm curious if anyone knows more.

This smells like over-engineering to me...

In my experience, including rendering code both server-side and client-side is overkill. Just put all the rendering and templating code client-side, period.

If you want your page to appear more quickly, then instead of loading content data with AJAX afterwards, just include JSON arrays of content directly within the HTML source itself, and use JavaScript to populate the page instantly, even as it loads.

(Obviously SEO is a different case, but there are tools built for that specifically.)

> Seven-table joins. Ugh.

What? That's what relationship databases are for. And seven is nothing. Properly indexed, that's probably super-super-fast.

This is the equivalent of a C programmer saying "dereferencing a pointer, ugh". Or a PHP programmer saying "associative arrays, ugh".

I think this attitude comes from a similar place as JavaScript-hate. A lot of people have to write JavaScript, but aren't good at JavaScript, so they don't take time to learn the language, and then when it doesn't do what they expect or fit their preconceived notions, they blame it for being a crappy language, when it's really just their own lack of investment.

Likewise, I'm amazed at people who hate relational databases or joins, because they never bothered to learn SQL and how indexes work and how joins work, discover that their badly-written query is slow and CPU-hogging, and then blame relational databases, when it's really just their own lack of experience.

Joins are good, people. They're the whole point of relational databases. But they're like pointers -- very powerful, but you need to use them properly.

(Their only negative is that they don't scale beyond a single database server, but given database server capabilities these days, you'll be very lucky to ever run into this limitation, for most products.)

Exactly. The fault lies with the original author in not explaining the intent behind the function, why it is written in the way it is.

I've seen this kind of code time and again from coworkers who have the "code should be self-documenting" mentality, who refuse to put in comments explaining why they wrote a function a particular way. But what they think is self-documenting, very, very, very rarely is to others.

> Your culture is not: Ping pong tables & beer in the fridge

> Your culture is: Who you hire, keep & reward vs. who you don't promote (and why)

I wish more people realized this. It seems so rare to hear, but it's so, so, so important.

Agreed. However, there's a caveat: not every organization needs 10x engineers. In fact, a lot wouldn't know what to do with them. So as far as they're concerned, they don't exist.

After all, a 10x engineer is still only 1x when it comes to adding new functionality to your CRUD app.

However, when you need a scalable recommendation system built in a weekend, that works on a sharded database, uses clever math to run with limited resources, and fits processing into an overnight cron job, and just works (without breaking down every few days over the next couple months), that's when the "10x" guy or girl is your only choice.

Very interesting, I never saw that before!

But I can't figure out, for the life of me, why the bizarre ".container:before" declaration is needed -- it would seem to be entirely superfluous, but if you remove it, the whole thing breaks. Can you explain what's going on?

I would argue that, nowadays, many young people expect the government to take care of necessary social work, making charity less relevant. Here's my theory, which admittedly has no data to back it up:

Older people, who skew Republican, believe in small government, and believe in private charity. (They're also more religious, and remember that a lot of charity is really donating to your church.)

Whereas younger people (especially techies), who skew Democrat, tend to believe more in active government, and believe that democratic participation will ultimately lead to effective social use of their tax dollars.

And it's not an unreasonable position, necessarily. If you support higher taxes and more political activism, there are many good arguments as to how government policy is a vastly better conduit for doing social good, than private charity.

Vertical centering isn't that useful when you already have to know the height of things... I mean, if you already know the heights, you can just put the numbers in straight.

The best way to do real vertical-centering that works with variable heights, and doesn't use JavaScript, is to take advantage of the fact that table cells do this with "vertical-align: middle". Inexplicably, only table cells allow true vertical centering with variable heights.

So you can either convert the surrounding element to a big ole <table><tr><td></td></tr></table>, or you can use CSS to give it a property of display: table-cell. And in both cases, give it a "vertical-align: middle". Then you're good to go!

And of course, horizontal positioning in the table cell is easy.

> In most residential apartment buildings, renting out your space for less than 30 days is illegal, unless you are present when you have that visitor.

Why can't NYC come up with some common-sense regulation, like everyone is allowed to rent their apartment to up to 8 separate groups of people, for not more than 6 mos out of the year total, or something? And that landlords are not allowed to interfere?

This would prevent "hotel"-style abuse, like different tenants every night in a residential building, but still give people the flexibility to rent out for the occasional weekend, or month, or whatever.

The 30-day thing is just ridiculous.

There's always something kind of magical about real-time sites -- like the Internet is a little less lonely, and there are real people out there.

Very cool!

Getting user feedback on fake stuff is great. Tim Ferris didn't know what to call the book that turned out to be The 4 Hour Workweek, so he spent money on AdWords to see which title more people clicked on. [1]

[1] http://futureperfectpublishing.com/2009/01/23/the-sticky-goo...

Is it really the place of the CSS standard to define it? Is that even remotely necessary?

I mean, every device is different. You don't want a "px" on your phone to be the same as a "px" on your desktop, which also shouldn't be the same as a "px" on your projector.

A "px", right now, is whatever the device+OS combo wants it to be, but that works, because they all try to make things the "right size" given the device size, resolution, and distance from your eye.

And it works fine. Just accept that "px" is device-defined, and it all works, just like it does now in practice.

Exactly. I remember, once a friend wanted to create a tool for designers to use for creating HTML+CSS visually, without having to know actual CSS properties and such.

Then I explained, the hard part of laying out webpages is not the basic layout -- it's how layout reflows when text overflows, when the browser window is too narrow, when image sizes change, what things maintain alignment and what things don't -- and that by the time you've added all these options to your visual tool, the visual tool is now equally complicated as CSS, so you've defeated the whole purpose.

At its heart, it's the fact that the specification of the program is the program. The devil is always in the details. (Which, incidentally, is why it's so hard to estimate development time accurately.)

While an interesting bit of trivia... this is completely pedantic.

To say that it is "doesn't really have anything to do with screen pixels, despite the poorly chosen name" is just silly.

It's quite obvious that px means pixel, has everything to do with it, and that the non-linear angular measurement is just a kind of more "formal" definition, but which no browser has ever actually followed, or probably ever will.