thathonkey

Oh thanks for breaking it down for me. When it comes to web development, for all intents and purposes, they can be thought of as one in the same since the browser version issued with a device is tied to OS version[1]. Of course some users will upgrade OS and/or browser, independently in some cases, which complicates things further.

[1] http://jimbergman.net/webkit-version-in-android-version/

Fonts are quite the subjective thing. M+ looks a little on the thin side to me. I greatly prefer Menlo (regular, which happens to be the default for Sublime Text on OS X) or Consolas.

Don't think there's any fragmentation problems on Android OS?

Just try creating a mobile website that supports common "modern" devices. Have fun trying to wrap your brain around all the idiosyncrasies across various versions and browser implementations (Android Stock vs Chrome etc) that will endlessly dirty your code if you want the site to look at all correct in a majority of Android devices.

The Android emulator is pretty nice... once you figure out how to set it up for whatever device you're trying to test. It's a ridiculous resource hog though by default (there are ways to mitigate this if you're on an Intel chip). Say what you will about simulation vs. emulation but the iOS Simulator is a dream to work with (again, for web development) and I've never had it mislead me even though it isn't truly emulated. But then you realize there is no way to install the Chrome browser unless you are hooked up to the Android Marketplace (even if you're on the latest version of OS). The best you can get is Chromium, which is a pain to install and doesn't work on some AVDs.

All that ranting aside, I've never had a problem with screen sizes, even when working on responsive stuff. But, yeah, Android is basically the Internet Explorer of the mobile space. You'll keep hearing "oh the next version will fix that!" and it may... but you'll be stuck supporting the versions that are broken for years to come.

Yeah the main paragraph text is definitely too thin/faint on OS X Chrome even. It was bugging me too so I simply stopped reading after a few paragraphs.

Day jobs as in 9-5, no, but a large % of them do something related to teaching. So most of them obviously needed some way of paying the bills.

It's interesting how few hours of sleep they get and they're all early-risers.

Is the rule still that if you allow in-app purchase or subscription then it must be sold through the App Store? You could circumvent this by distributing the software via the app store and then must authenticate before any of the functionality is usable. Amazon Instant Video and Netflix apps do this I think presumably so they don't have to pay 30% of their subscriber fees to Apple.

I listened to an episode of Radiolab about 3 "Black Boxes" lately and the first one is about this mysterious threshold in the brain between consciousness and unconsciousness.

Here is the episode if anyone is interested: http://www.radiolab.org/story/black-box/

My approach to CLI is basically: if I wanted to use the mouse, I wouldn't be in the terminal. Having to reach for the mouse is a huge waste of time and I only do it if I need to scroll (rare) or copy+paste (relatively common).

Although since I use OS X (Darwin) I don't always need the mouse to copy+paste (ie. pbcopy -> cmd+V).

Wait... Spagwood is an actual kids' name?

This is undeniably neat but I am curious if you "know what to do" because you have a lot of experience using applications that looked this way largely by necessity. I don't think the average computer user would favor this type of aesthetic on any level.

When I was growing up with computers, interfaces like this were on their way out. So to me it just looks clunky and messy. Other than inspiring nostalgia and impressing me with the amount of work that surely went into creating it, I don't think this theme has much real world application.

These themes that attempt to replicate the look and feel of a GUI are pretty gimmicky in nature (ever been to a terrible blog that tries to look like the OS X GUI or worse... one of the Windows GUIs?). This one just happens to be really high quality.

It was the kids' names that tipped me off. Dagwood and Spaniel? At least I hoped it was a parody after that part.

I fail to see how that solves the problem for anyone other than people who already know that they're looking for a Haskell REST framework that might be called Rest.

This comment section turned out about the way one would predict when so few of the participants have ever studied economics.

I disagree that the name for something like this is a trivial decision. Especially when considering the name for a framework which will need to be discoverable on Google to gain popularity. And even more especially when you choose to name the framework for working with a technological concept in one specific programming language the same thing (albeit different casing) as that technological concept itself.

How is that not a really important decision that should be considered practically? If I want to query Google for REST vs. Rest, or even converse with people about it, you don't think that will quickly become (needlessly) confusing assuming the framework becomes popular? And if you aren't expecting the framework to become popular, does that make it OK to choose such a lazy name?

But, hey, at least you got to namedrop the term "bikeshedding" along with your highly specious argument.

"We've decided to call our REST framework - wait for it - Rest."

