Qiita 4 - キータぞ、来たぞ、キータだぞー
■ このスレッドは過去ログ倉庫に格納されています
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/ >>326
それDEBUGモードになってるね
RustはC/C++と同じく整数演算はオーバーフローせずラッピングされるよ 型でエラーになるのはダメやろw
有限な数値型を引数にする関数は全部ダメ >>337
平日の昼間から一日中5chに張り付いてるようなやつらに保守性を説いても時間の無駄
理由は言わなくてもわかるよね？ 関数内部の単なる数値演算に保守性もクソもないぜ
そんなところの保守性にこだわるやつは仕事できないやつ
それよりも複数のデータや複数の関数に関わるところの保守性をしっかりやればいい 中身が何でもいいならわずかなパフォーマンス改善よりも楽に読み書きできるほうがいいわｗｗｗｗ 非常に大きな値を扱える方がいい場合もあれば
実用の範囲だけを速く扱える方がいい場合もあれば
複雑になっても将来の拡張に備えた形にした方がいい場合もあれば
それら様々な前提があるのだから
それぞれの前提でそれぞれのふさわしい別々のコードになるのは当たり前
各々の前提を無視して批判するのは愚か >>351
実行時にオーバーフローを検出する運用も普通に可能だけど安全の意味分かってる？ >>351
> RustはC/C++と同じく整数演算はオーバーフローせずラッピングされるよ
CやC++でラッピングされるのは符号なし整数の場合だけ。
符号付き整数のオーバーフローは未定義動作になるので通常許されない。 >>357
>非常に大きな値を扱える方がいい場合もあれば
>実用の範囲だけを速く扱える方がいい場合もあれば
>複雑になっても将来の拡張に備えた形にした方がいい場合もあれば
どの場合も保守性を無視したコードを書いていいわけじゃないんだぞ
ド素人さんw >>355
> 関数内部の単なる数値演算に保守性もクソもないぜ
>>315のクソコード見てから言え この狂人の会話についていけるやつが賢いと本気で思うやつおる？w >>363 ashworthの投稿は一目でわかるなｗ >>318
「let q100 = year / 100;」の方が生成コードが長く遅くなってるな
あくまでも速さ優先ということならば>>315の
「let q100 = (year * 42949673) >> 32;」が正解でいいんじゃないか
あとは状況による使い分けだろう >>366
> あくまでも速さ優先ということならば
https://godbolt.org/z/4sTMYGb9d
引数yearの型をu32にして普通に100で割るのが正解。 > あくまでも速さ優先ということならば>>315の
> 「let q100 = (year * 42949673) >> 32;」が正解でいいんじゃないか
「自分は>>315じゃないけどこの人のコードが正解だと思いますよ」みたいな投稿よくできるなあ。 周りが見てて赤面するような低レベル自演
それをいつも平気でするのが彼なんです >>367
なるほど
コンパイラが
let q100 = year / 100;
を
let q100 = ((year as u64 * 1374389535) >> 37) as u32;
へと自動変換してくれてるんだ
これは割り算が遅いため？ >>373
消えてんじゃん
それでちゃんと教えてもらえるなら安いが修了して嘘ばっか教えられたとか何も残らんとか独学と変わらんならただの銭ドブだな >>315と>>374を比べると微妙に違うんだな
q100 = (year * 42949673) >> 32
q100 = (year * 1374389535) >> 37 >>367
うるう年判定プログラムの最終的な正解はそれか
q100 = year / 100
return ((q100 & 3 == 0) | (q100 * 100 != year)) & (year & 3 == 0) うるう年の判定に速度なんて求められてないから可読性捨ててるコードが正解な訳ないんだよ https://qiita.com/jaque/items/b99ed9dce78cc64fa9d2#comment-c16f3fb050b21b73dc21
> 頭がまともならこうじゃねぇの？
> あまりにもバカらしいので動くかどうか検証してないけど。
> あれかな？ 掛け算には順序があります！とか言ってる脳みそウニな小学校算数信奉者なんかな？
> なんでreturnするだけでカンマがどうしたいう話になるんやろ？
この人何か辛いことでもあったのかな？かわいそうな人もいればいるものだね。 自宅Qiita巡回員がパトロール中にashworth見つけてきたのかと思いきや1コメ藤田で吹いたわw
しかもお前early return推奨しとるやんけww D-Threeってやつのが一番まともだが
F#で書いたせいで誰にも伝わってなくて草
JSでも同じように書けるだろうに
逆にStack Overflowなら確実にマイナスポイントになってそうなやつがいいねされてるのあたりはさすがQiita
なんだよ関数型として見ればかなり自然てw 条件演算子を使ってる奴はカバレッジの概念がないんだろうなあ https://qiita.com/jaque/items/b99ed9dce78cc64fa9d2#comment-47fc225ee5fb822d7d4b
> これ、酷いなぁ…。
> こんなのにいいねが6もつくんや…。
> 世も末やなぁ…。
とash worthが仰ってるコメント、
> 今回のコードもいい感じに整形したら意外とありかも？と思って書いてみましたが、やっぱりダメですね。（再代入とカンマ演算子がｋｓすぎる）
と書いててコメント投稿者は良い例として認識してないし「いいね」付けてる人も分かってる筈なんだけど、一人で発狂してるash worth本当に馬鹿だなあ。 前回のうるう年だとashworthはもう少しわかってるやつかと思ってたが今回の見ると俺の見る目が間違ってた
Zuishinや藤田らとどんぐりの背比べと言ってた人が完全に正しい ashworthがよくやってる行動で自分が知らない方法について否定したり馬鹿にしたりするの見ててだいぶ恥ずかしいんだけど本人的にはどうなんかね?
もう50過ぎみたいだけど自分のこと少しも客観視できないのかな
発達障害的な人物かしら >>287
おまえらって2月29日を迎えるから「うるう年」の話をしてたのか
警戒しててもシステム障害を起こしてワロタ
うるう年でシステム障害を起こす会計システムがすごい 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が続くとインデント平気でどんどん深くしちゃうタイプかな？
馬鹿すぎﾜﾛﾀｗ 流石に非生産的だしうざいから運営に報告したわ
多分何も対処しないだろうけど うるう年ではashworthが早期リターン推奨で藤田がifのネスト推奨だったのに何で今回は真逆になってるの？ 条件によらず最適な方法はひとつしかないと思ってるならashworthより馬鹿 うるう年判定はif使わないのが普通だろ
(4の倍数)＆(!100の倍数|400の倍数) >>398
うるう年と違って手が入る可能性のある関数だからだよ >>398
ashworthは前回と違い自分の把握してるパターンに当てはめられなかったから
藤田はどういう変更が入りそうか考慮できていないから(どちらのケースでも)
表面上逆になってるように見えるかもしれないけど
両者とも根底にあるのはスキル不足 ashさんはね
スキル不足という以前に単なる世間知らず
自分の実力も相手の実力も見えてない
哀れなお山の大将 自分の把握してるパターンて何だw
そもそもashworthが何を把握して何を把握してないかなんてこっちでわからんしだいたい何も把握してないだろ >>403
ashworthはRubyにオーバーロードがない理由、そしてなくてもいい理由すら想像つかないんだろうな 確かに記事の質も酷いから、他に書いてる記事見たらやっぱり酷い
新人、優秀すぎて草 #ポエム - Qiita
https://qiita.com/manrikitada/items/b2ea99d362d49caf1c55
会社名出してんのによく出せるな >>410
他の記事じゃないしそんなタイトルの記事もないが ダイレクト出版って一時期右翼系のインチキ臭い本の広告をYoutubeで打ちまくってた会社だっけ
「知識のエージェント」をマークダウン記法で強調しようとして失敗してんね
https://i.imgur.com/1cdiei9.png >>411
>>412
すまん、ちょっと首吊ってくる ■ダイレクト出版と経営科学出版とビビッドアーミー
https://anond.hatelabo.jp/20210923014629
> この会社は何をやってる会社というと「情弱向け商売」です。
スタッフすら情弱集めてカモにしてる雰囲気あるなあ。大丈夫なのこの会社？ いや、頭悪い記事書いてる奴が社員とも限らんのか。
インターン扱いで質低い仕事タダでやらされてる可能性もありそう。 >>413
若い人をほめるといいねがつくし年寄りをほめてもつかない
とりあえずいいねが欲しかったら「今の若い人はすごい！」と書いとけばいいよ
そうすればキータの主なユーザーである情弱を味方につけられるから えっ…ごめん客観的に見て>413の記事は有用だと思うんだが…何をそんなに争ってるのかワカラン >>419
同意
普通にまともな記事だった
ラーメンのやつもQiitaにしてはまともな部類 >>417
インターンでこのレベルの文章書けるなら
技術力低くてもとりあえず採用候補に入れる >>413の記事は個人の感想としか思えないので参考になるとかはないなあ。
ラーメンの記事、本見て分かったつもりの人が書いてる感じはすげえ伝わってくる。
企業の宣伝として公開してる記事だと思うが疑問なのはこれ社内でレビューしたの？ってとこ。やっててこれなら技術的にはだいぶアレな感じの会社だな。
なんでかこの会社のOrganization、初心者アピールしてる人がすげえ多い印象だけど組織としてどうなのかしら。 身内で「いいね」付けあってるような会社は5ch工作くらいやってても不思議じゃない希ガス 自意識過剰がすぎるw
一日中Qiitaと5chを巡回してるようなやつがなぜ相手にされてると思った？ ashworthの暴言は誰でも良いから相手して欲しかったんかな ラーメンの記事、ashworthのコメント消されとるなｗ
https://qiita.com/manrikitada/items/b2ea99d362d49caf1c55
記事に対してトンチンカンなコメントではあったけど消される程か?
あのコメントで消されるんだったら逆にashworthのアカウントBANされないのがおかしいだろｗ > あのコメントで消されるんだったら逆にashworthのアカウントBANされないのがおかしいだろｗ
訂正する。運営は正しい。
https://qiita.com/ashworth
> このアカウントは利用規約違反によりユーザー資格を取り消されています わかるやつには分かってるだろうけど
この感じ既視感あるな
毛の壁やんこいつ アカウント遂にbanされたかw
報告しておいてよかったわ
運営もたまには仕事するのう >>433
さんくす
技術ネタから遠いポエム書いてるようじゃやっぱあかんなあ 毛の壁の新しいアカウントがBANされてないので運営は正しくない 他のやつは良く知らんけど三項演算子のコメントは罵倒の嵐だったからな
なんでBANされないのか不思議に思うくらいだったから当然の処置 ラーメンの記事は10年前の古くなった訳本しか読まない弊害
第1版じゃなく第2版読んでれば違ってた
まぁそんなところもQiitaらしい ラーメンの話はよくわからんがオブジェクト作ったあとでプロパティ設定しちゃいかんのか？
ハッシュを作ってオブジェクトを作るのは二度手間感がすごいが >>437
第2版読んでればどういうコードになんの? ハッシュによる方法とキーワード引数とどっちが良いかはケースバイケースだと思うが、ラーメンという前提ではキーワード引数の方がマシだと思う。
ハッシュによる方法ではラーメン屋がナルトかなんか具材を追加したとしても昔の注文方法をする限り暗黙的にナルト抜きになってしまう。エラーで気づかせてくれるキーワード引数のほうが親切と思う人は多いだろう。 スープまで指定させるくらいならラーメンクラスから
・味噌ラーメンクラス
・塩ラーメンクラス
・とんこつラーメンクラス
・名古屋ラーメンクラス
とか派生させて、麺とか具とかスープに合うのをデフォルト設定で持たせるとかすりゃいいのに。 何が不便で何が便利という意識がないから
本に書いてること真に受けてる気がするわ 毛の壁ってなんかVSCodeの拡張機能作ってたな
ChatGPTを駆使したのか発注したのかしらんけど Rubyなんて汚い書き方上等の言語で何やってんだかっつー >>438
オブジェクトが生成されて以降はプロパティが外部から変更されない形であれば
プロパティの値に依存したコードが楽にかけてテストしやすくバグも入り込みにくくなるから
Constructor Injectionが推奨される理由とかでググってみるといいと思う Ruby のキーワード引数は言語デザインとしての失敗だと、
作者の松本も認めている。
普通にハッシュに詰めて、引数で渡せば良いだけ
キーワード引数があると、引数の規則が難しくなる。
それで確か、キーワード引数が非推奨に変わったでしょ？ >>445
ハッシュを渡すことで間違った引数を渡せるよりは遥かにマシ TypeScriptならその場合でも型チェックできるからいいとこどりだな ashworthは「〜っす」ていう語尾だったはずなのにキャラを忘れて関西弁になってたところがいかにも自演常習者って感じだな
多分今は別のキャラでやってるんだろ >>446
ちょっとぐぐると
h ttps://www.google.com/search?q=Ruby+%E3%82%AD%E3%83%BC%E3%83%AF%E3%83%BC%E3%83%89%E5%BC%95%E6%95%B0+%E9%9D%9E%E6%8E%A8%E5%A5%A8
Ruby 2.7からハッシュからキーワード引数への自動変換が非推奨という話はでてくるのだけど、それとは別に今ではキーワード引数自体が非推奨になってるってこと? ■ このスレッドは過去ログ倉庫に格納されています
