Qiita 4 - キータぞ、来たぞ、キータだぞー

**デフォルトの名無しさん** · 2024/01/17(水) 19:20:36.09

Hello hackers !
Qiitaは、エンジニアリングに関する知識を記録・共有するためのサービスです。
コードを書いていて気づいたことや、自分がハマったあの仕様について、
他のエンジニアと知見を共有しましょう ;)

https://qiita.com/

Qiita（キータ）は、Incrementsが運営するプログラミング情報のナレッジコミュニティ。
2016年現在で日本最大のプログラマーコミュニティとされている[1]。

https://internet.watch.impress.co.jp/docs/news/1025972.html

前スレ Qiita
https://mevius.5ch.net/test/read.cgi/tech/1542357242/
Qiita 2 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1658762410/
Qiita 3 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1685235361/

**デフォルトの名無しさん** · 2024/03/03(日) 16:22:53.63

>>309
じゃあashworthが称賛してる記事主のコードを見てみよう。

> year = int(input())
> if year % 400 == 0: # 400の倍数なら「うるう年です。」
> 　　print("うるう年です。")
> elif year % 100 == 0: # 100の倍数なら「うるう年ではありません。」
> 　　print("うるう年ではありません。")
> elif year % 4 == 0: # 4の倍数なら「うるう年です。」
> 　　print("うるう年です。")
> else: # どれにも当てはまらなければ、「うるう年ではありません。」
> 　　print("うるう年ではありません。")

んー大差なくね?
つか出力するメッセージとコメントが被ってる分どうかという気がするわ。

**デフォルトの名無しさん** · 2024/03/03(日) 17:17:37.89

> A: 4の倍数ならばうるう年
> B: 100の倍数ならば平年
> C: 400の倍数ならばうるう年
> になります。
>
> ここで、AとBの条件に注目して、
>
> 100の倍数ならば、4の倍数である
> ことに気づくと、
>
> 100の倍数は平年。そして100の倍数でない4の倍数はうるう年。
> という形で、AとBの関係を整理することができます。
>
> 同様に、BとCについても、
>
> 400の倍数ならば、100の倍数である
> ので、
>
> 400の倍数ならばうるう年。そして400の倍数でない100の倍数は平年。
> という形で、BとCの関係を整理することができます。
>
> まとめると、ある西暦に対して、
>
> 400の倍数ならば、うるう年
> 400の倍数でない、100の倍数ならば、平年
> 100の倍数でない、4の倍数ならば、うるう年
> 4の倍数でないならば、平年
> ということになります。

これコメントに書かなくて良い理由がわからん

つか記事主も「ただし」勝手に削除しとるのなｗ

**デフォルトの名無しさん** · 2024/03/03(日) 20:00:32.81

初めて聞いた「カルノー図」に発狂してるashworthオモロｗ

**デフォルトの名無しさん** · 2024/03/03(日) 21:02:10.90

・if は個人的に「もし～なら」で言ってほしい
・「ただし」はプログラミング的な英単語がない気がするので(however的な？)、仕様書とかでも多用しないで欲しい
・else、elseifも「ただし」じゃないと思うので相応の日本語にしてほしい
・早期リターンしてほしい

400から順番にreturnしてもらえれば、ワイ的にはおけ
仕様変更の可能性に対してはとりあえず関数にしてればいい
マジックナンバーじゃねとかライブラリ使えとか色々あると思うけど、この関数が必要なんだろうからテスト通れば許容すると思う

**デフォルトの名無しさん** · 2024/03/03(日) 21:47:18.39

閏年の仕様が変わったら判定関数だけ置き換えればいいのだから
判定関数の中身なんて何でもいいのよ
割り算(剰余算)と分岐はCPUにとって非常に遅いから避けるとするならば例えばこんな感じ

fn is_leap_year(year: u64) -> bool {
　let q100 = (year * 42949673) >> 32;
　((q100 & 3 == 0) | (q100 * 100 != year)) & (year & 3 == 0)
}

