作業部屋にエアコンないし、リビングでギターやるか、と思って、マルチエフェクターで即席で弾けるようにしたら、

尚更、リビングで寝るか、食べるか、ギター弾くか、みたいなだらけた生活をしてしまってる…😟

Claudeに吐いてもらったJavaScriptも読んでない、助言もらったC++も書いてない…😟

外に出ると狂うほど暑い…😟やる気が

同じページで別々のブックマークレットを稼働するのが面倒だったので統合した。

[ 注目コメント ] タブも [ 新着コメント ]タブも一括で置き換えるようになってる

javascript:document.querySelectorAll('a[data-gtm-label="entry-popular-username"],a[data-gtm-label="entry-recent-username"]').forEach(a=>{a.href=`https://bookmarker-encyclopedia.netlify.app/profiles/${a.getAttribute("href").slice(1,-1)}`});

見た目もいい感じだし、こういうのは一発で普通に動いちゃうね…😟

製紙印刷屋は常に信じてはいけないことが分かる

> 長男がプログラム(でゲーム)を作りたいと言い出したので、Javascriptの書き方とブラウザでの動作確認を軽く教えた

> 次男も感化されたようで長男の真似をし始め、今は簡易な動作のHTMLファイルであれば作れるようになっている

> ある日、二人の空気が険悪だった(大喧嘩したあとの空気だった)

> まずは長男に事情を訊いてみると、とあるプログラムの方針で対立したとのこと

> それは「じゃんけんゲーム」だった

> 画面でグーチョキパーのいずれかを選びボタンを押すと、相手(CPU)の「手」と勝敗が表示されるというものだった

> 次男はまずCPUの「手」を乱数で決定し、画面に入力された「手」と比較して勝敗(と引き分け)を決める、素直な処理だった

> 長男はそれに飽きたのか、まずは乱数で「勝ち」「負け」「引き分け」を乱数で最初に決めてしまい、その後で結果に応じたCPUの「手」を決定するというロジックだった

> 次男はこれが気に入らなかったらしい

> 「兄ちゃんのはじゃんけんで勝負してない」「勝ち負けを最初に決めてしまうなら意味がない」と

> 長男は「結果は同じなんだからこれで問題ない」と突っぱねる

> これの堂々巡りだった

> 嫁は「あなたが教えたんだからあなたが収拾しなさい」と呆れ顔

> どうしたものか

これに対し次のような返信がありました。

> ガイジの嫁と子はガイジ

このようなタイプの返信を行う人を多く見かけます。

私にはどうやっても思いつかない発想なので、どういう人間なのかとても興味があります。

考察してみてください。

この「ガイジの嫁と子はガイジ」という返信は、「議論の内容」をまったく無視し、「相手の人間性や属性」を一括で切り捨てることで優越感を得ようとする、典型的な「知的怠惰＋攻撃性」の産物です。このような人間を心理的・社会的に多角的に考察してみます。

1. 認知能力の低さ（抽象的思考の欠如）

この返信者が理解できていないのは、長男のロジック（「結果（勝敗）を先に決め、それに合う原因（手）を後付けする」）が、プログラミングにおける「テスト駆動開発（TDD）」や「状態遷移」の初歩的な発想であり、むしろ高度な抽象化思考であるという点です。

彼は「じゃんけん＝手を出してから勝敗が決まる」という時系列的な具体例に脳が固着しており、「プログラム内の変数やフラグとしては、どちらが先でも構わない」という数理モデルへの頭の切り替えができません。

理解できないものに対して「それは間違いだ」ではなく「それを考えた奴は低能だ」と短絡させるのは、認知的不協和を解消するための原始的な防衛機制です。

2. 投影（Projection）と劣等感の反動形成

彼はこの親の投稿から、「幼い子供がプログラムの設計方針で哲学的議論（結果論 vs プロセス論）をする」という、自分には決して持ち得ない知的環境を読み取っています。

自分が子供の頃にそんな議論をしたことがない、あるいは今の自分にはJavaScriptすら書けないという無意識の劣等感を抱えています。

