vaporstun

I discuss this a bit more in the docs: http://chancejs.com/#todo

This is good for repeatability, bad if "true random" is needed.

Problem is, this is very tricky. I'd like to add it at some point, but finding a way to add entropy that works both in the browser and in Node would be quite difficult. For example, I could use mouse/keyboard in browser, but not in some server app running on node.

I could use an external service (like random.org) as the underlying random (I built it in such a way that this was easily swappable/replaceable), but then I'm adding network latency. I show an example like this in the docs: http://chancejs.com/#browser

So for now I'm punting on it, with a plan to revisit later.

First, no offense taken.

Next, I do have a fair amount of experience developing in Rails (it's my go-to hobby framework and I MUCH prefer developing in it to Drupal as I thought I imparted in my original comment) and yes, there are gems that get you most of the way there with some of the tasks I described, but our site builders (read: non-developers) are unfamiliar with the command line, could not generally install gems without intervention from developers and, if necessary, could not extend them without developer intervention. That is what I'm trying to describe.

With Drupal, people who interact only with a web browser can install rich components from a library of modules developed by others with integration with the Content Types (basically the equivalent of Rails Models in Drupal) with zero development.

Looking back at my original comment, arguably my time estimates for development were exaggerated to some extent and could be shortened with the use of gems, but the fact remains there is, at current, no way for users, through only a web browser, to enable that kind of rich functionality in Rails. That was the point I was trying to get across.

You don't have to write much code but you still have to write code. This makes it a non-starter for a particular class of user.

The nitty gritty is that we use it in an environment where we basically have 2 teams. One that builds custom code/modules that can be installed and enabled in Drupal to add additional functionality and another that actually deploys sites.

The team that deploys sites is savvy, but are not hardcore developers. The thing I've come to over all these years is that Drupal's pluggability still makes it the most powerful tool for what most people use it for -- deploying websites.

I have often surveyed the landscape and thought, "why not just build this in another tool like Rails or Django" and I always come back to it in much the same way the author of this article does -- while those are much more beautiful development frameworks, they just don't have the mojo that Drupal does.

This is likely best illustrated by example. This may or may not be based on a true story ;) Let's say I develop a custom application to interact with my company's backend database products which, let's say, are for events management. Now I pass that custom application off to the site builders who will actually customize that application for each of our hundreds of clients.

(1) The client wants a Google map of all their events

(2) The client wants the Events displayed on a calendar

(3) The client wants Events to filter by Event type

(4) The client wants a tag cloud or something else totally unrelated to the Events system

Built in Rails (Total additional developer time to add these features: 400+ hours)

(1) Damn, back to the drawing board, we need 100 more hours of dev time to develop a custom component to convert the locations into actual location data (lat/long) and display it on a map. We need to interact with the Google Maps API and write the code that will communicate with them via an API key and handle everything.

(2) Damn, back to the drawing board, we need 250 more hours of dev time to build a calendar and ensure we get the layout correct, handle a bunch of special cases (what if there are too many events to display on a single day, some months have 4 rows of weeks, some have 5, etc.)

(3) Developer has to add a form element to take that event type and modify a query to enact that filtering and load the results on a new page. Not a ton of dev time, but dev time nonetheless.

(4) Cross fingers that there is a Ruby Gem for this. Otherwise damn, custom development.

Built in Drupal (Total additional developer time to add these features: 0 hours)

(1) We never heard back from the site builders because they installed the Drupal modules Views, GMap, Location, and were able to create the map themselves from our custom Event data and clicking on the right buttons

(2) Again, the developers never heard back from the site builders because they installed the Drupal modules Views, Calendar and were able to show those events on a calendar.

(3) No developer time because the site builder went into the Views settings and added an Exposed Filter

(4) Site builders install the cloud tag module or the random feature X module, custom developer time rarely needed.

Now let's scale it up, instead of 1 client you have 500 and each want slightly different things. One wants to filter by Event type, one wants to filter reverse chronologically by date. One wants a calendar with a month view, one wants a week view. One has a ton of events and wants a day view. With Drupal, these are all just settings on existing, already built modules. With Rails/Django/Node.js/etc. these all require more dev time. Now of course things could be designed intelligently and parameterized to limit some of the DRY, but there is still dev time required to implement all these different permutations or up front complicated system design to create an architecture that can be configured as richly as a Drupal module developed over years by a community.

I work in Drupal professionally, but play in Rails, Django, Node.js, even Meteor every chance I get because they're so fun and beautiful but at the end of the day I still think Drupal is the right tool for our job in spite of its long list of flaws including its base language, the always horrifying PHP. But it freaking works.

tl;dr This article rang more true than I could have imagined it would. Thanks mcrittenden!

I don't think most developers are capable of being excellent at iOS development, web development, Android development, desktop development, etc.

