jsankey

Exactly. The entire post is cherry-picking and proves nothing.

Absolutely, this is why popularity of the project matters, as it means it is more likely to be tested and actively maintained. And as a good citizen you should participate!

Also: if you find you need to write this non-core functionality in-house you could consider open sourcing it yourself. If you're right that this is a need not filled by existing libraries you might just find a community grows around your version to help you maintain it.

There's a lot of truth in this post but this line of thinking also plays into our own prejudices. I do often look at third party code and think it's pretty crappy, but then I need to remind myself that my own code is far from perfect!

More importantly, though, we tend to underestimate both how long it will take to implement something ourselves and especially how much it costs to maintain over time. If you can use third party code from a popular and active project you get a huge amount of testing, bug fixing and other maintenance from the community over time. If you implement in house then you've just given yourself an extra burden for the life of your project.

Obviously moving can be a big deal, but IMO you should seriously consider it. You have a problem with available time, and commuting by car is a massive time sink. It's pretty insane how much "human capacity" is wasted this way!

Good issue tracking tools can produce changelogs for you, which is preferable to maintaining a redundant, separate log manually. It also encourages good practices like tracking all user-visible changes and keeping issue summaries accurate and readable.

You're right that you'll (practically) always have more than one feature in a product, so counting features doesn't really make sense. You should approach it from the other end: identify a segment of the market, a narrow set of customers, and aim to build a product that is clearly the best option available for them. Judge every feature through this lens, and don't stray outside the focus until you've won that niche (if ever).

Easier said than done, of course...

No problem John, I'm not (yet, at least) a user of your app I'm just a fellow indie that wanted to illustrate the reality of doing business at just $30/copy. Prices are low enough to make most indie development uneconomical in pure dollar terms. Though I wholeheartedly agree that money is not the only motivation, customers need to realise that developers need to make a decent living in order for there to be a vibrant ecosystem of apps.

As an indie who has made the mistake of both pricing too low and spending too much time on development (vs marketing) in the past, it looks like you've done very well to avoid these pitfalls so far!

$30 is most certainly not "a lot of money", and it is this attitude that makes indie development so hard these days. This app is meant for serious bloggers (i.e. those that spend many hours writing each week), so if it works for them $30 is a steal.

Remember that out of the $30 John gets just $20 from Apple, and if you take another third out for other expenses you're looking at less than $14. Needless to say you need to sell a lot of copies at that price to break even on your development time, on the order of 10,000/year, which is more than 27 copies/day! Then take into account that the App Store makes it difficult to get repeat revenue out of customers even if they use your app for several years...

Although I agree that our own bodies tend to be pretty awesome and require less help than many people think, your argument in this case is a little shaky. We live in a very different environment to our ancestors and expose our skin to all sorts of things that they never could have. Even ignoring all the new compounds we interact with daily, just moving ourselves around the planet (to areas with different sun exposure, as a key example) can have a big impact on our health.

Yes, the problem is man made, but not only due to unofficial access to antibiotics. I suspect that's not even a major factor, but correct me if I've missed something.

As discussed: TB currently takes a long time to fully treat. A lot of patients can't afford a full course of the recommended combination of drugs. Even if they can, and are getting their drugs from official channels, they need to be monitored regularly (sometimes daily) to ensure proper treatment. The resources to do this monitoring simply don't exist in India (and many other countries). Thus, even if you could stop all unofficial access to antibiotics (impossible in practice), there is simply not enough funding to ensure every patient is properly treated.

This is why a shorter regimen is a key breakthrough. It makes proper treatment much more accessible (the big issue), while also reducing the discipline needed to complete a course (a small bonus).

Agreed. Living in the age of antibiotics we (in the developed world) have quickly forgotten how deadly TB is (it was a leading cause of death just 100 years ago). Given the difficulty in developing new antibiotics (and relative lack of commercial incentive to do so) the news that they've found a more effective new drug combination (including new drugs) is very welcome.

The fact that the regimen is shorter will hopefully mean higher completion rates: a big issue at the moment as the treatment can take up to 2 years leading many patients to take incomplete courses (and of course this fuels drug resistance). In Australia we're lucky enough to have the resources to provide free treatment with mandatory monitoring by health care workers (to enforce the full course is taken), but in India, PNG etc they desperately need a cheaper and more practical solution.

Edit to add: hopefully new drugs will also help those with sensitivity to the current antibiotics. They have some pretty harsh side effects, e.g. drug-induced hepatitis is a common problem which means many patients can't tolerate the preferred regimen.

Most programmers are barely capable Stack Overflow copy'n'paste merchants.

Programmers value the hacky over the elegant, and work hard to tight release cycles.

And yet there are programmers who care, and who seek out and use better ways of doing things, including the tools to help them. Just as there are journalists who care about getting things right, digging up and exposing the truth.

In fact, a great way to lift the general standard is to make the right way of doing something also the easy way of doing it: better tools can counteract short deadlines and occasional lapses of discipline.

This is a subjective issue, of course. Personally I find autocomplete and navigation in Xcode still sorely lacking compared to IDEs in the Intellij family, to the point where I happily pay for AppCode to do most of my iOS work (basically any serious coding, although I return to Xcode for UI work). I will concede the AppCode can be sluggish at times, though, which is my major gripe. Conversely I find Xcode more buggy: every other version seems to be plagued with crashing bugs.

