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.
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."
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.
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?
I was hoping people would just get that hitting enter in an input field submits the subscribe form. I'll need to make that more explicit, thanks.
Regarding submission of articles, I'd like to work with authors earlier in the writing process rather than just receive a bunch if completed work that may not be right for the site. However, even that should more transparent, I agree.
Best you can do: don't use Archer, use either something from Google or from Typekit.
Typekit uses many layers of protection, and implementing them would be difficult and not worth the time.
Second best thing: at least Base-64 encode the font, and limit woff usage to your ___domain only. Still trivial to hack, and doesn't really count as good protection, but better than what it is now. And you would still be violating ToS.
I enjoyed the article on process partitioning, however the article advocating assertions in place of tests is very immature. It needs at least some explanation of how you might implement the advice, and how asserts would actually provide equivalent protection. I was very surprised when it ended, it feels incomplete.
You may have misunderstood his point or maybe I am. The way I understood, it is not about assertions such as
i = min < max ? min : max
but rather about the architecture of the software. The software should come built-in with the features that by default prevent bad software designs.
His argument is not to abolish tests and use asserts, but rather to define a set of cases for which you would not need to test because the framework, by its nature, makes it unnecessary.
His example was SQL injection. (a) If I were to write my own MySql queries which directly talk with the DB, then I would need to write tests around those query to make sure it is not possible to execute SQL injection. (b) If I am using an ORM that comes with feature so I don't write the sql queries, it creates it on its own and also comes with the feature to handles possible use-cases which would normally lead to SQl injection, in such case, there is no need to write the test.
The site looks cool and interesting posts = but are you looking for technical detail analysis or stuff on trends to consider when building systems? (Example of the later because we just wrote it: http://www.3scale.net/2012/12/the-death-of-the-web-page/)
I don't want to be too narrow in these early days so I'll say we want content that will aid developers in discovering new development techniques as well as reinforcing the practice of ones they may already be aware of. I think both types of content you mention can aid in that.
Just read your post, njyx. While it's solid and thorough, my first impression is that it's a bit too high-level for an audience of application developers.
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.