Questions and feedbacks
Blogに当日いただいた質問等をまとめておりますのでよろしければどうぞ！☺ http://blog.toshimaru.net/rdm2018-active-record-anti-patterns/
Like(1)
現実として、ESLintやRubocopを流すときはどうしているのでしょう？ ホストにいれて動かしているのか、CIに任せている？
懇親会中にも口頭でお話しましたが、Ruby のシンタックスチェックについては自作の language server を使っています。 https://github.com/mtsmfm/language_server-ruby
ただ、ESLint や Rubocop については CI や、手動コマンド実行に頼っているのが現状です。 Rubocop については language server で対応中なのですが、コードアクションへの対応などで手が止まっている段階です。
Like(0)
Docker-Composer開発環境で複数のRailsアプリケーションを開発していると、プロジェクトAで使ってるポートとプロジェクトBで使っているポートがconflictしてしまうといったことがよく起こります。
発表後にも口頭でお話しましたが、https://github.com/mtsmfm/yaichi をリバースプロキシとして前段に 80 番ポートと3000番ポートを繋ぐように起動しておいて、プロジェクト A、B は 3000番ポートで起動するルールにします。
すると、yaichi がプロジェクト A も B 両方のネットワークに強引に自分を繋ぎにいくように作っているので、<container-a>.localhost と <container-b>.localhost で接続できるようになります。このとき、A も B もホスト側には直接ポートを露出しないのがミソです。
Like(1)
みなさん、ありがとうございました！ 個人的にはちょっと最後まで着地点を迷ってしまい消化不良の発表になってしまったなあとクヨクヨしてたのですが、参考になったとのお言葉をいただけて救いになりました。 もう少しわかりやすくブラッシュアップしたものを、今週中くらいを目処に、多分、きっと、補足として書きたいと思っております。 よろしくおねがいします！
最後に、Railsdm楽しすぎて、本当に最高のイベントでした。登壇させていただいてとても光栄に思っております。 ありがとうございました！
Like(2)
みなさんコメントありがとうございます！！ 回答させていただきます（大変お待たせしましたmm
発表して頂いた内容とは少しずれてしまうのですが、スライド中に挿入されていた手書きの画像？は何を用いて作成されているのでしょうか？
とてもアナログな方法でアレなのですが…、紙に筆ペンで描いてiPhoneで撮影して、Photoshopで加工（グレースケール化 → トーンカーブで背景を白に飛ばす → 乗算にして背景色と合成）みたいな感じにして作ってます。
ロゴ作りの時に「こういう要素・条件は最初に出しておいた方が良い」というものがあれば知りたいです。 ＃ 例えば、スライドにもあったTシャツなどにも使うなら前からこういう条件を付けておいた方が良い、など
ああ、そうですね、必要ですね。 もう少しまとめて、改めて別エントリに補足を書こうと思いますが、 デザイナーさんに読まれるかどうかは別として、基本的に現時点で考えていること、見えていることは全部書いておいた方がいいと思います
- ロゴに必要な要素（文字等）
- サービスコンセプト
- サービスの概要
- 使いたい用途
- 雰囲気を表すキーワード
- ラフスケッチの画像
- 参考事例の画像
ただ、savanna の例ですと、"business", とか "project" とか書いてあるせいで、ネクタイをしたトラのデザイン案なども結構来たので、そのへんの細かいニュアンスの誤解の調整を、個別のフィードバックで「ネクタイ取ったほうがいいです」みたいにして調整する感じになります。
コンセプトを決める上で、これって価値観へのカウンターになるんだろうか？とか迷ったりすることはありますか？ もしあればそんな時はどうしているか、または工夫していることなんかあれば、参考までに教えていただきたいです。
おお、なるほど！自分はあまりその迷いは経験がないなあと思いました。 なぜかというと、自分の作りたいものは何のカウンターになるのか？みたいなのを結構最初の方に考えているからだと思いました。 そうやって説明すればよかったんだなとこれ読んで思いましたmm ちょっと時間を下さい。スライドの説明を、もうちょっとうまく書き直してみたいと思います！
まつもとさんによる「楽しいプログラミング」について言及しているものとしては、1999年のJUSのworkshopの資料とかにもあるので、かなり初期からのRubyのコンセプト（この資料では「Rubyの信条」と言ってます）だったのでした。 https://www.jus.or.jp/workshop/ruby/ruby-report/ws1.pdf
ありがとうございます！！こんなに明快に説明されている資料があったのですね…勉強不足で申し訳ありません！ これを参考に少しブラッシュアップしたいと思います。 「楽しいプログラミング」自体は間違ってなくてよかったです！
Like(2)
懇親会等で、各質問者の方に直接回答させていただいたのですが、 回答を見たいという要望がありましたので再度ここに回答していきます！
もし、エンジニアに依存する他チームがなかなか自立してくれない、しかしそのチームがワークしないことには事業として危ぶまれるといった場合にはどのようなアプローチを取ることが望ましいと思いますか？
割とここは他チームがエンジニアの担当範囲だろうと思われていたり、逆にエンジニアが他チームの担当範囲だと思っていて…みたいなことが相互に起きてしまっている場合があるかなとおもっていて、 それぞれに期待することをすり合わせるのがいいのかなぁ、と思っていたりします。
エンジニアじゃない方からすると、システムに近い部分は自分の判断でやって大丈夫なのか？と不安になっているから、お願いしてきているのかも知れないです。 自分のチームで解決できる方が話も早いとおもうので、解決の仕方を伝授してやってもらうなどもありかも知れないです。
—
暗黙知が特定個人に蓄積し続ける状況を組織的個人的に対処していく取り組みのなかで、「いまいちだったなあ」とか「うまくいかなかったなあ」といったようなことがあれば教えてほしいです。
カスタマーサポートの人からの調査・修正依頼のチャンネルに対する対応を、よく気づく2人ぐらいがやっていた時に、 これは負荷を分散しないと行けないということで、 一次対応者を全エンジニアから毎日ランダムに2人選ぶ、という試みをやっていたことがありました。
当時よく起きていた問題や頻度を全員が把握できて、ドキュメンテーションや根本解決がすすんだという面はあったのですが、 どうしても差し込み作業になってしまうため、2人でも早く反応する人がでてきて偏りが生じたり、 しびれを切らしたよく反応する人が出てきてしまったりという現象がおきました。 また、カスタマーサポートからの依頼のドメイン範囲が広く、10人以上の中で2人選ぶため、調査・修正に対する知見が個人に厚い状態で貯まりづらい、という問題がありました。 （そのため、難易度の高い問題はどうしても一部のメンバーへエスカレーションされてしまう）
現在はドメインごとに担当者を置いているので、知見が貯まりやすい状態になってきました。
—
自身がバス因子であることを自覚したのはどういうことがきっかけですか？
スライド中にもあったように、いないとやばいといわれることが増えたこと （なにか問題に対する一次対応速度が早いのと、みんなが把握していないことを知っている事に気づいた時）
自分の仕事が本当に回らなくなって、間に合わないですごめんなさいというコミュニケーションを取りまくっていて辛くなってきた時に、ほぼ自分だけが対応している緊急対応が連発した時とかですかね…。叫んでました。
Like(4)
@expajp 特に授けていません。テストが足りないような場合はコードレビュー時に指摘が入ります。以前は、カバレッジを測定していたは、95%程度を保っていました。現在も、90%以上は保てていると思っています。
Like(0)
@momoshu 回答ありがとうございます！
Teleport、知りませんでしたがすごく良さそうですね。弊社は開発者があちこちのシステムに接続して作業する必要があるのでKubernetes関係なく役に立ちそうです :)
k8sのセルフマネージ感についてはなるほど確かに。。。という感じですね。
この手の新しいものを導入していくときは、社内にかなり下の層までデバッグできるくらい詳しい人がいないとトラシューできないので、今の段階ではセルフマネージドで自分達でメンテするのが手間はあるけど想定外リスク対策とかを考慮するといいのかな、と感じました。
Like(0)
trailblazer という gem に対してどのような印象を持っていますか？
Like(0)
コメントありがとうございます！ 各領域1人ずつでコードレビューができない、という状態をちゃんと理解できてないので複数回答させてください〜
エンジニアが1人なので、コードレビューしてもらうにはどうしたらいいか、ということですかね？ もしそうであれば、誰かにできる人にレビュアとして入ってもらうことが多いです（万葉だと社内のメンバーに入ってもらうんですが、他社のスタートアップなどの話を聞くと、知人や技術顧問などにしてもらっていますね） できれば、アプリエンジニアとサーバーサイドエンジニア間でもできるといいなと思いますが、やる気があったとしても、距離が大きくてなかなか難しいことが多いですかねえ（人にもよるので難しいんですが、結局双方絡むことになるので、全部でなくてもいいですが、ある程度見れるようになっていくといいなあと思います。）
各領域ごとの作業をレビューしあいたいみたいなことですかね？ もしそうであれば、esaなどの情報共有ツールを使って、アイデアや仕様を相談・確認したりします。 随時、相談・確認しながらやりますが、遅くてもイテレーションMTGなどでキャッチアップして、なるべく知識を集めて、熱いうちに鍛えるみたいなイメージです。動くものの場合は、GitHubのPRなどに動画gifなどを添付して、コード以外でわかるようにしたり、動作確認方法などを描いて、動作のレビューができるようにしています。
その他 異なる領域が含まれるチームで作業するときは、それぞれの作業がバラバラになりがちなので、まとめる役をやることが多いですね。（ディレクターがいる場合はディレクターの仕事だとは思いますが）
というので答えになってますでしょうか(?_?)
Like(1)
導入して失敗したなあ、という技術はありますか？
あまり思いつかなかったのですが、Bowerなど導入時点ではある程度使われていたものが時間が経ってからオワコンになってしまったという事がいくつかありました。そういうのを前もって完全に予測することは困難なので、手遅れになる前に負債を返しておくことを意識しています。
[会場での質問] esaをリリースしてから嬉しかった瞬間を教えてください
- ユーザーサポートをしていて、「ありがとう」と言われた時
- ユーザーサポートに感動したユーザーさんがそのことをblogの記事に書いてくれたこともあった
- イベント等でユーザーさんに会って、「esaいいね」と言ってもらえた時
- 新しくリリースした機能にたくさんstarが付いた時
- サービスが黒字化したとき
- webでesa関連の記事を見かけた時
等々
Like(1)
Railsコミッタ・メンテナとして「これはやりたくないけどやったら需要あるんじゃない？」と思う様なことはありますでしょうか？
※ 例えば https://railslts.com/ なんかはRails2系と3系のサポートをやっているプロジェクトの様です。
自分達は絶対やりたくはないけど・・・みたいな気軽なネタでもぜひ！
Like(1)
何を作るか、何が必要なのか、はどう決定してましたか？
Like(0)
開発、運用工数は会社の仕組みとして明示的に確保していますか？ 個々人のボランティアですか？
Like(2)
この手のツールのサーバ代とかもサークル費用で運用できたのですか?
(追記)発表内で回答済でした
Like(2)
導入して失敗したなあ、という技術はありますか？
Like(0)
アンチパターン名の出典を教えてください
Like(1)
Railsで今後10年、まだ戦っていけると思いますか？また、今後10年Railsで戦っていくために、必要なことって何でしょうか?
- 技術的な課題
- コミュニティーのありかた
- Rubyに求めるもの
- 世の中の情勢
いろいろな視点があると思いますが、何でもよいです。
Like(13)
プロジェクト立ち上げの初期でのモデル設計を行う際にどのようなコミュニケーションを取られていますでしょうか？ 同じ場所にいないのでホワイトボードに書きなぐって設計を進めるということが出来ないのですが、どうされていますでしょうか？ 又、立ち上げ時の共通認識の成熟に配慮されていることとかありますでしょうか？
Like(2)
現実として、ESLintやRubocopを流すときはどうしているのでしょう？ ホストにいれて動かしているのか、CIに任せている？
Like(1)
せっかくRubyを使っているので、コンパイルしてシュッとコードを生成するのではなく、黒魔術的に定義書けばOKみたいな仕組みだとうれしそうですね。
Like(0)
ちょっと発表テーマとはずれるかも知れないのですが、Docker-Composer開発環境で複数のRailsアプリケーションを開発していると、プロジェクトAで使ってるポートとプロジェクトBで使っているポートがconflictしてしまうといったことがよく起こります。
具体的に良くあるのはRails serverのポートやRedisのポートがcompose単位で被ってしまうといった事象なのですが、こういうときにエイヤでdocker-composeのポート番号を変わらないように修正しても、docker-compose.ymlにない部分（rails側のconfigとか）にポート番号定義が隠れていて動かない、など辛いことが多いです。
もちろん作業プロジェクトを切り替える時にdocker-compose downしろという話ではあるのですが、それも面倒なので何か良い解決方法があればお聞きしたいです。
＃会場にいるのでもし説明難しそうなら呼んで下さい 
Like(0)
gRPCも含めて、HTTPのコンテキストでRPCって言ったとき、同期呼出しはできるのでしょうか？ 非同期でしか結果を受け取れないのにRPCって言うのちょっと抵抗あります。
あ、別にブラウザだけを想定してるわけではないのですね。ちょっと勘違いしてたかもです。
Like(0)
知性の計り方
これはとても示唆に富んだ質問だと思います。 知性を計るには、その人が説明して、説明を受けた人が知性を得ることができるかどうか、になると思います。 ただ、これをどうやって計ればいいかはまだ答えを持っていません。テスト駆動開発の心意気で言えば、これを考えられれば知性の獲得がしやすくなりますね。
よい質問をありがとうございます。考えてみます。
Like(0)
Copyright © 2018 Yoshiyuki Hirano
紹介されたアンチパターンについては、誰しも やらかしてしまった体験 または レビューで見逃してしまった体験 ありそうですが、gunosy社でのそういった失敗したエピソード（トラブル事例）と、それを防ぐために、チームでどういう対策して解決したのかに興味を持ちました。
Like(0)