西日暮里.rb x Shinjuku.rb Extreme Fish Bowl に参加してきました

shinjukurb.connpass.com

参加してきました。楽しかったです。

雑にExtreme Fishbowlについて説明すると、集団の中の2人がペアプロして、残りが野次って、というのをずっと繰り返す感じです。 主に野次の担当をしました。

よかった

  • みんなのターミナル捌きが見れた
    • といっても環境自体はmtsmfmさんのなのでみんなちょっとずつ苦戦してたけど
  • これは後で直すとかいいながらgit commitする姿が見れた
    • こうやって技術的負債が生まれるんだなって思った
    • これは時間制限5分を徹底したせいで、ひどいときはシンタックスエラーでコミットされてて面白かった
  • 負債の返却もガンガン進んでよかった
    • これ消しましょう → 2クラスくらい消える
  • 言葉に対する認識の違いがおもったよりもあることがわかってよかった
    • マーク派 vs suit派
      • 英語的にはsuitなんだけど知らん人が結構いた
    • Deckっていったとき山札なのかトランプ1組なのか
    • このクラスの責任はどこまでなのよ問題
      • 結局神クラスが誕生した

つらかった

  • 英字キーボード
    • 僕JIS配列なんで死んだ
    • Enterのだいぶ上のほうを叩いてるのでずっとバクスラ連打してた
    • 僕「アンスコどこ!?」
    • 僕「クォートどこ!?!?」
    • 僕「コロンどこ!?!?!?」
    • C-[ でEscを打とうとしても [ の位置が違ってなんもできなかった
    • つらい

まとめ

  • お祭り的な楽しさがあってよかった
  • やっても特に設計スキルは上達しないと思う
  • 奇妙な一体感と諸行無常感があった

お祭りとしてはオススメです。

アイマスハッカソンなるものに参加して歌詞を自動生成してくれるものを作った

んだけどあんまりおもしろい結果にならなかった。

imas.connpass.com

やったこととしては、歌詞テキストを形態素解析してマルコフ連鎖でつなげるってやつ。

技術的にはだいたいこれの焼き直し。

alstamber.hatenablog.jp

  1. 気合で歌詞データを用意する
  2. マルコフする
  3. hkdnet/markov_gen
  4. 眺める

歌詞には著作権やらなんやらの権利があると思うのだけど、形態素解析して作ったものは権利的にどうなるのかわからなくてパブリックに見せていない。たぶん大丈夫な気がするが。

というわけで成果物をパブリックにするのがはばかられるのもあって厳しいところがあるがハッカソン自体は楽しかったです。

Raspberry Pi3を勢い余って買ったので無線LAN APにしてみる

github.com

気合でしました。ansibleにしてあるので実行すればたぶん動きます。 OSはnoobのほう。参考サイトとかは書いてある通りです。

注意点

  • 無線LANの口(wlan0)から受け取ったのを有線LANの口(eth0)に流してるので当然有線LANの接続が必要です
  • タグうったときには書き忘れてたけどhosts書いてください
    • hostsのグループ名をgizehから変える場合はsite.ymlのhostsも変えてください
  • gizeh/roles/wifi/templates/etc/iptables.ipv4.net はもしかしたら動かないかもです。
    • みた感じ動く気がするけど……
    • 参考サイトの "SET UP IPV4 FORWARDING" の項目に該当するので手動でやり直してみてください
  • SSIDはgizehになります

f:id:hkdnet:20161214085854p:plain

電子工作とかやるぞーっていうよりは適当なlinuxサーバとして使うつもりです。

でもアクセスポイント化すると前述のように有線LANの接続が必要になってケーブルがうざったいのでオフにする予定。 上のgithubのリンクはタグを見るようにしてるんでたぶんいつでも有効です。

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ならbrewUbuntuなら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があるみたいです。

第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:本を書く上で選んだサンプルが不適切ではないかという指摘です