**デフォルトの名無しさん** · 2024/03/03(日) 22:44:59.76

>>315
107374182500年は平年? 閏年?

**デフォルトの名無しさん** · 2024/03/03(日) 23:02:43.19

Rust推しは意識高い良く分かって馬鹿が多い印象

**デフォルトの名無しさん** · 2024/03/04(月) 00:48:03.64

>>315
素直に100で割らない意味がわからん。
要らんことやって仕事増やすタイプだろお前。

pub fn is_leap_year(year: u64) -> bool {
　let q100 = year / 100;
　((q100 & 3 == 0) | (q100 * 100 != year)) & (year & 3 == 0)
}
https://godbolt.org/z/YKPWx7ecW

**デフォルトの名無しさん** · 2024/03/04(月) 08:16:08.85

>>315
> 閏年の仕様が変わったら判定関数だけ置き換えればいいのだから
> 判定関数の中身なんて何でもいいのよ

仕様通りに動作するコーディングできるようなってからカッコイイこと言おうなｗ

**デフォルトの名無しさん** · 2024/03/04(月) 08:38:24.53

>>308
あまり見かけねえ書き方で新鮮だな

**デフォルトの名無しさん** · 2024/03/04(月) 09:02:08.19

>>315
Rustって使ったことないんだけど動確してみた。書き方合ってる?

fn is_leap_year(year: u64) -> bool {
　let q100 = (year * 42949673) >> 32;
　((q100 & 3 == 0) | (q100 * 100 != year)) & (year & 3 == 0)
}

fn main()
{
　let year = 107374182500;
　println!("is_leap_year({}) -> {}", year, is_leap_year(year));
}

実行結果:
is_leap_year(107374182500) -> true

https://wandbox.org/permlink/QpmojpixtLrxk9CW

**デフォルトの名無しさん** · 2024/03/04(月) 09:41:48.67

>>316 >>321
1000億年後の閏年とか低能丸出し
地球も存在しないぞ
それ以前に60万年後には誤差が半年となり夏冬逆転し無意味となる
それ以前にルールが変わるため大きな数に対応する意味がない

**デフォルトの名無しさん** · 2024/03/04(月) 09:52:37.00

日本語に弱いやつしかいないのに互いに馬鹿にしあってるの草

**デフォルトの名無しさん** · 2024/03/04(月) 10:05:22.74

年を表す引数の型にu64使うのが頭悪い。引数型で表せる値について動作保証できないロジックも同様。
引数に4300億とか与えるとオーバーフローするし場合により異常停止するだろこのコード。実際にそういう引数は与えないと強弁したところで潜在的不具合であることに変わりない。

**デフォルトの名無しさん** · 2024/03/04(月) 10:07:06.25

話題に加われない>>323がashworthなの一目瞭然で草ｗｗ

**デフォルトの名無しさん** · 2024/03/04(月) 10:17:08.86

https://wandbox.org/permlink/V9X44saMMVMpQVoi
> thread 'main' panicked at 'attempt to multiply with overflow', prog.rs:2:14
> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

あっこれはカッコ悪いなｗ

>>315
> 割り算(剰余算)と分岐はCPUにとって非常に遅いから避けるとするならば例えばこんな感じ

素直に100で割ってればオーバーフローしないんだし優先順位間違ってるよ。

**デフォルトの名無しさん** · 2024/03/04(月) 10:23:15.83

Rust使いでニワカかあ。
自己評価と実力が合ってない雰囲気で質悪そう。

**デフォルトの名無しさん** · 2024/03/04(月) 10:29:55.63

え、今更入力値が何でもアリになるの？w

**デフォルトの名無しさん** · 2024/03/04(月) 10:55:00.92

仕様に入力値の範囲が決められてないのに実装者の都合で制限設けて良いって判断は流石に草

