T-R

Good point. We plan to add something along the lines of "counterpoints" ("X does Z badly"), and we have other viewpoints ("Y does Z well"), but directly pointing users toward solutions that solve those counterpoints ("[take a look at Y, because] Y does Z better") isn't something we'd considered. I'll definitely keep that in mind as we hash out the counterpoints idea a little more. Thanks kindly.

Great ideas! Thanks kindly.

Thanks for the feedback.

Regarding sockpuppet accounts and the like, we do have that information - some of it will get more visible as we build out profiles and moderator tools, it's just been on hold while we focus on more user-facing features, since it hasn't been an issue yet. Account validation e-mails are also on the way.

Spam is definitely a concern, but we hope the fact that most content requires acceptance from another user before getting visibility will put up some barrier to entry, and in the cases where it's not sufficient, it should help us get some information on associated accounts. In cases where that fails, there's always manual moderation.

Regarding astroturfing, we welcome it, to some degree - we don't expect each viewpoint to maintain NPOV, we just want to make sure that each viewpoint gets visibility. Cons/criticisms will eventually broken out into a separate feature to reflect this.

Thanks for the feedback. One of the projects that our front-end engineer is currently working on should fix this issue, though it may not be live for a few days. Very sorry for the inconvenience.

The timeframe for getting citizenship in Japan is quite long, and from what I've heard from all those I know who have it, largely not worth it - if you don't look Japanese, you will generally continue to be treated as not Japanese. Landlords who refuse to rent to foreigners on the basis that you might book it out of the country will still not rent to you, and customs/immigration workers will still consider you a foreigner. It also just potentially introduces you to a new set of bureaucratic problems, all with forms that simply don't account for the possibility of a non-Japanese name.

- Most likely they're doing specific financing: whenever you pay with a card (or with your cell phone) in Japan, they ask you how many monthly payments you would like to pay over. There's also a general aversion to going into debt - cash and debit cards are generally preferred over credit cards in Japan.

- I'm not sure if I'm thinking of the right 'fake beer', but marketing of food products in Japan has lately been heavily skewed toward 0 calorie food and drinks. I'm not sure this is entirely fueled by reduced purchasing power.

- The internet in Japan is still very much limited by the fact that it's still primarily browsed via low resolution cell phones. It's getting better, but a fair amount of sites were written for C-HTML/i-mode-HTML, and laptop browsing experience suffered as a result.

- The effect of fringe groups on trends plays out differently in different industries. For Anime, shows with more mainstream appeal are actually hard to find now. On the other hand, in Japan, Anime has always been less mainstream than Manga - people who read a series as a comic book often find the TV shows to be watered-down, or don't find the voice acting to their liking. So, it's more just that a medium that's always had fringe appeal is doubling-down on it. That is, it likely would have happened even without reduced mainstream purchasing power - otaku, who actually buy merchandise, are just a more profitable group to market to.

With fashion and music, it's more that the fringe groups have bought the power to influence mainstream habits - plenty of people who aren't otaku but enjoy AKB48 and Perfume. Many shop at d.i.a. but aren't gyaru (at least not to the extreme the author portrays them as) - just trying to be fashionable, particularly in the short period of time between being in school (with black hair, uniform, and no piercings) and working (with black hair, uniform/suit, and no piercings). The increased availability of foreign brands also has an effect - by moving toward more extreme domestic trends, brands can better distinguish themselves from foreign competitors: with the surge in popularity of K-Pop, it doesn't make sense to try to compete with more of the same style of music.

I don't disagree with the general premise of the article, but I think its tone comes off as a little extreme at times - things aren't so bad there that mainstream purchasing has disappeared, it's just shifted toward some very distinctly Japanese trends, which were popularized at least in part due to the disproportionate spending by those groups.

> My only wish now would be to include a full keyboard (with pgup, pgdown, home, del in their own row)

Curious, why do you prefer them in their own row? I look explicitly for keyboards with them overlaid onto the arrow keys, so I don't need to move my hands (just use the fn key) to navigate text.

