IIW #16 レポート

1. 会場はComputer Musiam
   1. 博物館なので廊下が広くそのままカンファレンスに
   2. 外でやったら雑音がすごい
2. 誰もノートを取っていないセッションもある
3. 「Mobile SSO Enterprize」
   1. モバイルデバイスのシングルサインオンをエンタープライズ
4. 「Mobile SSO Devide To Browser」
   1. 同じデバイスのブラウザ・アプリ感の認証
5. 「GoogleのAuthの歴史」
   1. 悪用自体は減らせた
   2. ユーザービリティはいまいち
   3. アカウント同士の連携はどうすべきか？
   4. 今後
      1. webでも一度ログインしたらずっとログインしっぱなしにしたい
         1. OS自体にアカウントマネージャーを入れたい
      2. Bearer Tokenを減らしたい
      3. Cookie ID(よりセキュアな自己書名の仕組み)
      4. 怪しいログインを検知してユーザーに知らせる
   5. キーチェーンデバイスの仕組みを標準化(FIDO)
      1. 元々PayPalがはじめたもの。内部では色々対立があるらしい
6. 「OAuth & Jose BlueButton」
   1. OAuth 2.0 Client Dinamic Registrationのユースケース
   2. Bluebutton(医療情報の標準化・オープンアクセス)
   3. 定期送信の為の規格もある

IIWについて

1. 色々なセッションがあるよ！
2. ゆるいセッションもあるよ
   1. パーソナルクラウドが一応今回のテーマ
      1. 色々なプライベート情報をクラウド上のプライベートエリアに集めて管理する(?)

idカンファレンス16に参加してきました

1. もふったー
   1. レガシーwindows対応twitterクライアント
   2. Consumer Secretはパスワードのようなもの
   3. Twitterのドキュメントでは「要難読化」と書いている
      1. でも公式アプリでは生。メモ帳でのぞくだけで見れる
2. もふったーの難読化
   1. 最初は単純なハッシュ化→メモリダンプ
3. 次はトークンをサルトとして暗号化
   1. 最初のtwitter認証時はトークンないのでハッシュ関数にフックかけられるとむき出し
4. 最初の文字列は固定。難読化関数をパッケージ化
5. もふったー自体はリバースエンジニアリング対策していない
   1. windowのプロセスを監視
   2. チェックサムでブレークポイントでチェックサムが変化するのを利用
6. 難読化はどこまでやればいいのか？
   1. 有名なアプリはやった方がいいんじゃないかな？
   2. サーバーでの対策は？
      1. 1.0では難しい？
      2. twitterは2.0の対応が遅い

IIWでセッション立てたよ(技術者じゃないけど)

1. Internet Identity Workshop(IIW)
   1. アンカンファレンス形式
      1. 「分野の変化が早く、あらかじめニーズはわからない」
2. まずは各テーブルに分かれて座って「お題」にたいしてディスカッション
   1. 結構長い間議論する
3. 全員が輪になって座って報告しあう
4. セッションは色々
   1. にぎやかなもの、こじんまりしたものなど
   2. セッション例
      1. 匿名性について
         1. 匿名性の定義の合意に至れなかった
   3. 公開範囲について(?)のセッション
      1. 「すべて実名は危険すぎる」
      2. Facebookはクローズド
      3. LinkedINはオープン
5. 夕食で盛り上がってセッションを立てることに
6. セッションの立てかた
   1. 1セッション50分
   2. 時間と部屋を速いもの順に取っていく
   3. 一人をNote Taker(ログ取り人)を指定
7. 「実名って何」
   1. 盛り上がりすぎて誰もノート取ってなかった
      1. 何度も実名が変わった男性が最初に口火を切った
   2. 実名は変更できるか?
      1. 可能
      2. 欧米は言いかえなどもあり、日本よりずっと複雑
      3. 同一人物であると担保することが必要になることもある
   3. 個人の識別と特定に必要な情報は何か?
      1. 名前の空間の大きさによっても異なるのでは？
   4. 信頼性の担保ならば、国に登録している名前でなくてもいいのでは？
8. 振り返り
   1. やってみると得るものは多い
   2. 技術者じゃないけど、得るものは多かった

東京Node学園8に参加してきました

「パフォーマンスチューニングを行うことができるparamtuner」@muddydixon

