valid,invalid

関心を持てる事柄について

rbenv: yarn: command not found

手元の mac で突然 yarn コマンドがエラーを吐くようになった。何をしたか思い出せない…。

$ yarn
rbenv: yarn: command not found

うーん?と思いつつどこを参照しているか確認する。

$ which yarn
/Users/ohbarye/.rbenv/shims/yarn

なんで yarn がここに入っているのかわからないので消してみる。

$ rm /Users/ohbarye/.rbenv/shims/yarn

$ which yarn
/usr/local/bin/yarn

$ yarn -v
yarn install v0.27.5
[1/4] Resolving packages...
success Already up-to-date.
Done in 0.35s.

動いた。完

行ってよかった builderscon 2017 Tokyo

builderscon - Discover Something Newに前夜祭から最終日まで参加してきた。

感想

行く前から「絶対これを聞く!!」というような目当てがあるわけではなかったが、来てみれば発表のジャンルも幅広いし、著名な海外スピーカーも来るし(同時通訳つき)、何も見つけずに帰る方が難しぞこれはという感じで楽しめた。

前夜祭のアルコール、1日目〜2日目のコーヒーやジュース飲み放題、弁当支給(どうしても日吉の飯屋行きたかったので食べなかったけど)のホスピタリティ、そして会場:慶應義塾協生館がとても綺麗でトイレ事情も完璧。環境面でも言うことなし。ノベルティのトートバッグも格好いい(余ってたので2つ入手した)。

“Discover something new” というコンセプトも良いなァと思いつつ、当事者意識や質問が湧いてくるのは “知っている領域の延長” だったりする。なので理論上は勉強すればするほど楽しめる!!

聞いた講演

各日ごとに残したメモをそのまま公開している。

特に印象に残った講演

前夜祭全般

書くことはできませんが、最高でした。特に最初のトーク「オンプレミスデータセンター撤退! - 大人のビルコン 〜撤退技術スペシャル〜(1)」が一番のお気に入り。

前夜祭通して思ったのは、成功事例の紹介も大事だが失敗した話や苦労している話も同等かそれ以上に大事だということ。失敗談を語る勉強会みたいなのはもっと増えてもいいかもしれない。(現在進行系の話や事件直後の問題は公にできないかもしれないという問題はある…)

Desktop Apps with JavaScript

Slack 社 @felixrieseberg 氏によるデスクトップアプリ開発入門的なお話。

Electron をもともと知っている人からするとあまり刺激的ではなかったかもしれないが、個人的には「こんなに簡単にたちあがるのかァ」という発見があったので良かった。デモ慣れしててすごいなぁと思った。

Electron に関しては触らずに放置していた負い目も合ったので家に帰って実際に手を動かして試してみた。

QAタイムでは Electron 絡みでなく Slack 社に関する質問をしてよいものだろうか…ともぞもぞしてたら終わってしまってちょっと後悔。

マイクロチームでの高速な新規開発を支える開発・分析基盤

グッと来たところは以下です。

データドリブンってこういうことか…。

いらないと思われる機能をガシガシ消したい引き算の気持ちは常にあるのだが、プロダクトの引き算をするのにも裏付け・論理が大事なのでその辺にも強くなっていきたい。

RDBアンチパターンリファクタリング

ベストスピーカーを受賞したトーク。会場の空気が前のめりというか、あまりの話の深さに会場全体が集中している感じだったのでこれは取るだろうな〜となんとなく思ったりしていた。

時間がかかるからこそ戦略を立ててやっていかないといけない…というのは業務でもひどく実感しているところがあり、それが以下の質問だった。

RDBアンチパターン リファクタリングについて話をしてベストスピーカー賞を取ってきた #builderscon - そーだいなるらくがき帳にも書いていただいて大感謝というほかない。早速試してみないと。