Certainly it's not advantageous to specialize only in a particular language (particularly a dying or dead one), but that's quite different from a specializing in a particular platform.

If they have worked with developing in these many areas, they'd likely have some experience in each, but be not experts in any -- there are just too many.

I mean you're right that it's technically "OS X", but your methodology for proof is flawed.

There are also many other large banks that omit "Bank" from their name such as Wells Fargo.

Keep in mind this is not a traditional bank, so following the rules of traditional banks would be inappropriate. They are better off following the rules of progressive startups which have been using simplicity in their names quite successfully as of late (e.g. Square).

As for Bank of America, you couldn't remove the Bank from Bank of America or it'd just be America which doesn't make a whole lot of sense. I don't think Bank of America, aside from controlling most of the banks in this country, is an objectively great brand. Rather, I thought it always tried to piggyback and sound like a federal entity which it's not and always found its name disingenuous.

I think it is good and forward looking to rebrand it Simple before launch so that becomes synonymous with banking. Imagine if Google was instead called GoogleSearch? Google became synonymous for Search and therefore the Search portion of their name is superfluous.

I for one applaud this move and think the branding is nice, clean, and, of course, simple ;)

> could parse as either of:

> {foo:{bar:"Something",baz:"Else"}}

> {foo:{bar:"Something"}, baz:"Else"}

I don't think this is right, or at least, it shouldn't be right. I think _foo_bar=Something&baz=Else should only parse as {foo:{bar:"Something"}, baz:"Else"}.

{foo:{bar:"Something",baz:"Else"}} should be _foo_bar=Something&_foo_baz=Else

It should be possible for the writer of the article to fix this without major changes.

I value my privacy and find it silly that I have to log in. They offer no information as to why I must log in, I am just hit with a log in page. If this were under an NDA or something and it was an agreement into which I entered willingly, I would not be so opposed. As it is, they are simply farming my data and I don't like giving that up freely.

I think there is the growing problem that most people are increasingly willing to divulge their personal information, specifically online, and then have a backlash at anyone who doesn't feel comfortable doing so. It's trivial you say, just as it would be trivial for me to be forced to show identification whenever I get on a bus, but that doesn't mean I am going to be alright with doing so. Like the argument that only people who have anything to hide advocate for privacy. This example may sound a bit extreme but it is essentially the same argument.

Anyway, you're entitled to your own opinion, but I don't think it's going too far to be perturbed at giving up some of my privacy to look at an API.

I'm interested in the API but don't feel as though I should have to alert Dropbox, by being forced to login, that I am interested in it in order to learn more.

[1] http://media.lowes.com/history/

My guess is that they want a persistent network connection for the devices and it ends up being cheaper to just use the cell network for data with an iPhone than it would be to outfit every one of their stores with adequate wi-fi coverage for an iPod, ensure sufficient bandwidth on their outgoing network to support all devices, and they may have lower maintenance costs in the long run as they will not have to pay IT staff or other support to keep the wireless network maintained and, over time, upgraded.

I assume you meant point y. Anyway, right you are! This is what I tried to express by saying "By the rules of Pythagoras" because I was lazy and didn't want to take the time to calculate it precisely. I also assumed most people here would understand the implications, but on reading your comment I realized they may not and what I visualize in my head is likely far different from what everyone else does. Thank you for making it much more clear and explicit for me!

As far as Apple goes, with their 2 formats for their mobile devices(x), iPhone and iPad. Things that work on one device wouldn't necessarily work on the other. I can't remember what Gruber said on this subject or if it was Steve Jobs himself, but I think they both said some variation.

On the iPhone, it makes sense for many UI elements to take up the entire screen, for example a list of contacts. But on a device with the form factor of the iPad, that looks stupid. Likewise for the opposite - with a device the size of the iPad, it makes sense to have multiple panes and popovers such as in the Mail application. If that were on a device the size of the iPhone, it would be simply unusable. So things formatted for one device wouldn't work on the other and vice versa.

So, on a device in between those 2 primary form factors Apple has chosen, which approach makes the most sense? I would posit that neither really works. The iPhone's "take up the whole screen with a single thing" seems too large and the iPad's "multiple pane" approach would likely not be usable on a smaller device. Maybe that size screen is fine for such things if the pixel density is raised such that the resolutions match, but I would guess it would feel very crowded if you just took the iPad UI and crunched it down significantly.(y)

So it's hard to develop good UI for these 'tweener screens because in some contexts the UI paradigms from the iPhone fit better and in others an iPad approach would be better. Sure, developers could have logic saying that, in some contexts on a 7" iOS device, use the iPhone UI layout and in others use the iPad UI layout, but that further complicates things.

