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

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/
Qiita 4 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1705486836/
Qiita 5 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1717651046/
Qiita 6 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1739527246/

昔のCPUのC言語は引数スタックに積むから判り易かったんだが
最近のはレジスタ渡しで追い掛けるのがちと面倒(判らん訳じゃないが)

>>641
printf()でtime_tや_time64_tの値を出力するときは%lldで良いの？他にもっと良いのある？

出力したい値が符号付きなら出力フォーマットは%jdを使い、出力したい値はintmax_tにキャストすればおｋ

>>642
あいつChatGPTの出力貼り付けるだけになってたし力尽きたんじゃないかな

Qiitaから消えたと思ったらZennで暴れてたわw

>647
どうぞ
https://mevius.5ch.net/test/read.cgi/tech/1657839892/

キータももうオワコンだね

https://mevius.5ch.net/test/read.cgi/tech/1657839892/29
> 29デフォルトの名無しさん
> 垢版 | 大砲
> 2024/12/29(日) 01:55:29.01ID:hB4L1r8r
> Zenn記事で権威ある有名企業の記事にマサカリ投げられない
> って思って気づいたがそういう企業ってマサカリ多いQiitaでなくZennに行く
> Zennはマサカリの怖さがない
> 心理的に安全

たった1年前だがQiitaってそんなマサカリ恐れるようなとこだったっけ?

『「0.1+0.2≠0.3」を説明できないエンジニアがいるらしい』
https://qiita.com/higashi_nc/items/9a5ea00415a008f06843

↑は2年前の記事で盛大にマサカリ投げられているが1年前にはもうだいぶQiitaも衰退しててマサカリ投げるモヒカンも減ってた気がするが。

どれこれ関係ない
Stack Overflow をも壊滅させるビッグウェーブだから全滅もある
https://data.stackexchange.com/stackoverflow/query/1926661#graph

>>650
QiitaとZennを比較したレスをもとにQiitaを時で比較するのは公正でない

『Hello World あたたたた LuaJIT編』
　
バッファオーバーフローする可能性のあるコードをなぜ広めようとするのか?

元の記事『Hello World あたたたた 11日目 C編』がクソだと可視化されないと派生が生まれるというのは本当に不幸よなあ。

5chもゴミだらけだけどQiitaもそれ以上に酷い

『Hello World あたたたた C編 その2』
　
『Hello World あたたたた 11日目 C編』のstrcatでバッファオーバーフロー起こす可能性について対処してるのは良いが「コーディング例」として挙げられてるコードも微妙だなー。
hako_capを4倍する処理でオーバーフローが考慮されてないしoffsetの計算もsize_とintの値ちゃんぽんに計算してintに代入してる。「“規定のロジック”を逸脱してもよいならこう書くべきでしょう。」として掲載されてるコードも"た"が最初っから延々続いた場合 ta_count + 1 がオーバーフロー起こすロジックバグがある。
どうしてこんな記事を公開してしまうのか。

そんな欠陥言語Cに拘る人たち

ロジックバグは言語関係ないんだよなあ

『【アセンブリ言語】x86-64 vs AArch64 vs RISC-V vs Power ISA』
＞又、RISC系の3つでは.asciz（NULL終端ASCII文字列）を使っているのに対し、x86-64では最後に, 0を付けてNULL終端にしている点も注目して下さい。
　
writeで出力する文字列の終端に'\0'置くのは余計なんだがよく分かってない人みたいね。

write呼んでexit呼んでアセンブリ言語でハローワールド書けましたってこの手のQiitaの記事で、writeのシステムコールが返す可能性のあるエラーに正しく対処してるの見たことないな。

どうせおまいらprintfの戻り値確認してないだろ

printfが返すのは出力する想定の文字数であり出力が中断されることも想定の内のwriteシステムコールとは事情が違うんだゾｗ

出力したからと言ってすべてを表示するとも限らんだろうに

昔はよくQiitaを参考にしてたけど最近「～みた」「～話」系のゴミ記事が増えてSTACKOVERFLOWレベルの使えないサイトに成り下がった

比べるならcode projectじゃねえかなあ
もうない

stackoverflow日本語のは糞だけど英語のはマシだった記憶があるが今は違うのか

『Qiitaのはじめかた』
＞Qiitaにアカウントを作成すると、つぎの機能を利用できます。
＞記事を投稿する
＞記事に「いいね」する
＞記事を「ストック」する
＞ユーザーやタグ、Organizationをフォローする
＞編集リクエストを送る
　
コメントが挙げられないのは非推奨機能だからかな？