僕はMongoDBを本番で採用したことが無いけどFDWというPostgreSQLの機能がありますよってのをご紹介しました。FDWは要は他のDBのテーブルをPostgreSQL自身のテーブルのように見させる機能です。MySQLやOracleDBもあって便利なのでぜひ遊んでみて、試してみてほしいです。

Factory Class

Kickstarter で資金調達してキーボードを作ってる Jesse さんの話。

生産を依頼する工場選定に関する話題がメインだったのだが、中国工場の裏話が実話ナックルズというか、まぁとにかく"闇"という趣だった。

前日の講演 “Desktop Apps with JavaScript” で質問できなかったのをちょっと後悔していたのでこのトークでは英語で質問してみた。「中国での工場選定の他に、プログラミングやデザインでの課題はあったか?」という質問の答えが「プログラミングは本業で20年もやってるから大丈夫、助けてくれる人も多いし」という感じで強かった。

英語で質問するのはそんなに難しくなくても自分はリスニングに難ありなので回答を100%理解するのはあきらめて聞くのは同時通訳の方に頼ったりした。

帰り道で rebuld.fm に出演していた回を見つけたので今度聞いてみる。

rebuild.fm

ランチ

日吉の学生街がめちゃ懐かしかったので、申し訳ないながらも弁当をいただかずに外食した。

ハマトラ。竹炭入りの麺が黒い。昔はこってりした家系によく行っていたが今となってはあっさり塩そばを好むようになってしまった

f:id:ohbarye:20170806204724j:plain

とんかつ和栗。学生の時は無かった気がする。蒲田の有名店「檍」系らしい。林SPFポークは塩で食べるのがおすすめらしくカウンターに4種類もの塩が置いてあり、塩派にはたまらない

f:id:ohbarye:20170806204733j:plain

キャンパス

懐かしくて死にそうだった、次回も日吉だと個人的には嬉しい

f:id:ohbarye:20170806205422j:plain f:id:ohbarye:20170806205400j:plain f:id:ohbarye:20170806205413j:plain

最後に

ディズニーランド的なアレか…

builderscon 2017 - day 2 メモ

builderscon 2017 - day 1 メモ - valid,invalid に続いて2日目のメモ。まとめや感想はあとで。

※ 内容については間違っている可能性あり。


小さく育てるコンパイラ

  • コンパイラは実装量が多い
  • まずは既存言語のサブセット->自分が欲しい機能を足す->オレオレ構文に置き換えていく
  • なぜ構文が最後?どういう構文が良いかは動かさないとわからない。まずは動くものを作るのが大事
  • 既存言語は既に動いているので実装は絶対にできる。パーサの実装をまずは流用できる
  • MinCamlベース(小さい実装なので参考にしやすい)でLLVM
  • 今回欲しかった多相型

OSSの引き継ぎ方

  • Rubyの状況:2013年頃に初期の開発者がRustとかGoに行ったりしてしまった
  • 利用者としてできること contribute, fork, re-implementation, take over
  • 引き継ぎの始まり
    • イシュー/Email/DMで「引き継ぎたいんですけど」と言うと結構引き継がせてくれる。twitterはダメ
    • READMEで募集してるのもよく見る
    • 作者じゃないのに pull request にコメントしまくったりすると「お前やれよ」となったりする
  • rake
    • Jimが他界してしまって放置されることになった
    • これもhsbtさんが引き継いだ
    • まずhoeからbundlerへ。標準ボイラープレートを使って、テストや開発が簡単にできるようになっていれば参入障壁が下がる
    • 1.9のサポートを切ったらbreaking changeで色々なライブラリやツールから苦情が…
    • migration path をちゃんと用意すればよかった。うざいぐらいwarningだしたりとか
  • psych
    • Ruby側を変更するとJRuby側が壊れたりするのでCI入れたかったがownerしか設定できない
    • aaron からownershipもらうためにカンファレンスで直接はなした
    • セキュリティイシューも何回か踏んでいる。詳しい人が身近にいると便利
  • 「リリースすること」がとても大事
    • リリース権も一緒に渡したほうがよい
  • rubygems/rubygemsrubygems.orgではない)
    • 2015年にPMがいない状態でどうやっていくのか不明瞭になった
    • RubyTogetherという組織が引き継ぐことになった
    • その組織のbundlerチームが入って元々のコミッターが全員リムーブされた
    • ruby本体の変更を取り込んでもらうのが超大変

