2016-12-09

yarnをnpm i -gでインストールしようとしたら怒られた

タイトルどおりです。

$ npm i -g yarn
npm WARN deprecated yarn@0.17.10: It is recommended to install Yarn using the native installation method for your environment. See https://yarnpkg.com/en/docs/install

npmじゃなくてネイティブのパッケージ管理を使おうねと言われています。
OSXならbrew、Ubuntuならapt-getとかそういう話です。

これなんでだろって思ってたら公式に答え書いてありました。

yarnpkg.com

Install via npmのところ。

Note: Installation via npm is generally not recommended. npm is non-determinstic, packages are not signed, and npm does not perform any integrity checks other than a basic SHA1 hash, which is a security risk when installing system-wide apps.

For these reasons, it is highly recommended that you install Yarn through the installation method best suited to your operating system.

npmでインストールするのは通常オススメできない。なんでかっていうとnpmは非決定的で、パッケージが署名されておらず、SHA1ハッシュ以外の正真性チェックを行わないから。

というわけでbrew installとかでいれましょう。

Windowsユーザーはどうすんのかなって思ったらmsiファイルとchocolateyがあるみたいです。

2016-12-07

映画『君の名は。』ネタバレ感想

よかったですね。まあよかったんですけどいろいろ言いたいこともある感じです。

以下ネタバレです。

2016-11-15

第30回西日暮里.rb オブジェクト指向設計実践ガイド読書会に参加してきました

読書会第一回から2週間が経過して、読書会第二回が開催されたので参加してきました。

nishinipporirb.doorkeeper.jp

内容

今回は第三章、第四章が対象でした。第三章は依存関係の管理について、第四章はインターフェースについてです。とはいえ今のまとめは語弊があって、「依存関係の管理」はオブジェクト指向のキモであると筆者が書いたように本書全体で扱うテーマなので不適切です。第三章では特に依存関係とはなにか、どのような依存関係が望ましいのかという点について説明しています。第四章の"インターフェース"も、2種類ある"インターフェース"のうちの片方にしか触れていません。2種類あるというのは、1つは「ある1つのオブジェクトに対して送信できるメッセージの定義群」としての意味で、もう1つは「複数のオブジェクトに対して同じようにメッセージを送ることができるようなメッセージの定義」としての意味です。ざっくりいうと、前者が1つのオブジェクトがもつメソッドのシグネチャのまとまりで後者がJavaのインターフェースです*1。第四章では前者についてどのような定義がよいのか、何を考慮すべきかについて説明しています。

以下、トピックとして気になったものについてかいていきます。

依存関係の認識

本書では依存関係とは何かについて具体的に例を挙げて説明している。あるクラス内にクラス名がハードコードされていたらそれは当然依存関係であるのだが、それ以外にも初心者が気が付きにくいものがあげられていた*2

依存関係の方向を意識するのが大事なのはひしひしと伝わってきたのだけれども、ここでRubyの言語仕様的な難しさを感じる。Javaだとファイル単位でimport文を書くのであるファイルがどのパッケージに依存するかは宣言的。一方でRubyのrequireはファイル単位ではなくグローバルに影響を及ぼすので依存関係を意識する機会が少ないというのはあるとおもう。

コンストラクタで処理する

これは本の中にある変更に対する反論として挙がっていたのだけれども*3、あるクラスが他のクラスに依存してる場合、それを明示するためにコンストラクタ内で見せたほうがいいんじゃないかという話。遅延初期化は生成コストがバカにならない場合のみにすべきで普通のインスタンス変数は initialize メソッドで初期化したほうがいいのでは、という意見があった。

この指摘はたしかにそうかもなと納得したのでとりあえずメモ化みたいなのはやめる。

西日暮里.rbは今後も2週間に1回くらいのペースで「オブジェクト指向設計実践ガイド」の読書会を開催していくようなのでよければ是非。月曜日夜20時からで最寄りが秋葉原なので参加もしやすいと思います。なお次回は第五章と第六章の予定で第五章では動的型付け vs 静的型づけのセクションがあるので最悪の場合死に至るかもしれません。

*1:ざっくり言い過ぎなのはわかってます

*2:詳しくは読んでください

*3:本を書く上で選んだサンプルが不適切ではないかという指摘です

2016-11-12

近況

つらつら書く

本

漫画

シリーズ揃えてるやつから。