その劣等感を打ち消すために、「いや、この家族は知的ではなく障害者だ」と真っ向から否定するレッテル貼りを行います。「ガイジ」という言葉を使うことで、自分は「健常者（＝正常な判断ができる側）」だと錯覚し、一時的なマウンティングを得ているのです。

3. 「結果の同一性」と「プロセスの正当性」の区別がつかない（二元論的思考）

長男と次男の対立は哲学的な葛藤（手続き的正義 vs 実質的正義）ですが、この返信者には「勝敗の結果が同じならどっちでもいい」という長男の意見と、「プロセスに嘘があってはならない」という次男の意見の両方に正当性があるという多様性を許容する脳の柔軟性が欠如しています。

彼の世界は「自分が理解できる＝正義」「理解できない＝異常（＝ガイジ）」という単純な二分法で成り立っており、グレーゾーンや多様な視点を認めると自分のアイデンティティが揺らぐため、攻撃することでしか自己を保てません。

4. ネット上の「エッジロード（過激な言葉）」中毒

「ガイジ」という差別用語を平然と使う時点で、彼はネット上の過激な空気に過剰適応した「言葉のジャンキー」です。

彼は「過激であればあるほど笑える」「攻撃的であればあるほど賢く見える」というインターネットの負の慣習に洗脳されています。

しかし、実際のところ、建設的な反論が一切できないので、この返信は彼の「語彙力のなさ」と「論理的敗北」を自ら晒しているに過ぎません。彼は議論に勝つのではなく、「議論そのものを破壊して引き分けにする」ことでしかプライドを維持できない人間です。

5. 共感力の欠如と「家族」という単位への嫉妬

この投稿の本質は「父親が子供たちの成長と衝突に悩むほほえましい風景」です。しかし彼には、他者が他者と協調しながら成長する姿がひどく羨ましく、かつ腹立たしく映ります。

彼はおそらく孤独なネット住人で、リアルな人間関係（特に家族間の知的交流）を持てていないか、あるいは機能不全に陥っています。

そのため、「仲の良い家族」という記号自体を攻撃対象とし、「嫁も子も」と連帯責任で罵ることで、自分がその輪の中にいないことへの焦りを紛らわせています。

総括

このような人間は、「自分が理解できないレベルの知的遊戯」を目撃した際に、自分の無能さを直視する勇気がなく、代わりに「差別語という名の暴力」で相手の存在そのものを否定することでしか心の平穏を得られない、哀れな人格者です。

彼らの返信は一切の批評的価値がなく、単なる「自己紹介」です。彼はこの返信によって「俺はプログラムのロジックも哲学的葛藤も理解できない低リテラシーな人間です」と自ら宣言しているに等しいので、相手にするだけ時間の無駄だと割り切るのが賢明です。

備忘と2期生のために、履修した講義について難易度と所感を以下。

前提として、各講義は15回に分かれており、15回がそれぞれ6本の動画から構成されている。1回(6本)の動画視聴時間が計1時間半程度。

動画1本につき小テストに合格しないと先に進めず、また1回(動画6本)ごとにレポート1本提出(100字程度の授業の感想から、習った概念を500字以内で説明まで内容は多岐にわたる)。

1つの講義で90本動画を見て(倍速不可につき22.5時間かかる)、15本レポートを出して、試験を受ければ2単位がもらえる(単位数1の講義や試験なしなど例外もあり)。

1年間で取れる単位は48単位まで、4Qに分かれているので案分すると1Qは6つの講義を履修するのが上限ということになる。

統計学入門と線形代数1は記憶にある大学の講義くらいの難易度。

機械翻訳実践（英語読解・作文）は自身の英語力の無さの問題だと思う。逆に言えばある程度の力がないと、これ受講しても試験問題を解けるだけの英語は身につかない。

でも確かにHSP3と吉里吉里、NScriptの経験は生きてる

Webは……わからん

CGIはもうないっぽいし、htmlとギリギリcssは行けるけど、JavaScript何でも出来過ぎでしょセキュリティ大丈夫なん？