Factory Class

  • もともとはプログラマ
  • キーボードを作るのにそんな大変じゃないだろうと思っていた、一ヶ月ぐらいとか
  • 最初のプロトタイプに興味を持ってくれた人がいてkickstarterで300$ 50個売ろうと考えた
  • 2000個作ることになっていきなり大変になった
  • いろんな工場を回った、台湾、中国、日本(高かった)
  • 結果、Shenzhenで良い会社を見つけたのだがチームの営業員がやめてしまった
  • その会社の連絡がぜんぜんこなくなり、9ヶ月たって辞めた営業からキャンセルになったと連絡
  • その1ヶ月後に有名な企業から新しいキーボードが出た…何か裏側であったのかも
  • 反省としては、その工場からすると自分たちは最小顧客だったということ
  • 中国の起業とやりとりするときは非常に対面やマナーが大事

質問

  • 工場選定以外でプログラミングやデザインの問題はなかったか?
    • プログラミングは自分の領域なのであまり辛いことはなかったし、いろいろ助けてくれる人もいた
    • デザインについては外の人に頼んだりして結構うまくやってくれた
  • テストについて
    • 落下テスト、電気系統のテスト

The Evolution of PHP at Slack HQ

  • HHVM + Hack
  • SlackのDAUは半分が北米、次いでUK, JPの順
  • 急成長の中で大きいチームでも使えるようにする苦労
  • Jan 2017 Enterprise Grid リリースで大チームにも対応
  • 少チームでも大人数チームでも同じ体験をしてもらう必要がある
  • PHPを使っていると驚かれるが、世の中のスタートアップが使ってきたものである
  • Slack のリードプログラマfacebook出身でHHVMのエキスパートでもある
  • PHPは…正直ダメな子です
  • 2015年、SlackはOOPしてなかった…
  • 大きいチームで使われることになってパフォーマンスの問題が出てきたときの答えがHHVM
  • hack
    • バックグラウンドで走る静的型チェッカー。ただしPHPの特色である開発のスピードは落とさない
    • 後方互換姓あり
  • Route53によるカナリアリリースでパフォーマンス改善を確認できた
  • あるときHHVMのバグがあって大顧客のPixarに迷惑をかけたことがあった
    • パッチをあてられるような勉強も必要
  • レスポンスタイムが半分ぐらいに

builderscon 2017 - day 1 メモ

以下、所感混じりのメモ。まとめや感想はあとで書く。

※ 内容については間違っている可能性あり。


Desktop Apps with JavaScript

マイクロチームでの高速な新規開発を支える開発・分析基盤

  • LUCRA
  • gunosy で得られた知見を使って記事のグルーピングを機械学習でやる
  • 最初から分析できる環境が欲しかった
  • うまくいったポイント
    • やるやらないの切り分け
    • Gunosy の基盤の強さ、gunosy はGoの使用歴がかなり長い
  • やるやら基準
    • アプリのコンセプトを検証する
    • 大事なのは記事が見られて、検証・運用可能な基盤をつくること
    • やらないこと:Android、リファクタ、フォロー、お気に入り
  • gunosy/go という共有資産があり、OpsWorksでデプロイすればAPIサーバがすぐできる
  • 記事分類・生成に必要なAPI
    • クローラー、カテゴリ分類器、タブジェネレーター(特定カテゴリの記事一覧を生成する)
  • 2段階キャッシュ(ローカル、リモート)
  • マイクロアーキテクチャをやりすぎない
  • 分析
    • 大量のログを取得している、トップビューだけで10以上
    • 分析環境はRedash
    • 運用開発問わずチーム全員が分析用SQLを書く
    • Slack にKPIを通知
  • 分析結果の理由

    • ブランドイメージを追求したいからと言って、根拠なく「ファッション」「コスメ」を推すという意思決定は絶対にしない(データで確信が持てない施策は極力許さない)
    • 高いCTRやRRが期待できるプッシュ、機能通知しかやらない
  • ログ設計を最初からうまくやるには?

    • Gunosy にはもともと似たようなアプリがあり、ある程度ログの型が決まっているのでだいぶやりやすい
  • プロダクトとログの乖離
    • 開発者も分析基盤に触るが、専任のチームがいる。CSの博士号を持っていたり英語論文を読みまくったりするかなり高度な人たちが分析に責任を持っている。また、彼らの提案を受け入れる土壌がチームにある

