Show HN: Miyagi - A Journal of Application Development(miyagi.herokuapp.com)
miyagi.herokuapp.com
Show HN: Miyagi - A Journal of Application Development
http://miyagi.herokuapp.com/
6 comments
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."
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 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?
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?
Nice easter egg in the footer - clicking the sun/moon icons toggles between a dark and light color scheme.
You seem to be missing a subscribe button for the email form in the top-right corner.
Additionally, it would be nice to have a page about how to submit articles and whatnot.
You seem to be missing a subscribe button for the email form in the top-right corner.
Additionally, it would be nice to have a page about how to submit articles and whatnot.
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.
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.
Are you guys part of H&FJ's secret web font beta, or are you using Archer on the web in violation of your license agreement with them?
(Serious question. I want to know if they're accepting applications. Still eager to get Gotham on my site.)
(Serious question. I want to know if they're accepting applications. Still eager to get Gotham on my site.)
Looks like a violation, because .woff is hosted on their site and unprotected.
Addressed: https://github.com/rwdaigle/adj/pull/5
Thanks for raising the issue.
Thanks for raising the issue.
We're looking into this immediately. Thank you for raising the issue.
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.
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.
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.
Thanks for the feedback, Jesse. We're experimenting with various types of content and hear you on the general direction.
This looks like some interesting stuff. I'd love an an RSS feed to stay up to date.
Atom feed added at: http://miyagi.herokuapp.com/articles.atom
Thanks for letting the need for a feed be known!
Thanks for letting the need for a feed be known!
Agreed. I will forget the URL almost immediately. But if I can add it to my Google Reader list then, well, you will remind me yourself.
Is Twitter of any use to you both for that purpose? @MiyagiJournal
Not the parents, but RSS feeds are awesome. Twitter is ephemeral, but a feed can be batched and consumed at any time.
Looks like you're using Rails. Something like http://railscasts.com/episodes/87-generating-rss-feeds-revis... should be fairly straightforward.
Looks like you're using Rails. Something like http://railscasts.com/episodes/87-generating-rss-feeds-revis... should be fairly straightforward.
Yep, implementation is a no brainer, was just curious about the viability of RSS as medium. It appears it is not dead!
This exactly, I don't really have a way to save tweets with interesting content for later consumption, RSS does that for me by default.
If Twitter could be used that way, it isn't in this case. @MiyagiJournal hasn't posted anything about the latest two articles...
I also add my voice for an RSS feed.
If the app was OSS, I'd happy send a pull request.
I also add my voice for an RSS feed.
If the app was OSS, I'd happy send a pull request.
http://github.com/rwdaigle/adj - but beware that the stack may be highly volatile at this stage.
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/)
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.
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.
I'll def read your post and follow up.
I'll def read your post and follow up.
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.