All my work is via Git. So in my team we use GitHub for our normal projects (pay per project), and when we're done, I put it onto BitBucket (pay per user), so whatever I put onto BitBucket is then free of charge. I think I'll stick to this solution as it's cheap (read: free).
However, if I was to use your service, I'd be happy to use command line.
Shows how I shouldn't just depend on google to solve my problems for me. I searched for something like "turn off preview" but I never made the connection that it was called minimap. It's only slightly annoying. Thanks!
Hmm, I think a lot of people are missing the whole point in this article. I do around 60% Ruby on Rails, 35% iOS and 5% Android dev. The idea around a "lean" startup being, that an MVP, or each new feature, or even testing a change to a previous feature is usually done in quick succession. This being testing with current users over a period of say, a week, and then from the results, changes can be made and the team have learned from the testing.
So really, Android allows for this quick succession of testing features and iterating as quick as possible, with even to a few hours turnaround. Also, that it would cost a lot in development time to get something "just right" for the App Store for it to be accepted, whereas with Android you can keep on iterating and pushing changes without having to spent a huge amount of time making everything look perfect, and be absolute minimal in terms of bugs.
I love iOS development, and yes, I agree with most people on here about the revenue from iOS, the people paying for apps, Apple's process of helping keep out most malware etc. etc., but for the sake of a "lean" startup, spending extra weeks testing apps making sure it's completely bug free and "looking good enough" for iOS, as well as the wait for Apple to accept the application (and then for users to download the update, in the case of iOS 7, this has been solved), Android is a much better dev option for these changes.
Of course, when the team knows that the app is something that people care for, and they have a decent knowledge of what users want, what features they use, and the kind of value that the mobile app brings to them, then they can go ahead and make the best possible iOS app.
TL;DR
Saving time, money and quick iterations, learning from customers and getting quick data for problem validation, is much easier and faster on Android, than the process on iOS. Think Lean Startup.
As a mobile app user, I don't want daily updates from your app as you "iterate" away and try to figure out what to build. I want to download the finished product that works.
I'm not your free beta testing service. If you want to test concepts, do proper market research.
Well then you wouldn't be the early adopter :) The idea is to test it against early adopters who don't mind about these quick changes and are less worried about bugs, because the idea/product is something that's good enough to help you in some way, shape or form.
May I ask, what's proper market research? Considering you can get so far with "proper market research", but it definitely doesn't tell the whole picture. People often don't know they have a problem until one is solved and a good way.
I should have said, "traditional market research" instead, including trend and competitive analysis, segmentation, primary research such as focus groups and surveys, prototyping in front of a representative sample of users, etc.
An iterative approach is fine, once the above basics have been done, but if you need to deploy code changes in an app every day or even every week, the product is probably not ready for V1 yet.
Well of course all that is done before all of the developing of the app. The idea is to reduce the amount of uncertainty by not creating a full blown app that has had a lot of time and money put into it, when some of the features aren't helping in terms of getting new customers, keeping old customers and bringing any value to the product/service.
Isn't beta testing a problem more suitable for a third party service (https://testflightapp.com/)? Using app store to distribute beta quality product is a subpar solution IMHO.
Yes, TestFlight is absolutely great for beta testing.
However, in the startup sense, it's not exactly beta testing, it's testing the market, so beta testing would be fine to test something you've built works, but by no means will show what people will think of the app/product.
> Also, that it would cost a lot in development time to get something "just right" for the App Store for it to be accepted, whereas with Android you can keep on iterating and pushing changes without having to spent a huge amount of time making everything look perfect, and be absolute minimal in terms of bugs.
This is highly misleading. The App Store review process does delay iteration, and heavily crash apps are rejected but there is no requirement to spend a huge amount of time making things look perfect or absolutely minimal in terms of bugs.
Almost certainly. And that's another reason I can't stand it, its a my way or the highway culture rather than there's more than one way to do it culture (my mistake for hanging with the wrong crowd), and its marketed as a tool for noobs to quickly ramp up a simple CRUD plus a bit more.
Its marketing doesn't match its design. Its a tool for experienced experts to work slightly faster using the One-True-Workflow which they already know. On the other hand, most books, online tutorials, etc, show it as a noobs playground. Its like taking the kids to a neighborhood park that turns out to resemble an Indiana Jones movie set.
I had zero ruby experience when I started fooling with RoR in 05, 06. All rails did was get in the way of developing those language skills. Training wheels on a Harley Davidson, something like that.
Write once, upgrade never because it'll stop working and as a noob shielded from the cold hard world by the framework, you won't have the experience to be able to figure out why. What a pain. The whole experience, just suffering.
Off the top of my head, around 05/06 going in as a complete ruby and rails noob, there was no noob-obvious handholding way to handle many-many CRUD. Things have in fact probably improved quite a bit since then. The problem is with a one-true-path culture, everything has to be rewritten to fit the enforced style of the day. And frankly for some meaningless intranet "CRUD plus a little more" app thats now become somewhat biz critical, I don't want a life of permanent rewriting.
Ah, whatever, just ignore my ranting. My experience has been horrific and it'll color my judgment. I'm sure for everyone else its all candy corn and unicorns and balloons all day long, and will continue to be so. I'll just use something else.
I think Rails is wonderful, but it's not for me. It's explicitly designed to shut down many design decisions because they were made a priori by DHH. Don't want to co-mingle persistence and domain modeling? Too bad! Tie yourself to the ship and get on with it!
I realized the other day that Rails is designed for Internet time: ship as fast as possible, see if it sticks. If it does, then needing to re-write every few years is assumed to be no big deal, as, presumably, it is succeeding.
I view rewrites as a fundamental failure of design. I should be able to evolve the domain model independently of the UI. Only when there are massive, breaking changes in the scope of the application ("we're going to sell video games instead of show classifieds!") is a rewrite truly necessary.
But, IMO, industry hates design because it alludes to the fact that programmers are not easily replaceable. So, it pushes a new framework or language every 2 years to keep people hopping around, solving the same problem over and over. Meanwhile, it fails to train those people in the (mostly timeless) ways of solving problems reliably. And devs lap it up, secretly hoping it will fix all those icky maintenance problems they're starting to run into.
I've had a number of attempts at adding a "Buy it now" and some scammer from Nigeria (every time) ends up "buying it" and sending phishing emails. Only to have to wait again to put it up for sale after a few days.
