I was actually going to reply something along the same lines. These sorts of services exist on both iOS and Android (can't speak to Windows Phone). Not for the provided example, but for Android, the Intents like you mentioned, and iOS has a similar concept for things like "Apps that are capable of routing/mapping" and possibly other things. Neither of these are done through the example "standard prefix," but both are through by adding some standard permission or key to your app.
I'm familiar with the linking capabilities of apps, at least for iOS (haven't played with Android). I think it's a bit limited, as it currently stands, but I feel like the intent of the url schemes is somewhat different from the idea of linking on the web. On the web, you typically link to open content, whereas I feel like apps tend to be more personalized; seems like linking wouldn't work quite the same. Interested to think more about that, though.
I largely understand what he's saying, in terms of misuse of the protocol. I think you're going to find those sorts of things being the case for any toolset, though. Given enough time, and enough developers, you'll eventually run into people using it an entirely different way than you initially intended, regardless of the specifications or documentation written around it.
One thing I'm not sure I agree with, though, is the mobile application "linking" he mentions. When have non-web applications ever linked? What of all of the old "desktop applications" that everyone used to use? Those don't typically link, why is there a different expectation for mobile applications? Oh, and most mobile apps do support linking (in some sense, though it's not really a primary feature). Perhaps I'm misunderstanding what he means with this.
Ah, the weird extra arguments is something that I had noticed as well. And I have to admit, with some shame, that I have not taken the time to look into why.
Do I want to buy and manage servers myself? Would I pay for an additional computer to host my little toy Rails app? Will my ISP allow me to route network traffic to my personal IP with a standard plan? Most, at least that I've seen, prevent you from hosting.
For a little project something like the author of this article described, using virtual hosting is significantly easier (and more realistic). If you're going to run an enterprise operation, bringing that sort of hardware in house might make sense, but a lot of larger companies are still pushing that hosting out to places like Amazon as well.
Now, if you're asking why Amazon would allow (new) customers to scale up to $3000 worth of hosting overnight, maybe that's a separate issue. But how should Amazon judge that? There are probably users who want to jump straight up to that sort of scale. And evidently they did detect that the author didn't seem to fit that use case -- they actually called him about it pretty much right away.
Funny, I ended up with SourceTree because it seemed like a clean and simple (well, at least when I started with it), but still having all the tools I needed, alternative. Sure, it has gotten a bit more complex, but the basic functionality (as I see it: diff, stage, commit, push, pull, branch management) feels simple to me.
Could you explain what parts of it you don't like? Also, could you link to git gui? I tried to Google it, but didn't really get good results (shockingly, all the other Git GUI programs came up...).
Girlfriend has a 2008 MB that I bought off Ebay, other than the hard drive dying (and giving me ample warning and time to replace first), it's had no problem. Since it's limited to 4GB RAM, it isn't really ideal for development, but she runs Photoshop and Illustrator on it (albeit, a bit slow for my taste).
I personally own a late 2011 MBP (same as the article, I believe) with 8GB RAM, also no problems, running a pretty standard development set up.
I have another 2012 MBP through work which is a bit beefed up, though still nothing fancy. Also no problems. Also manage a couple of 2010 Mac servers there which have been running steady since late 2010.
Oh, and none of these have SSDs. So, say what you will about non-SSD, they work well enough for development.
All in all, have to agree -- whatever fits your budget, at least in my personal experience, will work pretty well. I know that people do certainly have issues with them occasionally, but when I compare my luck with them to my luck with various other brands (Compaq, Dell, etc), they've lasted significantly longer with few or no problems.
If you guys are really interested, the profile you linked has a list of projects. Glancing at the "vogar" project which it says is owned by e...@google.com (first I happened to pick), you can see links to the blog of Elliott Hughes. His site indicates he's a Google employee. So, not exactly proven, but seems to fit the bill.
Cool, I'll have to take some time to read through more of that, but a quick skim actually made clear to me some of the differences I was missing, especially when combined with the other comments.
Which is unlike Promises, which guarantee a single "end," but also don't care when that ends (could have already happened, could happen eventually). Seems similar in nature to a socket connection.
Not hoping to start any sort of flame war, but could someone try to explain this difference between streams and promises? The conceptual difference doesn't seem completely clear to me.
As someone who has no idea about the cost of high-scale computing like this, is $150/hr reasonable? It seems like an amount that's hard to sustain to me, but I have no idea if that's a steady, all the time rate, or a burst rate, or what. Or if it's a set up you'd actually ever even need -- seems like from the examples they mention (like the Tweets), they're above the need by a fair amount. Anyone else in this sort of situation care to chip in on that?
I guess I can't add an edit to my post, but ironically, a day later, a friend of mine posted on Twitter about having his dog at work. So maybe I am the one with the unusual office.
As someone who is in no way a senior developer, I can't imagine working in this sort of environment. Then again, I've been working exclusively in enterprise up to this point.
Perhaps this is more of the norm in the Bay Area (I assume that's where you're from, from your other comment), but I've never seen anything as open as that (dogs at least). I don't think anyone would claim that a "bring your dog to work and let it roam around freely" sort of environment would be productive. I'm surprised they would allow that at all, seems like it could cause other problems as well.
I still don't think that sort of generalization is fair, though. I think a normal, sane office could be open, but without the ongoings that seem to be present in the environments you and the parent witnessed. Well, I can definitely vouch for that being the case in the office I work in.
This seems like an unfairly-condescending post to me. The last line primarily. I don't think that having an open office implies the stereotypical "nerf gun wars, billiards, and foosball" environment (or at least it doesn't at the company I'm working for). Nor does it mean that those who work in it are irresponsible, immature, or self-important. Certainly those conditions exist, but it's not fair to generalize it that far.
I'm not sure that this is meant to be a replacement for a mouse -- seems more like an additional tool for specific tasks (like the Photoshop task mentioned in the article).
At first I was thinking that suggesting that you exactly check the output of a request might be a bit much, especially since it could be entirely variable and cause your tests to break at any point during refactoring. If that was done by a third party framework, as you point out, you might not get a whole lot of value from testing its output. However, if you're constructing your own HTTP requests, as seem to be, then yeah, you probably need to explicitly check that it is being built up correctly. Or, since this appears to be a single build up, and not common/shared functionality, it could probably be abstracted into a common function/utility that does it for you. That should be easily unit-testable. Fair enough.
What test would you have written to catch this? One that checks the exact contents of headers passed along? It's possibly they even had tests around this, but were expecting the same output that they were inputting (copy+pasta). Perhaps they had a more "integration"-ee test that actually hit the web with that bad header. At the point they wrote it, that test would have been passing. It wasn't until the parsing server changed (to Coyote, it seems) that the test would have started to fail.
Could you explain where you think the issue here is? Are you saying, as a user trying to upload, you could possibly (presumably accidentally) upload your passwd, or as a user of their site, you could somehow see their passwd file?
If it's the former, I think that's a 'vulnerability' with any site that has a file chooser.
If it's the latter, could you elaborate where and how you would do so? Perhaps you're saying you could load it through the simulator that's running on the actual computer/vm somewhere, but those simulator environment are sandboxes (afaik) so that you could only access files on within the simulator's context.
Note that this was on Dropbox, not on any of the mail providers. Unless Google (et al) is going out of it's way to send emails to its users in the list, which would surprise me.
It would be nice if someone would write a quick script to email these people notifying them. Maybe if I get more time tonight, I'll give it a shot. Otherwise, someone else could be the hero ;)
I'm not sure how they figure that. How would having a having the Chip and Pin have prevented the data from being stolen? How does them encrypting the data they send relate to the cards? Those seems like separate issues.
With regards to online use, I'll say I'm not familiar with how Chip and Pin really works, but presumably they have some guard for online use, right? Or is that just wide open still?
Without specifically being in the situation, it's hard to tell. The author implied that when they had spoken on the phone, he indicated to Troy that he wasn't sure if he was ready to commit, and then received the "please return by Monday" email within moments. It seems yours was more of a "yes, we're interested" followed shortly by the email. Maybe it's just their standard practice to immediately follow up "the call" with "the email," but I can see how it could be perceived differently depending on the receiver.