社会問題にもなっている就職氷河期直撃世代のえるきちです。クッソどうでもいい専門学校を出てから10年引きこもりニートしてました。 どん底（と言っても本当にどん底ではないかもしれない）からでも、普通に人生なんとかなるみたいな話です。あと、怪しげなサロンやスクールに通うくらいならN予備校に通う方がいいと思いますという話です。 ワナビー界隈だと年収公開したりするようなキラキラパリピが人気集めるんですって？わざわざ金の話をこれ見よがしに語る人、まっとうなエンジニアではないので気をつけた方がいいですよ。 年収は特に書きませんが、スタートアップに勤めて、同人誌書いたりしつつ、面白おかしく生きるのに問題無い金額は稼いでおります。 前提: 他の世代の人への補足アラフィフ4x歳だったら、経験も豊富で金も一杯もらってんだろ当然だろみたいに考える人もいるかもしれませんが、それは必ずしもそうとはいえません。 たとえ

プログラミング上達したいんだったら、四の五の言わずに、 ・クリーンアーキテクチャ ・レガシーコード改善ガイド ・アジャイル・サムライ ・リファクタリング 系のどれか を、全部最低5回読み返して欲しい。それでプログラマとしては圧倒的に成長できるんだから、マジで読んで — Next.js + Hasura 最速プロトタイピング本 @技術書典9 出す予定 (@erukiti) July 27, 2020 先日、こういうツイートをしたらバズってしまいまして。これらの本を理解できるまで読みこめばプログラマとして成長できますよーというもので、 ・ クリーンアーキテクチャ ・ レガシーコード改善ガイド ・ アジャイルサムライ ・ リファクタリング 系のどれか（例えばリファクタリング第二版） の4冊を挙げました。いろいろな人の感想を読んで、補足が必要そうだなと思ったので記事として書きなおしています。 この

皆さん異世界転生ラノベをご存知ですか？チートし放題な主人公たち好き勝手しやがってとか思っています？最近は「初級魔法で無双する」「生活魔法で無双する」みたいな話流行ってますよね。 でも、別に異世界なんていかなくても、転生しなくても、プログラミングのチートスキルなんて簡単に身につけられるんですよ。 ※ここでいうチートスキルは本来の意味のチートではないのでご注意ください。そっちのスキル身につけるのは楽しいかもしれませんが、本筋ではありません。 ※ここでいう「初級魔法」はラノベ読まない人の想像する初級魔法ではないことがほとんどなのでご注意を 特定のプログラミングスキルを身につけると、派生スキルが勝手にポコポコ生えてきたり、派生スキルの習得コストが圧倒的に安くなります。 たとえば、なにか一つのプログラミング言語をマスターした人なら、他のプログラミング言語を覚えるときのコストが低くなるというのは直感的

いまのところ僕は、TypeScriptは決して理想ではないけど、最善手の言語だと認識していて、僕のフロントエンド技術に対するスタンスという先日に記事にもそういうこと書いてたんですけど、なぜTypeScriptを最善手だと認識しているか？を記事にしてみます。 VSCode の存在正確にはTypeScript Language server が持ってる機能ですが、VSCodeは他のあらゆるIDEやテキストエディタと比較しても、軽量な動作を誇るエディタ・IDEでありながら、強力な補完、tipsでドキュメント表示などの機能を持っています。 ES ModulesTypeScriptのベースであるECMAScriptのモジュール仕様も良いものです。 歴史的経緯とDOM/ブラウザ仕様とガラの悪いコードを除けば、ECMAScript のコードではグローバルを利用しません。 モジュールは export され

僕は日頃からReact Hooks + TypeScript 最高だの言ってますけど、実のところ、それらを超えるモノが登場したら一瞬で「React Hooksなんて過去の技術だよねー、#にゃーん（社会性フィルター）」とか「TypeScript？へなにそれ？過去の言語ですよね」とかボロクソに言ってる自信があります。 補足: ボロクソにいうとは限りません。その頃に、単に手のひらクルーって返してるだけで、新しい技術を「〇〇＋□□最高！」って言ってるだけになるように、人格的に成長してるかもしれませんｗ 僕にとっては技術はただの道具にすぎません。 道具に対して必要以上の思い入れもしなければ、信仰する気持ちもありません。というより今あるクソなモノよりマシなものを求める渇望がここ数十年ずっと続いてる感じです。 そんな僕が判定するフロントエンド技術の数々を書いてみます。ブログなんでぶっちゃけテキトウで率直