1. 自動的にパフォーマンスチューニングしてくれるツール
2. Node.js製で。モジュールとしても利用可能
3. Strategyでパラメーター空間の探索アルゴリズムを変更可能
4. データをストリームで受けてリアルタイムで統計処理できるモジュール
5. 時系列データの欠損を補完してくれるツールも作っています

「NodeとPromiseと時々関数型」 @okapis

1. Javascriptコミュニティに道場破りに来ました
2. Scalaの非同期RPCライブラリ「Finagle」の基本はfuture/promise
3. 「Node.jsはコールバックではなくpromissを採用すべきだった」というブログが公開される
   1. コールバックは処理をモジュール化するのが難しい
   2. 逐次処理か非同期処理の区別が必要
   3. ネスト地獄は本質ではない
4. 正しく動くコードを書くのが大変
5. メンテナンス性が低い
6. プロミス
   1. 完了していないかもしれない計算の入った箱
   2. 計算が完了すると特定の処理をしてくれる場合が多い
7. 言語やライブラリによって機能や実装、名前も異なる
8. 「とりあえず関数型プログラミングと融合したケースを扱います」
   1. 手続き型はhow、関数型はwhat
   2. 値同士の関係を表現するのに関数を使う
9. プロミスで記述することで、処理の順番はコンピュータに考えてもらうことができ、非常にシンプルになる
10. プロミスは難しい?
    1. 動作を調べる必要があるのでは？
       1. シンプルである方が大事
11. まとめ
    1. コールバックは簡単
    2. だけど拡張性に乏しい
12. 関数型はプログラマの芸風を広げてくれる
13. 会場から
    1. 元々Node.jsはプロミスを採用していた
    2. javascriptの書き方として嫌悪されていた
       1. エラー処理のために、結局コールバックが必要
       2. エラーコールバックの数が現実のアプリケーションでは増えて汚くなる
       3. 結局、コールバックの第一引数にエラーを使うことに
    3. 現在はベースはシンプルにして、その上で好きなものを実装する形に

Let It CRASH @koichkさん

1. Earlangの耐障害性のポリシー
   1. あえて失敗を備えない
   2. 特別なプロセスが再起動させる
   3. エラー処理とアプリが分離する
2. NodeではuncaghtException
   1. そのまま続けちゃダメ
   2. 最近ではdomain.on(err)
3. ここで時間切れ(^^;)

Object.defineProperty

1. オフジェクトのプロパティの性質を制御する関数
2. 変更できなくしたり、プロトタイプ汚染を防いだり
3. ゲッター、セッターを定義できる

第63回PHP勉強会に参加してきました

Yiiでしょ(レアジョブ　岩村さん)

1. フィリピン側との共同開発
   1. そちら側で既にYiiを使っていた
2. デモアプリケーションを作れるコマンドがある
   1. データベースにつながっていなくてもOK
3. 便利な機能
   1. ブラウザベースのコードジェネレーターがある
   2. コントローラーにメソッドを追加しなくてもviewを設定できる(?)
   3. バリデーションルール
   4. 色々なエクステンション
   5. デバッグツールバーで内部の値を取得できる
4. レアジョブでは漸次導入中
5. 質問
   1. 設定をステージングに分ける機能は?
      1. 簡単な設定わけ機能はある
      2. 細かいのはエクステンションで
   2. コマンドラインツールは
      1. あるけど非推奨。
         1. 一応、エクステンションありますよ
      2. エクステンションはどこまでできる
         1. ほぼ全部、基本イベント駆動だし

WebStormまたはPHP Stormの話

1. jetBRAINS(チョコの会社)製
2. とにかく賢い
3. メジャーフレームワークサポート
   1. たいていの『あるといいな』に対応
4. とにかく強力
5. 環境設定もやってくれる
6. 最初からZEN　COADING対応
7. ないファイルは自動的に検出
8. JsDOCを自動チェック
9. 関数の呼び出し元に移動できる
10. chromeと入力がリアルタイムで同期
11. カラーピッカーもあり
12. コマーシャルライセンスで1万円〜2万円
    1. これでもギリギリです(^^;)

第二回 プログラマ向けデザイン勉強会に参加してきました

はじめての欧文書体

1. 欧文書体には様々な種類がある
2. 全ての書体にある訳ではないが字幅やウェイトなどがある
3. 書体はどこかの国で色々な背景を持って生まれている
   1. トラヤヌス帝のの碑文から作られた書体が映画などで使われている
   2. ギャラモン(人物名)、ヘルベチカ(スイスのラテン語名)
   3. 欧文書体はロゴ使用がだいたいOKだが和文はだいたい要お問い合わせ
   4. 日本語だと、proとつく方がいっぱい文字が収納されてる
