There is no entropy generation here, it is based on the Mersenne Twister, so it is pseudo-random only at this point. If none is provided, the seed is just the current timestamp.
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.
The other downside of Features in Drupal is that if we export something as a Feature (say a View) and then our site builders tweak and change that View for our clients and then we update some core element of that View and re-export the Feature, that re-export will overwrite any custom changes that were made to that View, thereby trashing any of the custom changes. This is a real problem with Features to which I'm surprised there has not yet been a good solution.
> Your comments comparing Rails and Drupal surprises me. I feel like you are writing without realizing how Rails development is done.
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.
Drupal developer with 4+ years of working with it under my belt.
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 disagree. I think companies ought to develop for every platform, companies ought to create a market, but developers ought to specialize generally.
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.
A Google search is hardly the way to resolve that. OS X searches for anything with OS or X whereas OSX only searches for things with OSX so of course the former has more hits.
I mean you're right that it's technically "OS X", but your methodology for proof is flawed.
I disagree. Even Citibank doesn't use the "bank" part on their main website, instead going by just Citi: http://citi.com
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.
While I think this may be true at first, if they gain any critical mass, the "Bank" in BankSimple would become redundant and wasteful.
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 ;)
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.
Right, and they can gauge interest easily and anonymously without requiring me to tell them specifically that I am interested in it.
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 am a little turned off by the fact that I have to log in to view this information. What is the point? Is this now Facebook?
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.
Right, I did read and notice that in the article, but the distinction I'd make is that there is a big difference from "having wifi at their stores," and covering every inch of a those very large stores. Many of them are >100K square feet[1]. To cover that adequately with wifi, in a fashion such that their business can reasonably rely on it at all times, is a significant investment. I'd guess that they are going to have wifi near the customer service desk or whatever so they can outwardly say, "we have wifi!" but not bother attempting to offer adequate coverage with the rest because, in addition to being quite large, they are often filled with items that would significantly attenuate wifi signal. (such as copper pipes, metal shelving throughout the store, etc.)
> Why would they want to pay more for iPhones with locked out features (like calls and email) instead of cheaper iPods?
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.
"Regarding point x, it's not that screen size is calculated on the diagonal; doubling the diagonal (and keeping the same aspect ratio) doubles the width and height as well."
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!
Another thing which the author seems to leave out is the usability paradigms for different sized screens.
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've experienced my own set of issues (oh god the kernel panics), but really, you haven't experienced anything he mentions?"
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.
"If you divide 480 by 44 you get a remainder of 20. Divide by 11 and you get a remainder of 9. 460 cannot be divided into equal parts of 11 nor 44. The vertical rhythm is corrupt."
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.
Potentially, but if so, it should be something which you'd have to opt into or open only for fellow developers.
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 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.
It's certainly not a direct correlation, but it does help to sort the spam bots and people who created an account but never use it from the rest.
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.
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.