この記事は、ウェブ技術の開発者（Java, PHP, Ruby, Go... 全て含む）のうち、少しでもJavaScriptを触ったことがあるけど、現代ウェブフロントエンドというか、特にウェブアプリケーション —— React, Vue, Angular など—— が分からない人に向けて、たったひとつの理解方法を提示するものです。 追記: ちなみに果てしなくどうでもいいですが、今回の記事が記念すべき100記事目らしいです。（Noteさん！その手のヤツはいっそ自動で記事にバッヂを表示するとかしてくれるとうれしいです！） 対象読者は、Java, PH(以下略）などのコードと一緒に、ほんの少しでもJSのコードを触った、見たことがあるというレベル感の人なので、既にReact, Vue, Angular などでガリガリコードを書いている人は対象ではありません。 あとホームページ屋さんとかウェブコーダ

技術書を印刷して、技術書典で頒布するときに部数を考慮するロジックのすべて（2019年9月20日バージョン） はてブのカテゴリーエラーは相変わらずのようなので、これが「生活」なのか「ゲーム･アニメ」なのか、それともちゃんと「テクノロジ」に分類されるのか、わたし気になります！ 注意: この記事は技術同人誌という超特異点についての記事なので、間違っても、アニメ・ゲームジャンルのサークルさん、参考にしないでください！極めて高い確率で死ぬ可能性が予見されます。 さて、技術書オンリーイベントの代表格、技術書典に参加するときに考えるべきロジックを、技術書典1から継続参加してるノウハウとして記事にします。 ※その日の天気、内容、告知、配置場所、時の運などによって左右されてしまう傾向があります。技術書典7（2019/09/22）は、台風が西日本あたりに来ていて、天気が荒れている可能性があります。 考えるべき

技術書典7 の歩き方（技術同人誌即売会、テクノロジーカテゴリー、あと非公式アフターの案内） #技術書典 #テクノロジー #テクノロジー 技術同人誌を愛する皆様、ごきげんよう。この記事は技術同人誌イベントに関する記事なので、できればはてブではテクノロジータグが付いて欲しいところですが、noteで技術系記事を書くといつも「生活」とか謎のタグが付いて怖いので、タイトルにはテクノロジーを強調してみました。 先日、本のうち一冊は入稿して、もう一冊は印刷諦めつつ、電子版だけでもなんとか出したいと思ってるけど、そもそも原稿の断片しかない状態で、ほんとに出るのか？お試し版小冊子だけでもなんとか出したいぞ！という状況のえるきちです。 ・ Effective React Hooks 第二版（技術書典では新刊） ・ TypeScript でクリーンアーキテクチャ本（小冊子＆電子版目標） ・ 技術同人誌を書く為の

先日のClean Architectureは全てのプログラマにお奨めしたい良著という記事では、ASCII DWANGOから出ているClean Architecture 達人に学ぶソフトウェアの構造と設計（以下、Clean Architecture本と呼ぶ）が、アーキテクチャパターンとしてのクリーンアーキテクチャ The Clean Architecture（日本語翻訳版） を採用するかどうかに関わらず、ありとあらゆるプログラマにお勧めしたい良著であると書きました。 Clean Architecture本は主に設計（実装面もある程度含む）において、メンテナンスしやすいものを作り上げるために必要な知見をコンパクトにまとめた本です。この本で押さえておくべき重要な概念は「知識」とその知識を利用する「依存関係」です。 この記事では、前回よりもさらに掘り下げて、Clean Architecture本を

Clean Architecture　達人に学ぶソフトウェアの構造と設計を読んだので、まとめてみます。コメントやツッコミなどのフィードバックがあればうれしいです。 続編としてクリーンアーキテクチャ本を読むためのポイントという記事を書きました。併せてご覧ください。 なぜ良著？著者のロバート・Ｃ・マーチン（著書読んだことあるかも？）は、50年前から現代に至るまで、様々なアーキテクチャを見て、第一線級として開発し続けてきた経験を元に、どのアーキテクチャでもクリーンにしようとするなら、基本部分は変わらないと言ってて、それらが美味くまとまった本だからです。 いってみればコンピュータ工学について抑えるべきポイントを解説した本であり、The Clean Architectureそのものについてはほとんど割かれていません。それくらい、基本として知るべき事が書かれた本なのです。 最近のアーキテクチャを追いか

10/8の技術書典5に向けて締め切りと格闘中のerukitiです、ごきげんよう。 技術書典5では、あ15東京ラビットハウスにて、最近流行のNextやNuxtなどJavaScriptフレームワークの仕組み解説の本とV8を崇める本を出します。（NextやNuxtの入門書ではないのでご注意を） 宣伝はそれくらいにして、本記事ではプログラマ向けの記事、デザインパターンの一種であるオブザーバパターンについて解説します。 オブザーバパターンはあらゆるところで使われていて、おそらく皆さんが知らず知らずのうちにお世話になっているでしょう。特にGUIやウェブプログラミングなどではまず間違いなく利用しているはずです。 画像の元ネタはこれです。 Twitterでつぶやくときは、#マンガでわかるDocker とか #わかばちゃんと学ぶ のハッシュタグを付けると湊川さんが喜ぶと思います。 その前にデザインパターンと

技術書典5にサークル参加する皆さん向け、特に技術書典経験の少ないサークルさん向けの記事です。 技術書典で爆死しないために、被チェック数の読みかた、印刷部数の判断の仕方、告知の仕方などをまとめた記事です。ただし、当記事では印刷部数と頒布部数について確約できるものではありません。皆様ご自身のご判断でよろしくお願いします。 追記: また、この記事の意図は、印刷部数の判断ということに慣れていない人に、ある程度指針を示すことで、原稿自体に集中できる環境に持って行ってもらいたいという点にあります。enjoyする為に情報をまとめ上げたわけですね。 被チェック数マイページに、被チェック数という数値が書かれている事にお気づきでしょうか？これは参加者の人達のチェックリストに、貴方のサークルが加えられた数で、当日来るモチベショーンの高い人の数であり、サークルカットから情報を読み取れる、もしくはSNSでの宣伝力の

先日、技術書典で爆死しないためにという記事を書いた東京ラビットハウスのerukitiでございます。爆死しないためにって記事書いたくせに爆死かよ！！！ タイトルは大げさです。実際には248部頒布しているため「そんだけの数を頒布して爆死って？？？？」というツッコミがあると思います。 あと、別につらい、とかそういう類いの話ではないので、この記事は面白おかしく読んでください。実際おもしろい経験をいろいろできました。一部の人の心臓には痛いかもしれませんが……。 今回は知見の共有ということで記事を書いています。 Twitterの #被チェック数 というタグで、それぞれのサークルの被チェック数の共有をしていたので、頒布数に関しても一例ということでご参考ください。 と言っても、割と特殊事例なほうかもしれないので普通にサークル参加する分には、遭遇する事例ではないとは思います！たぶん！ 爆死といった理由 これ