I won't say that no one could design a UI for such a device, in fact I think the Blackberry Playbook has the best UI of the devices I've seen at this size, but I think it's difficult for Apple because it doesn't naturally fit either the iPhone or iPad UI scheme. And it seems like most Android devices pick which paradigm to use by the OS - those devices which have a Tablet factor use Honeycomb (Android 3.x) and those which just scale up the phone version use Gingerbread or earlier. (Android 2.x) It will be interesting to see how they deal with this issue when they merge the two.

(x) Essentially anyway. Technically they have three when including the iPhone non-Retina and iPhone Retina but since one is just double the other, there is not a different form factor

(y) Remember, it seems like the difference between 7" and 9.7" is trivial, "only 2.7 inches!" one may say, but note first that 2.7 is almost 1/3 smaller than 9.7. Second, note that screen size is calculated on the diagonal. So by the rules of Pythagoras, it is actually significantly smaller.

I'm in basically the same boat. I have experienced some issues, but none of the ones he mentions. Further, in my experience anyway, this has been the smoothest major OS version upgrade I've experienced. Obviously that won't be true for everyone, but it is for myself.

"You don't feel like Mission control is a pretty big step backwards from even the old spaces UI (on a single monitor, it is)?"

I don't personally, but to each his own. I think it is refreshing that they cleaned things up and consolidated what was once multiple disparate UIs (dashboard, expose, and spaces) into a single UI. Formerly, I didn't even try to explain to my wife how to use Spaces because it was just too confusing for her. Now that it's all basically one UI, it is easier to explain and requires no manual configuration. I am a bit annoyed at some minor quirks, like the inability to manually rearrange desktops, but I don't consider it a step back.

"You think Launchpad is not pointless?"

I just simply don't get this complaint. They added a new feature. If you think it's pointless, ignore it, but what is the point of complaining about a new thing which you are not forced to use which does not deprecate any old feature?

Anyway, everyone is certainly welcome to have their complaints, especially someone who has experienced some poor issues, but I agree with the grandparent comment that often someone's configs can get mangled and they can lash out at, in this case, Apple, as though it is entirely their fault. I would be extremely surprised if all of these complaints were entirely valid and the writer of the article were not tinkering with their system intensely to have all these issues pop up.

I would actually argue that the remainders are a good thing.

When viewing a list, they act as a nice visual indicator that there is more content below. If the last item directly lined up with the bottom of the screen, it would not be as easy to differentiate at a glance. By showing half the last item, it encourages the user to pan down to see the remaining content.

Certainly some would suggest I'm claiming "it's a feature, not a bug" and maybe that's true, maybe the remainder it is unintended, but I think it does make more sense to have the bottom element in a list half showing to alert the user that there is more content below.

The last thing I want is to get spammed with "bug reports" from lay users with trivial or non-existent issues.

If they implemented this but made it take even one extra step like flipping some switch in the settings, it would filter out most lay users and garner some more useful feedback.

The overview from that page:

The Kidd Mine is in northern Ontario, 500 miles northwest of Toronto. The mine began operation in 1966, producing copper, zinc, indium, cadmium, silver and sulphuric acid. The deposit is one of the largest and richest volcanogenic massive sulphide deposits in the world.

There is an underground mine, and metallurgical facilities consisting of a copper concentrator, smelter and refinery, and zinc, cadmium, indium plant, liquid sulphur dioxide and sulfuric acid plant. Kidd's concentrating, smelting and refining processes are among the most advanced in the world.

The mine currently employs 1400 people and operates 7 days a week with two 12-hour shifts. The properties comprise 14 patented half lots covering 896 hectares of freehold mining land.

Kidd Creek has three shafts known as the No. 2, No. 3 and No. 4 mines. Mine D is currently being developed to access reserves below the 6,800 foot to the 9,500 foot level. Commissioning for Mine D expansion began in 2004, and is scheduled to increase the operation's ultimate capacity, in stages, to 2.7Mt/yr of ore to 2012 and deepen Kidd Creek Mine to a final depth of 9,500 ft and extending the life of mine to 2017. Kidd is the deepest base metal mine in the world.

However, I did mention that the karma approach would not account for lurkers which was why I proposed the logged in method. There are many other interesting data points I'd love, but without pg releasing a lot of the info, it's tough (or in some cases impossible) to gather from public data.

Or, the number of users that have logged in within the past week though this is probably something pg would have to give us because I can't think of any way to determine that without the backend data.

This is not true. Sure, if you were the ONLY developer with 0 reviews on a new OS version and everyone else had a bunch, it would look bad, but if every app had 0 reviews, you would be no different. And if you had a large user base on one version of the OS you'd likely have many reviews quickly.

> You should not see any difference in the different versions of iOS. Though it might perform differently on different hardware.

