00:04
はい、8月16日、火曜日ですね。
地獄朝9時8分もありました。
ちょっと、朝寝坊してしまったんですけどね。
はい、おはようございます。
himehimeのkkeethことくわはらです。
じゃあ、本日も朝活を始めていきたいかなと思います。
えっとですね、今回は、
えーと、珍しく日本語の記事2つですね。
もうちょっと読んでいこうなと思いました。
まあ、あのー、ざっくり禅の方を読んでたんですけど、
禅のポエムカテゴリーの記事、僕全然読んでなかったんですけど、
軽く眺めていったら、意外と面白そうなのがあったので、
その辺ちょっと読んでみたくなったって感じですね。
はい。
おはようございます。けんじさんですね。
今日もご参加いただきありがとうございます。
はい、えっと、
エブさんですね。ご参加ありがとうございます。
まあ、いったんざっくり、タイトルのある記事2つを読んでいこうと思います。
ちょっと、ポエム調なので、あのー、
何か技術的な学びがあるかちょっとわからないんですけど、
まあ、1回、読んでみたいなと思いました。
じゃあ、いきましょう。
1つ目ですね。技術記事を書く人を大事にしようという記事です。
はい。えっと、TLDRとしては、
まあ、タイトルの通りですね。
技術記事を書いて公開してくれる人は貴重な資源なので、
なるべく潰さないように大事にしましょうというところだそうです。
はい。じゃあ、入っていきたいと思います。
はじめにですね、プログラムを書いてて、
何かわからないことがあれば検索をすると思います。
すると、世の中にはごく少数の役に立つ記事と、
大多数の役に立たない記事があることがわかるでしょう。
役に立たないという言い方をするとちょっとあれかもですね。
その人、書いた人本人としては役に立つかもしれないし、
その人の学びの途中段階だったりするかもしれないので、
この筆者の方にとっては役に立たないかもしれないですけどね。
はい。役に立たないというか、
自分の欲しい情報が手に入らなかったとか、
その時に刺さるものじゃなかったみたいな、
ちょっと言い方が難しいかもしれないですけどね。
そんなニュアンスだと思って読んでいきたいと思います。
その役に立つ記事を求めてネットの海をさまよっていると、
あれ、またこの人の記事だと思うことがよくあるでしょうと。
例えばC++の言語仕様を調べていると、
あの人のビム関連を調べていると、
あの人の、また語言語ならあの人の、みたいな記事を見つけることがあるでしょうと。
逆に言えば、ある程度限定された分野において体系だった知識があり、
わかりやすい記事を書いてくれる人というのが
極めて貴重な人材だというふうになりますと。
しかし、そんな強強エンジニアも初めから強かったわけじゃないですよと。
当然のことながら、新人時代があって、よくわかっていない状況があって、
うかつな記事を書いたりしたこともあるでしょうと。
さて、新人がうっかりうかつな記事を書くと、
中にですね、主に中継エンジニアから寄ってたかって、
叩かれたりとか炎上することもありますと。
例えば動かなくて悩んでいたけど、こうすれば動きましたと書かれた記事が
SKLインジェクションの脆弱性を持っていたりとかすると、
もちろん燃えることになりますと。
でも当然のことながら、間違っている記事や危険な知識については
修正された方がいいのは当然だと思いますが、
03:02
それと同時に、ネットに何か記事を書く人というのは
それだけで非常に貴重であり、成長すれば有益な記事を書いてくれる可能性がある
資源だというふうに言えますと。
ということも、しかも同意も得られることだと思います。
本校はそういう人は潰れないように守りましょう。
また技術記事を書くことを奨励しましょう。
というようなことを主張するポエムになります。
続いてのセクションとして、検索やトレンドの問題と書いてますね。
間違っている記事はさておき、たまに用語の使い方がおかしい記事だったり、
中身のない記事について検索空間を汚染すると反発する人がいますと。
技術記事を誤信ブログではなくて技術記事投稿サイトに投稿することが多くなった現在、
そのサイトの検索ランクが非常に高く、何か検索したときに
対して中身のない記事がおそらくそのサイトにあるがゆえに検索上位に来てしまうということがよくあることです。
またよくもある話題になった記事というのはトレンドに乗ることがあります。
多くの技術記事投稿サイトというのはいいねの仕組みを持ち、
多くの人が短期間にいいねした記事というのはトレンドといって
そのサイトのトップページに掲載されることが多いです。
するとあまり一般的ではない用語の使い方をしているが、
その中身が分かりやすかった方はその用語がキャッチーだった等の理由で
トレンドに乗り多くの人の目に触れたりします。
するとはてなブック等で言及が増えホットエントリーとして
さらに多くの人の目に触れます。
するとその用語の使い方を苦々しく思う人が強い口調で批判コメント書く
なんてことが起きますねと。
よくある話だしよく目にしますねと思います。
私は間違った知識の訂正すること自体はまずいと思いませんが、
間違った記事を書くなとかその中身のない記事を書くなといった論には賛成できません。
特にその理由が検索上位に来てしまうから、
さらに被害者を増やすからといったものであればなおさらです。
まずい知識が検索上位やトレンドに乗ってしまい
間違った知識が再生産されてしまうというのは
検索エンジンやトレンドの仕組みの問題であって
執筆者の責任するべきではないと考えるからです。
ここに関しては完全に同意だなと思いました。
そもそも学んでいる途中のものを書いたりとか
書き出しの方とかは確かに間違っていたり
中身のない記事を書くかもしれないですけど
それを書くなという否定する権利が何であなたにあるんだと
ちょっと怒りの感情も出たりはしますね。
人の学びを止めるのはよろしくないと思うんでね。
もちろん読む人にとっては自分の時間が無駄になったと言って
支障するかもしれないですけど
それはあなたのググり力が悪いんじゃないかと思ったりもしたりしますけど
少なくともそういう学んでいる人をただただ否定するっていう論は
全く持ってちょっと僕も意味がわかんないなと思っています。
はい。じゃあ戻りますね。
現状、日本語によるプログラミング系の検索があまり良い状態ではなく
検索して1ページ目を見て諦めて英語で検索する
もしくは最初から英語で検索してしまう人は多いでしょう。
それには様々な要因がありますと
例えばPythonやRubyの基本的な操作で検索すると
06:03
やたらと大きなかつ無関係なイメージ写真が散りばめられた
いかがでしたでしょうかみたいなんで終わる系の記事がヒットしてしまいます。
またエラーメッセージで検索して
聞いたの個人メモみたいなのが引っかかって
しかもそれがあまり良くない実装だったりして
イラッとした人も多いんでしょうと
これらを検索ノイズと呼んで嫌う人は多いですし
その気持ちもわかります。
それでも私は情報の取捨選択の責任を
アウトプット側に負わせるべきではないと考えます。
それは僕も同意ですね。
一応注意書きがあって
英語で検索して出てくる
参考になる記事の多くが
スタックオーバーフローにあるということもそれを裏付けています。
スタックオーバーフローには回答にボーッとする機能があって
多くの人が参考になったと思う記事が評価される仕組みができています。
これを見ても記事の評価は著者ではなくて
読み手がするべきだというふうに思いますね。
一応注釈がありました。
戻りまして
絵の完成に11人が必要だ
1人が絵を描き、10人がそれを漕ぎ下ろすという言葉を見かけたことがあります。
そんな言葉がありますね。
絵の完成に11人が必要だ
1人が描き、10人がそれを漕ぎ下ろす
漕ぎ下ろすというのはすごいですね。
レビューとか指摘をするとかだと思いますけど
10人いたら大変だな
精神的エネルギーが必要な気がしますけど
世の中情報を出す人と出た情報に文句をつける人
というのは圧倒的に後者の方が多いです。
情報を出す側と情報を受け取る側
後者が圧倒的に多い状況で情報を出す側に
一定のクオリティフィルターを求めるというのは確かに非効率ですね。
それも本当にその通りだと今思いましたね。
責任というかそういうことをするのは確かに
クオリティフィルターはレビュー側とか読み手側の人に
委ねる方が確かにいいなと
こうした方が効率的ですよね。圧倒的に数も多いですからね。
でも個人的にはいかがでしたでしょうかのようなサイトを
ブラックリストに入れてブロックした上で
多くの記事を読み、著者を確認し
この人の回答記事は信頼できそうだ
という重みをつけていっていきましょうと。
はいはい。読み手側の方の仕組みですね、これは。
くだらない知識であろうが個人メモだろうが
まずはネットに出してもらう
それをどう処置したら選択するかは
受け取り側の責任だと私はやっぱり考えるよと言ってますね。
続いて批判を恐れるな問題というのがあります。
これもね、ちょっと強い主張かもしれないですけど。
新人を守ろうみたいなことを言うと
ネットに情報を公開するなら批判される覚悟を持つべき
その覚悟がないのならそもそもネットに公開すべきではない
という主張の人もいますと。
気持ちはわかります。
私はこの意見に全く賛同しませんと。
それも同意ですね。
現状ネットに情報を書くと何らかの批判を受けるのはそうですと。
批判されて傷つくメンタルであるならば
そもそもネットに何も書かないのが最善の自衛策だ
というのもその通りだと言っています。
しかし現状そうなっているという事実は肯定しませんと。
まあまあ、そうよねーっていう感じです。
09:01
ある意味で批判されるってことは
それだけ自分が注目されるようになったりとか
そこそこクオリティの記事が書けたんじゃないかってところですよね。
全く読まれないってことはそういうことにはならないので
ある意味で批判が来たっていうのは成長な価値だ
という捉えるのも一つの視点だと思いますけど
これもメンタルが必要だというところはありますね。
戻りますね。
繰り返しますがネットに何かを書き
公開する人はやっぱり貴重な資源ですよ
というのは変わらないですと。
気軽な気持ちで記事を書いたら盛大に炎上してしまったとして
その人は多分もうネットに記事を書かないでしょうと。
ある企業のアドベントカレンダーで
おそらく何回というと言われて気軽な気持ちで書かれたであろう記事が
炎上したことがありましたと。
そういうのを見ましたと。
今その記事もそのアカウントさえもそのサイドから消えてしまっています。
この記事を書いた人が別のアカウントを取り直して記事を書いたり
別の場所で記事を書いたりという可能性はおそらく低いでしょうと。
まずい記事が一つ消えたことを喜ぶべきでしょうか。
将来有益な記事を書いてくれたかもしれない人が
消えてしまうことを悲しむべきでしょうか。
それとも今後もまずい記事を書く可能性が高い人の目を摘んだことになるでしょうか。
これらどれを重視するかは人のポリシーに依存するので
ここで議論するつもりはもちろんありませんと。
私は間違っている記事やまずい記事に相当指摘するのは重要だと思いますが
検索ノイズかこれぞ反面教師だなぁわらわらみたいな
もしくはこんな記事を書かせる会社大丈夫かみたいなコメントが
情報の海の栄養価を高めるとは全然思っていないですと。
むしろ何も生産的じゃないコメントだよなって感じですね。
批判は楽です。記事を一本書くのに最低でも30分
下手をすると数時間以上かかりますが
ツイッターやハテブでアホかと書くのは数秒で済みますと。
何かまずい記事や間違った記事を見かけたのなら
それを直接叩くのではなくて
正しいと自分が信じる記事を書いて対抗してほしいと思います。
その記事は元記事よりも注目度が低く
思うように思い違いを修正できないかもしれません。
しかしその記事にぶこめでアホかと一言書くよりも
よっぽど建設的だと思います。
僕完全同意です。これは本当に。
もしくはコメントする時も自分のそのコメントとか
根拠とかをしっかり調べてそれをコメントしてあげたら
全然いいんじゃないかなと思いましたね。
そのコメントもあってその記事のクオリティとかが
決まってくるのでクオリティを下げるようなコメントは
何も生産的ではないし
自分の自己満のためのコメントはやめてほしいなと思いますよね。
続いて誰に向けて書いた記事かということです。
この記事は今検索ノイズを嫌がる人、批判を恐れる人は
ネットに記事を書くべきではないと思っている人に向けて
書かれた記事ではありません。
僕は誰かの意見を変えようとは思っていません。
この記事はまだ記事を書いたことがない
もしくは他の人の記事の批判もしていない
いわゆる駆け出しエンジニアに向けて書いています。
記事を書いたことがないあなた、批判を気にせず記事を書いてください。
少し知識が増えてきたあなた、公開された記事を気軽に批判しないでください。
まずは記事を書いて公開するという勇気ある行動に敬意を持ちましょう。
12:02
その上で記事の内容がまずい場合は
どうすればネットが良くなるかというのを考えて行動してほしいと思います。
ネットを良くする手段として
自分が詳しい分野について網を張り
間違った記事を見つけて批判する人たちがいます。
いわゆる警察と呼ばれる人たちです。
その警察の是非はさておき
警察のナリティはたくさんいるのであなたがならなくても大丈夫です。
それより記事を書く人になってほしいなというところですね。
確かに警察って絶対なくならないし
毎年毎年増えている印象でもありますね。
最後まとめです。
ネットに記事を書くならちゃんとした記事を書くべきという人と
内容は気にせずまずはアウトプットすることを重視せよという人がいて
それは何を重視するかというのが異なるので
基本的に議論する意味はぶっちゃけないと思っています。
またこの記事で議論しようとしないでくださいと。
僕は内容は気にせずまずはアウトプットすることを重視せよ派です。
私もその派です。
そうして情報をアウトプットしているうちにだんだん強くなって
他の人の参考になる記事を書いてくる人が増えていく。
嬉しいなというところで締められています。
とはいえ、この記事にもいろんなコメントがたくさん並んでいて
面白いな本当に。
独り言っていうのを前提の上でコメントする人もいたりとか
是非じゃないですけどいろんな意見とか
言いたくなったことを書いたりするコメントが結構詰まってますけど
批判的なコメントはなかなかなさそうなので
なかなかいいなと思いましたし
ちょまどさんがコメントしてるのは結構熱いですね。
彼女もやっぱりそういう心理的安全性の確保されたカルチャーを
作り守ることに改めて自分も努力していきたいな
というふうにコメントされてて
さすがの一言だなって感じですね。
以上、前半はこんな記事でした。
もし興味あったら見てみてください。
後ほど読んだ記事をツイートします。
ではもう一個ですね。
Only My Rails Wayです。
タイトルにある通りですけど
Ruby on Railsですね。
Ruby on Railsのことについて
自分の中のウェイなんで
道を書いたっていう感じだと思いますね。
じゃあいきましょう。
これは何ですけども
Rails Wayに沿ってとは
レビュー欄なのでよく言われますけども
定義が人によってブレてる気がするので
俺のRails Wayを示した記事だそうです。
いやもうマジなんですかね。
ネタに使いやすいというか批判もしやすいし
いろいろなものを含んでますけど
やっぱりそういう記事って
その人の本当に考えだったりとか
っていうのが主張とか
哲学が結構現れるので
僕は結構好きですけどね、こういうの。
ちょっと読んでいきたいと思います。
もはや本来のものとは別物かもしれませんが
俺はこういう観点でRailsを見て
コードを書いてるよということを知ってもらう意味でも
この記事を公開することにしました。
前提として、数人以上のチームで
プロダクトを実際に開発して運用する場合の
自分のスタンスを示したものです。
私も仕事では独自DSLは書きませんが
自由研究用途ならば自分も独自DSLを書いたりしています。
15:02
じゃあ行ってみましょうというところですね。
気づいたら23分なのでちょっと駆け足でいきますが
これちょっと面白そうなので
時間オーバーしても読み切っていこうかなと思います。
じゃあ行きましょう。まずモデル層からです。
データベースの操作及びビジネスロジックを記述するものですよ。
テーブルの属性は原則ノットヌルにするべきだと言っています。
ヌルをヌルと発音するかナルと発音するかは人によりますが
正しい発音はちなみにナルですね。
余談でした。
どうしても要件上ヌルを強要しなければならない場合のみ
ヌルを強要します。
コントローラーからパラムスを無思考で渡さない。
ここしかも太字になっていますね。
使用する属性のみコントローラー側で取り出してから
モデルに渡すのが良い。
外部通信、特にメール送信が起こるロジックに注意しましょう。
テストを書くときに正しくスタブ化しておかないと
CIで外部通信が無限に飛んでしまう場合があります。
イールドを使って外部からメール送信ロジックを差し込むような
メソッド設計するのも検討しましょう。
以上モデル層です。
続いてサービス層の可否ですね。
基本的に採用しないと言っていますね。
強いですねこの方は。
ビジネスロジックはモデルに詰め込みます。
気持ちとか方針はよくわかりますけど
僕はちょっとそうなのって思ったりしますね。
基本的にだから本当にどうしようもない場合は
使うと思うんですけど読んでいきましょう。
サービス層の汎用は乱用ですね。
乱用というのはドメイン貧血症を起こす
弊害があります。
あるためなるべくはサービス層は使わないと言っています。
サービス層の採用についてはよく論争になるが
それでいいと思っています。
議論が起こることは別にいいなという話ですね。
サービス層に限らずレールズデフォルトにない
パッケージを切り出そうとするときは立ち止まって
チーム内で議論した方が良いと。
本当にちゃんとレールに乗っかるということを
この人はやっぱりメインに置いている感じですね。
モデルはでっかくなっちゃってていいし
単にコードの行数を減らすためだけに
ファイルを切り出すのは責務が曖昧になりがちで
余計可読性を損なうのでやめた方がいいと。
コードの行数で可読性を判断しない。
これは大事ですね。
短いから読みやすいというわけではないですし
僕も過去の経験ですごい短いソースコード
文字数にして100文字くらいのソースコードを見たことがあるんですけど
めちゃめちゃ難解な正規表現がドーンと書いてあって
誰もレビューできないよみたいなコードを見たことがあるんですよね。
それを果たして可読性いいかというと
そんなことは絶対ないと思うので
短いが可読性が高いというわけではないと思いました。
あといいですね。
コードを長くするというのは結構いいなと思いましたね。
FATコントローラーになるよりは
モデルのほうが要するに長いというのが
僕も確かにまだいいなと思っていますね。
続いて、新しく入った現場の既存コードにサービスがあると
体中を光の速さで確かな俯瞰が駆け巡ると。
18:00
ほんとこの人はサービスを嫌いなんだな。
ちょっと面白かった最後の一言。
今のがサービス層の可否の話でした。
続いてリポジトリ層の可否です。
原則対応しない。
これも使わないんですね。
データベース以外からのデータの取り出し
例えばAPIコールなどは
モデル層にアクティブモデルのモデルを利用して書きます。
ほんと振り切ってるというか方針ががっつり決まってますね。
モデルがDBと通信しているのか
他のどこかと通信しているのかは
意識せずに書けるようになるとグッドだと言ってます。
結構すごいですね。
リポジトリ層の可否で原則対応しないは
僕あんま聞いたことないので
結構新鮮ですね。
確かにモデル層に全部突っ込んでいて
モデル層の中でうまいこと制御できていて
可動性も高いんだったら
それは確かに一つの設計としていいなと思いますね。
シンプルですね物事が。
とはいえ
そんな複雑度が上がっていくとそうにはならない気がしますけど
なので原則とか基本的にっていうワードを使ったんだと思います。
続いてビュー層ですね。
今のでモデル層終了です。
次ビュー層ですね。
いきましょう。
SSRするならですね
ERBが安定作だと言ってますね。
スリムやハムルっていうのは見かけの記述量を減らせますけど
ERBっていうのがRubyマインで
保管しやすいので実質のタイピング量がそこまで減らせるわけではないと。
あとスリムやハムルを使うと
リアクトやビューに移行するときに書き直しが大変だと。
それは確かにありますよね本当に。
テンプレートエンジンのメリットはありますけど
その他にそれにロックしてしまうっていう
別の弊害が発生するのでなかなか難しいところなんですよね。
ERBが安定っていうのは確かに
いろんなものを加味するとそうかもしれないですね。
あとERBは別に遅くないよと言ってます。
Ruby 2.5でかなり高速化したそうですね。
あとそもそもビューの
ビューのレンダリングエンジンの早い遅いを議論する前に
Nプラス1が起きていないかを調べるのが先だと。
確かにそうですねそこから見てみましょう。
まずツールじゃなくて自分たちの実装そのものをまず調べるのが先だと。
フロント側でのJQueryとかHTMLのレンダリングを前提にした
js.erbダメ絶対って言ってます。
絡まった運命も変えていける力が欲しい。
この人ほんとポエム能力高いな。
続いて
ドラッパーって読むんですかね。
ドラッパーですか。
ドラッパーも最近あんま必要だと思ったことがないと。
ヘルパーでいいんじゃないっていう話です。
すみません僕はレール図を触ってないのでわからないですけど。
っていう主張だそうです。
続いてフォームオブジェクトも基本的に使用しないと。
フォームオブジェクト使わないですね。
続いてフロントにHTMLの描画に任せJSON APIに徹するならっていうタイトルです。
21:02
HTMLの描画を任せJSON APIに徹するなら
標準のAPIモードを使い続けるのが一番いいと。
グレープはあんまり必要だと思ったことがないよっていう風に言ってます。
この辺は僕があんまりレール図を勉強したことがないので
コメントいただけなくて申し訳ないなって感じです。
今のが一応ビュー層の話でした。
じゃあラストですね。モデルビューときたらコントローラー層ですね。
ちょっと短いですね。
コントローラーの責務っていうのは入力地のバリベーション、
入力地を適切なビジネスロジックへ移情、
適切な出力形式を選択してアウトプットレンダラーに処理を移情しますと。
この3つになります。これが責務です。
コントローラーは薄いほうがいいが薄ければいいというわけでもないと言ってますね。
取り分け速度を重視するフェースではある程度コントローラーに
ロジックメーターものが入ってしまうのは仕方ないが、
リファクタリングチケットはちゃんと残しておきましょうと。
あと横断的な関心事ですね。
例えばロギングとかですけども、そういうもの以外を
ビフォーアクションやアフターアクションに書かないってところですね。
ここ不当人になってます。
ビジネスロジックが中途半端に書かれていたり、
オンリーやエクセプトがバックをするコントローラーに出会うと
人はどこまで立ち向かえるのか不安になりますと。
言いたいことは分かりました。
ビフォーアクションやアフターアクションでドライしようとしないと。
へー、へー、へーと思ったけど、
今僕はビフォーアクションとアフターアクションがあんまり分かってないので、
ふーんしか分かんなかったです。
続いて、モデル層でも述べたが、
モデルに渡すのに必要なパラメーターを選定するのは
コントローラーの役割であるという認識ですと。
以上、今のがコントローラー層でした。
続いて、テストです。
メインはいつもCIグリーンだと言っています。
当たり前のようだが、これが守られている現場は観測範囲で50%以下だと。
当たり前のことを当たり前にやっていきたいし、ちゃんとしようと。
あ、これいい言葉ですね。
当たり前のことを当たり前にやっていきたいっていうのはいいワードだなと思いました。
そもそも、ちゃんと当たり前って言えてる人って結構少ないですよね。
自分のことも含めてですけど。
続いて、Rスペックに自分は慣れているが、別にマインテストでもいいよって言ってます。
別にツールは極論なんでもいいですよね。
ちゃんとそのアプリケーションとかシステムの動作っていうところが担保できてればってことですね。
続いて、ファクトリーボットはやはり強いと。
続いて、TDD原理主義者ではないけど、
不具合の修正であったり、設計が固まっていたりする場合は
TDDするとサクッと書けるケースが多いのでよくやりますと。
設計が固まっていたりする場合はTDDするとサクッと書けるケースが多いのでよくやりますと。
設計が固まっていたりする場合はTDDするとサクッと書けるケースが多いのでよくやりますと。
実装書いてからテスト書くのは別にそれで良いと思っています。
実装書いてからテスト書くのは別にそれで良いと思っています。
テストをどこまで緻密に書くかっていうのは必ず脳筋と相談ですね。
テストをどこまで緻密に書くかっていうのは必ず脳筋と相談ですね。
それによって全現場は同じことを思っていると思います。
カバラッチ100%は死ぬほど暇な現場で無いと現実的ではないので、
達成できなくても気にしない。
達成できなくても気にしない。
いいと思います カバレッジ100%を目指す意味なんだっていうのは正直ありますしね
24:05
100%バグがないアプリとかシステムなんてこの世の他にありえないので 100%なんてまずありえないです
矛盾してますけどね はい ついでテストを書く優先順位は以下の3つですよと言ってます
1番は正常系ですね 2番は異常系のうち発生確率×被害っていうのが大きいと見積もられるものが
第2位です 第3位が異常系のうち発生確率×被害が小さいと見積もられるものですね
はい 言ってます まあそんな感じですね
あとちなみにテストを書くと多分正常系vs異常系でいくと 1対9か2対8ぐらいで異常系だらけだと思うんで
正常系から先に書くってのはもちろん大事ですし 何が正しいかっていうのを定義して
その1テストの後異常系書くんですけど 大体テストを書く
テストを書くコースっていうのは異常系にひたすら尽きると思うんで どんどん異常系のところを書いていくのはいいんですけど
まずはでけえなというところですよね 確率×被害が大きいって見積もられるものからやるのは本当にいいなと思いました
はい 以上テストでしたね 続いてデプロイです デプロイすごい早いっていうか短いですね
デプロイは最速を目指すんだったら Railsの場合はヘロクがいいよって言ってます
チームにインフラエンジニアが不在の状況ならばPaaSとかSaaSに思いっきり依存しましょうと
1アプリケーションエンジニアがIaaSで頑張らないよというところですね
IaaSと読むのかIaaSと読むのか今何ちょっと僕よくわかってないんですけど
とりあえずアプリケーションエンジニアがそこでインフラザサービスで頑張らないようにしましょうというふうに言ってます
続いてドライに関するポリシーですね たまたま似通ってるだけのコードを共通化しないと これは不当人になってます
続いて責務が同一であって初めて共通化して良いと
そうですね 似通ってるだけのコードを共通化しないはすごく感じてますね
結果切り出したけど結局使われているところ1カ所2カ所ぐらいしかなかったという時もあったりしますから
あとですねLubocopを騙すために責務は考えずに5行ごとにメソッドに切り出したりするのは最悪だというふうに書いてます
ここもしかも不当人になってますね 5行ごとにメソッドに切り出したりするってすごいですね
それなら書き下したほうが絶対に良いと言ってます あと一見ダサいコードっていうのは意外と読みやすいですと
こじれたプライドを捨てて書き下そうというふうに言ってます 確かにね
かっこいいコードを書きたくなるってすごく分かるんですけど 過読性とかで加味すると意外とダサいコードの方が
読み手の人の考数を奪われなかったり人のエネルギーも使わなかったりするので プライドあるかもしれないですけど捨てて書き下そうっていうこれはある意味で
僕は結構共感をしますね まあ自分のエンジニアレベルを下げる可能性もちょっとあるので
まあそこは要相談ではありますけどね
はい今のがドライに関するポリシーでした 続いてパフォーマンスに関するポリシーです
最初の実装時にあれこれ考えてひねた実装にするのでなく無直に書いてまずは計測し ましょうと
ああいい話 最初の記述と矛盾するようだが基本的にRubyは遅くないしRailsも遅くないと
遅いのは99%自分が書いたIOかSQLだと言ってます まあ自分の経験上もだいたいそんな感じですね
だいたいSQLだったりしますけど 無邪気に何かセレクトアスターで取ってくるとかもうアホかってたまに思ったりしますけど
27:07
まあそういう現場をたくさん見てきたのでうーんって分かったら思ったりします あとなんかテーブルジョインなんか6,7個のテーブルジョインしてて
このSQLを手つけるのも正規すぎて触れないみたいなのを見たりはしましたけど はいまあ余談ですけど
あともう一個ですねパフォーマンス向上のためにRuby 5とかRuby Javaみたいなフルリプレスプロジェクトを立ち上げるのは
予算と時間の無駄だと思う すごいな無駄とはっきり断言するんですね
で遅いのはいつも言語じゃなくててめーのこの この人ほんとポエマーとして才能あるな
すごく面白いですねはい 確かにRubyが遅いっていうのは多分だいぶ昔の話だと思うんですよね
やっぱりちゃんと技術ってのは日進月歩で進んでるはずなので レールズンはだいぶ早くなってきたんじゃないかなと思いますね
以上パフォーマンス増加するポリシーでした まあでもJavaの方が早いのは確かにそうかもしれないですけど
まあ時間と予算的にそこにフリプレイする意味はあんまない気はしますけどね僕もね はい
続いて継承か異常かというところですね 継承でうまくいかないライブラリを使用しない限りは基本的に異常で倒していいんじゃないかっていう
ふうにおっしゃってます 横のクラスの機能を使いたいんだよみたいなで継承しない機能の横連簿というアンチパターン
になりますのでやめたほうがいいよというふうに言ってました なるほどね基本的には異常を使いましょうということです
デリゲーションのことですね異常 続いて独自DSLですけどこれはもう一言書かないの一言で終わってます
はい続いてライブラリー管理ですね 利用するライブラリーは少ない方がもちろん良いとライブラリーが多ければ多いほど
メンテされないライブラリーを抱え込んでしまうリスクが高まります ライブラリーが多いとアップデート時のエンバグリストも増えますとそのままバージョンを
上げられなくなるレイリーズを何度見てきた そこから先はもう一方通行だよというふうに言ってます
まあ難しいところですよね 外部依存するってことはそれだけの影響が入ってくるのでね
続いてですねコードが例えば独自DSLとかで短く書けるっていうだけがメリットの ライブラリーは使用しないと
ライブラリーを増やすくらいならコードの文字数増えるほうが絶対にいいというふうに 言ってますねと
あと標準構成で特別な設定もせずに COCでガンガン書き詰められるって最高ですよねと
新規採用するライブラリーはスター数やメンテの頻度チャットのチェックしましょう というところでした
割と参考になるというかその通りだなという感じの ご意見ですね
あともうちょいですね 続いて認証の話です 認証は大数ゼロ
サースの利用かあるいはデバイスですねを使いましょうと言ってます デバイスが辛いとよく言われるんですけど
他のライブラリーはもっと辛かったというので 悲しみって多分明日へ向かう原動力
本当に面白すぎるな まあまあでもそうね 過去に受けた悲しみが未来の自分の原動力って確かにそうかもしれないですね
心が折れてない人はってことですね 折れた人は原動力にならないかもしれないです はい
まあでもやっぱりオースゼロに倒せるんで かつお金があるんだったら僕はオースゼロを使うのは全然ありだと思います
30:01
そういう認証周りところだけでちゃんと企業化したプロがいるんだったらそこにお 金を払って頼るっていうのは僕ある意味ビジネス的には正しいと思ったり
しますけども もちろんメンテナンス暴走とかいろんな制約はありますけど
自作するのは認証周りはちょっと怖いよねってさすがに思いますね もちろん勉強するの構うので全然やってはいいと思いますけど
はい余談でしたで続いて決済ですね 決済はまあ基本的なストライプが最高に体験がいいらしいので今のとこストライプで
確かにいいんじゃないかなと思います 過去にいろんなやつもあったし例えば gmo さんの色の api も公開されてたりするので
まあそういうのを使ってもいいかもしれないですけどまぁストライプでいいんじゃない かなっていう感は僕も今のところありますかね
はい 続いてデータベースですねデータベースはもう rdb が同安定だと言っています
はい検索にエラスティックサーチを使うぐらいってことですねはいどちらも本番では マネージドサービスをやっぱり利用したいよねっていうまあそれはそうですよね
でまぁ特殊な要求や要件があって初めて他のデビューを検討しましょうと 開発者の使いたいありきのエゴで p キーな db っていうのを使わない方がいい
ですよって言ってますね はいまあここは完全同意って感じです何も他に言いたいことがな
愛であと2つモノリスかマイクロサービスかというところです えっとこの方自身が過去にですねものリスからマイクロサービスへの設計の切り替え方って
いう聞いたの記事を書いてでも本にリンク貼ってますけど これを前提にした上でまぁこういう記事を書いてあれだがマイクロサービスにしたって
プロダクト同士が依存関係を持ってしまったらまあ開発作動 開発速度はスケールしないとアスケルアウトをしないって言いますね
ぶっちゃけモノリスでマザーズなり m & a なりエグゼットまで行けると思うしまずはそれを 目指すべきだというふうに思っています
ipo はさらなる資金調達の場であって株式の株主の利益確定の場ではないと m & a はさらなる成長のための手段であって創業者の利益確定の手段ではないと
よく言われますけども id ベンチャーの経営者の多くがエグジットで株を切り売り付けて 売り抜けてか数億円から数条件のキャッシュを得たいと本音では考えていますと
まあそれはそうでしょうね でもプロダクトの出口戦略まあいわゆる売り抜けですよね
を考えるのは全然悪いことではないですとエンジニアの役割はプロダクトに 準視することではないと
そうねはいプロフェッサーと主に死ぬのがエンジニアの役割ではないよね確かに言った思い ます
まあちょっとものですかマイクロサービスかという視点からちょっとビジネス的な視点になったなって 感じはしますけど
はい でえっと最後ですねマインドですマインドコードゴルフに興味はない
大事ですねコードゴルフはあくまで遊びだと思ったほうがいいかもしれないです僕も まず動くものを世に出すのがやっぱり何よりも優先されますそしてそれで
お金を生み出すことができれば最高ですよねと で動いて儲かっている綺麗なコードより
性なりか動いて儲かっているクソコードへ性なり動いて儲からない綺麗なコード 越えられない壁として動かない綺麗なコード
いわゆる動かないクソコードと ところですねはい
というのでとにかくやっぱり動いて儲かっているコードの方がやっぱり価値は高いと はい
33:02
言ってますね それはやっぱりの綺麗な子の方がそら価値は高いし
ででもクソコードとしてもやっぱり動いて儲かっているとはそれはやっぱり価値は高い その次に動いて儲かっ動いてるけど儲からない綺麗なことになります
そこから超えられない壁が動かないかつ綺麗な方ということですねはい で
次ですねえっと pl 既存して j カーブを狙う戦略はあまり好きではないと まあ初月から黒字をコツコツとできればフクリで増やしたいですよね
そうですねフクリの威力がすごく高いんで まずはやっぱりまず売上が立つっていうところを作っていくとやっぱ大事ですねビジネスとして
は 最後フレームワークの本質っていうのは自由をあえて束縛することで速度を上げることに
あります 売り切り割り切りは重要ですねフレームワークに反逆をしないというところでした
はいまあ自由をって最初に言ってますけど自由ではないんですよねこれ 自由ってあのちゃんとルールがあった上で好きにやってくださいというのが自由なん
ですよね ルールがない自由というのはただの無法地帯のことなので
なので今回の幅は言うと名は無法地帯を束縛することで速度を上げていくってちゃんと 自由を作っていきましょうとかと思いますね
はい以上 ざーっと読んできましたけどエコオンリーマイレールずべっていう記事でした
でコメントが2つ来てたのでちょっと見てみましょうかはい コメントだと外部仕様が固まってテストレビューが終わってから
ip 化まあライブラリ化するときにパラメーターかとか最適化とかリファトリングしたい ようですねっていうはい
できるかどうか別として確かに流れとしてはそうできたら確かにいいなと思いますよね はい
ところですもしか最初からですね設計だったりレビューするときにもうそういう先のことを観点に 加えといた
あのレビューとかコメントがあったらどうもしか設計ができたら最高だと思いますけど まあそんなスーパーのエンジニアはなかなかいないのではい
で a コード圧縮のためにラムダ式濡れにするぜ ラムダ式はの用法要領を守りくださいって感じですねはい
という感じでじゃあだいぶオーバーしましたね43分なのではいなくなりましたけど こちらで今日の朝活は以上にしたいなと思います
たまにはこうポエムの記事読むのはやっぱ面白いですね でもやっぱ技術記事に関するやっぱポエムなので割と参考になるというか
なかなかどうしてあの知的に面白かったなと思いますのでまたそういう記事も バーと読んでいきたいなと思います
やっぱ日本人の方と後海外の方であの 書き方という観点微妙に違ったりするのでそれはそれでちょっと面白いなと思いましたので
はいまた何か誰だろうと明日も読んでいきたいなと思います じゃあえっと今日はこちらで以上にしたいかなと思います今日も何かを参加たくさんの方に
ご参加いただきありがとうございました 夏休みの方はゆるいとお休みくださいかつお仕事の方は今日も世間は休みで
ファイフィキャッハーしてるかもしれないですけど 心を強く頑張っていただければと思いますでは終了しますお疲れ様でした