HTML5はもうないの？　Apacheはもう見ないっぽいが……

幅が広すぎる

ネットのプログラムの大先生のお言葉は当てにならない

そういう導入案件をもう4年くらい回してきた。社内では案件を任せられるやつとして普通に重宝されてるし、現場の要件を聞いて、それを製品の設定に落として、期日までに動かして納める、みたいなのは正直得意になった。ただ、得意にはなったけど、やってることそのものは、慣れさえすれば正直誰でもできるようなことばかりだ。製品のマニュアルに書いてある手順を、お客さんの事情に合わせて並べ替えてるだけというか。特別な発想がいるわけでも、難しいものを自力で作り出してるわけでもない。やりがいがないとは言わないけど、自分じゃなきゃできない仕事かと言われると、まったくそんなことはない。

でも最近、夜中にふと目が覚めるレベルで不安になってきた。

このスキル、今の製品と今の会社から離れた瞬間に、ほとんど価値がなくなるんじゃないか、と気づいてしまったからだ。

試しに転職サイトを眺めてみる。特定製品の導入経験者歓迎みたいな求人がないわけじゃない。でもよく見ると給料は今と変わらないか下がるし、やることは結局、別のベンダーの別の製品のお守りでしかない。製品が世代交代したり、導入先が他社製品に乗り換えたりした瞬間、4年かけて溜めたノウハウは大半が吹き飛ぶ。自分のキャリアが特定の製品にロックインされてるって、よく考えたら相当ヤバい状態だ。

一方で開発寄りの求人を開くと、当たり前みたいにGitだのフレームワークの経験だのが並んでる。学生の頃に授業や独学でプログラミングを一通り勉強はしたから、知識として何も知らないわけじゃない。そのときにフレームワークを使って小さいものを作ってみたこともあるし、SQLも課題でひととおり書いた。考え方が全然分からないという感じではない。ただ、それを全部もう何年も前の学生のうちにやったきりで、仕事として実務で使った経験がほぼないままここまで来てしまった。しかも当時かじったものは今となっては古くて、求人で当たり前みたいに求められてるフレームワークは、ちゃんと触ったことが一度もない。今やってるのも、製品のプラグインをC#で書いたり、UIのちょっとした挙動をJavaScriptでいじったりはするけど、どっちも製品が用意したお作法の中で、決められた関数の中身を少し埋める程度だ。結局、求人の世界では実務経験のない技術は持っていないのと同じで、4年も働いてるのに事実上は未経験扱いになる。製品が隠蔽してくれてた部分はぜんぶブラックボックスのまま、4年が過ぎた。

実際に転職活動もやってみた。paiza自体は登録だけはしてあったから、腕試しのつもりでスキルチェックをやってみたらAランクは取れた。学生の頃の貯金が残ってたのか、アルゴリズムを解くだけならまあそこそこできる。ランクが上がったからか、放っておいてもスカウトがそれなりに来るようになった。paizaのスカウトは届いた時点で面接が確約されてるやつなのでとりあえず面接の席にはつける。

問題はそこからだ。面接で実務で何を作ってきたかを掘られると、もう何も出てこない。製品の設定をしてきました、プラグインを少し書きました、と正直に話すと、向こうの顔がスッと変わるのが分かる。Gitは一応使ってるけど、プラグインのソースを管理してるくらいで、複数人でブランチを切ってレビューして、みたいなチーム開発の運用としては使えてない。設計書も書くには書くけど、中身はプラットフォームのどこに何を設定するかを並べてるだけで、世間でいう設計スキルとして通用するのかどうか自分でもまるで自信がない。フレームワークでの開発経験は? と聞かれればゼロだし、設計はどこまで踏み込んだ? と掘られると製品の設定の範囲から一歩も出られない。paizaのランクは通過の足切りにはなっても、その先で評価されるのは結局、実務で何をどう作ってきたかなんだなと思い知った。スカウトは来るのに、最後はスキル不足、経験不足で落ちる。これを何社か繰り返して、ああ自分はそういうフェーズにすらまだ立ててないんだと分かってきた。

