t-wadaのブックマーク / 2013年10月8日

t-wada id:t-wada

2013年10月8日のブックマーク (7件)

Node.jsをサーバサイドのUIレイヤに限定するのか？ - ワザノバ | wazanova.jp
http://www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-front-end/ Nicholas ZakasはYahoo出身で現在Boxに勤めるフロントエンジニアで、JavaScriptに関する複数のオライリー本の著者でもあります。彼が自身のブログで、Node.jsをサーバサイドUIレイヤのみで活用することを提言してます。 JavaScript エンジニアはフロントエンドのコントロールはできるが、サーバサイドのUIレイヤはバックエンドエンジニアの領域で、それがフロント（JavaScript）エンジニアとバックエンドエンジニア双方のストレスであった。（参照図１） Node.jsの登場で、サーバサイドのUIレイヤをサーバサイドのビジネスロジックから分離し、フロントエンジニアはブラウザ & サーバのUIレイヤ、バックエンドエン
t-wada 2013/10/08
Node.js を "サーバサイドの UI レイヤ" にするという Nicholas Zakas のエントリに対する賛成/反対コメントの抄訳

node.js

architecture
リンク
Node.js and the new web front-end - Human Who Codes
Posted at October 7, 2013 by Nicholas C. Zakas Tags: Architecture, JavaScript, Node.js, Web Server Front-end engineers have a rather long and complicated history in software engineering. For the longest time, that stuff you sent to the browser was “easy enough” that anyone could do it and there was no real need for specialization. Many claimed that so-called web developers were nothing more than g
t-wada 2013/10/08
Node.js を"サーバサイドの UI レイヤ"として導入し、バックエンドシステムは(既存の言語で)ビジネスロジックを提供する RESTful なサービスとして分業させていくアーキテクチャについて

node.js

architecture
リンク
Disqus のスケール - Django で月間80億PVを処理する
私が把握してる限り Django で一番大きなサービス Disqus のスケール (執筆時点ではサービスダウンしてる)。元ネタは Scaling Django to 8 Billion Page Views です。月間80億PV、45k req/s のほぼすべてのトラフィックを Django で処理しているとのこと。抄訳になるかな。 WAF は高速開発とパフォーマンス、新しい人が入ってすぐに開発に参加できることとカスタマイズ等のトレードオフがあります。この記事ではそのトレードオフである高速開発とパフォーマンスをどう両立させるか、Disqus のノウハウが紹介されています。 >>> なぜ WAF (Web Application Framework) は遅いのか最初に思い浮かぶのは、アプリケーションに必要ではないボイラープレート (django.contrib とか?) や不要なコードがあ
t-wada 2013/10/08
Surgoさんの「○○のスケール」シリーズ、今回はDisqusについて。Varnishの使いこなしが印象的。"実は言語やWAFは遅さにあまり関係なく、ネットワーク内の他のサービスとの通信のオーバーヘッドが原因"

architecture

web

python
リンク
makopi23のブログ豆ナイト Presents 「DAD はアジャイル開発の決定打となるのか？」に参加しました
2013/9/30(月) 豆ナイト Presents 「DAD はアジャイル開発の決定打となるのか？」に参加してきました。こくちーず http://kokucheese.com/event/index/109869/ 以下の書籍をターゲットとした勉強会なのです。 DAD本に関するセッションを聴講するのは、これが３回目です。初回はDevsumiで江木さん、次はDevloveで岡さんと藤井さん、そして今回の中佐藤さん。ウチの会社も某・巨大SIerで、アジャイルを推進する立場にある私にとってDADの考え方には大変興味があります。あと、DevloveのDAD本読書会にも参加してますが、この日も読書会の方が数名参加されてました。顔見知りもチラホラと。こーゆうイベントや勉強会でDADがもっと広がるといいですね～というわけで、当日メモした内容を復習用にダラダラと書き起こしてみる。↓ ■あし
t-wada 2013/10/08
書籍『ディシプリンド・アジャイル・デリバリー』イベントの詳細なまとめ "（自称）アジャイラー（アジャイリスト）へ" "アジャイル（実質）否定派へ" "エンタープライズアジャイル ≠ 大規模開発" 面白い

agile

book

opinion
リンク
Who's using Groovy in production?
Answer (1 of 5): Tons of companies are using Groovy in a way or another in production. There are different use cases for applying Groovy in a given project. One might want to use it as an embedded business language (a Domain-Specific Language), and I've seen companies using Groovy for its nice ...
t-wada 2013/10/08
Quora に投稿された "Groovy って production で使われてるの?" という質問に対して Guillaume Laforge 本人が回答している。いろいろな企業で使われている。

groovy
リンク
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。
t-wada 2013/10/08
TDD を導入する際に立ちはだかった現実、躓きやすさや燃え尽きをどう乗り越えたか。すばらしい資料。 "レガシーコード山脈" "生産性の谷" "自己満足の砦"

TDD

testing

opinion
リンク
いまだにユニットテストって受け入れられないんだろうな - 個人的なまとめ
色んな所で「テスト(ここではユニットテスト)を書かないのは小学生までだよねー」とか、もっと汚い言葉で言われたりするけど、いまだにうちのチームでは自分だけしか書かない現状が悩ましい。 Jenkinsさんが激おこになっても誰も何も反応しない。もちろん、全部が書けるとも思ってないので、自分が不安なところとか、変更が多く入りそうなところとかを中心に書くようにしてる。一種の精神安定剤みたいなもん。あるとき、一緒に働いてるエンジニアさん(ここではAさんとしておこう)に「ここ難しそうだから、テスト書いたほうがいいですよ」って話をしたら、「じゃぁ、工数かかっちゃいますね」って言われて結局書いてなかったな。そうだよ。ユニットテスト書いたら工数かかるよ。それは純然たる事実。でも、再利用できないチェックシートを作ってやるよりもいいと思うんだけどね。しかもこの前に見せてもらったこのチェックシートも運用レベル
t-wada 2013/10/08
ユニットテストを書く文化のある組織と無い組織ははっきり分かれている。こうやって孤独に戦っている人を支援するにはどうすれば良いのだろう。導入が上手くいった事例の Wiki でもあれば良いだろうか。

testing

opinion
リンク
- 2013年10月10日
- 2013年10月8日
- 2013年10月7日