五行思想
良い話
これは素晴らしい。
落ちに、これは大変なのでFW使います、あたりにして欲しい
ちょっと感動しました
“APIからユーザー名を取得するTypeScript関数。エラーハンドリングを学んだら、意図した通りに動いてくれない野放図なコードだとわかる。パフォーマンスを学んだら、このコードが典型的なN+1問題だと即座に認識”
よい話
氏名取得のための処理、五行無限の気付きあり/良い記事。
クライアント側のコードだけ変えても指摘されてる問題の本質は解決されてなくない？ってのがあるように見える。
copilotってここまでやってくれないよね。相当詰めないと。
極端な例って書いてあるのにー
“N+1問題”この例ってニュアンスが違う気がする。リストとってきてそのリストを元に再度一つづつ問い合わせを行う事だと思うんだけど...
ふむふむ、コードって奥深いのにゃ。ボクにはおやつの方がもっと違って見えるにゃ！
これは良記事
さすがに妄想が過ぎるので、責務の範囲を設計するということを学んだほうがいい。/「もしも」プログラミングを卒業して、現実を見たコードを書いたほうがいい。
良記事。結局AI使ったところで、エンジニアがこの辺のジャッジができる必要があるから、そんなに速度上がらんのよ。できないレベル感のエンジニアは逆にAIに主導権を握られて高速でジェンガタワーを作ってしまう。
いい記事だしなんか悔しいな
教材として良さそう
いいね、コーディング忘れたおじさんは癒されるね
深いね。確かに学び続けることの重要性が伝わる
そんなにいろいろ想定して結局意味ないパターンの方がおおいので特にスケーラビリティとかはほんとうに必要になってから対応しろ…とかおもってたら最後に「トレードオフを学んだら」がでてきてぐうの音もでないな？
コードを見ながら設計するな。非機能はプロジェクト共通で設計しろ
これはいいな
まとめて取るにはuserId50件を保持してないといけないけど、、、全然典型的ではないような。 “典型的なN+1問題”
ユーザ名を取得するサンプルコードだなと見えるし、それ以上は何も見ない。まさかこれが実運用で使われるとは露とも思わないからだ。
admin/1 にアクセスされて困るなら、バックエンドが悪い。(フロントエンドで対処するのは無意味)
バックエンドでやって…
とっても最初の疑問として fetch つかってるから get は不適切だなーとは思った (アクセスに時間がかかる関数に即座に値が帰りそうな get は微妙というニュアンス)。それ以外はまあ用途別なのでなんとも…
個人的には非同期関数がgetなのが一番嫌かも セキュリティ周りはBEで担保しろよと思うので、後はエラーハンドリングとパフォーマンス周りどこまで拘るかなと思った。それによってテストの必要性も変わってくるし
フロントエンドでしょ。 別に最初のコードで問題ない案件が大半だと思う。
userId指定してユーザデータ取ってくるAPIに見えるのに、仮に大量のユーザ返して来たらAPI側が頭おかしいか、叩くAPI間違えてるのか？みたいな話になると思うんだよね。リーダブルコードにならない国語破綻コードなの？
いろいろ突っ込まれてるけど良い記事だと思う。フロントエンドでそこまでやるか？という心のツッコミも含めて
全く関係ない業務してるけど勉強になった。実務に関係ないから興味ないは好奇心の死だと思う。そこがないと勉強も頭打ちやん。「バックエンドでやれよ」で終わりは違うと思う。
エクセプションを誰にオーバーライドさせるかは、アーキテクトの設計次第では？
「正解」を示したつもりでも文句の付け所はあるんだから、つくづくコードレビューって好き嫌いの問題だと思う
“初心者は「他に方法を知らないから」 これを書きます。熟練者は「すべての選択肢を知った上で、今回はこれで十分だ」 と判断して書きます。見えている世界がまったく違います。”
プログラミングに限らず、どんな仕事でもそうだ。様々な場面を想定できないと、適切な選択をすることはできない。
どこまでを想定してfunctionを設計するか
問題は「動くコードが書ければ十分」と感じているエンジニアはこの記事を目にすることがないことだ
いい記事だと思う！知ってて書かないのと知らなくて書かないの、たしかに違うねー。
それほどスキルの高くないメンバーがいる社内勉強会の導入にもってこいの良記事だと思う。とてもわかりやすい。完璧にやるにもやらないにも理由が必要なことを、突っ込まれる前に考えるようになりそう
見えていることと頭で思い浮かべたことは区別するべき。
“野放図”
感動。
いい記事。ケースバイケースではあるけど、たぶんtypescript化と、定数に切り出し、responseの結果判定だけ入れるかな。useridはもっと手前でチェックするし、テストの必要があるコードではない/確かに名前はfetchにしないと
プログラミングの9割は異常系でできている
良い話。知識が生きる場所
良い記事だ。
良い記事だったわ
constで関数定義していいんか？それで実際動くの？以外の感想は出てこない。
今年の技術系エントリで一番いい記事。対象読者も広そう。
試しにここに書いてある「観点」を指示してChatGPT5に食わせたら素人目にはここにあるのと似たコードが出てきました。
めちゃくちゃ良い記事だ。これが解像度の違いってヤツだと思う。
めっちゃ良い記事！非エンジニアなのでコードの妥当性は分からないけれど、視点と視座、デリバリーと要件とのトレードオフなど考えされられたし、なにより学習の必要性ってこういうことだよなと理解させられた。
この方にはてなオブ・ザ・イヤーを
そうして、動けばいいだけだったはずのコードが、このような重いコードになって、後任者を苦しめるのであった。トレードオフを学ばない人が圧倒的に多い、人は基本的に気になったところだけやる。
良記事。学んできた内容によって、ソースコードを見た時の気づきが異なってくる。学ぶ理由のひとつ
指摘事項を全部取り込んだら可読性が悪いソースコードが出来上がるよな
とてもよい！！ありがたい！！
学べば学ぶほど、いろいろな選択肢や例外が見えてしまって、判断が遅くなるフェーズってありますよね。無学者からすると「何をそんなに考えてるの？ 意味あるの？ 心配しすぎじゃない？」みたいになりがち。
この内容を言語化できるのすごいなぁ
人生で一番大切なのはトレードオフ。
別に違って見えはしないだろ。動きは見た通りなんだから。なんか違う意味があるのかと思ったわ。
一関数に詰め込みすぎで、適切な隠蔽をすべき
良記事。こちらが感じた違和感は最後でちゃんと回収されている。
どこで使うか次第じゃないん? なんか皆がそこまで良記事って呼んでいるのがよくわからないです..
Excelのヘルプ機能の開発者に読ませたい
分かりやすい良記事。でもシステムプロンプトにそれらを書いておけばいいんじゃないでしょうか。
役に立たない記事どうも
これさ「人間に対して、もっと勉強しなさい」なのよ。たった一言「AI」と入れただけでトップコメみたいに、AIを引き合いに出す。AI関係ないんだって。言葉も、ちゃんと学べ！だな。
すばらしい。リスクとコストのトレードオフと,「時間」稀少価値に触れてる。要求の仕様化で各観点を定量的制約条件として定義し,それに一貫性持たせ,制約含めて検証できるかが鍵。スキル程度と見え方の相違も同意
このフォーマット面白いな
これらって、ほとんどネット上に作っていることが原因だよな。インフラが変わったときに、その世界では何が影響するのか想像できる知識が必要になる。
ただ動けばいいコードの10倍大変なんだよな。
"同じものを見ていても、○○と××では見えている世界がまったく違っている"をメタに体感できるブコメ欄。
知っててやらないと決断したのと、知らないしやってないのとでは大違い
面白そう、読む。
難しい
型に始まり型に終わる、達人の型はときに初心者のそれに近く見えるが、実は見てきた世界が違う…世阿弥元清の風姿花伝／花鏡が浮かんだ。かっこいいな
学び続ける人生は新たな発見と共に世界を広げ、日々を豊かに彩る。一方、学びを止めれば単調な繰り返しに陥り、生きる喜びも色褪せ、心は枯れていく。
でもココナラさんて「えっこの機能ないの？」みたいなことあるからな……技術者側じゃなくてサービス設計の問題かもしれんけど……
エラー処理しないとと、apiは無認証で使えるの？、とは最初に思ったが、色々考えることあるよね…
こういうのは座学で学ばなくていいと思う。実践で指摘されたり、失敗していくうちに身につければいい。それと早すぎる最適化はいらない。
すこ。最後に必要な機能を取捨選択したうえで、最初のコードくらい透明に実装できるようにいかに隠蔽かって腕やフレームワークの見せどころ、だったけどもうAIにそれも含めてちゃんと伝えれば出来上ちゃうの、神。
https://support.google.com/edu/classroom/thread/367124802?hl=en&sjid=10960887315234543938-NC
面白い。見えたうえでやらないのと、見えないは世界が違う。
本文中にも書いてあるけど、実際にはgetName自体でこんなにいっぱい書くんじゃなくて生fetch自体をもっとロバストにラップして使うと思うよ。
新人教育に良さげ
https://my105.iit.edu/registrar/forms/data/form_40852/files/element_6_a05f643b28398c1c5506e19103c0a022-Does-Coinbase-have-live-support_ProvideRiskFree.pdf.tmp
とりあえず言えるのは、テストのためにdepsを受け取るのは悪手だと思う。 個人的には、最終手段かな⋯。 普通なら、fetchをスタブ化するのがいいよ〜。
同じ5行のコードが全く違って見える12の瞬間、なぜ私たちは学ぶのか？
五行思想
良い話
これは素晴らしい。
落ちに、これは大変なのでFW使います、あたりにして欲しい
ちょっと感動しました
“APIからユーザー名を取得するTypeScript関数。エラーハンドリングを学んだら、意図した通りに動いてくれない野放図なコードだとわかる。パフォーマンスを学んだら、このコードが典型的なN+1問題だと即座に認識”
よい話
氏名取得のための処理、五行無限の気付きあり/良い記事。
クライアント側のコードだけ変えても指摘されてる問題の本質は解決されてなくない？ってのがあるように見える。
copilotってここまでやってくれないよね。相当詰めないと。
極端な例って書いてあるのにー
良い話
“N+1問題”この例ってニュアンスが違う気がする。リストとってきてそのリストを元に再度一つづつ問い合わせを行う事だと思うんだけど...
ふむふむ、コードって奥深いのにゃ。ボクにはおやつの方がもっと違って見えるにゃ！
これは良記事
さすがに妄想が過ぎるので、責務の範囲を設計するということを学んだほうがいい。/「もしも」プログラミングを卒業して、現実を見たコードを書いたほうがいい。
良記事。結局AI使ったところで、エンジニアがこの辺のジャッジができる必要があるから、そんなに速度上がらんのよ。できないレベル感のエンジニアは逆にAIに主導権を握られて高速でジェンガタワーを作ってしまう。
いい記事だしなんか悔しいな
教材として良さそう
いいね、コーディング忘れたおじさんは癒されるね
深いね。確かに学び続けることの重要性が伝わる
そんなにいろいろ想定して結局意味ないパターンの方がおおいので特にスケーラビリティとかはほんとうに必要になってから対応しろ…とかおもってたら最後に「トレードオフを学んだら」がでてきてぐうの音もでないな？
コードを見ながら設計するな。非機能はプロジェクト共通で設計しろ
これはいいな
まとめて取るにはuserId50件を保持してないといけないけど、、、全然典型的ではないような。 “典型的なN+1問題”
ユーザ名を取得するサンプルコードだなと見えるし、それ以上は何も見ない。まさかこれが実運用で使われるとは露とも思わないからだ。
admin/1 にアクセスされて困るなら、バックエンドが悪い。(フロントエンドで対処するのは無意味)
バックエンドでやって…
とっても最初の疑問として fetch つかってるから get は不適切だなーとは思った (アクセスに時間がかかる関数に即座に値が帰りそうな get は微妙というニュアンス)。それ以外はまあ用途別なのでなんとも…
個人的には非同期関数がgetなのが一番嫌かも セキュリティ周りはBEで担保しろよと思うので、後はエラーハンドリングとパフォーマンス周りどこまで拘るかなと思った。それによってテストの必要性も変わってくるし
フロントエンドでしょ。 別に最初のコードで問題ない案件が大半だと思う。
userId指定してユーザデータ取ってくるAPIに見えるのに、仮に大量のユーザ返して来たらAPI側が頭おかしいか、叩くAPI間違えてるのか？みたいな話になると思うんだよね。リーダブルコードにならない国語破綻コードなの？
いろいろ突っ込まれてるけど良い記事だと思う。フロントエンドでそこまでやるか？という心のツッコミも含めて
全く関係ない業務してるけど勉強になった。実務に関係ないから興味ないは好奇心の死だと思う。そこがないと勉強も頭打ちやん。「バックエンドでやれよ」で終わりは違うと思う。
エクセプションを誰にオーバーライドさせるかは、アーキテクトの設計次第では？
「正解」を示したつもりでも文句の付け所はあるんだから、つくづくコードレビューって好き嫌いの問題だと思う
“初心者は「他に方法を知らないから」 これを書きます。熟練者は「すべての選択肢を知った上で、今回はこれで十分だ」 と判断して書きます。見えている世界がまったく違います。”
プログラミングに限らず、どんな仕事でもそうだ。様々な場面を想定できないと、適切な選択をすることはできない。
どこまでを想定してfunctionを設計するか
問題は「動くコードが書ければ十分」と感じているエンジニアはこの記事を目にすることがないことだ
いい記事だと思う！知ってて書かないのと知らなくて書かないの、たしかに違うねー。
それほどスキルの高くないメンバーがいる社内勉強会の導入にもってこいの良記事だと思う。とてもわかりやすい。完璧にやるにもやらないにも理由が必要なことを、突っ込まれる前に考えるようになりそう
見えていることと頭で思い浮かべたことは区別するべき。
“野放図”
感動。
いい記事。ケースバイケースではあるけど、たぶんtypescript化と、定数に切り出し、responseの結果判定だけ入れるかな。useridはもっと手前でチェックするし、テストの必要があるコードではない/確かに名前はfetchにしないと
プログラミングの9割は異常系でできている
良い話。知識が生きる場所
良い記事だ。
良い記事だったわ
constで関数定義していいんか？それで実際動くの？以外の感想は出てこない。
今年の技術系エントリで一番いい記事。対象読者も広そう。
試しにここに書いてある「観点」を指示してChatGPT5に食わせたら素人目にはここにあるのと似たコードが出てきました。
めちゃくちゃ良い記事だ。これが解像度の違いってヤツだと思う。
めっちゃ良い記事！非エンジニアなのでコードの妥当性は分からないけれど、視点と視座、デリバリーと要件とのトレードオフなど考えされられたし、なにより学習の必要性ってこういうことだよなと理解させられた。
この方にはてなオブ・ザ・イヤーを
そうして、動けばいいだけだったはずのコードが、このような重いコードになって、後任者を苦しめるのであった。トレードオフを学ばない人が圧倒的に多い、人は基本的に気になったところだけやる。
良記事。学んできた内容によって、ソースコードを見た時の気づきが異なってくる。学ぶ理由のひとつ
指摘事項を全部取り込んだら可読性が悪いソースコードが出来上がるよな
とてもよい！！ありがたい！！
学べば学ぶほど、いろいろな選択肢や例外が見えてしまって、判断が遅くなるフェーズってありますよね。無学者からすると「何をそんなに考えてるの？ 意味あるの？ 心配しすぎじゃない？」みたいになりがち。
この内容を言語化できるのすごいなぁ
人生で一番大切なのはトレードオフ。
別に違って見えはしないだろ。動きは見た通りなんだから。なんか違う意味があるのかと思ったわ。
一関数に詰め込みすぎで、適切な隠蔽をすべき
良記事。こちらが感じた違和感は最後でちゃんと回収されている。
どこで使うか次第じゃないん? なんか皆がそこまで良記事って呼んでいるのがよくわからないです..
Excelのヘルプ機能の開発者に読ませたい
分かりやすい良記事。でもシステムプロンプトにそれらを書いておけばいいんじゃないでしょうか。
役に立たない記事どうも
これさ「人間に対して、もっと勉強しなさい」なのよ。たった一言「AI」と入れただけでトップコメみたいに、AIを引き合いに出す。AI関係ないんだって。言葉も、ちゃんと学べ！だな。
すばらしい。リスクとコストのトレードオフと,「時間」稀少価値に触れてる。要求の仕様化で各観点を定量的制約条件として定義し,それに一貫性持たせ,制約含めて検証できるかが鍵。スキル程度と見え方の相違も同意
このフォーマット面白いな
これらって、ほとんどネット上に作っていることが原因だよな。インフラが変わったときに、その世界では何が影響するのか想像できる知識が必要になる。
ただ動けばいいコードの10倍大変なんだよな。
"同じものを見ていても、○○と××では見えている世界がまったく違っている"をメタに体感できるブコメ欄。
“野放図”
知っててやらないと決断したのと、知らないしやってないのとでは大違い
面白そう、読む。
難しい
型に始まり型に終わる、達人の型はときに初心者のそれに近く見えるが、実は見てきた世界が違う…世阿弥元清の風姿花伝／花鏡が浮かんだ。かっこいいな
学び続ける人生は新たな発見と共に世界を広げ、日々を豊かに彩る。一方、学びを止めれば単調な繰り返しに陥り、生きる喜びも色褪せ、心は枯れていく。
でもココナラさんて「えっこの機能ないの？」みたいなことあるからな……技術者側じゃなくてサービス設計の問題かもしれんけど……
エラー処理しないとと、apiは無認証で使えるの？、とは最初に思ったが、色々考えることあるよね…
こういうのは座学で学ばなくていいと思う。実践で指摘されたり、失敗していくうちに身につければいい。それと早すぎる最適化はいらない。
すこ。最後に必要な機能を取捨選択したうえで、最初のコードくらい透明に実装できるようにいかに隠蔽かって腕やフレームワークの見せどころ、だったけどもうAIにそれも含めてちゃんと伝えれば出来上ちゃうの、神。
https://support.google.com/edu/classroom/thread/367124802?hl=en&sjid=10960887315234543938-NC
面白い。見えたうえでやらないのと、見えないは世界が違う。
本文中にも書いてあるけど、実際にはgetName自体でこんなにいっぱい書くんじゃなくて生fetch自体をもっとロバストにラップして使うと思うよ。
良い話
新人教育に良さげ
https://my105.iit.edu/registrar/forms/data/form_40852/files/element_6_a05f643b28398c1c5506e19103c0a022-Does-Coinbase-have-live-support_ProvideRiskFree.pdf.tmp
とりあえず言えるのは、テストのためにdepsを受け取るのは悪手だと思う。 個人的には、最終手段かな⋯。 普通なら、fetchをスタブ化するのがいいよ〜。