**デフォルトの名無しさん** · 2024/03/04(月) 11:23:54.90

じゃあバリデーションが必要だなww

**デフォルトの名無しさん** · 2024/03/04(月) 13:14:12.60

要件定義の際にクライアントに「1億年後も検証出来る仕様にした方がいいっすか？w」と聞かなかった上流の責任笑

**デフォルトの名無しさん** · 2024/03/04(月) 13:53:50.23

Rust支持の人達って安全について意識が高く技術的レヴェルが高い層だと思っていたので自ら率先して不具合を作り込もうとする>>315の存在には驚いたんだけど、よく考えてみると

「えっ今どきEmacsなんて使ってるの？今はVSCode一択でしょ」
「えっ今どきSVNなんて使ってるの？今はgit一択でしょ」
「えっ今どきJavaなんて使ってるの？今はKotlin一択でしょ」
「えっ今どきC++なんて使ってるの？今はRust一択でしょ」

使ってる道具でマウント取ろうとする奴なんて昔からいるし使ってる道具が新しく洗練されてたとしてそれ使ってる奴の技術的高さを証明するものではないしなあ、変な先入観持ってたわと反省。

**デフォルトの名無しさん** · 2024/03/04(月) 14:34:57.46

>上流の責任笑
これが末端コーダーの考え方

**デフォルトの名無しさん** · 2024/03/04(月) 15:14:26.33

>333
ヒント:冗談

**デフォルトの名無しさん** · 2024/03/04(月) 16:34:00.40

入力値に制限がないなら、
文字列とか小数とかそれ以外のパラメータなときを考慮してない
今までのコードは軒並み全部ダメってことでw

**デフォルトの名無しさん** · 2024/03/04(月) 17:50:07.95

>>334
何をバカにされてるかわかってない辺りがまさに末端コーダー

**デフォルトの名無しさん** · 2024/03/04(月) 17:59:24.41

>判定関数の中身なんて何でもいいのよ
判定関数自体の保守性が論点にも関わらずそれを無視した独りよがりのオナニー汚コードを恥ずかしげもなく披露するメンタリティが怖い

**デフォルトの名無しさん** · 2024/03/04(月) 18:31:19.07

>>335
元記事に整数と書いてあるんだからそこまで考える必要はないでしょ

**デフォルトの名無しさん** · 2024/03/04(月) 19:15:00.88

>336
納期近いのか？イライラしても仕事は進まんぞ

**デフォルトの名無しさん** · 2024/03/04(月) 19:16:47.00

97/400の閏年は10万年で1ヶ月の誤差が出るため100万の入力すら対応する必要がない
そこへ億の入力をして騒ぐのはキチガイ

**デフォルトの名無しさん** · 2024/03/04(月) 20:12:58.89

整数、西暦なんて数値制限がないんだから、
型も限りなく無限にちかいbit、桁数まで対応しなきゃいけんのかw
こりゃ大変だなw

**デフォルトの名無しさん** · 2024/03/04(月) 20:22:40.17

現在のグレゴリオ暦を運用し続けたとして1兆年後どうなるか? みたいな計算をしたいとして、間違って良い理由はないんだよなあ。

**デフォルトの名無しさん** · 2024/03/04(月) 20:30:16.70

>>322
>>315のコードでおかしな結果を出す一番近い年が107374182500年だと思ってる??

**デフォルトの名無しさん** · 2024/03/04(月) 20:34:57.33

3320年で1日の誤差
10万年で1月の誤差
120万年で1年の誤差
季節が数か月ズレると役立たないから
多くても数十万年に対応してれば十分かな
それ以上の数値を持ち出す人は本質的に何が重要なのかを理解できていないバカ

**デフォルトの名無しさん** · 2024/03/04(月) 20:52:01.50

> 多くても数十万年に対応してれば十分かな

クソコードは数十万年に対応出来てることを証明するのにも無駄に労力要るんだよなあ。