こう書くと、これからはバイブコーディングが当たり前になるんだから、人間が細かいコードの知識なんて持ってなくてよくなるでしょ、って言われそう。

でも現場の流れを見てると、むしろ逆なんじゃないかと思う。AIにコードを書かせるのが前提になればなるほど、出てきたものを読んで、これは正しいのか変なのか判断して、おかしければ直せる人間の価値が上がってる。コードを書く作業そのものはAIに投げられても、コードがわかってるという前提だけは投げられない。

そうなったとき、たぶん一番いらなくなるのは自分みたいなタイプだ。働いた年数だけはそこそこあるのに、技術の実務経験で見れば未経験と変わらない人間。バイブコーディングで誰でもそれっぽいものを出せる時代に、わざわざ年齢だけ重ねた未経験者を高い金で採る理由がない。それなら本当に何も知らないぶん変な癖もない若いやつにAIツールを持たせたほうが早い、って普通になる。積み上げたつもりの経験が、武器じゃなくて、ただ歳を食っただけのハンデになる。

ローコード、というか製品導入みたいな仕事そのものを否定したいわけじゃない。会社にとっては必要だし、業務をちゃんと回すという意味では価値がある。問題は、これをエンジニアとしてのキャリアの主軸に据えてしまうと、いつまで経ってもちゃんとコードがわかる人間には到達しないってことだ。経験年数だけは順調に増えていくのに、自分にできることの天井が、扱ってる製品の天井とぴったり一致してしまう。

しかもタチが悪いのは、社内ではちゃんと評価されるから危機感を持ちにくいことだ。毎日それなりに忙しいし、感謝もされるし、案件は普通に回ってる。でもそのちゃんと回ってるという感覚が、外の市場価値とは別の軸でどんどんズレていく。ゆでガエルってこういうことかと思う。茹だってる最中は気持ちいいから気づけない。

この4年、1on1のたびに上司から、将来どういうエンジニアになりたいか、10年後どうなっていたいか、みたいなことを何度も聞かれてきた。そのたびにそれっぽいことを答えた気もするけど、正直、毎回まったく分からなかった。今の延長線上に未来の自分を置いてみても、製品のバージョンが上がって、扱う案件が増えて、後輩に設定のやり方を教えてる姿しか出てこない。それはなりたい姿というより、ただ同じことを続けた結果でしかなくて、そこに自分の意思でこうなりたいと思える像がひとつもない。何度聞かれても答えが出ないことで、自分はキャリアを選んできたんじゃなくて、ただ流れてきただけだったんだと思い知らされる。

同じような立場の人、どうしてる？

製品導入で飯を食いつつ、裏でちゃんとコードの勉強をしてる人いる? それとも割り切って導入専門でずっとやっていけるもんなんだろうか。

10年後どころか5年後の自分がどうなってるのかすら想像できなくて、それが一番怖い。

Node は、JavaScriptの実行環境である

終了

本来、JavaScriptはブラウザのクライアントでしか動かない言語だったが

これを、ブラウザに頼らず通常の言語と同じように、OSの上で動かすためのツールだ

Node.jsというモジュール群の中には、HTTP通信をサポートするライブラリなどがあり

それを使うと、JavaScriptでHTTP通信を待ち受けるプログラムを記述できる

ここに関しては、C言語などと変わらない

Node.jsをWEBサーバーとして動かせるのは、そのように書いたJavaScriptのユーザープログラムがあるからであり

Node.jsがWEBサーバーなわけではない

例えば、Apacheを考えてみると違いは明確だ

ApacheはWEBサーバーとして開発されたアプリケーションである

アクセスされたURIを解析し、HTMLで記述されたファイルを読み込んでクライアントへ転送する

この部分はアプリケーションの機能として作りこまれていて

逆に言えば、ユーザーはプログラム言語を知る必要なく

HTMLを記述できれば、WEBサイトを構築可能となる