大砲とスタンプ1〜4巻
- 久々に読んだらよかった。いつの間にか5巻出てたので今度買う
- 物理本で揃えてるのだけどあるならKindle版に移行する予定
- ちゃんと話がいろいろ繋がってることを再確認できてよかった
- 速水螺旋人の読み方、これ絶対「トルネード」だろって思ってたのに「らせんじん」らしい。外した
東京喰種無印版1〜14巻
- 石田スイはwebコミ読んでて一般デビューしたのもしってたけど忘れてた
- 飲み会で話題にあがったので読んだ
- 亜門萌え
- まだ1周しかしてないのでまたゆっくり読みそう
王様達のヴァイキング1〜10巻
- 4周くらいした
- 是枝くんが最高だったのでC++とPython欲が高まったけど一応WEB系の人間なのでギリギリ思いとどまった
からかい上手の高木さん4巻
- 脳が溶けた
- 4巻の高木さんすごくてほんとにすごい
- テンションが上がりすぎて読んでたら足がつった
- あしたは土曜日の春夏と秋冬も読んだ。よかった。心があたたまる
ヴィンランド・サガ1~18巻
- 3周目が終わったところ
- 「話がプラネテスと同じだよね」って話をしたら友人に「は？？？？」って顔されたけど同じだと思う
- だからギラギラしてたときのほうが好きなのもプラネテスと同じなんだけどそれでも面白い
あの娘にキスと白百合を1〜5巻
- 白峰さんよりは黒沢さん派なんですけどいちいち出て来るキャラが立っててすごくよい
- サブキャラだと自転車通学のエピソードと広報委員会のエピソードがよかった
- これも周回候補
AIの遺電子3巻
- 須藤先生の過去をちょこっとやった感じだけどこれいつまで続くんだろう
- 無難な面白さなので買ってる
3月のライオン1〜12巻
- 1〜11は読んでたけど盛ってなかったのでこの機会に一気買いした
- 変わらずよかった。れいくんの無自覚高飛車な感じがよい
- アニメ1、2話だけみて、シャフ度出ないなーって思ってたけど二階堂だけシャフ度で笑った
亜人ちゃんは語りたい4巻
- 安定の面白さ
- サッキー幸せになってほしい

まだ1巻しか買ってないやつ

上野さんは不器用1巻
- キモオタ用下ネタ含みラブコメ。ラブコメというかコメディ+ラブ要素？
- 結構わらったしよかったので続きも買う
青春のアフター 1巻
- 緑のルーペ先生の。一般デビューしてたの知らなかったです
- 1~3話で心をグサグサえぐってきたのでつらかった
- 続き絶対買う。そろそろ完結らしい
かぐや様は告らせたい 1巻
- 恋愛心理バトルギャグ漫画
- おもしろかったけどなんか物足りなかったので続きはいいかなって感じ
- キャラがあんまりツボにハマらなかったのかもしれない
ちおちゃんの通学路 1巻
- ハイテンションコミュ障アクションギャグ漫画
- 面白かったけど続き買うかっていうとちょっとわかんない
- Kindleの発色と絵面があんまりあわない気がする
徒然チルドレン 1巻
- なんか異常に安かったときがあって買った
- 面白いが続きは別になくてもいいかなって思ったのと前にwebで見たなあという気持ちが強く残ってしまった
  - 九井諒子とかはwebで見たぞって思いつつも買ったけど
りぶねす 1巻
- なんか異常に安かっt
- 続きは別になk
- webでは見てない

not 漫画

1日で読めてわかるTCP/IPのエッセンス
- 普通に忘れてるので勉強になった
読者ハ読ムナ(笑)
- 藤田和日郎の新人アシスタント育成術の本。いま6割くらい。
- 中盤からは創作に特化した話だけど序盤は一般論としていいこといってると思う
オブジェクト指向設計実践ガイド
- ちょっと積み気味。漫画読みすぎのため
- 勉強会いくのでちゃんと読みますすみません……

近況書くつもりだったのに最近読んだ漫画を羅列しただけで終わってしまった。まあこれが僕の近況ということで。

2016-11-01

読書会でガヤガヤしてきました - 第29回西日暮里.rb オブジェクト指向設計実践ガイド読書会

nishinipporirb.doorkeeper.jp

先日出版されました「オブジェクト指向設計実践ガイド」の読書会に参加してきました。
一言で言うと最高でした。

本についてはまあいまさら僕が説明するまでもない気はしますが、Sandi Metzルールで有名なSandi Metz氏が書いた本の和訳です。
原著は5年前に出版されていたそうですが先日和訳版が出版されました。

翻訳者であるtaiki__tさんが西日暮里.rbのオーガナイザーをやっているということでせっかくだから翻訳者を交えてやっていこうぜというイベントだったようです。

読書会というのの形式で一般的なのかはよくわかりませんが、今回は読む時間をとって、付箋になんやかんや書いて、貼って、ざっとトークするというのをやりました。
予習済みの想定なので読む時間は、あんまりとってなかったです。たぶん1章10分くらい？
僕は5章か6章まで読んでたんですが、その状態で1章2章をパラ見するという経験をして、それだけで結構面白かったです。

トーク部分は、ちょっと脱線することもあったけど言いたいことを言えたし聞きたいことを聞けたしという感じで大満足です。
付箋にはなんでも書いてよかったのですが、大別すると「わかる」「これみんなは実際どうしてんの？」「これさすがにおかしくね？」の3つくらいのレベル感のものがありました。
2つ目は、まあたとえば定量的な計測の難しい感覚的な部分についてどう思うかという質問であったりとか、チーム開発でこれを実践していくためにはどうやってます？とかそういう話でした。