4. 書体が持つ雰囲気
   1. セリフ書体は高級感
   2. インパクトがある書体
5. 実践編: Webサービスで使いやすそうな書体
6. Helveticaはありふれた感がある
7. 有料webフォントもありでは？
   1. 色々なフォントが使える
   2. 違った感じがする
8. 書体を選ぶということは既にデザイン
9. 専門雑誌もあるよ

ノンデザイナー　デザインブックを読み解く

1. ノンデザイナーズデザインブックについて
   1. デザインの基本原則が書かれている
   2. パワポとかにも
2. 基本原則
   1. 近接
      1. 似たものは近くに
   2. 整列
      1. 似たものは並べる
   3. 反復
      1. 同じ特徴を繰り返す
   4. コントラスト
      1. 違いをはっきり出す
3. なぜ近接がデザインにとって重要なのか？
   1. ゲシュタルト原理
      1. 人間はパーツをまとまりとして理解する
         1. プレグナンツの法則
      2. 互いに閉じあっているものは一まとまりになりやすい
   2. ゲシュタルト原理は機械学習で言うところの枝刈り
4. 人は分類せずにいられない
   1. 見出しをつけると理解が進む
5. サビタイジング
   1. 数の認識方法の違い
   2. 4個までは一瞬で把握できる
6. なぜ整列が重要なのか
   1. 特定の図形のパターンにだけ反応する細胞がある
      1. 無視すると目が泳ぐ
   2. あらましをつかむのは周辺視野の役割
7. 反復がなぜ重要なのか
   1. 人間はパターンで認識する
      1. ジオン理論
         1. 基本的な幾何パターンで認識する
8. コントラストが重要なのか？
   1. 三次元認識
      1. 霞んで見える→遠くにある→重要でない
      2. 注意の瞬き
         1. 何かを認識すると、0.5秒間ほかの事を認識できなくなる
   2. 注意は選択的に働く
      1. 何箇所かだけで焦点を合わせ、それ以外を無視できる
   3. wordpressの集中執筆モード

0.1ランク上のアイコンの作り方講座

1. まず情報を整理する
   1. アイコンで最も重要なポイントだとおもっている
   2. まず思いつく限りキーワードを出してみる
   3. 出し切ったら絞り込む(4つくらい)
      1. 多すぎるのはNG
2. 記号化
   1. 見た目の部分をシンプルに
   2. よりプリミティブに
      1. 「まずあるのは視点だけ」(ソシュール)
   3. アフォーダンス
      1. 物理的形状が機能に影響を与える
3. グラフィックのポイント
   1. 光を意識する
      1. 光源とオブジェクトの関係を意識する
      2. 影といっても色々とある
      3. 陰(グラデーション)と影(光源が物体にあたって直接落ちる影)
      4. 布は微妙にグラデするのでちゃんとつけましょう
4. 素材は頑張って探してましょう(iPhoto stock exchangeなど)
5. フォトショでプラグインを購入するのもあり
6. サイズを変える時の注意事項
   1. 輪郭が不鮮明になって、ぼやけてくる
   2. アンチエイリアスをオフに
   3. 色を補正。コントラストを強めに
   4. アンシャープでぼやけた画像をくっきりと
   5. テクスチャは拡大
   6. 背景とかで演出を

デザイン検討会

　実際にデザイナーにデザインを見て欲しいアプリの検討会が行われました

entakun

http://entakun.co/

1. タスク管理のツール
   1. redmineよりもシンプルに
      1. ちゃぶ台、円卓のイメージ
      2. イメージカラーはオレンジ
   2. オープンソース
   3. バックエンドはMongo+Sinatra
2. 会場から
   1. メールのノーティフィケーションは？
      1. 近くの人とメモ的に使うから不要
   2. 複数の人が同時に使うとコリジョンする？
      1. します
   3. デザイナーさんから
   4. 色分けを背景一色で表現せず背景は色を抑え、先頭にコントラストの大きい色を配置したほうが色弱の人には字が見やすいいい
      1. テキストフィールドの見分けがつきにくい
      2. パーツの分け方が弱い
   5. トップページで「ちゃぶ台のイメージ」にするメリットが薄い
      1. たまたま手元にあった画像でイラストを差し替えたサンプルを例示
         1. イラストがもっとはっきりした方がいいのでは?
      2. トップページにもっと実例が欲しい。具体的なスクリーンショット
   6. ボタンはユーザーの導線に合わせて

