That every developer simultaneously develops for iPhone, Android, Windows Phone, WebOS, Blackberry, Meego?
Developers aren't so cavalier as you about suggesting that you port your code to multiple platforms because we do know how much time, effort and platform-specific knowledge it takes to build a decent app.
Many iPhone, Android, Windows Phone apps are written by single developers that can't take 6 months per platform to learn how to code for it.
For most of us making a bet on single platform is the only viable strategy.
Bad strategy? Maybe. The only one possible? Unfortunately.
You would be pissed off too if your business failed not because the owner of the platform you bet on built a better product than you (and with their money, teams of programmers, marketing and ability to advertise to users of that platform they do have a huge advantage) but because they just used their monopolistic control over their platform to set business terms that are unheard of on other similar platforms and kill your business without them needing to lift a competitive finger.
I'm sure you'll tell me that Apple has the right to screw everyone on their platform and if I don't like it, I should just use another platform.
And that's exactly what I'm hoping people will do once they realize that Apple not only has the power to screw their developers and their users but is actually screwing them, as this on-going saga of 30% monopoly tax on content sales shows.
"Five of us spent nearly a year and a half of our lives and over a million dollars in cash and sweat equity developing the iFlowReader app"
if they were serious about the risking all their eggs in same basket, they could have used consultants/outside developers to port their app to other platforms with less than 10% of the said investment
Note that they state both cash and sweat equity of one million+.
Between five people and 1.5 years, a million dollars in sweat equity for developers is probably understated. They invest the time & skills (that they could have been using to freelance or consult for others) into their own company. Some people would consider this 'free' - but it's not free, the opportunity cost is still there. When you're closing shop without a gain, you are going to start looking back and counting all those lost opportunities in terms of dollars.
a) A game has no issues. It's life cycle is short.
a.a) A long-term product/service strategy can't rely on one platform as they are under the whim of the owner.
b) Don't build exclusively for one platform. Thats right, develop for android, webos, etc. The point is that one choice is to be fucked in the ass by a company at their discretization, the other choice is to have protection vs that.
You can't complain "waa waa waa apple chaned their rules" too bad. It's apple's proprietary tightly controlled market. You want to make money? Bend over backwards for them. Otherwise piss off. It happened to twitter clients, its happening to facebook clients, its happening to apple clients. Learn from history.
Windows applications have been lucky. MS has been pretty nice over the years with what they allow. However if MS says "30% surcharge on any application selling something running on windows" then guess what, same cries will happen. Boo freakety hoo. This is what people were saying about being careful with apple's tight control. This is why I support android. But some didn't listen so they get fucked in the end.
Yes, "boo hoo", and all that, but what about the third-party in this failure: the user. Ultimately, we lose. iFlow was a unique application that was innovating in the reader space. It's a shame that they were pushed off of the platform that I prefer.
I'm not going to get all sanctimonious about it, but it's slowly beginning to weigh on my decision making process. I love my iOS devices, I really do, but when I look at Apple's approach, it appears that their bottom line comes first. Period. It's already hurting innovation in limited ways, as we can see here. What happens as they continue this approach and it affects more types of software?
In my view, Android looks more attractive all the time, and I'm not exaclty happy to say that.
That is the truth. I don't understand why so many people are willing to defend Apple in this situation. There is no way to construe these rule changes as anything but anti-user, and you should worry when a company breaks profit records but continues moving in an anti-user direction.
Look. iPhone is superior to Android. I know it every day I use an Android. However I cannot buy an iPhone because:
a) I use sprint and am happy with it.
b) I don't support Apple's control on a moral level. So I will not support Apple by buying the iPhone.
c) I won't develop for iPhone except as an after-thought or short-term project. This way I make money, and get out. I won't make any long-term plans for it. In fact that is true of EVERY mobile platform. Never bind a single long-term plan with one platform. Tomorrow Android can fail and WebOS rises to beat everyone in one swoop. You can't build a company on hopes and luck alone.
What ground can't move at any time? Being completely independent of anybody else is mind-bendingly hard. I bet you aren't either. Very few are — most are just lucky enough not to have had their dependencies fail so catastrophically.
I'd put it this way: there's building on shaky ground and there's building on ground that's designed to disappear as soon as you get something good going.
I'm sorry for iFlow's people but if your business requires to be approved by a potential competitor to exist you are going to be in trouble.
A web company is the most independent company that exists. They are even, in some cases, outside of control of the government (although this is starting to change). And it isn't mind-bendingly hard; a couple of the biggest companies in technology (Google and Facebook) were started by college students in their dorm rooms / garages.
My friend bought a building. 50 apartments. He got investment money from family to put a down payment on the loan. Fix it up. Have tenents pay rent and cover the loans while looking for a seller. Sell it for a proffit.
This was great. Except that he had ABSOLUTELY no risk-mitigation. He could not afford to keep the house on the market for 3 yrs to ensure that no matter what, he does not lose all the invested money.
Guess what? Problems arose trying to sell the house. Took 3 months longer than expected (9mo total vs expected 6). Money ran out. Boom foreclosure. Lost 800k.
The lesson I learned is that take what you are assuming will happen, and make at least SOME risk mitigation. How can you get out? If you can't what will you lose? Etc. Don't make long term risky goals based on hopes that everything will be alright. Assume the worst, can we still come out even if that happens?
Risk and trust are inherent in entrepreneurship. We all count on any number of providers to behave fairly, from technology service providers, to API services, to retailers, distributors, and other partners.
Sure, it's best to have many legs to stand on, but that is simply not the case for most early startups.
I never said if anything was right or wrong, nor did I assume any of it, I just asked if it was related. Good to know curiosity gets flagged around here.
Often when pairing we'd commit with messages like "WIP: 1" "WIP: 2" etc. push pull switch machines (remote pairing) get checkpoints in there. Then before pushing to the main branch we'd roll all that up into one commit with a very helpful message. Boom solves a great workflow problem.
Git gives you granular control of every aspect of itself. When you REALLY need it, it works out. Insane history rewrites make the full team have to propperly sync. Rebase is an amazing tool for getting your repo up-to-date and not making someone else when looking through history have to worry about mix-matching commits to see exactly how one branch turned out. Its personal prefernece. In the end of the day, git will not let you cover your tracks.
Anecdote:
I fucked up some commits. I put in wrong conmiter names and so on, omitted some data in some of my commits. With git I could clone my repo, experiment with rewriting commits to fix conmiter names, and then merge it to everything. Yes history is changed, but end of the day this is not about hiding shit. This is about keeping the repo information useful and simple. If you want to blame shit on people, there are external systems which will ensure that people will get blamed for their own shit. VCS is not for that, VCS is to version your code, be able to un-fuck yourself up, and figure out why someone did something and how they did it exactly at some point in time. Nowhere in the is "blame people for mistakes" seen.
I've seen people not want to get blamed or use VCS. They used a word document to version their source. Yes. And I assure you it took people lots of time to realize wtf is going on.
If anything the lastpass breach gave me MORE confidence in lastpass. For all we know there was no breach. HOWEVER lastpass immedicately communicated to everyone and discovered an issue in a very paranoid way. I think this is security I wish every site had. However I kid myself thinking that is possible, I rather that a single-point-of-failure is lastpass vs a crappy website that exposes a password which compromises tons of accounts and having to change all of them even if I was notified.
Furthermore lastpass supports youbi key so it supports two-factor auth.
Consider this question: Let us say the cost of an infrastructure at google HQ is X. X is the cost regardless of internet. Now let us say you have Y which is the price of an average inernet connection for google offices. Or you pay 4 * Y to get that connection. Ok lets make it 10 * Y. Whatever. The point is that if it makes your workers a bit more productive (5000 people?) lets say 3%. I think that 3% productivity on developers translates to WAY above the price of that connection.
To determine what language to use, ask yourself the following question:
a) How many devs will or you want to support your application.
b) Approximately (ballpark) how many users will be sending simultaneous requests? If there are going to be 20 people logged in total, performance is not an issue.
c) How much time you have.
d) How much hardware will you be using?
e) Do you realize that doing queries from a table of 10 or 1000000 records are equivalent to the application if you return 2 rows to it? The work is in the database and will remain unchanged.
Now, many places chose RoR/PHP (and some good frameworks) as a front-end, while using a "fast" language like java or erlang for the back-end. Facebook is one such example. They use erlang to handle comet requests and php to render the front end, and I think java to do back-end messaging and so on. The front-end code just queries it.
If its a simple data application (show page, get input, query/update db, show page) then RoR is easy to make/maintain. If there are 10,000 users logged in at once, I'd think about this further. If you are a sole maintainer, RoR is nice since it makes writing and maintaining simple granted you know what you are doing.
