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

＞正直言えば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みたいのもいるのは世の中広いなｗ

配列の配列
配列のポインタ
であればどちらも一般的な訳で

>>742
それは二つの違いをわかっていない
その「struct でサイズと buf をセットで持たせる設計」はファットポインタ
つまりアドレスと長さの両方を持つことで可変長のものを受け渡しする方法

一方で今回は固定長の配列
長さを関数呼び出しなどで受け渡しする必要がない
structでサイズを持って受け渡しすることは無意味で無駄で非効率になる
この違いがわからない初心者なのだろう

おっプログラミングの経験ない人か。本当に居るんだねｗ

uint8_tの要素数が3のRGBもYUVも区別できなくて問題ないって人かあ。

ラッピングは型安全性やカプセル化のためプログラミングの常識だが
今回の問題では一切関係がない
ラッピングすることなくそのまま成立する

無関係なラッピングを持ち出しそれに固執していることからも本質を理解できていないとみえる

「そんなクソな書き方しねぇよ」という話が理解できない人いんのねｗ

今回ラッピングなんかはどうでもよくて根本の話は>>742だよね
可変長ならば先頭アドレスと長さをセットで持たなければならない
固定長ならば先頭アドレスのみ持てばよくて長さは型情報として持つべきである

ID:IinJ/Cgwはashworthかな

そこは各型のデータが持つ情報により3つに分かれる
①アドレスのみ
②アドレスと有効長
③アドレスと有効長と容量

①は単体もしくは固定長の連続体
②は可変長の連続体
③は可変長の連続体で伸縮可

①の連続体の場合はその固定長の情報は型に含まれるため受け渡しする必要がない
記事『配列ポインタ型でサイズ安全な関数引数を実現する』が述べているのはそういうことで正しいが説明不足だな

『C言語の標準ライブラリを自作して学ぶ、安全なメモリ管理と文字列操作の真髄』
https://qiita.com/toranoko/items/f3f01e99f0132558a128

オーバーフローチェックは重要、みたいなこと書いてるのに

> // 実データの前に size_t 分のヘッダ領域を確保
> block = malloc(sizeof(size_t) + size);

冒頭のコードでオーバーフロー無視してるのはなあ、無能すぎね? つか42tokyoかあ。

>>756
これで満足か？

#include <stdckdint.h>
size_t total_size{};
if (!ckd_add(&total_size, sizeof(size_t), size)) {
　block = malloc(total_size);
}

>>757
？

C23でようやく標準化されたオーバーフローチェックなんて99%のプログラマーが今後も知らないままだろう
標準化があまりにも遅すぎた
C++23の新機能も同じだ
みんな知らない学習する気もない使う気もない広まらない

>>757
> これで満足か？
　
その記事のおかしいとこそこだけだと思った?

>>759 expectedが追加されてるけど、例外使いまってる既存資産から置き換えも考えずらいし、新規で使うにも別にC++じゃなくても良くね？な型。

CとC++の標準拡張が連携とれてないよな
この言語はもうダメだ

>>762
言語は思考を規定する

>>756
> C言語を学び始めると、標準ライブラリ（stdio.h, stdlib.h, string.hなど）の便利さに気づきます。しかし、その内部で何が起きているのかを意識することは少ないかもしれません。
>
> そこで私は、C言語の標準関数のゼロから再実装に取り組みました。

とか言っててft_mallocの実装mallocのラッパーになっててｸｿﾜﾛﾀｗ

> 1. メモリブロックへの「メタデータ」埋め込みによる ft_realloc の実装

glibcならmalloc_usable_sizeでメモリーブロックのサイズ取得できるのに車輪の再発明だなあ。将来的にmalloc部分も自作するとしてメモリーブロックのサイズはどっかに格納すんだしmalloc使ってるならmalloc_usable_size使うで良かろう。
ft_reallocもメモリーブロック再割り当て必要ない場合も常に新しいメモリーブロック割り当てるし第1引数にNULL渡された場合も考慮されてないなあ。
よくこんな記事スクール名誇らしげに明記しながら公開するもんだわｗ

> これで満足か？
>
> #include <stdckdint.h>
> size_t total_size{};
> if (!ckd_add(&total_size, sizeof(size_t), size)) {
> 　block = malloc(total_size);
> }

記事主のレベルに合わせて
if (size > SIZE_MAX - sizeof(size_t)) return NULL;
で良くね?

>>757
> 2. 線形リストの動的管理と「ポインタのポインタ」の威力

> ポイント：
> なぜ t_list ** なのか？