技術的な指摘や議論の場としてコメント欄が使われるため、感情的・攻撃的になりやすく、その結果として利用規約やコミュニティガイドライン違反になりやすい
意見が割れるテーマの記事には多くのコメントが付き、口論や誹謗中傷に発展しやすい

編集リクエストって「お前のバカ記事直してあげたからこれに更新しなさい」って機能だしコメ欄よりよほど攻撃的な使い方できるけどね。
まあ記事主側が一方的に拒絶できるし送る側も徒労に終わる可能性理解してるから大幅に書き換える編集リクエストを送る奴もおらんから誤字やタグ修正くらいにしか使われてはいないけど。

Qiita Woman Summit supported by パナソニック コネクト
https://increments.connpass.com/event/375321/
> 【基調講演：ちょまどさん登壇】性別・職業区分問わず、どなたでもご参加いただけます！

目玉がオタサーの姫だった人かあ。

そんなこと気にしてるのはお前だけじゃないかな

Xamarinを使うなら人脈が重要と君臨しておられた偉い方ですよ

まだそれ擦ってるんだ
お大事に

何開発したでもない万年初心者みたいな人だけどいまだに有難がってる人がいんだねｗ

>>671
妊娠中の大きいお腹をインスタに挙げてた人かな

Xamarinのインストールだかビルドが難しいとかで
知ってる人に教えてもらわないとどうにもならんのを
「Xamarinするには、まず人脈♪」と揶揄されたのを
俺の発言みたいに広めるな！と件の人が騒いで
騎士団も同調したんだっけか?
製品の不評なところは社内でフィードバックして
改善に努めるとかそんなんじゃないのね。

>俺の発言みたいに広めるな！と件の人が騒いで
>騎士団も同調したんだっけか?

君認知歪みすぎじゃないか

＞正直言えばXamarinと人脈については全く関連はないと思ってるのが正しい技術者なのでいいと思う。ただちょまど氏が神なのは否定しませんけどね。
　
騎士団の中ではコイツが一番キモいかな。

＞私の不在中、そのような内容のスライドに私の名前が使われたらしいのですが、
＞私はそんなことは言っていません。
＞
＞この話はこれでおしまい！
　
おしまい！って、製品の改善に言及してなくてﾜﾛﾀｗ
MSのエヴァンゲリオンやっててこれｗ

何号機よ？

>>680
これは恥ずかしい変換ミス
やっぱ憂さ晴らしで人を叩く奴って知能が…

囲んでおめでたうゆってやろう

>>683
？

徳弘の元ネタも知らんくせに炎上させんなのやつ

何言ってんだこいつ

もしかしてエヴァンゲロリスト

『大学生エンジニア Rustの勉強を始める 🦀』
https://qiita.com/kohta9521/items/082317eae9d2a9d3bd6a
> 1. 非CS専攻（法学部）としての「低レイヤー知識」への渇望

> 🎓 法学部としてのコンプレックスと渇望

> 私は法学部法学科に所属しており、大学でCS（コンピュータサイエンス）を体系的に学んでいません。

> 法学部出身の私にとって、低レイヤーの専門用語（スタック、ヒープ、ポインタなど）は高い壁です。

> 法学部出身の私が、ポインタやメモリ管理といった低レイヤーの概念と格闘している「ありのままのログ」です。

> 「法学部卒で普通のフロントエンドエンジニアにRustなんて無謀だ」と思われるかもしれません。

法学部アピール多すぎない?
まだ卒業してない身で「法学部出身」「法学部卒」って頭良くはなさそうだけど。

> 私は法学部法学科に所属しており、大学でCS（コンピュータサイエンス）を体系的に学んでいません。
> プログラミングにのめり込めばのめり込むほど、CS専攻の方々が持つ「メモリ管理」や「DBの内部構造」といった基礎体力の差に悔しさを感じてきました。
>
> フロントエンド（TypeScript/Next.js）だけでは見えにくい、 「裏側で何が起きているか」 を理解したい。そのためには、ガベージコレクションがなく、メモリを意識せざるを得ないRustこそが、今の私に最も必要な「矯正ギプス」だと確信しました。

Rustの勉強が低レイヤの学習になると思ってるみたいだけど言語の学習以前にコンピュータサイエンスの学習を意識された方が良いと思うね。

これが今のQiitaのレベルなんだよ
もはや読むに値しない

同じ人の記事
　
『[ Rust学習 ]大学生エンジニアによるマクロとはなんぞや？』
　
よく調べず憶測で分かった気になってる感ハンパないんだがｗ

aiが書いた文章の肥溜め

内容USO800で
｢法学だからCSやらなくていい｣は傲慢だな
言い訳に聴こえる

