The upside is that people have to be quick to spot the typos, e.g. "miriad" ;).
1,088 karma · joined August 6, 2009
I've developed on both platforms and only one of these reasons rings true to me -- the QA headaches of testing on many devices. IMO Android tooling is superior, the APIs are pretty much a wash and there are more advanced features exposed on Android (though not in every area). On Android you also: don't have to worry about retain cycles (and don't get me started about pre-ARC days); have access to the source code and bug tracker (a huge time saver in some situations); don't have to deal with provisioning profiles for development and beta testing.
I think you're unfair to Jenkins in a couple of ways:
1) It's not as hard to set up as you make out. If you want to see what it's really like for nothing to work out of the box then head to the pre-Jenkins (then Hudson) era when CruiseControl was king (and I mean no disrespect to CC, it was a groundbreaking project). I agree, though, that the overall UX leaves plenty to be desired, and indeed this is one way we compete with Jenkins.
2) The strength of Jenkins is support for a huge range of environments and tools, with contributions in the small from a massive user base. Part of the trade off for this flexibility is some extra complexity.
I gather CircleCI approaches this space from a different angle, by narrowing focus thus making a streamlined UX a lot easier. That's a fine approach, and I wish you great luck, but it's not a way to "vanquish" Jenkins because you won't be able to satisfy most of the Jenkins user base.
Our approach is somewhere in between, and the balance is our greatest challenge. We've spent a lot of effort focused on ease of setup, and even more on ease of ongoing maintenance (especially for large build farms). I don't expect we'll ever compete with Jenkins on pure flexibility, rather I think there is room for many competitors in this space. After all, everyone should be into CI!
Based on existing methods my solution started with the same trie and then generalised to a more flexible DFA by merging states. I used information theory (specifically Minimum Message Length) to turn it into an optimisation problem and tried a few different algorithms, in the addition of Ant Colony Optimisation to an existing algorithm produced the best results for my tests. (They were pretty limited, though.)
Every project's main build should be scriptable -- for reproducible releases, continuous integration etc. I wonder how Apple internally builds things for release when something this simple doesn't work (maybe they don't use OCUnit?).
I could certainly see a minority of Reader customers paying enough for the service to make a small team very comfortable. It would have been nice for Google to spin it out for this reason, though I suspect there were significant technical barriers.
Another tip: try both Xcode and AppCode: http://www.jetbrains.com/objc/. It's a subjective thing but for myself AppCode is far better (it helps that I also use IDEA for Java, including Android).
I also agree that the lack of "diffability" for XIBs, despite them being XML, is a pain.
Maybe I was missing something, but my experience matches the OP.
That's true and will work in most cases, but perhaps not when client sessions are short-lived.
> Basically, you can fold elements of the collection up into the parent, and the client will automatically make less requests.
Now it looks like my choices are to either fetch more data than I need, or make more requests than I need.
> Best of both worlds.
Well, both best and worst of both worlds. Each approach needs to stand up to cost-benefit analysis alone or I doubt it's worth maintaining both.
I do see advantages in these patterns, but I think some of them are more theoretical than practical, and I'll take the practical advantage I see today over the theoretical one I might need in the future.
But it seems to me that if this was happening at even a basic level, then whoever is in charge of the product at Instagram must have known they were adding some pretty onerous terms. And if they didn't, it's a pretty massive failure to take the ToS seriously.
Neither option inspires confidence in a service that people provide with important data.
Secondly, when your data is hierarchical, it's nice for other reasons to reflect this in your URI structure. It's intuitive (and thus discoverable in its own way) and can make for human-friendly URLs (especially when your datatypes have natural identifiers).
Speaking from practical experience using an API like this: it can result in a lot of extra round trips to get to your final destination. The indirection is nice purity-wise, but in practice do you really want to make 3-4 times the round trips to the server for every API interaction? Especially when you might be on a mobile network? All for the sake of flexibility you may never need?
I'd say supporting the discoverability for learning, and consistency etc is nice. But in practice concerns like this (and the DHH example, and others already in comments here) will crop up and clients will start building their own direct URLs. So the idea that you'll be able to change the URL structure without affecting clients is a pipe dream.
However, for a service like Instagram, the ToS are a critical part of the business. Any changes made to the terms should be known, understood, and agreed on by whoever sets the overall strategy for the product. The legal team helps them encode it, marketing and PR help them communicate it outwards, but the strategy should be coming from the top, and the responsibility should rest there.