複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ

  • 何も考えずに作ると何が起きる?
    • DOM をコードで作ってるとか…
    • 巨大なものを一目で理解するのは不可能
  • 分割する?機能、画面、リソースなどの単位
  • Presentation Domain Separation
    • Presentation と Domain をワケましょうということしか言っていない
  • MVVM
    • MVVM で model が VM を持っても良さそうだけど…?実際にやるとDOMのテストとかがModelのテストに入ってきてつらい。オブザーバパターンで依存関係を整理したりできる
    • PDS は model 設計については何も言っていない
  • layered architecture
    • モデルを3層にする。アプリケーション、ドメイン、インフラストラクチャ
    • アプリケーション層:プレゼンテーション層との窓口
    • ドメイン層:ディレクタ的関心。ドメイン層の設計は非プログラマでも読める感じだと良い
    • インフラストラクチャ層:技術的関心。プラットフォームや外部APIに依存した実装をドメインに書くと汚くなってしまうからインフラストラクチャ層に追いやろう
    • 依存関係はP->A->D->I だけどテスタビリティが高いのはDだからそこに依存したい
  • clean architecture

    • テスタビリティの高いドメイン層を中心に依存する
    • この考え方は具体的なアーキテクチャではない
    • 実現方法は、インフラストラクチャ層をDIする、プレゼンテーション層をモデル層が監視するオブザーバパターンなど
  • 状態管理の問題

    • ドメイン層に状態が散らかりすぎる
    • CQRS(コマンドとクエリを分ける)
  • バリデーションはアプリケーション層に書いている。コマンドというクラスを作って「アプリケーションへの入力が正しいかどうか」を判定する。(モデルに持つのがよくあるパターンだけど。フォームクラスとかは?)

  • 悩んだら原則に立ち返る

RDBアンチパターンリファクタリング

  • 不適切なデータベースがコードやサービスの成長を止める
  • データベースリファクタリングおすすめ
  • データベースの不吉な匂い
    • データは生き物、どんどん追加されていく
    • 積み木と同じなので初期設計に失敗すると仕様変更ができない
  • 何をリファクタするかはシステムによる

    • シングルアプリケーション vs マルチアプリケーション
    • シングルアプリケーションのときはDBマイグレーションが活きてくる
    • マルチアプリケーションは難しい、片方は止められなかったり…
  • データベースリファクタリングはすごく長いスパンになる、だから戦う準備が大事

    1. 抽象化。データベースアクセスには永続化フレームワークをはさむ
    2. データは変化する。モニタリングして変化の影響を知る必要がある
    3. テスト。
    4. 覚悟。DB停止はありえる。エンジニア以外がサービスの停止可否を握っているなら政治力も必要
  • 手間も時間もかかるからころ検討が大事。そのデータベースに価値はあるか、費用対効果は、いつやるべきか

    • 対象選定
    • リリース時期を決める
  • 変更前・中・後すべてのテストを行う

  • DBは影響範囲が広いので切り分けできるように小さな変更を繰り返すことが大事

質問