AIルシファ

直接言ってこい

『プログラマはドメインの実装に集中すべき』
　
記事主はコミュニケーション能力に難ありそうなのに主張が強いのはまあ荒れるかな。

>>696
その人が理解してる狭い範囲で書いてるから間違いが多くなってるね
例えばオブジェクトを返すために「ポインタが必要になります」という件
Rubyなどでは常にGC領域に確保したエリアを指すポインタやfatポインタになってることを知らない
むしろポインタを返すか値を返すかの選択指定ができないRubyなどの言語こそ「ポインタが必要になります」なのにね

>>696
クラスが良いものとされていた過去の言語と、
クラスは良くないとされている現代の言語を比べてるんだな。
そのケースは共通メソッドPay()を呼べれば良いだけのようだから、
クラス継承関係の必要はないためクラスは不要だが、
そこも理解せずになぜかクラスを絶賛していて草。

『なぜあの人と話すと仕事が止まるのか。』
　
責任を避けたいのか指示や説明に曖昧な表現をする人は実際いて、記事では良いこと言ってると思うんだけどもコメ欄見ると曖昧支持派が案外いるようで意外な感じ。そんなんで仕事効率よく回るのかな?

そもそもの話として指示してる側がよく分かってない場合まであるかな。

ネットwatch板に行けや板違いのクソジジイども

会話・チャットでやり取りをしていて、「なんか、このひと面倒くさいなー」とイライラすることがある。
イライラするだけなら、まだ我慢できる。けれど、それが仕事に支障をきたすのであれば話は別だ。
─── で、そういう場面は珍しくない。
そういうひとのことばを観察していると、あいまいな表現が多いことに気が付く。
それで、会話の回数が多くなって生産性が落ちたり、認識の齟齬が生まれて作業のやり直しが発生したりしている。
結論：
コミュニケーションコストは低い方がよい。
仕事の文書は多義性をもってはいけない。
「あいまい」な表現は避けるべき。
今日はこういう話をする。
「あいまい」なひとたち
日々の仕事のなかで、あいまいな表現（意味がひとつに定まらない状態）を意識して探すと、その多さに驚く。
例えばこんな具合だ。
↑
抽象的な会話が出来ない人かなー

本田勝一
外山滋比古
ああそういうことか