なんて書いてるけど、理解がハンパだからft_lstadd_backの実装クソダサいことになってるなｗ

>>766
レス先が間違ってるのか何の話やらさっぱりわからん

誤)>>757
正)>>756

文字種による組み合わせの数
ASCII文字列に限定して組み合わせの数を考えてみることにします。
アルファベット大文字: 26 アルファベット小文字: 26 数字: 10 記号(印字可能な記号類): 32 使える文字種は 94種類となります。
これらを使って 4桁のパスワードを作る場合の組み合わせの総数は*通りあります。
しかし「大文字・小文字・数字・記号を必ず1つずつ含む」という条件を課した場合には、
各文字から1文字ずつ抜き出した組み合わせの並び替えを考慮して*通りになります。
見た目は「複雑さが増した」ように思えても、実際には総当たりに必要な総数は15分の1に減少してしまいます。
NIST SP800-63の草稿を書いた ビル・バー(Bill Burr)氏6はウォール・ストリート・ジャーナルのインタビューに対して
「今では自分がしたことを後悔している」と述べ、英大文字・小文字・数字等の複雑な組み合わせを提言したことを悔いています。

2026/3/25 10:46 9回答 至急です！
中学校の先生をしている私の友人と食事に行った時に、友人が「業務が多くて大変…何か便利なパソコンのソフトというか、
痒いところに手が届くようなシステムを誰か作ってくれないかなぁ…」とボソッと呟いていました。
私はどんなシステムだといいの？と聞いたのですが、具体的には今思いつかないとのことでした。
私はExcelなどでシステム（？）を作ったりするのが好きなので、その友人の力になればと思いました。
そこで質問なのですが、先生方の日々の業務の中で、「こんなシステム、アプリがあればいい！」
「こんなシステムがあって便利だった！」というのがあれば教えていただきたいです。
※個人で作れる範囲でお願いします…
あくまで先生方の業務を助けるものなので、授業 を勝手にやってくれるアプリなどは違います。

https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q11326593111
リンクくらい貼れよ無能

そのURL、まさに正解です！鋭いですね。

AIの上から目線ωωω=2πf

しょうもない記事量産して組織票してそうな会社あるけどqiitaはbanしないのかね

ゆめみ？児相？

AIに生成させて自分は見返してもないようなのポストするだけのゴミ山で
しょうもなくないものなんてあるのか？

ゆめみだと10歳娘とかいうきっしょいSSと猛虎弁で記事を連想してるやつの悪印象がつよいな

youtubeもだいぶAI汚染されて来た

『C言語で学ぶ低レイヤーメモリ管理！！(憧れの低レイヤー)』
https://qiita.com/kmtech/items/6e601c74577e6060dd63

GoやTypeScript使ってる人からするとスタックやヒープの話が低レイヤー扱いになるというのは文化の違いなのか? コイツがアホなのか?
いろいろ間違ってるけど

> ローカル変数の寿命が関数の終了とともに尽きる理由は、関数からリターンする際にスタックポインタが戻り、フレームが論理的に消滅するためです。

が一番酷い。言語仕様的にはローカル変数の寿命はブロック内と決まってるのに実装で理解しようとしてる。

どうみてもアホい

> 1. メモリレイアウトの構造（セグメント）
> プログラムが実行される際、メモリは大きく分けて以下の5つのセグメントに分割されます。

ROのデータ領域もあったら良かったね

> 3. ポインタの本質：メモリアドレスの操作
> ポインタは単なる「メモリアドレスという数値」です。

C言語はポインタ型により構造が違うことも認めてる言語なんだけど

> 5. データ構造のレイアウトとアライメント
> CPUが効率よくデータにアクセスするため、構造体のメンバ間には「パディング（隙間）」が自動的に挿入されます。

環境依存の話を世の中の理みたいに説明されてもどうなんだか

> 7. デバッグと解析ツール
> 低レイヤーのバグは人間が見つけるのは困難ですが、AddressSanitizerなどのツールを活用することで自動検知が可能になります。

サニタイザで不具合が見つかるかは希望的な話でしかないんだが

規格を確認したりしないで見えてるものが世界のすべてと考える人っぽいな

偏見だらけでやばいなこいつ
https://www.youtube.com/@nandemo-soken

Qiitaにおいて「個人開発」タグとAI関連タグの両方を紐づけた記事数は、2025年を境に急激な伸びを記録しました
「AI自らが論理的に思考し、複雑な工程を完遂する力」の社会実装が進んだことが、開発現場におけるAIの役割を決定的に変えたと考えられます
エンジニア個人が「コードを書く」のではなく、「AIに指示を出してレビューする」スタイルが定着しました
://corp.qiita.com/releases/2026/04/trend-announcement/