Nyanstagram

　猫専用のアプリ。(http://www.nyanstagram.com/)

1. いいフォントはないですか？
   1. 漢字のタグ付けが残念になっている
2. 毛並みっぽい背景画像が欲しい
3. アプリを横展開したいので、メインカラーでいいのを教えてください
4. 毛並みっぽい画像はfurで素材サイトを検索
5. フォントは難しいのでカタカナでいいのでは？
   1. それか小さく通常のフォントで
6. 色は共通ではなくアプリごとに
   1. 色は自由に決めればいい。イメージを固定すると地味な色ばかりになる
7. フォントは遊びが強いものはフリーの方がいい
   1. 視角文化研究所のフォントとかオススメです

NHNテクノロジーカンファレンスに参加してきました

Open Compute Japanについて(鵜沢幹夫さん)

1. Open ComputeはFacebookがはじめたデータセンターのオープンソース化
2. 背景
   1. アクセスがデータセンターが巨大化
      1. 27MWの電力
      2. 一人のエンジニアで数万台を管理する程度の自動化
   2. モバイルにトラフィックに移行し始めている
3. なぜオープンソース?
   1. インフラエンジニア間のコミュニケーション
   2. エコシステムの構成によるコスト低下
4. 競争からエコシステムへ
5. BtoCでは、どうしてもコスト低下が必要になる
6. データセンターの実際
   1. 隙間はありあわせの材料
   2. ホットアイルは配線なし
   3. サーバーは全て差し込み。工具がなくても分解組み立てが可能
   4. 2を除いて5までの四種類のサーバー
   5. 一号棟は人工ミストで冷却
      1. 実験に使うような純水を使っている(地下にすごいプラントが)
   6. 二号棟では気化熱を利用するシステムに
   7. 高温多湿の環境でもなんとか動く
7. DONE IS BETTER THAN PERFECT

データセンターの不思議運用テクニック

1. 高密度ラックに施錠つきはありえない
   1. 空気の流れが悪い
   2. でも日本だと難しいところも
   3. メッシュのラックを使いましょう
2. 不思議な運用って？
   1. 綺麗な配線を目指しましょう？
      1. 付属品の電源ケーブルは長すぎるので、短いのを買いましょう
      2. 引き出し式では遊び必要
   2. リールから自作しない
      1. 長期使用でトラブル
   3. 市販の極細タイプケーブを
   4. サイドフローは敵
   5. サーバーの構成に合わせてフローの構成
   6. 風がちゃんと通らないと落ちるので、真ん中は1U分交互にあける
   7. 熱い空気を吸い込むのを防ぐ為に遮蔽版を
      1. 工作用紙でちょうどいいらしいです(^^;)
   8. 風向計も自作
3. 上にL2スイッチを置く構成は空気の流れを乱すので、できたら下に

1. アイルキャピッング
   1. 熱い空気とつめたい空気を分けて、熱い排気は速やかに排出
   2. 設置のときに気をつけないといけない
   3. エアフローを変更できるスイッチがある
2. 配線をひとつにまとめる
   1. ただし、ファンの交換には干渉しないように
3. 分業の細分化によって保守とデザインが大変に
4. 小物をどんどん活用しましょう
5. 「空気を読みましょう」
6. 「交換できるようになっているものは交換する可能性があります」
7. 質問
   1. 細いケーブルの電波耐性は？
      1. 最近はいいのが出てきている。ただし、長くても数メートルが限度
      2. UPSとかあるときついけど、直流給電できれば
      3. ケーブリングの工夫で軽減できるよ!
      4. なんとか運用で逃げられる
   2. 古いデータセンターによくある扇風機、効果あるの？
      1. コールドアイルは部屋の隅なので無いと死ぬ。実際にはエアサーキュレーターの方が効く
   3. 湿度は？
      1. かなり大事。特に外気型は大変

こんなデータセンターはいやだ

1. 楽天のインフラ設計の人
2. 楽天の事例ではありません
   1. 地方データセンター
      1. 地方のデータセンターは交通の便がいいとは限らない
      2. 豪雪地帯のど真ん中
      3. 駅からバスが一時間に一度、終バスも速い
         1. 暇つぶしの用意をお忘れなく!
   2. セキュリティ
      1. 昔はセキュリティはゆるゆる
      2. 今はめちゃくちゃ厳しい
      3. 障害のようなイレギュラーが起きると大変なことに
   3. 貸し出し
      1. どうしても足りないものが出てくるので、データセンターに借りることに
      2. 有料と無料があって複雑。事前の確認を
   4. ファイバー
   5. キャリアごとに分けているからといって安心できない
      1. 系統としては一系統とか
      2. 引き込みが分かれいるか
      3. 縦管は？
         1. 交差していたり
   6. ＋ルーム内の引き込み口は？
      1. 実は途中のルーターはひとつだったり
   7. 頑張って交渉するべき
   8. 電源にも同じことが言える
   9. 最後にはDCレベルの冗長構成が必要
   10. 電源容量の確保も大事
       1. 定期的に確認を
   11. 非常時の燃料は本当の非常時には確保できません
   12. ブレーカー
       1. プレーカーを上げる作業は意外と面倒
       2. 予備は何かあった時にちゃんと耐えられるものを
   13. エアフロー
       1. データーセンターで設備だけでできない冷却を行うようになっている
       2. 自然風の取り込みには注意
3. 泣かない為には事前準備は大切
4. 質問・意見
   1. 掃除は
      1. 結構大事、かつ大変
      2. ルンバを入れたところがある
         1. 広すぎて電池切れて息耐える
   2. 冗長化対応をコマンドで切り替える機種があるので用確認

「落ちる時は落ちる」

こんな利用者はいやだ

1. 事業者側から見た困った利用者
2. 布団をサーバーの前に引いていた
   1. 羽毛がトラブルの原因になるのでやめてください(＞＜)
3. しまらない扉
4. ラックを加工し始める人
   1. 金属粉がダメージになる
5. 床下の配線
6. ラックが物置になっている
7. なぜか野良AP
   1. 携帯のテザリングも注意

　ここで講演者交代

1. あくまでフィクションです
2. 入れないデータセンターと出れないデータセンター
   1. 指紋認証の罠
      1. 中々通らない
   2. なんとか入ったものの、出るときにも引っかかって出られない
   3. 緊急連絡先もない
   4. データセンターにトイレもない…
3. 友連れ防止扉が狭いので、交換部品をもって入ったら動けなくなった
4. 二重床になっている床を開けっ放しして帰っていく人がいる
   1. 落ちる
   2. エアフローが変わる
5. 立会い20人が本当に来た
6. 「L2スイッチ貸してください」
7. 床を開けて穴をダンボールでふさいで行く人がいた(!)
8. 質問
   1. 血まみれになった光ファイバーはどうしたの？　というフィクションを話してください
      1. 拭きました。ケプラーで保護されているので多少の汚れは大丈夫。ただし電源が走っていたらまずかった
   2. アメリカではサーバーの前に兵士が立ち番しているケースも

パネルディスカッション

　データホテルの嶋田さんとさくらの社長の田中さんによる

1. 本当に儲かっている？
   1. 田中さん「上場しているのでガラス張りですが、儲かっています」
   2. 嶋田さん「うちは過酷なトラフィックがあると儲かる。ソーシャルアプリとか」
   3. 会場から「今年はまぢきつい」
2. AWSは敵か味方か？
   1. 田中さん「敵です。でも、クラウドしかやっていないのも事実なので対抗はできる。ライバルなのは間違いない」
   2. 嶋田さん「影響力は大きい。でも、敵とも味方ともいえない。隣に外人さんが引っ越してきたような感覚」
3. 目障りな競合は？(^^;)
   1. 嶋田さん「今年の後半は値下げブームが来るので、値下げしてくる業者はやっかい」
   2. 田中さん「AWS」
      1. 自然にライバル関係ができたりすることはあるけど？
         1. 田中さん「各分野ではぶつかるが、全体でぶつかっているところはない」
4. 人物金、技術、大事なものは
   1. 田中さん「やはり人。技術を買ってくるのだけだと、優位は出ない」
   2. 嶋田さん「データホテルのロゴには人の文字が入っている」
5. SDNは必要
   1. 田中さん「もっと泥臭いものでないと」
   2. 嶋田さん「つながりさえすればいいかな？　と」
6. OCPJはどう？
   1. 田中さん「人出しています」
   2. 嶋田さん「興味あります」
7. どこへ向かうのか？
   1. 嶋田さん「海外で使いたい、というお客さんが増えている。シンガポールもデータセンターパークを造っている。国際化のムーブメントは加速するのではないか？」
   2. 田中さん「東京の市場が厳しくなるので、減らすかもしれない。でもそれでは夢がないので国際化に乗っかりたい。特にアジアはこれからすごく延びる。でも、国情を考えると日本の北の方にも目があるのではないか？」
   3. 嶋田さん「欧米に行きたいお客さんと南の方に行きたいお客さんがいて、それぞれに対応が必要。ただ、カントリーリスクなどを考えると、アジアのデータを日本に集めるという方向性もあるのではないか？」
8. ホスティングは楽しい？
   1. 田中さん「私は人生ホスティングですから当然です。手段にこだわれるのは楽しい」
   2. 嶋田さん「田中さんのホスティング愛には負けるけど、パソコン触って楽しいという感覚の延長で楽しんでいる」
9. 質問
   1. 電力事情はこれから厳しくなっていくが大丈夫か？
      1. 田中さん「これからどんどん新しい発電方式が出てきて、電力会社としては高くなるけどトータルでは安くなるのではないか？」
   2. アクセスが悪いとエンジニアが集まりにくいのでは？
      1. 田中さん「北海どうでも場所による。石狩は札幌に実は近く、各社の営業所もあるのでレスポンスもいい。ただ石狩市民の雇用がほとんどないのでそこがネック」

第65回PHP勉強会に参加してきました

　恵比寿のEngine Yardで開催された第65回勉強会に参加してきました。

behat/PHPUnitではじめるBDD/TDD

1. 前回のPHP勉強会をきっかけにBDDを開始
2. TDDは混乱を小さくする
3. BDDは自然言語でテストを記述
   1. 抜け漏れ防止
   2. オブジェクト指向強化
4. Behatとmink、PHPUnitを使用
5. behatのインストールは3種類
   1. Comporser
   2. Git
   3. Pear
6. behatの下にjenkins用のbuild.xml
7. FacebookAPIの不具合もbehatで監視している
8. フィーチャーからスケルトンを自動生成
9. ボタンidが振ってあると便利
10. 時間的にタイトなので、ウェイトを入れる
11. メリット
    1. なんちゃってアジャイルを避けられる
    2. 事前の洗い出しが網羅的に
12. デメリット
    1. 後回しになりやすい
    2. 問題が見つかったらすぐに対処しないと無駄が
13. WebDriverの選択重視。クロスブラウザに問題あり

Riak && riak-php-client

1. Dinamoにインスパイア
2. Erlangで実装
   1. 高可用性
   2. スケールアウトが容易
   3. マスターがない
   4. Erlangで動くので固まりにくい
   5. ただし遅い
   6. トランザクションしない
3. Baas的に使える
4. バイナリのホットフィクス可能
5. RiakのPHPクライアント開発に参加してください
6. 質問
   1. 安定性は？
   2. 3年動いているクラスタがある
   3. Couchとの比較は
      1. Couchはオワコン
   4. 落ちた時に再配置は?
7. DHTの別のところにあるレプリカにうつるからおけ

LT

Yandoさん(Rails4)

1. WebDB　PresのRails特集面白かった
2. Ruby1.8はPHP4
3. 「Rails is OMAKASE」
4. Postgresの勢力増加
5. Turbo Links(bodyだけ書き変え
6. Asset　Pipeline
   1. Assetic(Cake PHP)

syzuhikoさん　comporser　

1. comporserはPHPフレームワークをサポートしている
2. フレームワークごとにことなるvenderに対応している
3. Packegistに問題多数
4. CakePHP2本増刷しました

ooharabutyouさん

1. ＰＨＰで複数環境をコントロールするコマンドphp-nabe作りますた
2. エクステンションをオフにできたりする

郡山さん　Bear.sundayの紹介

1. 依存関係逆転の法則
   1. 「発電所ではなく、コンセントに依存する」
2. 生成使用分離の原則
   1. 生成するか使用するかのどちらかでどちらも同時にしてはいけない
3. デメテルの法則
   1. 「友人のみの公開」
4. Tell　Don't　ASK
   1. オブジェクトの中にロジックを閉じ込めろ