**デフォルトの名無しさん** · 2024/03/04(月) 20:55:08.59

> それ以上の数値を持ち出す人は本質的に何が重要なのかを理解できていないバカ

↑入力値によってはプログラムが落ちる事の重大さを理解してないアホ

**デフォルトの名無しさん** · 2024/03/04(月) 20:59:22.65

入力値によってプログラムが落ちると思っているアホがいるのか

**デフォルトの名無しさん** · 2024/03/04(月) 21:07:19.90

>>315のコードは
・なぜ引数yearの型がu64なのか
・yearを100で割れば良いところを2**32/100倍して32ビット右シフトなんて馬鹿なことをしてるのか

謎なのよなあ、こんなコード業務で書いたら絶対レビューでなんか言われるやつじゃん。

説明すれや＞本人

**デフォルトの名無しさん** · 2024/03/04(月) 21:27:56.24

今どきのコンパイラは、定数割り算を定数掛け算とシフトでコード生成するから、それ自体を問題にするのは知識不足としか。

**デフォルトの名無しさん** · 2024/03/04(月) 21:30:45.48

>>347
>>326

**デフォルトの名無しさん** · 2024/03/04(月) 21:56:19.34

>>326
それDEBUGモードになってるね
RustはC/C++と同じく整数演算はオーバーフローせずラッピングされるよ

**デフォルトの名無しさん** · 2024/03/05(火) 00:11:26.36

型でエラーになるのはダメやろw
有限な数値型を引数にする関数は全部ダメ

**デフォルトの名無しさん** · 2024/03/05(火) 00:19:04.31

それはあるな
少なくともbigintは必須

**デフォルトの名無しさん** · 2024/03/05(火) 00:24:51.84

>>337
平日の昼間から一日中5chに張り付いてるようなやつらに保守性を説いても時間の無駄
理由は言わなくてもわかるよね？

**デフォルトの名無しさん** · 2024/03/05(火) 00:40:04.95

関数内部の単なる数値演算に保守性もクソもないぜ
そんなところの保守性にこだわるやつは仕事できないやつ
それよりも複数のデータや複数の関数に関わるところの保守性をしっかりやればいい

**デフォルトの名無しさん** · 2024/03/05(火) 05:36:37.94

中身が何でもいいならわずかなパフォーマンス改善よりも楽に読み書きできるほうがいいわｗｗｗｗ

**デフォルトの名無しさん** · 2024/03/05(火) 06:40:09.05

非常に大きな値を扱える方がいい場合もあれば
実用の範囲だけを速く扱える方がいい場合もあれば
複雑になっても将来の拡張に備えた形にした方がいい場合もあれば
それら様々な前提があるのだから
それぞれの前提でそれぞれのふさわしい別々のコードになるのは当たり前
各々の前提を無視して批判するのは愚か

**デフォルトの名無しさん** · 2024/03/05(火) 09:50:57.37

>>351
実行時にオーバーフローを検出する運用も普通に可能だけど安全の意味分かってる？

**デフォルトの名無しさん** · 2024/03/05(火) 10:58:46.36

>>351
> RustはC/C++と同じく整数演算はオーバーフローせずラッピングされるよ

CやC++でラッピングされるのは符号なし整数の場合だけ。
符号付き整数のオーバーフローは未定義動作になるので通常許されない。

**デフォルトの名無しさん** · 2024/03/05(火) 11:09:30.17

>>357
>非常に大きな値を扱える方がいい場合もあれば
>実用の範囲だけを速く扱える方がいい場合もあれば
>複雑になっても将来の拡張に備えた形にした方がいい場合もあれば
どの場合も保守性を無視したコードを書いていいわけじゃないんだぞ
ド素人さんw

**デフォルトの名無しさん** · 2024/03/05(火) 11:10:48.88

>>355
> 関数内部の単なる数値演算に保守性もクソもないぜ

>>315のクソコード見てから言え

