My biggest hesitation is how to deal with user contributions to source code - ideally I wouldn’t like to separate underlying code sets, but some contrubitors may feel being taken advantage of. The GUI front end would be available either from Mac App Store or as direct download. Hopefully the app will take some of the burden of answering these questions or at least provide some revenue for the time invested into them. So one of the ideas that’s been with me for a while is to develop a GUI front end that will simplify installation and subsequent project management. I also get many support questions which seem to indicate many newcomers to iOS/OS X platform want to use the tool, but are not familiar with UNIX command line and hence have hard time installing it.
#STARTUPIZER DELAY INSTALL#
Appledoc Google Groups forum is getting more users and contributions too, which is wonderful!īased on user feedback, I noticed many developers prefer to install appledoc through one of the installers - either install script included with repo (which, by the way, seems to be having some issues on Mountain Lion) or Homebrew. Of course I also provide support to existing version as much as possible. It doesn’t do anything useful yet, but you can follow along. While it’s been more or less stagnant during the past few weeks, it’s available on experimental branch on GitHub. Whenever I get some time for appledoc, I focus on next major release - 3.0. If you need his services, find him at his website (he’s also offering various consultant services, take a look at his consultant page). While I can’t speak of translation accuracy (am not speaking German myself :), I find him quick, responsive and professional.
#STARTUPIZER DELAY UPDATE#
I’m currently working on 2.1 update which will address some of the bugs and bring German localization - contribution of Sebastian Tischer.
I find it reasonable compromise between user satisfaction and time invested. Then listen for feedback and implement features most users request. That’s how I did with Startupizer too: rather implement less features up front and release early. You can frequently hear about 80/20 solution: implement features that will cover 80% of users needs. Something we as developers tend to forget when thinking of various “cool” features our apps may have. When developing, one must always be concious not to implement too many details that will unnecessarily prolong development time and bloat the product while only serve a fraction of users. Interestingly, very few feature requests were sent in, my guess is the app satisfies the needs of most users. Stability was in fact one of the focuses when developing it, so I’m happy to see it working that way. Startupizer 2 proved as very stable - some users reported crashes, but most of those were one-shot and didn’t repeat. I also do a bit of work and I’ll outline it below:
It’s full summer here, so I spend my time with family and friends, relaxing and preparing for the upcoming months.
0 kommentar(er)