As for the idea that Google should start from scratch: that would just put them back a decade. I'm very glad they decided to build on an existing great platform instead.

I should have been more clear: I agree with you on this and think C should be one of the batch of first languages students are exposed to (as the best choice in its class at the moment). The OP seems far too biased towards C, though.

What worked for me was early exposure each of: a specific teaching language (somewhat like Eiffel, within a simplified environment), C/C++ and Scheme. They each taught me very different things and I'm glad they were all offered in my undergrad, although I think they should offer Scheme earlier (IIRC it was part of an optional third year course, which also touched on e.g. Prolog).

It helps a lot to be exposed to a variety of approaches, exactly as you say, and to be exposed early while you're still forming ideas about how things work.

Simply saying C is the "best" way also misses that point that different people are motivated to learn in different ways. For many, ramping up quickly in Python and plugging something into a Twitter library would show them that they can actually do something interesting right now, which is enough to keep them coming back for more. Others are driven by understanding how things work, and would be happy to crack open a core dump to figure out what happened.

Yes, this was very jarring, leaving exactly the opposite impression the author was aiming for at that point! My memory of learning to drive a manual was also not nearly as fraught as the author describes, and I don't claim any particular driving prowess (this could be a function of the car, though, I learned on one that I suspect was more forgiving).

It's not clear that running makes joint problems any more likely, in general, see:

http://www.npr.org/2011/03/28/134861448/put-those-shoes-on-r...

For example, keeping joints active with weight bearing exercise reduces the likelihood of developing arthritis. As other comments have mentioned, a common problem is overtraining, and especially starting out too fast. Patience is required to build up the strength and technique required to maximise benefits while minimising the risk of injury.

I would be more careful trusting The Australian on anything to do with smoking (and a few other issues) given their writers' links to the tobacco-funded IPA. Media Watch put it a lot better than I could, with sources:

http://www.abc.net.au/mediawatch/transcripts/s4026465.htm

Absolutely, the forums are very useful particularly at beta time. But they aren't the best or only way to share information. I think Apple could still open up things a bit more here to help developers without harming themselves. There are no real secrets once millions of developers have the betas anyway.

I'd love to see them open up more around bug reports too, there's a lot of mystery and guesswork due to the closed nature of Radar. (Not to mention all the duplicated effort in Open Radar that tries to compensate.)

This is compounded by the fact that you can't publicly discuss issues with prerelease versions of iOS/Xcode (although they seem to be relaxing this as of iOS 8, there are still restrictions). This prevents excellent blog posts like this from helping a wide audience of developers when they need it most (trying to update their app in time for release).

Just a heads-up: the font-weight of your lead paragraph makes it too light on Chrome+Windows, some of the diagonals pretty much disappear.

Excellent question and this is on our roadmap (yes, I know, vapourware until we ship it). The plan is to export as HTML with standard microdata annotations (the same we use to automatically import). That should be fairly durable, as far as formats go, and even if the HTML dies at least it is structured (for conversion to a new format) and text-based (at worst you can still read the source).

> as my bookmark folders for recipes (RIP BroEats.com) and designs and other things is filled with more and more duds

If you'll forgive me the self-promoting diversion, this is one of the reasons I created my recipe manager app Zest (http://plentyofzest.com/zestapp/). It's frustrating to have a recipe move/disappear, so now I can collect them all in one place.

If you've accidentally published a key, your only safe option is to change that key. Abolishing it from history is closing the gate after the proverbial horse is well into the distance.

It's nice that the dollar figures are all upfront on this page, but it seems a bit strange to say "Get a working, launchable prototype for $3,500" when the client actually pays $3570. It seems that you're putting half of your fee on the client side and the other half on the programmer side, but in doing so the client's seeing a mixed message that could be off putting.

I'm excited to see the integrated UI designer - it's frustrating having to switch back to Xcode when working on the UI. So much so that for short periods I even try switching back to editing code in Xcode too ... but I always come back to AppCode eventually.

Actually, our taxes are not high compared to other OECD countries (only Mexico and Chile have significantly lower tax/GDP ratios):

http://www.treasury.gov.au/Policy-Topics/Taxation/Pocket-Gui...

I actually prefer Android as a user. But if I'm building native (instead of HTML5), it's because I want a polished UI, and that is easier to deliver on iOS where there are only a handful of devices to test against (in particular screen resolutions). Assuming the app goes well on iOS then I'd happily take on the extra effort of an Android version.

This and the linked guides claim there is no advantage to using instance variables (preferring properties), but I see at least one advantage: simplicity. When you're reading code that uses an instance variable you know exactly what it's doing, you don't have to check the attributes of the property, or the getter/setter implementation, or think about any KVO going on.

I'm not saying this makes instance variables preferable, but there is something to be said for minimising the number of places you need to look when trying to understand a snippet of implementation.

I tried to track the history of CI once[1] -- a similar practice may date back as far as the 60s at IBM. There are multiple sources indicating daily builds with tests at Microsoft from at least the early 90s (not quite CI but at the scale of the projects probably as close as practical at the time). Long before Agile became trendy in the 00's.

[1]: http://www.alittlemadness.com/2009/01/09/continuous-integrat...