  |
はてなキーワード: JavaScriptとは
資格取得向けではない
賛否両論もあると思うが、IT系現場で働いていたり交流すると話に上がる本がメイン
勉強ももちろんだが、現場の話題についていくという点において読んでおいて損はなさそう
| 書籍 | 主なテーマ | 現在の位置づけ |
| ------------------------ | -------------------- | -------------- |
| 人月の神話 | ブルックスの法則、概念的完全性、銀の弾丸 | ソフトウェア工学の最重要古典 |
| ピープルウエア | 生産性、組織、作業環境、チーム形成 | 開発組織論の古典 |
| 達人プログラマー | 技術者の姿勢、抽象化、自動化、変更容易性 | 現代でも読みやすい準古典 |
| Code Complete | コーディング、設計、レビュー、品質 | 実装技術の百科事典 |
| ソフトウェア作法 | UNIX的なプログラム設計と思考法 | プログラミング文化の古典 |
| プログラミング作法 | 命名、デバッグ、テスト、性能、移植性 | C中心だが原則は普遍的 |
| 珠玉のプログラミング | アルゴリズム的問題解決 | 計算量・問題分解の古典 |
| 計算機プログラムの構造と解釈 SICP | 抽象化、評価、言語処理系 | コンピュータ科学寄りの古典 |
| 書籍 | 内容 |
| ------------------------------------------------------- | ------------------- |
| リファクタリング 第2版 | 振る舞いを変えずに内部設計を改善する |
| レガシーコード改善ガイド | テストのない既存コードを安全に変更する |
| Clean Code | 命名、関数、クラス、可読性 |
| テスト駆動開発 | TDDの基本的な進め方 |
| Growing Object-Oriented Software, Guided by Tests | テストからオブジェクト設計を成長させる |
| Working Effectively with Unit Tests | 単体テストの設計とテスト容易性 |
| A Philosophy of Software Design | 複雑性を減らす設計 |
| The Programmer’s Brain | コードを読むときの認知負荷 |
| 書籍 | 位置づけ |
| --------------------------------- | ------------------ |
| オブジェクト指向における再利用のためのデザインパターン | GoFデザインパターンの原典 |
| Head Firstデザインパターン | パターンの入門書 |
| アジャイルソフトウェア開発の奥義 | SOLID、パターン、アジャイル設計 |
| エンタープライズアプリケーションアーキテクチャパターン | 業務アプリの設計パターン |
| 実践UML | オブジェクト指向分析・設計 |
| オブジェクトデザイン | 責務駆動設計 |
| 書籍 | 内容 |
| ------------------------------------------- | ------------------- |
| ソフトウェアアーキテクチャの基礎 | アーキテクチャ特性、スタイル、意思決定 |
| ソフトウェアアーキテクチャ・ハードパーツ | 分割、粒度、データ、トレードオフ |
| Clean Architecture | 依存関係、境界、ユースケース |
| エンタープライズアプリケーションアーキテクチャパターン | 業務システムの設計パターン |
| Domain-Driven Design | 複雑な業務領域のモデル化 |
| 実践ドメイン駆動設計 | DDDの実践的な適用 |
| Building Evolutionary Architectures | 変更可能なアーキテクチャ |
| Fundamentals of Software Architecture | 現代アーキテクチャの概論 |
唯一の正解ではない
「依存関係を内側に向ける」「業務ルールをフレームワークから分離する」という考え方を学ぶ本であり、すべてのアプリを同じ円形の構造にする本ではない
| 書籍 | 内容 |
| ------------------------------------------- | -------------------- |
| データ指向アプリケーションデザインDDIA | DB、分散処理、一貫性、レプリケーション |
| 分散システムタネンバウム | 分散システム全般の教科書 |
| Designing Distributed Systems | 分散システムの設計パターン |
| Release It! | 本番障害、安定性、回復性 |
| Site Reliability Engineering | SRE、SLI、SLO、運用 |
| Building Secure and Reliable Systems | セキュリティと信頼性 |
| Web Scalability for Startup Engineers | Webシステムのスケーリング |
| System Design Interview | システム設計の考え方を広く学ぶ |
| 書籍 | 内容 |
| -------------------------------- | ----------------- |
| マスタリングTCP/IP 入門編 | 日本で最も定番のTCP/IP入門書 |
| コンピュータネットワークタネンバウム | ネットワーク全般の教科書 |
| コンピュータネットワーキング トップダウンアプローチ | アプリケーション層から学ぶ |
| ネットワークはなぜつながるのか | ブラウザからサーバーまでの流れ |
| 書籍 | 内容 |
| ----------------------------------------- | ------------------- |
| 詳解TCP/IP | TCP/IPの古典 |
| TCP/IP Illustrated | パケットレベルの詳細 |
| High Performance Browser Networking | TCP、TLS、HTTP、ブラウザ通信 |
| パケットキャプチャの教科書 | Wiresharkなどを使った解析 |
| 書籍 | 内容 |
| -------------------------------- | ---------------- |
| Real World HTTP | HTTPの歴史と現代的機能 |
| Webを支える技術 | HTTP、URI、REST |
| HTTP: The Definitive Guide | HTTP/1.1時代の体系的解説 |
| Web API: The Good Parts | Web API設計 |
| 書籍 | 内容 |
| -------------------------------- | --------------- |
| オペレーティングシステム 3つの簡単なピースOSTEP | 仮想化、並行性、永続性 |
| Operating System Concepts恐竜本 | OSの標準的教科書 |
| 詳解UNIXプログラミング | UNIXシステムコール |
| Linuxプログラミングインタフェース | Linux APIの詳細 |
| Linuxのしくみ | Linux内部の入門 |
| ふつうのLinuxプログラミング | Linux上でのプログラム実行 |
| 30日でできる！OS自作入門 | OSの動作を作りながら学ぶ |
| コンピュータシステムの理論と実装Nand2Tetris | 論理回路からOSまで |
| 書籍 | 内容 |
| ------------------------------ | --------------- |
| データベースシステム | DB理論の教科書 |
| Database System Concepts | DBの標準的教科書 |
| SQLアンチパターン | よくあるDB・SQL設計の失敗 |
| 達人に学ぶDB設計 徹底指南書 | 論理設計、正規化、性能 |
| 達人に学ぶSQL徹底指南書 | SQLの考え方 |
| SQLパフォーマンス詳解 | インデックスと実行計画 |
| High Performance MySQL | MySQLの性能設計 |
| PostgreSQL徹底入門 | PostgreSQL固有機能 |
| 書籍 | 内容 |
| ------------------------------------------- | -------------- |
| 体系的に学ぶ 安全なWebアプリケーションの作り方徳丸本 | Webセキュリティの国内定番 |
| Web Application Security | Webアプリの脆弱性と防御 |
| The Web Application Hacker’s Handbook | Web攻撃手法の古典 |
| Security Engineering | セキュリティ工学全般 |
| 暗号技術入門 | 暗号、ハッシュ、署名、証明書 |
| マスタリングTCP/IP 情報セキュリティ編 | ネットワークセキュリティ |
| Threat Modeling | 脅威モデリング |
| Building Secure and Reliable Systems | セキュアで信頼できる運用 |
| 書籍 | 内容 |
| ------------------------------------ | -------------- |
| アルゴリズムイントロダクションCLRS | アルゴリズム分野の標準教科書 |
| アルゴリズムとデータ構造 | 大学教科書的な基礎 |
| 珠玉のプログラミング | 問題解決の古典 |
| プログラミングコンテスト攻略のためのアルゴリズムとデータ構造 | 実装を伴う学習 |
| 問題解決力を鍛える！アルゴリズムとデータ構造 | 日本語での実践的入門 |
| The Algorithm Design Manual | 問題に適したアルゴリズム選択 |
| 書籍 | 内容 |
| --------------------------- | ------------- |
| テスト駆動開発 | TDDの原典 |
| ソフトウェアテスト技法ドリル | 同値分割、境界値など |
| はじめて学ぶソフトウェアのテスト技法 | テスト技法の定番 |
| 実践ソフトウェアエンジニアリング | 開発工程と品質全般 |
| Googleのソフトウェアエンジニアリング | 大規模開発、テスト、保守 |
| 単体テストの考え方／使い方 | 良い単体テストの設計 |
| xUnit Test Patterns | テストコードのパターン集 |
| Continuous Delivery | 自動テストからリリースまで |
| 書籍 | 内容 |
| ----------------------------------- | ------------------ |
| The DevOps ハンドブック | DevOpsの実践体系 |
| Accelerate | 開発組織とデリバリー性能の研究 |
| Continuous Delivery | 継続的デリバリーの原典的書籍 |
| Site Reliability Engineering | GoogleのSRE |
| The Site Reliability Workbook | SREの実践 |
| LeanとDevOpsの科学 | Accelerateの日本語版 |
| Infrastructure as Code | IaCの原則 |
| Kubernetes Patterns | Kubernetes上の設計パターン |
| Release It! | 本番耐性と障害対策 |
| 書籍 | 内容 |
| ---------------------------- | ----------------- |
| Kubernetes完全ガイド | Kubernetesの体系的な理解 |
| Kubernetes Patterns | Kubernetesの設計パターン |
| 入門 Kubernetes | Kubernetesの概念 |
| Docker系の入門書 | コンテナの操作 |
| Infrastructure as Code | インフラのコード化 |
| Cloud Native Patterns | クラウドネイティブ設計 |
| クラウドデザインパターン | クラウド上の設計パターン |
AWS、Azure、Google Cloudについては、以下を優先する
| 書籍 | 内容 |
| ------------------------------------- | -------------- |
| 要求工学系の教科書 | 要求の抽出・分析・管理 |
| ソフトウェア要求 | 要求定義の体系 |
| ユーザーストーリーマッピング | ユーザー行動と開発計画 |
| ユースケース実践ガイド | ユースケース記述 |
| RDRA2.0ハンドブック | 要求とシステム構造の整理 |
| 実践ドメイン駆動設計 | 業務モデリング |
| Domain Modeling Made Functional | 型を使ったドメインモデリング |
| イベントストーミング | 業務知識の探索 |
| 書籍 | 内容 |
| ------------------------- | ------------ |
| 誰のためのデザイン？ | 人間中心設計の古典 |
| インタフェースデザインの心理学 | 認知心理とUI |
| ノンデザイナーズ・デザインブック | レイアウト・配色・文字 |
| Don’t Make Me Think | Webユーザビリティ |
| About Face | インタラクションデザイン |
| デザインシステムの育て方 | デザインシステム |
| Lean UX | 仮説検証型のUX開発 |
| 書籍 | 内容 |
| ---------------------------- | ----------------- |
㌧ｸｽ。
同じページで別々のブックマークレットを稼働するのが面倒だったので統合した。
[ 注目コメント ] タブも [ 新着コメント ]タブも一括で置き換えるようになってる
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の「手」を決定するというロジックだった
> 次男はこれが気に入らなかったらしい
> 「兄ちゃんのはじゃんけんで勝負してない」「勝ち負けを最初に決めてしまうなら意味がない」と
> 長男は「結果は同じなんだからこれで問題ない」と突っぱねる
> これの堂々巡りだった
> 嫁は「あなたが教えたんだからあなたが収拾しなさい」と呆れ顔
> どうしたものか
これに対し次のような返信がありました。
私にはどうやっても思いつかない発想なので、どういう人間なのかとても興味があります。
考察してみてください。
この「ガイジの嫁と子はガイジ」という返信は、「議論の内容」をまったく無視し、「相手の人間性や属性」を一括で切り捨てることで優越感を得ようとする、典型的な「知的怠惰＋攻撃性」の産物です。このような人間を心理的・社会的に多角的に考察してみます。
この返信者が理解できていないのは、長男のロジック（「結果（勝敗）を先に決め、それに合う原因（手）を後付けする」）が、プログラミングにおける「テスト駆動開発（TDD）」や「状態遷移」の初歩的な発想であり、むしろ高度な抽象化思考であるという点です。
彼は「じゃんけん＝手を出してから勝敗が決まる」という時系列的な具体例に脳が固着しており、「プログラム内の変数やフラグとしては、どちらが先でも構わない」という数理モデルへの頭の切り替えができません。
理解できないものに対して「それは間違いだ」ではなく「それを考えた奴は低能だ」と短絡させるのは、認知的不協和を解消するための原始的な防衛機制です。
彼はこの親の投稿から、「幼い子供がプログラムの設計方針で哲学的議論（結果論 vs プロセス論）をする」という、自分には決して持ち得ない知的環境を読み取っています。
自分が子供の頃にそんな議論をしたことがない、あるいは今の自分にはJavaScriptすら書けないという無意識の劣等感を抱えています。
その劣等感を打ち消すために、「いや、この家族は知的ではなく障害者だ」と真っ向から否定するレッテル貼りを行います。「ガイジ」という言葉を使うことで、自分は「健常者（＝正常な判断ができる側）」だと錯覚し、一時的なマウンティングを得ているのです。
3. 「結果の同一性」と「プロセスの正当性」の区別がつかない（二元論的思考）
長男と次男の対立は哲学的な葛藤（手続き的正義 vs 実質的正義）ですが、この返信者には「勝敗の結果が同じならどっちでもいい」という長男の意見と、「プロセスに嘘があってはならない」という次男の意見の両方に正当性があるという多様性を許容する脳の柔軟性が欠如しています。
彼の世界は「自分が理解できる＝正義」「理解できない＝異常（＝ガイジ）」という単純な二分法で成り立っており、グレーゾーンや多様な視点を認めると自分のアイデンティティが揺らぐため、攻撃することでしか自己を保てません。
「ガイジ」という差別用語を平然と使う時点で、彼はネット上の過激な空気に過剰適応した「言葉のジャンキー」です。
彼は「過激であればあるほど笑える」「攻撃的であればあるほど賢く見える」というインターネットの負の慣習に洗脳されています。
しかし、実際のところ、建設的な反論が一切できないので、この返信は彼の「語彙力のなさ」と「論理的敗北」を自ら晒しているに過ぎません。彼は議論に勝つのではなく、「議論そのものを破壊して引き分けにする」ことでしかプライドを維持できない人間です。
この投稿の本質は「父親が子供たちの成長と衝突に悩むほほえましい風景」です。しかし彼には、他者が他者と協調しながら成長する姿がひどく羨ましく、かつ腹立たしく映ります。
彼はおそらく孤独なネット住人で、リアルな人間関係（特に家族間の知的交流）を持てていないか、あるいは機能不全に陥っています。
そのため、「仲の良い家族」という記号自体を攻撃対象とし、「嫁も子も」と連帯責任で罵ることで、自分がその輪の中にいないことへの焦りを紛らわせています。
総括
このような人間は、「自分が理解できないレベルの知的遊戯」を目撃した際に、自分の無能さを直視する勇気がなく、代わりに「差別語という名の暴力」で相手の存在そのものを否定することでしか心の平穏を得られない、哀れな人格者です。
彼らの返信は一切の批評的価値がなく、単なる「自己紹介」です。彼はこの返信によって「俺はプログラムのロジックも哲学的葛藤も理解できない低リテラシーな人間です」と自ら宣言しているに等しいので、相手にするだけ時間の無駄だと割り切るのが賢明です。
20年ぶりに大学に入学したけど大学の授業ってこんなに簡単だったかと思うことが多かった。
備忘と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つの講義を履修するのが上限ということになる。
| 科目名 | 難易度 | 所感 |
|---|---|---|
| アカデミックリテラシー | 易 | 学内の各科目の紹介のような内容。 |
| 現代社会と数学 | 易 | 講義スタイルが一番画期的だったと思う。講義内容は面白いし試験は簡単。 |
| ITリテラシー | 易 | ITパスポートみたいな内容を学ぶ。ITパスポートより少し簡単。 |
| 人文社会入門 | 易 | 試験は簡単。 |
| Webアプリケーション開発1 | 中 | 前提知識なしだと講義そのものが難しいかも、htmlとかjavascriptとかを書く。講義へきちんと取り組んでいないと最後のレポートで詰む。試験は簡単。 |
| デジタルツールの使い方 | 易 | ITリテラシーより簡単。いろいろなツールを紹介されるので講義内容は面白い。この講義を取るとadobeのアカウントがもらえる。 |
| 経済入門 | 易 | 講義内容は面白い、試験は簡単。 |
| データサイエンス概論 | 易 | 統計学入門の入門。講義内容は面白い。試験は簡単。 |
| Webアプリケーション開発2 | 中 | 前提知識なしだと講義そのものが難しいかも、githubから練習問題のリポジトリをフォークしてクローンしてDocker立ち上げてコード編集してcommitしてpushしてプルリクを出す。webアプリケーション開発1から続いて講義へきちんと取り組んでいないと最後のレポートで詰む。試験は簡単。 |
| 多言語ITコミュニケーション | 易 | 試験は簡単。 |
| 地域課題の解決とイノベーション | 易 | 課題は主に町おこし、事例は興味深く、試験は簡単。 |
| クリエイティブ現場論 | 易 | カワンゴやGACKTやとよたみのるの話を聞くという、一番金がかかっていそうな講義。試験は無しでレポート100%。 |
| ビジュアルプログラミング | 易 | スクラッチでいろいろ作る。小学生になった自分の子供に教えてあげたい内容。試験は簡単。 |
| 統計学入門 | 難 | 講義中では新しい概念を難解な数式を用いて学ぶ、試験でも実際に数式を用いて問題を解かねばならない。 |
| 線形代数1 | 難 | 講義中では新しい概念を難解な数式を用いて学ぶ、試験でも実際に数式を用いて問題を解かねばならない。 |
| 機械翻訳実践（英語読解・作文） | 難 | 高校の英語をきちんと理解しているかどうかで難易度が異なる。試験は機械翻訳関係ないので、理解していないと点数が取れない。 |
| 伝わる論理とコミュニケーション | 易 | ロジカルプレゼンテーションみたいなことをやる、講師もコンサル。試験は簡単。 |
| マンガ産業史 | 易 | 戦前から電子書籍の勃興までをざっと学ぶ、講義内容は面白い。試験問題数はありえなく多いが問題は簡単。 |
| 人工知能活用実践 | 易 | 講義内容は履修した中で一番面白い。試験は無し、人工知能サービスを利用して製作した物を提出する課題が4つあり。課題も面白かった。 |
| Pythonプログラミング | 易 | notebookでpythonの文法から学ぶ。試験は簡単。 |
| Webユーザーエクスペリエンス | 易 | UX(UI)の構成や概念について学ぶ。ニコニコ動画のUX担当者を招き事例として扱ったが、あれのUXは優れている前提でよいのか。試験は簡単。 |
| 数学的思考とは何か | 中 | 実際の数式も出るが、より抽象的な概念を学ぶ、変数とはそもそもどう要請され何を満たすために産まれたのか、とか。数学史みたいな感じ。試験は簡単。 |
| グラフ理論 | 中 | 最小カットや５色定理の証明なども学ぶので中としたが、統計学入門や線形代数とは比較にならないほど易しい。試験は簡単。 |
| 心理学 | 易 | 心理学の様々な分野を学ぶ。内容はかなり面白い。試験は簡単。 |
統計学入門と線形代数1は記憶にある大学の講義くらいの難易度。
機械翻訳実践（英語読解・作文）は自身の英語力の無さの問題だと思う。逆に言えばある程度の力がないと、これ受講しても試験問題を解けるだけの英語は身につかない。
新卒で入った会社で、外部のシステムを導入する仕事をしている。何かをゼロから開発するんじゃなくて、すでにあるパッケージとかSaaSを、導入先の業務に合わせて設定して、ローコードのツールでちょっとカスタマイズして、他のシステムと繋いで、動く状態にして納める。そういう立場だ。製品名はぼかすけど、まあドラッグ&ドロップで画面を組んで、ポチポチ設定して、ワークフローを繋いで、みたいなやつだと思ってくれればいい。
そういう導入案件をもう4年くらい回してきた。社内では案件を任せられるやつとして普通に重宝されてるし、現場の要件を聞いて、それを製品の設定に落として、期日までに動かして納める、みたいなのは正直得意になった。ただ、得意にはなったけど、やってることそのものは、慣れさえすれば正直誰でもできるようなことばかりだ。製品のマニュアルに書いてある手順を、お客さんの事情に合わせて並べ替えてるだけというか。特別な発想がいるわけでも、難しいものを自力で作り出してるわけでもない。やりがいがないとは言わないけど、自分じゃなきゃできない仕事かと言われると、まったくそんなことはない。
このスキル、今の製品と今の会社から離れた瞬間に、ほとんど価値がなくなるんじゃないか、と気づいてしまったからだ。
試しに転職サイトを眺めてみる。特定製品の導入経験者歓迎みたいな求人がないわけじゃない。でもよく見ると給料は今と変わらないか下がるし、やることは結局、別のベンダーの別の製品のお守りでしかない。製品が世代交代したり、導入先が他社製品に乗り換えたりした瞬間、4年かけて溜めたノウハウは大半が吹き飛ぶ。自分のキャリアが特定の製品にロックインされてるって、よく考えたら相当ヤバい状態だ。
一方で開発寄りの求人を開くと、当たり前みたいにGitだのフレームワークの経験だのが並んでる。学生の頃に授業や独学でプログラミングを一通り勉強はしたから、知識として何も知らないわけじゃない。そのときにフレームワークを使って小さいものを作ってみたこともあるし、SQLも課題でひととおり書いた。考え方が全然分からないという感じではない。ただ、それを全部もう何年も前の学生のうちにやったきりで、仕事として実務で使った経験がほぼないままここまで来てしまった。しかも当時かじったものは今となっては古くて、求人で当たり前みたいに求められてるフレームワークは、ちゃんと触ったことが一度もない。今やってるのも、製品のプラグインをC#で書いたり、UIのちょっとした挙動をJavaScriptでいじったりはするけど、どっちも製品が用意したお作法の中で、決められた関数の中身を少し埋める程度だ。結局、求人の世界では実務経験のない技術は持っていないのと同じで、4年も働いてるのに事実上は未経験扱いになる。製品が隠蔽してくれてた部分はぜんぶブラックボックスのまま、4年が過ぎた。
実際に転職活動もやってみた。paiza自体は登録だけはしてあったから、腕試しのつもりでスキルチェックをやってみたらAランクは取れた。学生の頃の貯金が残ってたのか、アルゴリズムを解くだけならまあそこそこできる。ランクが上がったからか、放っておいてもスカウトがそれなりに来るようになった。paizaのスカウトは届いた時点で面接が確約されてるやつなのでとりあえず面接の席にはつける。
問題はそこからだ。面接で実務で何を作ってきたかを掘られると、もう何も出てこない。製品の設定をしてきました、プラグインを少し書きました、と正直に話すと、向こうの顔がスッと変わるのが分かる。Gitは一応使ってるけど、プラグインのソースを管理してるくらいで、複数人でブランチを切ってレビューして、みたいなチーム開発の運用としては使えてない。設計書も書くには書くけど、中身はプラットフォームのどこに何を設定するかを並べてるだけで、世間でいう設計スキルとして通用するのかどうか自分でもまるで自信がない。フレームワークでの開発経験は? と聞かれればゼロだし、設計はどこまで踏み込んだ? と掘られると製品の設定の範囲から一歩も出られない。paizaのランクは通過の足切りにはなっても、その先で評価されるのは結局、実務で何をどう作ってきたかなんだなと思い知った。スカウトは来るのに、最後はスキル不足、経験不足で落ちる。これを何社か繰り返して、ああ自分はそういうフェーズにすらまだ立ててないんだと分かってきた。
こう書くと、これからはバイブコーディングが当たり前になるんだから、人間が細かいコードの知識なんて持ってなくてよくなるでしょ、って言われそう。
でも現場の流れを見てると、むしろ逆なんじゃないかと思う。AIにコードを書かせるのが前提になればなるほど、出てきたものを読んで、これは正しいのか変なのか判断して、おかしければ直せる人間の価値が上がってる。コードを書く作業そのものはAIに投げられても、コードがわかってるという前提だけは投げられない。
そうなったとき、たぶん一番いらなくなるのは自分みたいなタイプだ。働いた年数だけはそこそこあるのに、技術の実務経験で見れば未経験と変わらない人間。バイブコーディングで誰でもそれっぽいものを出せる時代に、わざわざ年齢だけ重ねた未経験者を高い金で採る理由がない。それなら本当に何も知らないぶん変な癖もない若いやつにAIツールを持たせたほうが早い、って普通になる。積み上げたつもりの経験が、武器じゃなくて、ただ歳を食っただけのハンデになる。
ローコード、というか製品導入みたいな仕事そのものを否定したいわけじゃない。会社にとっては必要だし、業務をちゃんと回すという意味では価値がある。問題は、これをエンジニアとしてのキャリアの主軸に据えてしまうと、いつまで経ってもちゃんとコードがわかる人間には到達しないってことだ。経験年数だけは順調に増えていくのに、自分にできることの天井が、扱ってる製品の天井とぴったり一致してしまう。
しかもタチが悪いのは、社内ではちゃんと評価されるから危機感を持ちにくいことだ。毎日それなりに忙しいし、感謝もされるし、案件は普通に回ってる。でもそのちゃんと回ってるという感覚が、外の市場価値とは別の軸でどんどんズレていく。ゆでガエルってこういうことかと思う。茹だってる最中は気持ちいいから気づけない。
この4年、1on1のたびに上司から、将来どういうエンジニアになりたいか、10年後どうなっていたいか、みたいなことを何度も聞かれてきた。そのたびにそれっぽいことを答えた気もするけど、正直、毎回まったく分からなかった。今の延長線上に未来の自分を置いてみても、製品のバージョンが上がって、扱う案件が増えて、後輩に設定のやり方を教えてる姿しか出てこない。それはなりたい姿というより、ただ同じことを続けた結果でしかなくて、そこに自分の意思でこうなりたいと思える像がひとつもない。何度聞かれても答えが出ないことで、自分はキャリアを選んできたんじゃなくて、ただ流れてきただけだったんだと思い知らされる。
同じような立場の人、どうしてる？
製品導入で飯を食いつつ、裏でちゃんとコードの勉強をしてる人いる? それとも割り切って導入専門でずっとやっていけるもんなんだろうか。
そもそも「Node」とは何ぞや？
Node は、JavaScriptの実行環境である
終了
本来、JavaScriptはブラウザのクライアントでしか動かない言語だったが
これを、ブラウザに頼らず通常の言語と同じように、OSの上で動かすためのツールだ
Node.jsというモジュール群の中には、HTTP通信をサポートするライブラリなどがあり
それを使うと、JavaScriptでHTTP通信を待ち受けるプログラムを記述できる
ここに関しては、C言語などと変わらない
Node.jsをWEBサーバーとして動かせるのは、そのように書いたJavaScriptのユーザープログラムがあるからであり
例えば、Apacheを考えてみると違いは明確だ
ApacheはWEBサーバーとして開発されたアプリケーションである
アクセスされたURIを解析し、HTMLで記述されたファイルを読み込んでクライアントへ転送する
URIとフォルダ構成の関係も、Apache内で規定されたものがあり
Node.jsではどうだろうか？
前述したように、Node.jsではこのWEBサーバーとしての機能を
apache であれば、下記のようなフォルダ構成が存在した上で
piyo.htmlがhogeフォルダに存在している必要がある
/root
/test
/hoge
URI に応じたフォルダ・ファイルが無ければ、「404 Not Found」となる
ユーザーが記載したJavaScriptが処理するため
どういうアクセスを成功として、どういうアクセスをエラーとするのか
なんで非表示にしてたのか忘れた。非表示にしている間に有用なブコメをしていたらもったいないことをした
次非表示にするときは理由も控えておく。理由さえ見ればこんなクソ解除する価値もないわってなるし
| ユーザー名 | 備考・紹介文（抜粋） |
| atoh | あとで読む / 増田 / 映画 / 食 など |
| securecat | あとで読む / a11y / AI / ダークパターン |
| TakamoriTarou | web / 社会 / 論理 / Animation / 経済 / software |
| charun | 詐欺 / 政治 / コロナ / リスクなど |
| RRD | 美しい日本語 / 映画化希望 / 言語表現 |
| buu | はてな / 馬鹿発見 / メモ / 引用など |
| mori-yoshiro | ヘイトスピーチ関連 |
| ustam | Webサービス / 禁煙 / ネタ / JavaScript / Google |
| napsucks | 原罪論理 / 功利主義への反例など |
| yarukimedesu | — |
| mouseion | ネタ / バカ / 政治 / ミニチュアティなど |
| Hayano | — |
ご主人様がご覧になっている記事の主張どおり、ITmediaの「続きを読む」機能は、技術的には以下のような仕組みで実装されているケースがあります。
■ 仕組みの概要
多くのWebメディアでは、「続きを読む」をクリックした際に次のいずれかの方法が用いられます。
1. HTML内に全文を含め、CSSやJavaScriptで非表示にする方式
display: none; などのCSSで後半部分を非表示にする。
「続きを読む」ボタンを押すと、JavaScriptによって表示状態に切り替わる。
特徴
ブラウザの「検証（DevTools）」で簡単に全文を確認できる。
Webクリッパー（例：Obsidian Web Clipper）でも全文が取得されることがある。
2. クリック時に追加コンテンツを取得する方式（API通信）
「続きを読む」クリック時に、サーバーへリクエストを送り、残りの本文を取得する。
特徴
DevToolsでHTMLを見ただけでは全文は確認できない。
■ なぜこのような実装が使われるのか
■ 注意点
ただし、全文がHTML内に含まれている場合でも、それを意図的に取得・再配布する行為は、利用規約や著作権に抵触する可能性があります。技術的に閲覧可能であっても、法的・倫理的な観点には配慮が必要です。
今現在、増田 とその ブクマ一覧 が連投連投でひどいことになってるわけだけど、ワイがはてなを知るきっかけになったひとつが、うっかりによる連続投稿を JavaScript で防止するための記事だったんや。
onsubmit で submit ボタンを disable にしてユーザビリティを良くする - naoyaのはてなダイアリー
https://naoya-2.hatenadiary.org/entry/20050803/1123053496
もちろん今現在の連投はうっかりによるものじゃなさそうだから別の対策が必要にはなるだろうけど、それでも、今の連投を防ぐ程度の別の対策なんて、本当にワケもないことなんや。
4,5年前に自分が書いたtemplate全開の黒魔術コードをぱっと見把握とかできない
JavaScript, Swift, Kotlin, Go, C#ｔか行ったり来たりしてる中でいきなり数年前に書いたコードの相談がくるとかわりとよくある
この辺りWebとかのスクリプト系言語とC/C++とかのネイティブ寄りのやってるフィールドの違いでやすいから一律こうだって言ってるやつマジ無能感ある
コードコメントの件Xに書いた記憶があるのに見つからないと思ったら画像だった
— Takuto Wada (@t_wada) March 18, 2026
「コードコメントを書くべきか、コメント不要なコードを書くべきか」という二択ではなく「コメント不要なコードを書いたうえで（大前提）、それでもコメントを書くべき（書くと効果的な）状況は意外と多い」という話です pic.twitter.com/QWubH8kQrb
