フロントエンドを楽にするために
Qiitaを支えたい技術 at 時雨祭
- HN: mizchi
- Qiitaの方からきました(入社半年たったらしい)
- Reactオジサンはそろそろ飽きてきた
- Angularに興味が無いのでこっちにきた
最近書いてないけど Wordpress.com にブログは持っていたり、一応GutHubに自分以外のユーザーもいた事があるソフトを公開している。Twitterのツイートもある。限られた自分の時間で発信していることだし、そろそろ自分ドメインで自分のコンテンツをちゃんと集約化したいなと思いました。
普段サーバー関係の仕事をしているので、Wordpress や他の CMS をいれたりするのは出来ると思いますが、今のところ静的なコンテンツのみの想定だし、CMS だと機能が豪華すぎます。またバックアップやセキュリティ対策などレンタルサーバーであってもちゃんと運用するにはそれなりの手間(コスト)がかかります。ここはコストをかけずにもっとコンテンツだけに集中したいとおもうようになりました。
https://gist.github.com/mala/5062931
の続き。
Twitterの人に色々と問題点は伝えたんだけど、これからOAuthのサーバー書く人や、クライアント書く人が似たような問題を起こさないようにするために、どうすればいいのかについて簡単に書きます。既存の実装真似して作るとうっかりひどい目にあう。
自分は意図的に「Twitterの脆弱性」という表現を使わないように気を使っていて、それはクライアントアプリ側の責任もあるからなのだけれども、安全に実装するための方法がわかりにくかったり誤解を招きやすかったり、Twitterに買収されているTweetDeckにも問題があったりしたので、それはやっぱりTwitter側の責任の比重が大きいとは思う。とはいっても別に責任を追求したかったり◯◯はクソだといったことを言いたいわけではなく、誰が悪いとか言う以前に、複合的な要因によって問題が起きるときには原因を正しく理解する必要があると思う。
原文:Scaling Isomorphic Javascript Code (This is just for study, please contact me at tily05 atmark gmail.com if any problem.)
考えてみれば Model-View-Controller とか MVC ってよく聞くよね。実際どんなものか知ってる? 抽象的に言うなら「オブジェクト情報の保持されるグラフィック・システム (つまり、ラスターではないグラフィック。ゲームとか) 上に構築された、表示系を中心としたアプリケーションにおいて、主要な機能どうしの関わりをうまく分離すること」とでも言おうか。もう少し深く考えを押し進めてみれば、これは当然、他のさまざまなアプリケーションにもあてはまる言葉 (bucket term ?) だ。
過去に多くの開発コミュニティが MVC による解決案を提供し、それによってよくあるユースケースにうまく対処し、地位を築くことができた。例をあげるなら、Ruby や Python コミュニティは Rails や Django を作り、MVC アーキテクチャを実現した。