**デフォルトの名無しさん** · 2024/03/05(火) 11:33:45.43

>>361
どう見ても同一人物だろw
アホか

**デフォルトの名無しさん** · 2024/03/05(火) 11:52:26.48

>>361
>>147のクソコード見てから言え！

**デフォルトの名無しさん** · 2024/03/05(火) 12:09:50.59

この狂人の会話についていけるやつが賢いと本気で思うやつおる？w

**デフォルトの名無しさん** · 2024/03/05(火) 12:30:39.80

>>363 ashworthの投稿は一目でわかるなｗ

**デフォルトの名無しさん** · 2024/03/05(火) 18:44:35.96

>>318
「let q100 = year / 100;」の方が生成コードが長く遅くなってるな
あくまでも速さ優先ということならば>>315の
「let q100 = (year * 42949673) >> 32;」が正解でいいんじゃないか
あとは状況による使い分けだろう

**デフォルトの名無しさん** · 2024/03/05(火) 19:35:33.31

>>366
> あくまでも速さ優先ということならば

https://godbolt.org/z/4sTMYGb9d

引数yearの型をu32にして普通に100で割るのが正解。

**デフォルトの名無しさん** · 2024/03/05(火) 20:42:06.70

> あくまでも速さ優先ということならば>>315の
> 「let q100 = (year * 42949673) >> 32;」が正解でいいんじゃないか

「自分は>>315じゃないけどこの人のコードが正解だと思いますよ」みたいな投稿よくできるなあ。

**デフォルトの名無しさん** · 2024/03/05(火) 20:50:34.98

周りが見てて赤面するような低レベル自演
それをいつも平気でするのが彼なんです

**デフォルトの名無しさん** · 2024/03/05(火) 21:13:56.87

ashworthの投稿は一目でわかるなｗ

**デフォルトの名無しさん** · 2024/03/05(火) 22:49:41.95

まだクソザコミジンコいるの？いい加減飽きたよ

**デフォルトの名無しさん** · 2024/03/05(火) 23:54:29.42

ashworthの投稿は一目でわかるなｗｗ

**デフォルトの名無しさん** · 2024/03/06(水) 10:25:59.29

C言語1からお教えします！
https://qiita.com/ToaruSWEng_Yopiro/items/0fa594857d72c68fe3f7

宣伝記事。
30日で5万円て微妙な線かな。本人の実力とかサッパリわからん人だけど。

**デフォルトの名無しさん** · 2024/03/06(水) 23:45:18.98

>>367
なるほど
コンパイラが
let q100 = year / 100;
を
let q100 = ((year as u64 * 1374389535) >> 37) as u32;
へと自動変換してくれてるんだ
これは割り算が遅いため？

**デフォルトの名無しさん** · 2024/03/07(木) 17:33:15.65

>>373
消えてんじゃん
それでちゃんと教えてもらえるなら安いが修了して嘘ばっか教えられたとか何も残らんとか独学と変わらんならただの銭ドブだな

**デフォルトの名無しさん** · 2024/03/07(木) 20:58:11.23

>>315と>>374を比べると微妙に違うんだな
q100 = (year * 42949673) >> 32
q100 = (year * 1374389535) >> 37

**デフォルトの名無しさん** · 2024/03/08(金) 01:22:49.50

ashworthの投稿は一目でわかるなｗ

**デフォルトの名無しさん** · 2024/03/08(金) 01:36:10.70

>>376
2^5＝32倍すれば同じ

**デフォルトの名無しさん** · 2024/03/08(金) 20:20:11.11

>>367
うるう年判定プログラムの最終的な正解はそれか
q100 = year / 100
return ((q100 & 3 == 0) | (q100 * 100 != year)) & (year & 3 == 0)

**デフォルトの名無しさん** · 2024/03/08(金) 21:23:51.45

うるう年の判定に速度なんて求められてないから可読性捨ててるコードが正解な訳ないんだよ