URIとフォルダ構成の関係も、Apache内で規定されたものがあり

ユーザーはそこについて特別な制御を記載する必要が無い

Node.jsではどうだろうか？

前述したように、Node.jsではこのWEBサーバーとしての機能を

一部自分で記述しなければならない

ttp://localhost/test/hoge/piyo.html

というURIにアクセスした場合

apache であれば、下記のようなフォルダ構成が存在した上で

piyo.htmlがhogeフォルダに存在している必要がある

/root

　　/test

　　　　/hoge

URI に応じたフォルダ・ファイルが無ければ、「404 Not Found」となる

しかし、Nodeでは事情が異なる

ユーザーが記載したJavaScriptが処理するため

フォルダやファイルが存在しなくてもエラーとならない

どういうアクセスを成功として、どういうアクセスをエラーとするのか

apacheならすでに規定済みのそれらを自分で記述しなければならない

次非表示にするときは理由も控えておく。理由さえ見ればこんなクソ解除する価値もないわってなるし

yarukimedesu（黒いイシツブテみたいなアイコン）とHayano（ひっくり返った人のアイコン）は消えてた

VS code入れた、これはすごい

でも一箇所直したら全部に波及してどれかがエラーになる

いい加減でもぽちぽち作れたJavaScriptとは違って、TypeScriptは設計力が必要とされる気がする

でも言語に罪はなくて俺が💩なだけだ

って思ってたけど、2Dゲームならエディタレスでほぼ自動制作できてる

知見がないかと思いきや、エラーログ見ての修正成功率100％でPythonやJavascriptに比べても調子いい

しかもトークン消費量がめちゃ少ない

ある程度完成したら記事書こーっと

某氏の記事に感謝(はてなブログの人なので書くと消されるかもの杞憂)

ご主人様がご覧になっている記事の主張どおり、ITmediaの「続きを読む」機能は、技術的には以下のような仕組みで実装されているケースがあります。

■ 仕組みの概要

多くのWebメディアでは、「続きを読む」をクリックした際に次のいずれかの方法が用いられます。

1. HTML内に全文を含め、CSSやJavaScriptで非表示にする方式

ページ読み込み時点で、記事の全文がHTMLに含まれている。

display: none; などのCSSで後半部分を非表示にする。

「続きを読む」ボタンを押すと、JavaScriptによって表示状態に切り替わる。

特徴

ブラウザの「検証（DevTools）」で簡単に全文を確認できる。

Webクリッパー（例：Obsidian Web Clipper）でも全文が取得されることがある。

実装が簡単で、ページ遷移が不要なため表示が高速。

2. クリック時に追加コンテンツを取得する方式（API通信）

初期HTMLには冒頭部分のみが含まれる。

「続きを読む」クリック時に、サーバーへリクエストを送り、残りの本文を取得する。

有料記事や会員限定コンテンツでよく使用される。

特徴

DevToolsでHTMLを見ただけでは全文は確認できない。

アクセス制御を実装しやすい。

■ なぜこのような実装が使われるのか

パフォーマンス向上：ページ遷移なしでスムーズに表示できる。

SEO対策：検索エンジンに全文を認識させやすい。

実装の簡便さ：開発コストが低い。

■ 注意点

ただし、全文がHTML内に含まれている場合でも、それを意図的に取得・再配布する行為は、利用規約や著作権に抵触する可能性があります。技術的に閲覧可能であっても、法的・倫理的な観点には配慮が必要です。

goでローカルホストにhtml配信して、JavaScriptとかPythonをちょっとフロントで扱えるだけでいい

情報の取得が必要ならUserscript使って表示した画面のhtmlを物故抜いてgoに送るだけでいい

それを変換してExcelにペタッできる情報をクリップボードに渡すだけでいい

キラキラ勢の視座が高いのは結構だが、現場で作られているのはこういうツールなのだ

SaaS？なにそれおいしいの、だ　認証ってなんだ、だ

FORTRAN

COBOL

C

SQL

Pascal

C++

Java

C#

HTML

JavaScript

PHP

Python