RDBパターンでRDBでないのを聞くのは恐縮 MongoDB MongoDBをすてるマイグレーションパスについて考えている 少しずつデータシンクして切り替えていく アプリケーションもMongoに合わせたコードになってしまっている マルチアプリケーション 一度に億単位のデータ全部をmigrateするのは無理

  • JSON
  • FDW (foreign data wrappers) postgres のように mongodb を扱うことができる、テーブルのように

QR code

  • QR code はデンソーが発明
  • 仕様書もある
  • 実は16個に分割できる
  • ヘッダーに全部でいくつ、自分が何番目かを持っている – 医療用カルテで1つだけだとエラーが起こりやすいので必要だった

狭いマンションにもドラム式洗濯機は置ける

結論

3方向をぴったり壁で囲まれた64cm×64cmの一般的な防水パンにもドラム式洗濯機が置くことができる!!!

f:id:ohbarye:20170723134341p:plain

f:id:ohbarye:20170723134004j:plain

ドアの開閉もできる。

買ったもの

kakaku.com

公式ページ: メーカー希望小売価格は税込246,240円。高い!!

幅639 × 奥行600 × 高さ1050mm

選んだ経緯

id:taketyan引越・同棲 1 年目の 2016 年に買って良かったもの | Born Too Late 記事で読んだ TW-117X3L の後継機、TW-117X5L が欲しかったのだが、幅645 × 奥行750 × 高さ1060mm を設置しようとすると壁を破壊しないといけないので諦めた。

調べるとプチドラム/ミニドラム式洗濯機というのがあるらしいとわかり、その種の中で最も評価が高かった Cuble NA-VG710L にした。

価格

トータルで152,037円かかった。

注文明細

本体価格は135,000円だったが、延長保証や取り付けなどの手数料もかかった。古い洗濯機のリサイクル回収代はもとから含まれていたようだ。

******************************************************************
 ご注文商品明細
******************************************************************
★洗濯機 パナソニック NA-VG710L  ★延長保証加入★(商品コード:1207582)
  無料搬入商品   取付希望    リサイクル回収:1個
 ¥135,098(税込) × 1 個 = 135,098 円

リサイクル回収運搬  (商品コード:99992002)
 ¥3,240(税込) × 1 個 = 3,240 円

---------------------------------------------------------------
小 計 ¥ 138,338
延長保証料 ¥ 6,755
送 料 ¥ 0
取付料 ¥ 3,240
手数料 ¥ 1,220
===============================================================
合 計 ¥ 149,553

リサイクル券

エアコン、テレビ、冷蔵庫・冷凍庫、洗濯機を捨てる際には家電リサイクル法にもとづいて料金を支払わないといけない。今回は料金郵便局振込方式だったので新しい洗濯機の配送 兼 古い洗濯機の引取が来る前に郵便局に行ってリサイクル券を買う必要があった。

券を購入するには捨てたい洗濯機の製造業者と品目が必要だと書いてあるが、とりあえず型番だけメモして行ったら調べてくれた。

この券の購入に2,484円かかったのでトータルで150,000円を超えてしまった。

感想

購入について

よくわからない家電ECサイト勘弁してくれ〜と思っているものの、数万円単位での値引きや取り付けとか引き取りの依頼を含めると使わざるを得なかったのが辛いところ。

注文から4日で届いたのは早くて嬉しい。

製品について

とりあえず洗濯&乾燥を試してみると4時間30分ほどで洗濯〜乾燥まで終わった。これまでの縦型洗濯機だと計5時間(洗濯1時間 => 洗濯機の乾燥1時間 => 浴室乾燥機で3時間)かかっていたのとあまり変わらないが、わざわざ干さなくてよいのが最高。

騒音が気になるかもと思ったが壊れかけの旧洗濯機より遥かにマシだった。洗濯機からドアを一枚挟めばまったく気にならない。

また、製品のデザインがかっこよい。洗濯機の前でぐるぐる回る洗濯物を何も考えず眺めていたら10分ぐらい経過していたので暇つぶしにもおすすめだ。