そうは思わんが

>>783
URLもまともに貼れないのか

有料AIはまともなコードはくのか？
無料のはレビューしないと使えんもの多い感じ

レビューしてるかは相当怪しい
レビュー以前に生成物を自分で読み返しもしてない

新語の布教
AIスロップ（AI Slop）とは、生成AIを用いて思考停止状態で大量生産された、低品質で無個性な文章、画像、動画などのコンテンツを指す俗語です
英語で「残飯」や「汚水」を意味するslopに由来し、ネット空間にゴミを撒き散らすようなスパム的投稿が、SNSやブログで急増している問題を指します
QiitaはAI slop？

よわよわ初学者を囲い込みたい人の数だけ利益増える系企業がくだらない記事量産して組織評するだけのサイトと化してる

最初からそうだった

素人が聞きかじりと独自解釈で記事書いて
それを別の素人に読ませるんだから悲惨の再生産でしかない

マサカリ投げる人を見なくなったのは運営が排除したんだろうなあ

AI記事にマサカリ投げるAI作らねえとなあ…

誤情報を別の誤情報で上書きしてやる！

知らないのは知らないと言った方が良い
AI:
まったくその通りですね。無理に知ったかぶりをするよりも、
「知らない」と正直に伝えた方がお互いに誠実でいられます。
今後は、不確かなことや把握していない情報については、
ご指摘の通り素直に「わかりません」とお伝えするようにいたします。
いつでも遠慮なくご質問ください。

QiitaはAIチャットの進化で完全終了

どっちもアホならAIのがマシだな

健忘症AI

毎回bingでググってんだけど、なんやねんこの鶴
https://i.imgur.com/A2YFdhp.jpeg

>>799 POSIX関連を多く投稿してる人のアイコンっぽい

>>800
ほえー
長年の疑問が解けた

>>799
マイクロソフトの検索エンジンはかなりのポンコツだぞ？

書籍の内容のまとめとか、就活生の自己アピールみたいなのは読み物としてはゴミでつまらん。他で扱わないネタやオリジナリティのあるもので勝負しないとサイト丸ごとゴミの山になって終わるな

bingで検索すると出やすいよなqiita

bingでアマギフ乞食しとる
楽天ポイントも出てるが品切れだとよ

プログラミングを楽しんで書いた人の記事がなくなった

bingが糞なのは完全に同意だけどyahooよりはマシかも知れない

てかここqiitaのスレだった

>>807
ヤフー検索は少し仕様を変えただけのGoogle検索

なら、duckduckはbing

最近はQiitaよりredditの外人のスレのほうが引っ掛かる感じ

2025年のLikeの中央値は0だぞ！！！
遷移は明確に右肩下がりソースzenn.dev/mima_ita/articles/f78dcbef2a81d3

他人の記事にいいねなんてしないんだよ
お前らは仲間いいねをつけた工作記事宣伝記事を見せられてるだけ

一応QiitaはRSSで気になる単語をピックアップしてみてたけど、本当AI生成記事しかないからやめちゃった
他なんかないかな

>>813
企業研修の担当者が仕事の心掛けを就活生に語るのとかあるぞ。一般人にとってはゴミ記事だけどw

>>813
Qiitaしょうもない日はspeaker deckとかdocswellはたまに見る

Qiita見るくらいならRedditでも観たほうがマシ

広告の少ない無料techブログとしての利用価値は高い

まともな人間はアドブロック入れてるんだよ

スライド共有サイトは、まだQiitaとかZennに比べたらAIスロップはマシそうだな
とはいえ、もうAIでスライドも作れる以上はあんまり無事なのも長くないかもしれないが
自分もこのへん見るか

株式会社アイ・エス・ビー
https://kizuna.5ch.io/test/read.cgi/infosys/1756826944/

https://special.nikkeibp.co.jp/atclh/ONB/24/isb0809/

>>820
マルチポストか？
首吊って死ね

kaizen nagoyaようやく静かになったな

とはいえQiitaはもうゴミ溜めになっていた

kaizen nagoyaはzennに住処を移したんだっけ？

飽きたらおしまい

会社説明会での欲しい人材だの研修での仕事への取り組み方だのは自社内でやれよクソが、公共の場所でしかもトレンドがついてトップページに出て来て目障りなんだよ馬鹿

ActiveX なんて単語久しぶりに観たわ

>>826
誤爆か？

>>826
VSCodeスレから来たんかな？