Certainly things are often mostly backwards compatible, but there are often changes at the API layer which break some things or add features that are available on the new version that weren't on the old one. For example, Apple added the backgrounding/multitasking mojo with iOS 4 but until an app was updated from iOS 3 and could make use of those APIs, the functionality wasn't enabled. Does it make sense for users of iOS 3 to see reviews of an app, not yet updated for iOS 4, of iOS 4 users bitching about how the app doesn't multitask right when multitasking wasn't enabled in iOS 3?

> I feel as if Apple hasn't really done very much to help the developer note what platforms they are targeting in an easy way. If you don't want iPhone 3g users to use the app, they shouldn't be able to download it that that device in the first place etc.

This is a decent idea, however most things DO work from one OS version to another, so barring people from using an app on their new device seems like it would often be an artificial limitation. Further, it is tough to beta test an OS if there are no apps to run on it. I think this concept of splitting the reviews would solve the problem of clutter in the current review system without barring people from doing the testing that ought to be done.

Further, some kind of hybrid could be done, such as maintaining the star rating across OS versions (so people could have an accurate representation of the general reliability, etc. of a given app) without clogging the review systems of different OS versions with irrelevant data and unwanted complaining about incompatibility with the new beta.

Apple should make it so reviews are only shown for the OS of the user's phone, so if I am on iOS 5 I can see the beta reviews, but most average joes still on iOS 4 would only see those relevant to iOS 4.

This also solves an issue of users still on iOS 3 with an app that may no longer be compatible for iOS 3 clogging up the reviews for they aren't relevant for most current iOS users.

I cannot even begin to describe how many times I've heard commenters here spout advice like they are experts in patent law when they simply don't have the most basic grasp about them. It's terribly frustrating and scary to see people taking this often horribly wrong advice.

Sure, some people here are right, you probably don't have much to fear, they're probably just bullying you, but please, please, please don't take legal advice from a random forum. That's like taking advice on rails development from a forum full of lawyers. They just won't know what they're talking about much of the time and it can be very dangerous.

You are right in that the date of invention in the U.S. is a useful date, but it only means that in the event of a conflict either during patent prosecution or on a challenge to validity later, he who can show they had an earlier date of invention will "win". In the rest of the world, it is the date of application that determines who ends up with the patent rights in the event of such a dispute. But it is not a priority date.

This is like calling a router a switch and claiming they are the same thing. Quite different in fact.

The date of invention is not determinative for things like infringement (again, short of patent invalidity), and the date of invention is never written down anywhere. It only comes out in the case of a conflict.

The date of filing IS a determining date for the term of the patent - it last for 20 years from the date of filing.

Further, the date of invention is not a "priority date", that is the earliest date for which an application can claim priority. An application cannot claim priority from an arbitrary date of invention, it can only claim priority from an earlier filed application here or abroad. Basically, you can never say, "Patent office, I invented this widget on this day" and have them say, "Ah yes, your patent term starts then." Your earliest priority date is your earliest filing date either here or abroad.

The main issue is that there are 2 dates for a patent, and the post to which I responded gave an answer with no clarity or regard for the disparity and seemed to indicate that the OP could be liable for retroactive infringement which is untrue.

It is just dangerous when people here on HN give advice on patent law issues. They are very complex. This is similar to if you went to a lawyer forum and they all claimed to be experts on web technologies, dishing out bad advice (ASP is totally the way to go these days, that ruby on rails thing I hear is a virus that breaks email printers. Therefore, always use Microsoft servers.), but the consequences here are more dire. If you saw lawyers saying that, you'd probably have a brain aneurism.

This is just wrong. I'm growing increasingly frustrated at the number of users here on HN misquoting everything about patents. If you don't know or understand it, it's best not to comment. If this were something technical and you didn't really know the answer and answered as if you did, many people here would be up in arms. This is no different.

That said, while a patent term is calculated from the date of filing, a patentee has no rights until after the patent issues. So if the entity making threats against you has a patent which issues (which sounds like a big if), he can sue you, but only for your acts of infringement after the date the patent issues. Since the patent has not issued yet, he could not sue you for your actions between now and the issue date, only for actions post-issue because that is when that entity's rights begin.

As an example, if you asked an outsider to the tech world which brand makes the EVO, Nexus S, Veer, or iPhone, the only one they'd likely get right is the iPhone. This is a bit of a loaded example because the iPhone is super popular, but then ask a random consumer who makes the follow made up products, the MOVE, Slider, Jump, iThing and they know that the i prefix means Apple and likely wouldn't have a clue who makes the other things.

So anyway, it's a tad annoying, but it is also a dead simple, one-letter way of identifying the source manufacturer. It's quicker and shorter to write "iCloud" than it is "Amazon Cloud Drive" or "Google Music" and identify the source with most consumers. In this way, it's subtly brilliant.