[ryandaigle]

When we look out at the world today we have trouble finding a trusted source for high-level technical content regarding application development. Miyagi is our experiment to address that need.

While initially seeded with content from within Heroku the intent is to publish and promote good ideas independent of their origin. I'd be interested in hearing 1) if you feel, as we do, of the need for such a site and 2) general interest in contributing to or reading such content.

[dizzystar]

This is all too advanced for me, but I think it is a good idea. I only wish the articles were a tad longer. The SQL article looks really good, but the Tests article stops far short from its title and seems more preachy than useful.

I think the challenge of writing any good coding resource is balancing philosophy with content. Most books and articles swing far into philosophy with little assertion to back it up, usually at the cost of content. The authors always forget that the reason I bought the book or opened the article is because I am, 99% of the time, already sold on the philosophy, idea, programming language, [flavor]. The Tests article offers little substantial content and doesn't bother to offer up any specific examples. Yes, there is a mention of RoR and its ORM, but then it concludes: "Well designed code will never substitute testing, but does give you the reassurance that no code coverage can match." In regards to this, I think Rich Hickey said it best: "gem install hairball."

[ryandaigle]

Thank you for this feedback. You're validating the general direction we were hoping to pursue. Expect to see more high level content always paired with meaningful examples and real world application.

[yajoe]

I appreciate the effort. I think you would do well to work down Joel's reading list.

http://www.joelonsoftware.com/navlinks/fog0000000262.html

I'd like you to think about the TDD article harder -- testing isn't easy, and asserts aren't substitutes for good tests. Just because an ORM solves SQL injection doesn't mean it has protected you against bad data. And how do you have confidence that pending changes don't regress prod? Asserts are great for bailing at runtime (which nobody actually wants in practice), but they haven't yet found use at predicting which builds will fail. For that you need sample inputs, and these sample inputs are the basis of every test :)

Also, coordinating multiple processes/threads/drones/ect is easy when the mutex is reliable and transactionally safe. Often neither is true, especially for systems that scale to tens of millions of users and have their data partitioned or in volatile containers. What patterns should developers consider?