コミュニケーション能力の低そうな奴ｷﾀｰ(AA略

noteに投稿すれば利益でるかもしれない情報を
なんでわざわざQiitaに無償提供しないといけないんだよ

>>702
本文読んでないけど「その多さに驚く」「たとえばこんな具合だ」とかはGPT構文

>>702
主張の甘さはともかくすごく読みやすいよく出来た文章
現時点のプログラミング能力が低くてもよほど高い技術力を求める職種じゃなければ書類選考は通すかな

『TRONはマイクロソフトのOSよりも開発が遅かった』
　
> TRON をリアルタイム OS というのであれば、Windows もリアルタイム OS です。
　
とか言ってて草ｗ

Windows CEは現行品じゃねえからなあ…

『アセンブリ言語を学ぶことで得られるメリット【アセンブリ言語さくっと入門】』
　
雑な記事で間違いも散見されるけどこんな記事がいいね多く貰えるのかｗ

サルでも判る
猫でも判る
こんなのがベストセラーですし

QiitaってCSS/HTMLの埋め込み出来んのね
なんつー不便な
外部サイトをEmbedで埋め込めばいいんだけど
自前で提供してほしいなあ

CSS埋め込むとCSSに攻撃されます

>>712
Qiita Discussions へようこそ
://github.com/increments/qiita-discussions/discussions

投稿したら運営が必ず返信してくる有用サイトを教えてあげる

>>714
リンクもまともに貼れないのか…

>>715
バカで草
5chは初めてか？

>>716
直リンクなんて今は誰も気にしないよ
おじいちゃん

>>717
横だが
ほんとに何を間違えたか分かってないのか、
分かってとぼける為に編み出した言い訳なのかどっちだ？

Rustは非常にシンプルで
最も多用されて使いやすい半開区間
従来 i = 0 ; i < n を 0..n と表記
稀に用いられる閉区間
従来 i = 0 ; i <= n を 0..=n と表記
このようにシンプルに従来と対応している
この2種類しかないため逆に取り違えて誤用することもない

https://youtube.com//shorts/Z8y4gXpQbKw

>>718
ジジイ乙

>>720
みいちゃん…

最後に出てくる「みいちゃん」は、過去に5ch（旧2ch）で起きた有名なコピペや「知ったかぶりをする初心者」を揶揄する文脈で使われるネットスラングです。
「君は何も分かってない初心者（あるいは痛い人）だね」という強烈な皮肉を投げ、議論を打ち切っています。

直リン派の認識
利便性と現代基準 今のブラウザやアプリはセキュリティが強く、多くの掲示板アプリ（専ブラ）は `ttp` でも自動で補完してリンク化します。
「h抜き」はもはや二度手間を強いるだけの無意味な儀式に見えています。

h抜き派のに認識
5chには「リンクの先頭の `h` を抜く」という古い慣習があります。
これはかつて、不用意なクリックによるブラウザクラッシュ（ブラクラ）やウイルス感染を防ぐための自衛手段でした。

この状況をAIに解説させて思ったがなぜhttp抜いたか分かってないんじゃない？
ブラクラやウイルス感染を防ぐためじゃなく5chでURL規制で貼れないことが多くIP規制になることもあってhttp削除
714以外は他人の投稿でこのスレをあまり見ないからここでhttp削除の必要がなかったとしても気にするつもりはない
リンクを貼りたいなら貼りたい人が貼り直せ
そこまでリンクにこだわるならなぜおまえが貼り直さない？
おまえがQiita Discussionsに投稿するかは気になるがリンクのことはどうでもいい
小さいことにこだわるやつだな

規制とかどうでもいいわなURL貼れないならそもそも書き込みを諦めればいいだけだし

http削ると貼れたりするから諦めなくても大丈夫

リンク貼ったら一発退場が懐かしい

『C言語とアセンブリ言語の実行速度を比較する』
　
printfで整数値を10万個出力するのに
・アセンブリ言語からprintf呼び出し→約7秒
・C言語からprintf呼び出し→約40秒
　
ちょっとあり得ん結果になってるんだけど考察もなく終了という気持ち悪い記事。

Cでcountをレジスタに割り当てたら速くなるんかな
最適化するだけでもっと速くなるかな

実行環境が違っててconsoleの性能差だったら笑う

__stdcall と __cdecl か

>>726
Cコンパイラで*.asm吐いて比べてほしい記事やなあ

consoleの差に一票

『C言語にも配列のlengthプロパティをください ― 配列ポインタ型でサイズ安全な関数引数を実現する』
　
フツー構造体を定義するところを一見便利そうでその実不便な方法を提案する人

>>732
どんな構造体を定義して何をするつもり？

分かんない人は黙ってれば良いのにｗ

>>732
その記事のやり方が正しい
それが静的な型チェックも実行効率も共に満たす方法

chatgpt様に訊いてみた
　
＞技術的な評価（ざっくり）
＞この記事の主張は Cの仕様としては正しいです。
＞ただし実務では多くの場合：
＞・void f(uint8_t *buf, size_t len)
＞・sizeof(array)/sizeof(array[0])
＞・マクロ
＞・_Static_assert
＞などで処理するケースが多いです。
＞理由は単純で
＞・uint8_t (*buf)[N] は APIとしてかなり使いにくい
＞・可変長配列や動的メモリと相性が悪い
＞からです。
　
「uint8_t buf[BUF_SIZE]が意味あるデータ構造なら要素数で区別するのではなく構造体に定義した方がまとまり良いし保守性も向上する」とか言わなかったのは意外な感じ。

#define _countof(array) (sizeof((array))/sizeof((array)[0]))

>>732
あほやん
これでも良いけどさ→(*buf)[i] = (uint8_t)0x00U; /* ポインタを一段デリファレンスしてからアクセス */
これと等価やで→buf[0][i] = (uint8_t)0x00U;
蛇足→0[buf][i] = (uint8_t)0x00U;
しかも結局buf[1][i]とかにもアクセス出来るので根本的な解決になってない

実行効率も落ちるんじゃね

>>736
それは悪手

>>732 が本気で便利なら40年50年あるCの歴史でそのやり方が主流にならないはずがない
「フツー構造体」は違うかも試練が「不便な方法」は同意

記事主がコメント欄で
　
＞＞特定の要素数を前提とする場面なら struct が手っ取り早いような気がしますが，どうなんでしょう？
＞
＞ご指摘の通り、自分の触っているコードベース上でも struct でサイズと buf をセットで持たせる設計が一般的で、筆者自身もそちらを採用することがほとんどです。本記事は「素の配列をそのまま渡す設計を採用した場面で、型にサイズ情報を持たせる手段がある」という紹介にとどまるものでした。ちょっと自分の書き方が一般的と誤解させるような内容になってしまいました。気をつけます。mm
　
と書いてる通り一般的方法ではないんだけど>>735みたいのもいるのは世の中広いなｗ