Comparing this to 538's (quite different) Analysis [1]:

#1

* 538 - Brazil - 36.0%

* WOLF - Brazil - 32.2%

#2

* 538 - Argentina - 17.0%

* WOLF - Netherlands - 23.5%

#3

* 538 - Germany - 12.0%

* WOLF - Germany - 21.6%

This paints a pretty interesting picture about trying to use statistics and math to predict sporting tournaments like this. Seems like nobody has been very successful at this yet. Obviously it gets "easier" as the tournament progresses, though.

* [1] http://fivethirtyeight.com/interactives/world-cup/

Now you're onto something! Your first point is true. If the suspect manages to dispose of even some of the substance, that could hurt the case. Or it may not. There's lots of factors, I was just giving the simplest example I could think of (trying to flush a sufficiently large amount of cocaine).

To elaborate on your own example though, pretty sure that even if a firearm is legally registered you can still get in trouble for having it around, especially loaded, in the context of selling illicit substances.

That is almost beside the point, though. How many dealers do you think are using registered firearms to protect their trade? Of that group, how many are registered to the dealer using it and not some random family-member or whatever?

Sorry, I think you're missing my point that is even if somehow they could flush the entire amount of the illicit substance in time, they probably have other items on hand that would be just as good from an evidence perspective.

For example, you can't flush a scale down the toilet.

If we're talking low-level or mid-level dealers, chances are they have a quantity of pre-packaged amounts of their product on hand and maybe even a firearm or two. Unless they can quickly melt-down and/or liquify all of that stuff, it isn't going down any toilet pipe while the homeowner argues with the cops at the door about the status of a warrant.

I edited my example to make it a little better. Point being: If you are a big enough dealer to be useful to the police in a larger investigation (or to warrant SWAT team "no-knocking" at your door), you probably have quite a bit of related evidence that would not fit down a toilet.

That is way too logical and cost-effective. Plus then they wouldn't get to use the cool-as-shit flashbangs that their dept got on the cheap.

Not to mention you'd have to be a pretty low-level drug offender to be able to destroy enough/all of the evidence in the time "not knocking" saves the police.

(ie. You can't exactly flush a kilogram of cocaine and a triple-beam down the average toilet in a matter of minutes)

Hence why I said the lack of training is a side-effect of militarization. In other words, yes, militarization of police is the main problem here. I agree with you; I was just pointing out yet-another-reason why it is even worse in practice than in theory.

This is a side-effect of police militarization that doesn't get much attention from its critics: using advanced military equipment should also require advanced military training. Local police agencies that receive all this new military-spec equipment don't always get (or more likely, never get) the funding for necessary training on how to use it. Much less does such training really exist since this stuff was all designed for use in actual war zones. The extant training materials would inherently be oriented around that type of usage.

Even the worst part of the worst city in the USA could not be more different than a war-stricken area of Iraq or any other region where military action is a common occurrence (other than that they probably contain more friendlies than enemies).

Aside: It is truly sickening that they used a flashbang on a residential house where they hoped to apprehend a single, low-value suspect that could not possibly have been that well armed. Again, lack of proper training.

Depends which part. Happens all day every day in Palestine.

Yeah but it could be a premature optimization if you blindly decided to use a library because the cost of having to download it (in the case of browser JS) and/or parse (in the case of server JS) an extra script file may outweigh its performance benefits.

JavaScript has quite a few advantages compared to RoR (eg. it will forever be the language in browser, hence if you choose Node then you are using the same language on both sides. This is the main reason I think it won't be a fad like Ruby. Also Node is way faster than RoR on average). So no, nothing like that.

Javascript isn't really a fad. Server-side JS isn't going to be a fad either, hate to break it to you.

It is an enhancement for the benefit of front-end performance. I'd like to hear how you think that is not true?

Anyway, that is why I asked the loaded question about how many users you think there are that browse Twitter.com on their RHEL box? Hint: HN is not a good sample to answer this.

And how is a ~14-year old technology (that has been ubiquitous now for at least 6 years) considered bleeding edge?

What percentage of Twitter's users do you think use Linux for browsing? Much less RHEL. Anyway, this is purely a front-end enhancement mostly for the benefit of mobile users.

Also lol @ mp4 being "bleeding edge" tech. It certainly is not. Even in the Linux community.

Really, GPS is what you're going to call it? That is a bad idea for a bunch of reasons, mostly practical (GPS already means Global Positioning System to just about every American and search engine, etc.)