**デフォルトの名無しさん** · 2024/03/08(金) 21:40:30.10

なんて2年前のしょーもない記事を延々擦ってんの

**デフォルトの名無しさん** · 2024/03/09(土) 01:32:01.74

https://qiita.com/jaque/items/b99ed9dce78cc64fa9d2#comment-c16f3fb050b21b73dc21
> 頭がまともならこうじゃねぇの？
> あまりにもバカらしいので動くかどうか検証してないけど。
> あれかな？　掛け算には順序があります！とか言ってる脳みそウニな小学校算数信奉者なんかな？
> なんでreturnするだけでカンマがどうしたいう話になるんやろ？

この人何か辛いことでもあったのかな？かわいそうな人もいればいるものだね。

**デフォルトの名無しさん** · 2024/03/09(土) 02:35:14.90

ashworth生きとったんかワレ

**デフォルトの名無しさん** · 2024/03/09(土) 03:01:34.02

自宅Qiita巡回員がパトロール中にashworth見つけてきたのかと思いきや1コメ藤田で吹いたわw
しかもお前early return推奨しとるやんけww

**デフォルトの名無しさん** · 2024/03/09(土) 08:46:40.66

https://qiita.com/Sicut_study/items/71b866d8f064699cb57b
胡散臭すぎると思いつつ読んだら最後に士商法のリンクがあって納得した

**デフォルトの名無しさん** · 2024/03/09(土) 08:51:24.21

ashworth本人が書いてるんだろうなぁ

**デフォルトの名無しさん** · 2024/03/09(土) 11:20:29.30

D-Threeってやつのが一番まともだが
F#で書いたせいで誰にも伝わってなくて草
JSでも同じように書けるだろうに

逆にStack Overflowなら確実にマイナスポイントになってそうなやつがいいねされてるのあたりはさすがQiita
なんだよ関数型として見ればかなり自然てw

**デフォルトの名無しさん** · 2024/03/09(土) 11:39:24.84

ashworth発狂してて草ｗ

**デフォルトの名無しさん** · 2024/03/09(土) 11:51:36.66

条件演算子を使ってる奴はカバレッジの概念がないんだろうなあ

**デフォルトの名無しさん** · 2024/03/09(土) 12:16:07.82

https://qiita.com/jaque/items/b99ed9dce78cc64fa9d2#comment-47fc225ee5fb822d7d4b
> これ、酷いなぁ…。
> こんなのにいいねが6もつくんや…。
> 世も末やなぁ…。

とash worthが仰ってるコメント、

> 今回のコードもいい感じに整形したら意外とありかも？と思って書いてみましたが、やっぱりダメですね。（再代入とカンマ演算子がｋｓすぎる）

と書いててコメント投稿者は良い例として認識してないし「いいね」付けてる人も分かってる筈なんだけど、一人で発狂してるash worth本当に馬鹿だなあ。

**デフォルトの名無しさん** · 2024/03/09(土) 13:09:29.90

前回のうるう年だとashworthはもう少しわかってるやつかと思ってたが今回の見ると俺の見る目が間違ってた
Zuishinや藤田らとどんぐりの背比べと言ってた人が完全に正しい

**デフォルトの名無しさん** · 2024/03/09(土) 13:54:31.13

ashworthの投稿は一目でわかるなｗ

**デフォルトの名無しさん** · 2024/03/09(土) 13:57:15.07

抜群に馬鹿でしょashworth

**デフォルトの名無しさん** · 2024/03/09(土) 14:09:45.45

ashworthがよくやってる行動で自分が知らない方法について否定したり馬鹿にしたりするの見ててだいぶ恥ずかしいんだけど本人的にはどうなんかね?
もう50過ぎみたいだけど自分のこと少しも客観視できないのかな
発達障害的な人物かしら

**デフォルトの名無しさん** · 2024/03/09(土) 14:13:11.40

