サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
CES 2025
twitter.com/t_wada
データアクセスレイヤのテストを書く際にDBをモックするのは自作自演のテストになりがちなので個人的にはおすすめしません / “Prisma で本物のDBMSを使って自動テストを書く - mizdra's blog” https://t.co/3YIcK3ptU9
Gitのコミット粒度はまずConventional Commitsで種類が混ざりにくいようにしつつ、「小さいコミットを後からくっつけたり並べ替えたりする方が、大きいコミットを後から分割するよりもずっと簡単なので、迷ったら細かくコミ… https://t.co/AlCtjvT3rC
まさにこれですね https://t.co/Qfj2uFkmrR https://t.co/p6sMbdjjUo
ざっくり捉えがちな凝集度と結合度に関してここまで細かく明解に説明している資料にはなかなか出会えない。読むと凝集度に対する解像度が上がる。すばらしい資料。 / “オブジェクト指向のその前に-凝集度と結合度/Coheision-Cou… https://t.co/VAa9OA9VjE
DDDもマイクロサービスも、その始まりや大事な点は実装以外にあるのに、どうしても実装面が注目されがちなのは、技術はコードを読んで理解するのが結局早いという経験則からきているのではないかと思う。でも実装面だけ見るとDDDはただのOO… https://t.co/0aOZ8BeSRx
Easy: 手数の少なさを重視（そのかわり覚えることが増え、特定の状況には強いが他には弱い設計になる） Simple: 覚えることの少なさを重視（そのかわり手数が増えたり、自分で組み合わせたりしなければならない） この二つを混… https://t.co/DpMqZlBRzS
依存の注入はコンストラクタでやろう ↓ 依存と生成知識がシステム中に散らばる ↓ 生成知識をファクトリーで隠蔽しよう ↓ 今度はファクトリーがシステム中に散らばる ↓ ファクトリーはシステム中にDIコンテナひとつでよくね？ ↓ D… https://t.co/UKr6gg1p0j
バグはコードに原因があり、コードを直さない限り常に処理に失敗するもの 例外はコード外に原因があり、状況によって発生するもの コンパイルエラーはそもそもコードを実行する段階にたどりついていないもの https://t.co/ra9tQ4zkNp
最新の Technology Radar でも「言動に難ありだけど10倍の生産性がある個人の時代は終わりで、多様な背景を持つメンバーのチームワーク、学習、継続的改善が10倍のパフォーマンスを生む」とありますね… https://t.co/bnXZ7fb4ZJ
「伝統とは火を守ることであり、灰を崇拝することではない」という言葉、素晴らしいと思って調べたら Gustav Mahler の言葉で、俺の中で最高のエモさを記録した
もう業務時間後に勉強会をする時代ではなくなってきているので、業務時間後の（半強制の）勉強会はアピールポイントではなく、エンジニア採用にはマイナスに働くようになる。 勉強会/読書会は業務時間内に行うということを、もっと普通のことにしましょう。 という趣旨のことを複数の現場で話した。
Test Sizes の考え方は「単体テスト」や「結合テスト」といった名前を使うと人によって定義がぶれて勘違いや議論の発散が生じるので、自分たちでテスト対象を要素に分解し、自分たちのサイズ（SMLなど）を定義しようという取り組みで… https://t.co/UjNzV1TYvx
ソフトウェア開発において質と開発速度はトレードオフの関係ではなく、早期から質に投資すれば結果的に安く早く開発できる。技術的負債を軽視すると速度は落ち続ける。質への投資の損益分岐点は1ヶ月以内に訪れる / “Is High Qual… https://t.co/HHAigk8iWg
@ktanaka117 テストファーストだけど TDD でないもの（私見） 1. テストを先にたくさん書いてしまう（インクリメンタル設計/開発がなされていない） 2. リファクタリングが行われていない（内部の質の改善がなされて… https://t.co/KPfNjkj7bW
日本の多くのプログラマーは - 自動テストを書いたことがない - テスト駆動はやったことがあっても、テストファーストをやったことがない - CI を経験したことがない 上司の理解がなく、そもそもまわりにレガシーコード（テストの無いコード）しかない #jasst
DB設計のカタログサイト。新しくテーブル設計する際には必ず一度ここを見る。見た目は古臭いけど数と質が圧倒的 / Industry Data Models https://t.co/5FPA7fmpyx
講演前日と当日に心がけていること 1.徹夜をせず、6時間は寝る。壇上では頭をフル回転させたい。眠いとアドリブが効かない。 2.早めに会場入りし、会場の明るさ、スクリーンの位置や輝度、聴衆の入った後方座席から講演資料がどう見えるか等を確認する。状況次第で講演資料を控室で調整する。
React, Jest, Flow, Immutable.js が特許条項付き BSD ライセンスをやめ、 MIT ライセンスに変更された。来週リリースされる React 16 から適用される予定。大変めでたい。 / “Reli…” https://t.co/iBw1aoHtXC
コードには How テストコードには What コミットログには Why コードコメントには Why not を書こうという話をした
@gomachan46 「許可を求めるな、謝罪せよ」はいわば超訳で、原文は「It is easier to ask forgiveness than it is to get permission」なので「事前に許可を得るより、あとで許してもらうほうが楽」と訳すのが良い派です
「テストコードはDRYを捨ててベタ書きする方が良い」という意見は15年前くらいから定期的に出てきていて、一時期はその方が良いとも言われていたが、後に望ましくなかったことが分かる。DRYを捨てて重複が増えたテストコードはメンテナンスコストの増大を招き、多くの現場を苦しめたからだ。
私が見てきた現場の多くはこの逆で、プロダクトファーストおじさんが書き散らしたコードのメンテナンスと改修を押し付けられた若者が疲弊していく構図が多いです https://t.co/duqruayTuz
大文字区切りは camelCase, アンダースコア区切りは snake_case, ではハイフン区切りの通称はと調べると、 kebab-case という呼び名が見つかる。ケバブは肉の串焼き。つまりハイフンが串、単語が肉というわけで、なるほど洒落が効いているし覚えやすい。
マジレスするとprivateメソッドをテストしたくなったら設計を確認した方が良いです。privateメソッドはpublicメソッド経由でテストできるはずですし、できない場合は責務や依存の持ち過ぎです。別オブジェクトのpublicメソッドとした方がよい場合もあります。 #jggug
講演内容は、ドワンゴがニコ生を Scala で書き直している話。書き直す対象のコードは…… PHP 300万行。そのうちコピペ1万ヶ所。潜在的不具合(PMD警告)4500ヶ所。循環的複雑度600超メソッド多数。 #devsumiA
java-ja なんだろ? 自重するなよ #keccon
現実乙 QT @sinsoku_listy: 現実は、男「そこテストレッドになってるよ」男「ん？でもテストケースおかしくね？」男「ほんどだ。悪ぃ」男「たく、しっかりしろよ」 こんな感じ RT: @yoshiori: でもペアプロってこんな感じじゃね？
次のページ
このページを最初にブックマークしてみませんか？
『Takuto Wada (@t_wada) | Twitter』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