最近仕事中に Apple Music で聞いている音楽 - むかし聞いていたけど最近どうしてるんだろうシリーズ -

むかし聞いていたけど最近どうしてるんだろうシリーズ

Arts & Crafts になぜか偏った

新しいアルバム出しているんだなーと気付いてそのまま聴ける Apple Music 最高

The Most Serene Republic

www.youtube.com

Dirty Projectors

www.youtube.com

Los Campesinos!

www.youtube.com

Broken Social Scene

www.youtube.com

Stars

www.youtube.com

Ra Ra Riot

www.youtube.com

『日本語という外国語』読んだ

日本語という外国語 (講談社現代新書)

日本語という外国語 (講談社現代新書)

あらすじ

日本人が考える「日本語」と外から見た「ニホンゴ」は違います。「どこが難しい?」「意外な魅力とは?」「どう教えるか?」豊富な日本語教育経験から語る、日本人のための日本語再入門。(講談社現代新書

日本人が義務教育〜高等教育で学ぶ「国語教育」ではなく、日本語を母語としない人向けの「日本語教育」にフォーカスした本。

面白かった点

日本語は日本人が思うほど難しくない

「第4章 外国語として日本語を眺めてみると」より。

昨日、私は八時におきました。九時に、朝ごはんを食べました。朝ごはんは、トーストとサラダでした。おいしかったです。十時に電車で銀座へ来ました。デパートで黒いコートとストライプのネクタイを買いました。

外国人がこのように話すのを見た日本人はたいてい「日本語上手ですね」と感心する。しかし、著者によれば「一日に三時間、月曜から金曜まで学べば、早ければ一ヵ月、どんなに遅くても二ヵ月で、このレベルまで達する」という。

国語教育を思い出し、五段活用やらサ変やらカ変やらを思い浮かべる日本人にとっては「そんなはずない」と言いたくなるかもしれないが、「です・ます」にフォーカスして学ぶ限りでは日本語の動詞は非常に簡単なのだと。

日本語表現のゆたかさ

上記のような簡易さがある一方で、話を最後まで聞かないとわからないような複雑な表現も多々ある。

とりわけ、「第5章 日本語表現のゆたかさを考える」で挙げられていた例文、「山田選手はかなり練習させられていたらしいよ」の一文の述語の説明は白眉だった。

「させられていたらしい」という述語だけで以下の4つの情報を表現している。

  1. 過去のことである(〜た)
  2. 本人の意思とは反していた(〜せる)
  3. 一過性のことではなく継続していた(〜ていた)
  4. 話し手にとってこの件に確証はない(〜らしい)

テンス・アスペクト・ムード

聞きなれない文法用語があった。テンス(時制)はまだしも他の2つは何だろう。

アスペクト

アスペクトは「ある動作がどの局面にあるか」を表現する文法形式。「相」ともいう。「食べ始めた」という言葉は以下のように分解できる。

アスペクトを変えることで「食べいた(進行)」や「食べ終えた(完了)」などの表現が可能になる。

ムード

ムードは「単なる事柄を表す以外の話し手の気持ちのありよう」について述べる文法形式。言語学では「法」と呼ぶ。

これを用いることで「働くつもりだ」「食べるらしい」といった表現が可能になる。

ここまでの知識を総動員すると、「させられていたらしい」は結局以下のように解析可能となる。

  • 「させ」: 使役
  • 「られ」: 受け身
  • 「てい」: 進行(アスペクト
  • 「た」: 過去(テンス)
  • 「らしい」: 推測(ムード)
  • 「よ」: 判断(ムード)

感想

日本語教育に関する内容が中心の本だが、これに携わらない人や興味のない人であっても、普段意識することのない母語言語学面での分析からは上述のような面白い知見を見つけることが出来ると思う。

とりわけ、日本語を話したり学んだりしている外国人と普段から接している人にとっては彼ら彼女らがどのように日本語を捉えているのか、どのような点に躓きがあるのかを理解する一助となるので、一層お薦めできそうだ。