>>287
おまえらって2月29日を迎えるから「うるう年」の話をしてたのか
警戒しててもシステム障害を起こしてワロタ
うるう年でシステム障害を起こす会計システムがすごい

**デフォルトの名無しさん** · 2024/03/09(土) 14:25:42.44

https://qiita.com/jaque/items/b99ed9dce78cc64fa9d2#comment-c16f3fb050b21b73dc21
> 頭がまともならこうじゃねぇの？

> return z * (
> 　　　　(a >= 10)
> 　　　　　　? 10
> 　　　　　　: (a >= 5)
> 　　　　　　　　? 5
> 　　　　　　　　: (a >= 3)
> 　　　　　　　　　　? 3
> 　　　　　　　　　　: (a >= 2)
> 　　　　　　　　　　　　? 2
> 　　　　　　　　　　　　: 1
> 　　);

else ifが続くとインデント平気でどんどん深くしちゃうタイプかな？
馬鹿すぎﾜﾛﾀｗ

**デフォルトの名無しさん** · 2024/03/09(土) 17:11:07.39

流石に非生産的だしうざいから運営に報告したわ
多分何も対処しないだろうけど

**デフォルトの名無しさん** · 2024/03/09(土) 18:13:38.91

うるう年ではashworthが早期リターン推奨で藤田がifのネスト推奨だったのに何で今回は真逆になってるの？

**デフォルトの名無しさん** · 2024/03/09(土) 19:03:44.68

条件によらず最適な方法はひとつしかないと思ってるならashworthより馬鹿

**デフォルトの名無しさん** · 2024/03/09(土) 19:29:16.06

うるう年判定はif使わないのが普通だろ
(4の倍数)＆(!100の倍数|400の倍数)

**デフォルトの名無しさん** · 2024/03/10(日) 09:24:24.15

>>391
流石にそれらより遙か下だわ

**デフォルトの名無しさん** · 2024/03/10(日) 09:34:19.32

>>398
うるう年と違って手が入る可能性のある関数だからだよ

**デフォルトの名無しさん** · 2024/03/10(日) 14:25:21.63

【Ruby】ラーメンでわかる！引数多すぎ問題の解決方法
https://qiita.com/manrikitada/items/b2ea99d362d49caf1c55

程度が低い記事に程度が低いコメント

**デフォルトの名無しさん** · 2024/03/10(日) 16:33:06.65

>>398
ashworthは前回と違い自分の把握してるパターンに当てはめられなかったから
藤田はどういう変更が入りそうか考慮できていないから(どちらのケースでも)

表面上逆になってるように見えるかもしれないけど
両者とも根底にあるのはスキル不足

**デフォルトの名無しさん** · 2024/03/10(日) 17:27:00.72

ashworthの投稿は一目でわかるなｗ

**デフォルトの名無しさん** · 2024/03/10(日) 18:06:21.08

ashさんはね
スキル不足という以前に単なる世間知らず
自分の実力も相手の実力も見えてない
哀れなお山の大将

**デフォルトの名無しさん** · 2024/03/10(日) 18:55:59.10

自分の把握してるパターンて何だw
そもそもashworthが何を把握して何を把握してないかなんてこっちでわからんしだいたい何も把握してないだろ

**デフォルトの名無しさん** · 2024/03/11(月) 00:37:00.24

>>405
藤田さんチィースっw

**デフォルトの名無しさん** · 2024/03/11(月) 01:26:50.22

>>403
ashworthはRubyにオーバーロードがない理由、そしてなくてもいい理由すら想像つかないんだろうな

**デフォルトの名無しさん** · 2024/03/11(月) 01:34:14.86

確かに記事の質も酷いから、他に書いてる記事見たらやっぱり酷い

新人、優秀すぎて草 #ポエム - Qiita
https://qiita.com/manrikitada/items/b2ea99d362d49caf1c55

会社名出してんのによく出せるな