Phones do come with email addresses, and that's primarily used instead of text messages, but there is SMS/MMS (at least, I'm pretty sure that's what Softbank's S!Mail is, though, I get the impression it's mostly just used in-network, by people on family plans). Also, Naver's 'Line' is particularly popular for messaging right now.

Definitely odd that they didn't at least go with "Rakuten Buy.com", as they did with play.com...

That's not a name change, per se - Rakuten (楽天) is Japan's largest e-commerce site, and recently has been expanding overseas. They also own Play.com, Linkshare, and Kobo - it appears they've decided to get all of their websites under the Rakuten branding.

http://en.wikipedia.org/wiki/Rakuten

Also, a preemptive apology for the fact that the site currently requires Javascript - it's being worked on at this very moment.

That's great to hear. Thanks for the heads up.

A large part of the reason that many APIs fail at content negotiation has to do with the fact that many clients don't support it properly. Chrome in particular completely ignores the Vary header (and its devs have marked the issue as "won't fix"), so it's not practical to have the same URL respond with different media types based on the Accepts header (it overwrites the cached item, so the back button doesn't work properly). Many APIs compensate for this by putting the format in a query parameter.

If I recall, I think the over-styled but less-usable drop-down list was a deliberate decision, much like the call to setTimeout.

(I'm a housemate of StuieK and Firehed, and also contributed to the page)

Hey - I'm the back-end engineer for Slant.

Thanks kindly! We're just getting started, so any feedback you might have would be tremendously appreciated.

An excellent and practical article. I do want to emphasize one thing, though, since I feel like the article almost seemed to downplay its significance:

MongoDB does not support joins; If you need to retrieve data from more than one collection you must do more than one query ... you can generally redesign your schema ... you can de-normalize your data easily.

This is a much larger issue than it seems - nested collections aren't first class objects in MongoDB - the $ operator for querying into arrays only goes one level deep, amongst its other issues, meaning that often-times you must break things out into separate collections. This doesn't work either, though, as there are no cross-collection transactions, so if you need to break things into separate collections, you can't guarantee a write to each collection will go through properly. (Though, I suppose if you're using the latest version, you could lock your whole database)

I'd maybe argue that "framework" is a bit of a misnomer - Opa is a programming language based on ML (it was originally called MLState) where the compiler determines/enforces what runs on the client or server. It originally compiled down to native code on the server via OCaml as well as front-end Javascript, until the more recent switch to using Node.js on the backend. A lot of the security benefits it offers likely come from the type system (with type inference), probably similar to building a site in Haskell (compile-time errors on unclean strings, type-safe URLs, etc.).

Along side of this, it includes a slew of libraries and tools for doing things like authentication, interfacing with specific web services, and building websites, which is why it seems they've started to focus on the "framework" aspect.

I believe he's right, though - I've heard that Mode 7, and specifically the fact that it could simulate a 3D perspective with that effect, was a selling point of the SNES over the Genesis/Megadrive to developers (that, and its higher number of colors). I admittedly haven't played around with Mode 7 much myself.

Apparently Wikipedia has a nice article on it - http://en.wikipedia.org/wiki/Mode_7

For anyone who's wondering:

Mode 7 was the SNES graphics mode that allowed for things like rotating and zooming a background layer - used for things like the track in Mario Kart and F-Zero, or the worldmap in Final Fantasy 6 (while you're in the airship). The Scroll Register was used for scrolling in Mode 7.

H-Blank is the horizontal blanking period (and associated interrupt) - a time period between the drawing of scanlines on the screen (there's also V-blank, between frames). Changes made during H-Blank could make for some interesting effects - it was used for things like the circle that closes around Mario at the end of a level of Super Mario World: The rectangle draw routine is used, but the size of the rectangle is changed between scanlines, creating a circle. I'd imagine this was used for some of the wavy distortion effects in games like Chrono Trigger and Earthbound as well.

Even after the Recruit scandal[1], Recruit still has pretty much an absolute monopoly on HR in Japan. Their massive recruiting events are the primary method of finding a job. At the events, applicants are commoditized by filling out forms with the same subset of credentials, everyone wears pretty much the same suit, and even those with naturally lighter hair dye it black. Recruiting events for students and recent grads are separate from those for the previously employed (which are not as well attended by major companies). They're a major contributor to the status quo in Japan where high school and college names are the most important credential (which makes entrance exam scores of the utmost importance), introductory pay is low, and where those who leave a previous job have a difficult time finding a new one.

[1] http://en.wikipedia.org/wiki/Recruit_scandal

My understanding is that the thickness comes from the fact that the body isn't a single piece of metal, so you can swap out the RAM and HDD (unlike the 31A and 21A). Also, apparently you can repartition the SSD that's used as an OS cache into a separate drive reasonably easily.

As much as I'd prefer the formfactor of the 21A, the ability to upgrade to 8GB of RAM is too big of a selling point to pass up on the 32VD.

Why do you say to be wary of the 32VD? I was literally just about to buy one.

Are there really no instances of rewrites succeeding? Are we sure that projects that failed doing rewrites wouldn't have failed more painfully if they'd continued dealing with the cruft of the old codebase?

It's possible the problem is more in how these projects went about their rewrites, than just the fact that they did. What was the scope of the rewrite - did they simultaneously re-architect, redesign the UI, and try to implement all their hoped-for features (second-system effect)? Did they try to re-use old modules (temporarily or permanently - did they not reuse enough, or did they invest too much time making old code compatible)? Did the entire team immediately switch over to working on the rewrite, or did it get too few resources?

It might be worth investigating how a rewrite could possibly be done successfully, instead of assuming that the only option is to slowly refactor.

I use 2FA, but it's an absolutely frustrating experience. Most apps just don't support it. Google Music Manager requires a trip to accounts.google.com for a new App Specific Password every time I restart my computer, whereas Swiftkey just loses its ability to offer suggestions until I manually re-authenticate, which takes several minutes every time it happens, while I wait for an SMS and switch between apps.

> I believe just the starting of the timing is done by hand. The stopping is done when a contact is automatically detected.

That's exactly the issue, though - there are a handful of mechanisms in place to ensure that the clock stops and points are awarded properly - electrical equipment is used, buttons on the tips of the Epees are tested with a 750g weight, fencers test on eachother's masks before each match, testing kits are used to check wiring, etc., and the judges are there to watch movements to account for possible disputes. The task of starting the clock has been significantly overlooked compared to the task of stopping it.

Aside from this, the rules and the scheduling of matches are done with the assumption that there will be no major disputes, which needlessly compounds the damage from any dispute that happens.

Chrome's excessive caching is so broken for RESTful web services that I've just given up on letting it cache any requests from Javascript. It completely ignores Vary headers, too, so hitting the back button after an AJAX request to the same URL (but with a different content-type) as a visited page displays the AJAX response (e.g., JSON) instead of the page. Worse yet, it's been marked as WONTFIX.

http://code.google.com/p/chromium/issues/detail?id=94369

It was Japanese - it was the Kanji for sakura (桜) - hence the cherry trees in the background.

Am I mistaken in my understanding that WebSockets is a stateful protocol? If your problem maps well to resource oriented architecture, when would the benefits of switching to this outweigh the fact that you'd be giving up response caching and scaling on a per-connection basis?

The statelessness constraint is there to provide for cacheability; so that resource usage doesn't scale on a per-connection basis. HTTP's architectural constraints might not always be the best fit for your application's architecture, but the constraints aren't arbitrary.

This has been posted here a dozen times before, many times by the author himself.

http://www.hnsearch.com/search#request/all&q=Gameboy+emu... http://news.ycombinator.com/item?id=2427963 http://news.ycombinator.com/item?id=2477582

Impressive as the emulator is, it's been suggested to him before (and he has acknowledged) that he shouldn't be running non-public-domain ROMs on his site. If he gets a C&D/DMCA takedown, I have zero sympathy.