トーク的に広がりがあって面白かったのは2, 3はまあそれぞれ言いたいことがあるので盛り上がって、あと1には具体的な事例がついてるとネタとしてよさそうです。
本に書いてあってそうだよね〜〜〜わかる〜〜って程度の部分はトーク的にはさらっと流してよさそうだなと思いました。 *1

トーク内容で特に記憶に残ってるのは、「メソッド分割しすぎって思うことがある」という話。
いままで「でっかいメソッドは悪。殺すべし」ということは教わってきたけど「分割しすぎ」って言われたことがないのでふーんって感じでした。具体的なコードをみて話したわけではないので、どういうレベルのものを指していっているのかが気になりました。

あと、僕以外だれも付箋つけてなかったけど本の中にある『オブジェクト指向とは「依存関係を管理すること」です』ってフレーズがあってかっこいいなって思いました。
「オブジェクト指向って何？」って聞かれたらどう答えるだろう。特に思いつかないけど。メッセージパッシングだよとかいってごまかしそう。

復習がてら読み直すにはいい会だったので第3章以降も開催されるといいなって思います。ぜひぜひ。

余談ですが買うなら物理本かgihyo digital publishing版がよさそうです。
Kindle版はコード部分のフォントがプロポーショナルで、しかも元ソースが = でアラインするタイプのフォーマットなのでクソ読みづらいです。

gihyo.jp

追記

あんまり本の内容を書きすぎてもよくないかなとおもって基本的には書かないようにしていたのだけど、どうもSandi Metzの主張と食い違うところがあったのでそこだけは書いておくことにした。

クラス内からのインスタンス変数アクセスもメソッド呼び出しを経由せよ、という内容があった。
その恩恵の例として、ちょっと値を変更したときにも呼び出す側のコードを変更せずに済むので保守性が高いというのがあった。

class Foo
  def bar
    @bar
  end

  def some_method
    puts bar
  end

  def another_method
    puts bar * 2
  end
end

変更するとこんな感じ

class Foo
  def bar
    "bar: #{@bar}"
  end

  def some_method
    puts bar
  end

  def another_method
    puts bar * 2
  end
end

ここについて強く主張していたのはmtsmfmさんだったと思うけどこのコードはよくなさそう。
インスタンス変数 @bar がある場合に bar メソッドはインスタンス変数 @bar を返すと期待してしまうけど実際は違う値が返ってくるから。驚き最小の原則に反する気がする。
@bar にナニカ変更を加えた値を使うなら例えば bar_inspection とかそういう別名メソッドを生やすべきでしょうよって感じの主張で、うんうんその通りだわって思った。*2

*1:意見交換は対立構造があったほうがいいよねって話なのですげー普通の話だった

*2:読んだとき微妙に首かしげたけど付箋に貼るの忘れてた……

2016-10-02

オフラインリアルタイムどう書くE08

オフラインリアルタイムどう書くE08(http://mtsmfm.github.io/2016/10/01/doukaku-e08.html) 回答

以下回答

2016-09-20

縦型組織が流行ってるけどちょっとしたらまた横型組織が流行るんじゃないの

みなさんのチームは情報共有ちゃんとできてますか？

お仕事の話で「情報共有ができてない」という声はよく聞きますよね。
じゃあ実際「できてる」状態ってどんな状態なんだろなって思うことしきりなわけですが*1
今回はそういう厳密な話は置いといて、組織構造と情報共有について考えたことを書こうと思います。

その動機

こういう施策をとる場合、解決すべき課題としては以下のようなものがあげられます。

職種感の壁によるコミュニケーション齟齬がつらい
├価値観の違い
├文化の違い
└お互いの無知

コミュニケーション齟齬の結果としてアウトプットの質の低下、速度の低下、コストの増加があるので改善したいと。

組織変えればめでたし……？

組織構造変えれば全部うまくいきました最高！めっちゃコンウェイ！

というわけではなく、まあ門外漢でも思いつくものとして、横のつながり希薄にならない？っていうのはありますよね。
具体的には知識・ノウハウの共有の妨げになるのではないか。個人の成長が阻害されないかという点です。

これについては、某所*2では勉強会の開催や元々あったslackチームを活発にするよう頑張ってるという対策が挙げられてました。

そういう事例をみて僕は思ったッス

この組織改革は、以下のような捉え方ができます。

今現在実現できていることと実現できていないことがある。
実現できていないことができるようにするために、いま実現できていることのコストをちょっと上げてでも対応することにした。

この組織が新卒採用をしながら成長していった数年後、そこには縦型組織に慣れた人が存在するはずです。そうすると逆の課題が発生して横型組織に戻っていくのかもしれません。

*1:現段階で一番好きなのは、ないと業務に支障をきたすレベル1、あると嬉しいレベル2、なにかを創発するレベル3という三段階説

*2:ぼかしてるのではなく忘れた

Smoky God Express