サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
note.com/erukiti
プログラミング上達したいんだったら、四の五の言わずに、 ・クリーンアーキテクチャ ・レガシーコード改善ガイド ・アジャイル・サムライ ・リファクタリング 系のどれか を、全部最低5回読み返して欲しい。それでプログラマとしては圧倒的に成長できるんだから、マジで読んで — Next.js + Hasura 最速プロトタイピング本 @技術書典9 出す予定 (@erukiti) July 27, 2020 先日、こういうツイートをしたらバズってしまいまして。これらの本を理解できるまで読みこめばプログラマとして成長できますよーというもので、 ・ クリーンアーキテクチャ ・ レガシーコード改善ガイド ・ アジャイルサムライ ・ リファクタリング 系のどれか(例えばリファクタリング第二版) の4冊を挙げました。いろいろな人の感想を読んで、補足が必要そうだなと思ったので記事として書きなおしています。 追記
この記事は、ウェブ技術の開発者(Java, PHP, Ruby, Go... 全て含む)のうち、少しでもJavaScriptを触ったことがあるけど、現代ウェブフロントエンドというか、特にウェブアプリケーション —— React, Vue, Angular など—— が分からない人に向けて、たったひとつの理解方法を提示するものです。 追記: ちなみに果てしなくどうでもいいですが、今回の記事が記念すべき100記事目らしいです。(Noteさん!その手のヤツはいっそ自動で記事にバッヂを表示するとかしてくれるとうれしいです!) 対象読者は、Java, PH(以下略)などのコードと一緒に、ほんの少しでもJSのコードを触った、見たことがあるというレベル感の人なので、既にReact, Vue, Angular などでガリガリコードを書いている人は対象ではありません。 あとホームページ屋さんとかウェブコーダ
この記事では面倒なので名前に .js が付いているものは省きます。例えばNext.js は Next と表記します。 まず結論から日本ではVueはReactと二分する人気があるように観測されますが、世界的な数字で人気・シェアを見るとReactが圧倒的です。 シェアだけで見るとAngularとAngularJS(Angular系の1.x系)の合計値はVueよりも高いですが、「今後はもう採用したくない」と考える率が高く、Angular/AngularJSの人気が低下しているということは間違いありません。 ※追記: Angularのシェア、人気度に関しては、Angular及びAngularJS両方を含む数値であり、AngularJSとAngularは別物であるものが混ざってカウントされているため、Angularのシェア及び人気度はあやふやかもしれません。他の数値に関して信頼性を疑うべきかどうかは
社会問題にもなっている就職氷河期直撃世代のえるきちです。クッソどうでもいい専門学校を出てから10年引きこもりニートしてました。 どん底(と言っても本当にどん底ではないかもしれない)からでも、普通に人生なんとかなるみたいな話です。あと、怪しげなサロンやスクールに通うくらいならN予備校に通う方がいいと思いますという話です。 ワナビー界隈だと年収公開したりするようなキラキラパリピが人気集めるんですって?わざわざ金の話をこれ見よがしに語る人、まっとうなエンジニアではないので気をつけた方がいいですよ。 年収は特に書きませんが、スタートアップに勤めて、同人誌書いたりしつつ、面白おかしく生きるのに問題無い金額は稼いでおります。 前提: 他の世代の人への補足アラフィフ4x歳だったら、経験も豊富で金も一杯もらってんだろ当然だろみたいに考える人もいるかもしれませんが、それは必ずしもそうとはいえません。 たとえ
Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んだので、まとめてみます。コメントやツッコミなどのフィードバックがあればうれしいです。 続編としてクリーンアーキテクチャ本を読むためのポイントという記事を書きました。併せてご覧ください。 なぜ良著?著者のロバート・C・マーチン(著書読んだことあるかも?)は、50年前から現代に至るまで、様々なアーキテクチャを見て、第一線級として開発し続けてきた経験を元に、どのアーキテクチャでもクリーンにしようとするなら、基本部分は変わらないと言ってて、それらが美味くまとまった本だからです。 いってみればコンピュータ工学について抑えるべきポイントを解説した本であり、The Clean Architectureそのものについてはほとんど割かれていません。それくらい、基本として知るべき事が書かれた本なのです。 最近のアーキテクチャを追いか
皆さん異世界転生ラノベをご存知ですか?チートし放題な主人公たち好き勝手しやがってとか思っています?最近は「初級魔法で無双する」「生活魔法で無双する」みたいな話流行ってますよね。 でも、別に異世界なんていかなくても、転生しなくても、プログラミングのチートスキルなんて簡単に身につけられるんですよ。 ※ここでいうチートスキルは本来の意味のチートではないのでご注意ください。そっちのスキル身につけるのは楽しいかもしれませんが、本筋ではありません。 ※ここでいう「初級魔法」はラノベ読まない人の想像する初級魔法ではないことがほとんどなのでご注意を 特定のプログラミングスキルを身につけると、派生スキルが勝手にポコポコ生えてきたり、派生スキルの習得コストが圧倒的に安くなります。 たとえば、なにか一つのプログラミング言語をマスターした人なら、他のプログラミング言語を覚えるときのコストが低くなるというのは直感的
プログラミング上達したいんだったら、四の五の言わずに、 ・クリーンアーキテクチャ ・レガシーコード改善ガイド ・アジャイル・サムライ ・リファクタリング 系のどれか を、全部最低5回読み返して欲しい。それでプログラマとしては圧倒的に成長できるんだから、マジで読んで — Next.js + Hasura 最速プロトタイピング本 @技術書典9 出す予定 (@erukiti) July 27, 2020 先日、こういうツイートをしたらバズってしまいまして。これらの本を理解できるまで読みこめばプログラマとして成長できますよーというもので、 ・ クリーンアーキテクチャ ・ レガシーコード改善ガイド ・ アジャイルサムライ ・ リファクタリング 系のどれか(例えばリファクタリング第二版) の4冊を挙げました。いろいろな人の感想を読んで、補足が必要そうだなと思ったので記事として書きなおしています。 この
先日、ウェブフロントエンドについて理解するためのただ一つの方法を記事にしました。それは「古い知識に頼るな。公式を読め」でした。たった一つの方法です。これをできない人は必ず行き詰まります。公式をひたすら読み込むことができる人は、たぶん大丈夫でしょう。 今回の記事は、その先にあるものです。 モダンフロントエンドの重要性ここでは少し前回の記事のおさらいをしておきます。 2020年のソフトウェアエンジニアリングの世界ではウェブ技術の重要度は増すばかりです。もちろんウェブ技術というのは広い分野です。ウェブ(HTTP/HTML/JS/CSSその他)によるサーバー・クライアント型のソフトウェアは、莫大な市場を背景にどんどか技術が投入されています。 ウェブ技術の中でも、ここ数年はフロントエンド技術の比重がとても大きくなりました。前回の記事にも書いた通り、少なくとも50%以上の影響力を持っています。 ソフト
僕は日頃からReact Hooks + TypeScript 最高だの言ってますけど、実のところ、それらを超えるモノが登場したら一瞬で「React Hooksなんて過去の技術だよねー、#にゃーん(社会性フィルター)」とか「TypeScript?へなにそれ?過去の言語ですよね」とかボロクソに言ってる自信があります。 補足: ボロクソにいうとは限りません。その頃に、単に手のひらクルーって返してるだけで、新しい技術を「〇〇+□□最高!」って言ってるだけになるように、人格的に成長してるかもしれませんw 僕にとっては技術はただの道具にすぎません。 道具に対して必要以上の思い入れもしなければ、信仰する気持ちもありません。というより今あるクソなモノよりマシなものを求める渇望がここ数十年ずっと続いてる感じです。 そんな僕が判定するフロントエンド技術の数々を書いてみます。ブログなんでぶっちゃけテキトウで率直
もしあなたがLLMを使ったプロダクトを何かしら開発している、もしくは興味があるのなら、メモリを大量に積んだMac Studioの購入を検討すべきです。 対象読者NVIDIAが絶対にいいという人はこの記事の対象読者ではありません。また、用途によって、ローカルマシンによるローカルLLMが向いてる・向いてないは明確にあるので、向いてない用途にしか使わない人も対象読者ではありません。あしからず。 また、この記事は別にNVIDIAをdisる意図はありません。みんな違っていい。NVIDIAもいい選択肢ですが、Mac Studioも悪くないですよ、と言いたい。 結論LLMプロダクト開発において、今年はもはやローカルLLMを無視できない、してはいけない状況です。 LLMプロダクト開発をする会社の視点でいえば、是非とも80GB以上の十分なGPUメモリを積んだマシンを用意できるようなアジリティを持つのが望まし
皆さんはGitHub Copilotを使っていますか?VSCodeやIDEに拡張を入れると、生成AIとペアプロのようなことができるという、アレです。 最近はこれがないと仕事ができない。なかった時代を思い出せないという人が増えています。プログラミングの生産性に明確に差が生まれます。僕もその口です。 ただ、GitHub Copilotを使いこなせていないという話も度々聞きます。Copilotが提案してくれるコードが微妙で役に立たないというような感じです。 その差はどこにあるのか?を知りたくて6/24に試しにCopilotを使った動画を撮ってみました。実践的なCopilot実演動画というのはすごく珍しいらしく、GitHub dockyardというコミュニティの竣工イベントに登壇してみないか?というお声がけをいただいたので、8/5にGitHub Copilotを使いこなせるとどうなるのかというライ
いまのところ僕は、TypeScriptは決して理想ではないけど、最善手の言語だと認識していて、僕のフロントエンド技術に対するスタンスという先日に記事にもそういうこと書いてたんですけど、なぜTypeScriptを最善手だと認識しているか?を記事にしてみます。 VSCode の存在正確にはTypeScript Language server が持ってる機能ですが、VSCodeは他のあらゆるIDEやテキストエディタと比較しても、軽量な動作を誇るエディタ・IDEでありながら、強力な補完、tipsでドキュメント表示などの機能を持っています。 ES ModulesTypeScriptのベースであるECMAScriptのモジュール仕様も良いものです。 歴史的経緯とDOM/ブラウザ仕様とガラの悪いコードを除けば、ECMAScript のコードではグローバルを利用しません。 モジュールは export され
VRは仕組み上どうしても矛盾を抱えているので、本命はAR/MR(か、それをベースにした新しい流れのVR)だと確信したという記事です。先日Oculus Questの記事を書いたんですが、VR元年は来ても少なくとも現行の技術で作られるVRの延長線上に未来は無く、今までと同じくずっとVR元年が続くという認識になりました。 VRの抱えてる致命的な矛盾VRゴーグルをかぶると、プレイヤーの視界は全て3Dグラフィックでレンダリングされます。そこには一切現実空間(物理世界)は存在しません。全てコントロールされた没入度の高い世界を作り出す技術がVRです。 いくつかの体を動かす系ゲームをやってみたんですが、どれも致命的な矛盾を抱えてると僕は感じました。 VR空間内の認識と物理世界がかみ合わないのです。 VR空間内では広く感じる為に、タガが外れて、思いっきり力を込めた動作をする可能性があります。 例えばSair
これは、プログラミングを覚えるための方法について、自分なりの知見をまとめる記事です。 前編では僕の道筋を示しながらプログラミングを覚える過程を雑に書いてみました。後編であるこの記事では、プログラミングを覚える・上達するための方法を掘り下げていきます。 ・ まずはコードを書いて動く環境を作る ・ 初学者が最初にやるべきこと(写経 + 改造) ・ 題材探し ・ ブログを書く ・ インプット・アウトプット・実践のバランスを取る ・ 実験してみたいという好奇心 ・ ユニットテスト ・ TDDという設計手法 ・ 英語の読み書き について書いています。 まずはコードを書いて動く環境を作ろうコードを書いて動くようにするまでを、一番最初に整えるのは鉄則です。プログラミングとはコードを書いて動かしてその結果を見る、というサイクルをひたすら繰り返す行為だからです。サイクルはなるべく小さいモノを大量にまわすこと
今、一部のエンジニアでコンピュータサイエンスが重要なのかそうでないのか?と言った話題が盛り上がっています。 僕の主張は、コンピュータサイエンスも、ソフトウェアエンジニアリングも、コミュニケーションや、言語学、あるいは他のあらゆるものも含めて、プログラミング(設計、実装、テストその他全部含む)はそれらの集合体(総合格闘技)であるというものです。 プログラマ(いわゆるPGではなくSEなども含む)は、理系の職業と思われる事も多いですが、実質、理系と文系、双方にまたがっているケースがほとんどです。研究職だとか特定の例外でのみ理系要素に偏ってるでしょう。 プログラミングは、数学、工学、文学、コミュニケーションその他の総合格闘技である以上、どれかを毛嫌いしたり、どれかに傾倒しすぎるのは勿体ないので、少し興味を持ってみませんか?というのがこの記事です。 ただ、分量が多いので、今回の記事は今話題になってる
フロントエンド技術は、ある時期を境に爆発的進化を遂げて、面白く・DX(開発者体験)の良い世界に発展しています。 DXはDeveloper eXperienceの略で、2017年くらいから話題になっているようです。(正しい起源はわかりませんが、雑に検索した限りは、2017年のMediumやdev.toでの英語記事がヒットします) DXに関して日本語での記事は「DX: Developer Experience (開発体験)は重要だ」を読むとわかりやすいと思います。 ウェブ技術をやっている人の中で、バックエンド側しかまだ触ってない、JavaやRuby、PHPのような言語でしかウェブに触れてない人は多く、そういった人に、今のフロントエンド情勢ってこんな感じだよ!って知ってもらいたいという思いがあり、都内の某所にある「ラボ」でモダンフロントエンドエンジニア勉強会というのをお試しで開催してみました。
「枯れた技術」と言われたとき、それが安定していて、保守しやすいものであるという認識が多いように観測されます(観測範囲問題かもしれない)。 この記事でいう技術は「ソフトウェア技術」に特化した内容です。ソフトウェア技術はまだこの世に生まれでてから100年も経過してないような若すぎる産業であり、脆弱性など、ソフトウェア技術に固有の事情があります。 でもそれってほんとですか?事実ですか?正しくそのことを検証しましたか? あなたが枯れてないと認識している技術よりも保守しやすいと思っているのは、ただの思いこみではないですか? 昨日軽い気持ちで書いた僕のフロントエンド技術に対するスタンスという記事のようにフロントエンド系のバズる記事を書くとだいたい「保守とか考えてるの?」みたいなコメントがつくことがありますが、では、バックエンド、組み込み、機械学習、インフラを見て、枯れた技術ってほんとに枯れてるの?保守
先日のClean Architectureは全てのプログラマにお奨めしたい良著という記事では、ASCII DWANGOから出ているClean Architecture 達人に学ぶソフトウェアの構造と設計(以下、Clean Architecture本と呼ぶ)が、アーキテクチャパターンとしてのクリーンアーキテクチャ The Clean Architecture(日本語翻訳版) を採用するかどうかに関わらず、ありとあらゆるプログラマにお勧めしたい良著であると書きました。 Clean Architecture本は主に設計(実装面もある程度含む)において、メンテナンスしやすいものを作り上げるために必要な知見をコンパクトにまとめた本です。この本で押さえておくべき重要な概念は「知識」とその知識を利用する「依存関係」です。 この記事では、前回よりもさらに掘り下げて、Clean Architecture本を
LLMプロダクト開発者がMac Studioを買ってローカルLLMを触るべき理由という記事を書きました。 mutaguchiさんのツイートを見て、LLMプロダクトの開発とはどういうものなのかを知らない人も多いのかなと気づいたので、そこらへんを記事として書いてみます。 https://t.co/4WvjuuoGnC 「LLMプロダクト開発者がMac Studioを買ってローカルLLMを触るべき理由」の記事のはてブコメント見てたんだけど、ほとんど理解されてなかったのが興味深い。 ・プロプライエタリなLLMでは、ランニングコストが嵩み、これを利用したサービスは成立しづらい… — mutaguchi (@mutaguchi) April 24, 2024 商用LLM APIとローカルLLMって使い方が全然違う気がしてる。 商用LLM APIって、機微情報を送らないこと、規約違反テキストを送らないこ
プログラミングの習得・上達方法は人それぞれです。アカデミックでコンピュータサイエンスを習った人、独学でやってきた人、得意なこと・苦手なこと様々でしょう。 道筋はいくつもありますが、ここでは僕の道筋を書くことで、誰かのヒントになればと思います。 前編はわりととりとめもなく僕という個人の道筋を示す記事としました。後編ではこれまでに得た知見をまとめました。 僕 is 誰erukiti と申します。プログラミングを始めて30年になります。プログラミングは完全に独学で覚えました。上達の効率はさほど良くない方だとは思います。 専門学校卒ですが、専門学校はモラトリアムのためだけに言ってたので実質内職しかしてないです。高校もパソ通にハマって勉強一切やってなかったので、ギリギリの卒業でした(日数も成績も) そのあとは10年引きこもりニートしておりました。 そっから就職して、辞めてからフリーランスでエンジニア
先日、技術書典で爆死しないためにという記事を書いた東京ラビットハウスのerukitiでございます。爆死しないためにって記事書いたくせに爆死かよ!!! タイトルは大げさです。実際には248部頒布しているため「そんだけの数を頒布して爆死って????」というツッコミがあると思います。 あと、別につらい、とかそういう類いの話ではないので、この記事は面白おかしく読んでください。実際おもしろい経験をいろいろできました。一部の人の心臓には痛いかもしれませんが……。 今回は知見の共有ということで記事を書いています。 Twitterの #被チェック数 というタグで、それぞれのサークルの被チェック数の共有をしていたので、頒布数に関しても一例ということでご参考ください。 と言っても、割と特殊事例なほうかもしれないので普通にサークル参加する分には、遭遇する事例ではないとは思います!たぶん! 爆死といった理由 これ
JSXとHTMLベースのテンプレート言語の比較を行い、批判されがちなJSXが実はベターな解だったのでは?という記事です。 僕の結論は、HTMLとJSのどちらが制御構造を持てばいいのか?でいえばJS側が持つ方がリファクタリングしやすいため、JSXの方が良いというものです。 さて、先日、JSフレームワーク事情2020年始めという記事を書きました。これは、JavaScriptフロントエンドフレームワーク、Angularの人気が下落中という記事の元ソースであるThe State of JavaScript 2019を見ながら、React/Vue/Angularや、Next/Nuxt/Gatsbyが置かれている状況を解説するものでした。 他には、確証はないものの、Reactのシェアと人気がともに高い理由は、意外にJSXにもあるのではないか?と考えています。VueもAngularも基本的にはHTMLを
noteではおそらくみなさんはじめまして。Qiita戦闘力 5,715のerukitiです。Github戦闘力は417でした。qiita.com/erukiti とか github.com/erukiti で日頃活動しております。技術書典では2,3,4と連続でサークル参加していてJavaScript入門書(200部完売)・JavaScriptAST本(まぁマニアックな本かつ台風だったので200部中170部頒布)と、今回のBitcoin完全に理解した本(200部中200部完売)をそれぞれ出しております。 今回の本は、エンジニアなら自然言語で説明するよりソースコードの方がわかりやすいだろ!というコンセプトで暗号通貨・ブロックチェーンについて解説するシリーズの第一弾です。初版は技術書典4(2018/04/22)に頒布いたしました。 電子版を、このたびnote.muでも頒布することにしました!コン
プログラムを作る時に、紙に設計を書いてから書く人、いきなりコードを打ち始める人、色々なパターンがあると思います。 僕がプログラムを書く手順について雑にまとめてみました。 関数と書いてるものは、場合によってはクラス・メソッドその他かもしれません。ご自身の環境に合わせて適宜読み替えてください。 まずはプログラミング自身というよりはそこに至るまでの話から始めます。 脳内のあれこれを吐き出すまずは何を作るのか、どうやって作るのか、なぜ作るのかなどを整理します。 紙やホワイトボードは最強です。UMLなりポンチ絵なり、文字なり好きな物をものすごい解像度で描けます。 安いノートを買ってきてもいいですし、ホワイトボードや、消せる紙、NuBoardなどを使うというのもいいでしょう。ちなみにお金を掛けずに擬似的NuBoardをするのであればクリアファイルを活用するといいでしょう。 タブレット+ペンもとても便利
技術書典7 の歩き方(技術同人誌即売会、テクノロジーカテゴリー、あと非公式アフターの案内) #技術書典 #テクノロジー #テクノロジー 技術同人誌を愛する皆様、ごきげんよう。この記事は技術同人誌イベントに関する記事なので、できればはてブではテクノロジータグが付いて欲しいところですが、noteで技術系記事を書くといつも「生活」とか謎のタグが付いて怖いので、タイトルにはテクノロジーを強調してみました。 先日、本のうち一冊は入稿して、もう一冊は印刷諦めつつ、電子版だけでもなんとか出したいと思ってるけど、そもそも原稿の断片しかない状態で、ほんとに出るのか?お試し版小冊子だけでもなんとか出したいぞ!という状況のえるきちです。 ・ Effective React Hooks 第二版(技術書典では新刊) ・ TypeScript でクリーンアーキテクチャ本(小冊子&電子版目標) ・ 技術同人誌を書く為の
2018年10月8日(月・祝日)は技術書典5です。サークルリストが公開されました!気になったサークルさんをチェックリストに入れましょう!筆者のサークルはあ15の東京ラビットハウスです!チェックお願いします! 技術書典は、日本でもトップ級のエンジニア達が、ソフトウェアやハードウェア技術について情熱をもって書き上げた、ガチな技術書やハードウェアを頒布しているイベントです。 あまりにも盛況すぎて、ついに技術書典5は秋葉原を脱出して池袋サンシャインに移転することになりました。前回と比べて3倍の床面積!出展サークル数2倍近く!規模がどんどん拡大していく技術書典、いつかはビッグサイトに行く日も来るのでしょうか? これまでの秋葉原UDXのときよりは、会場にだいぶん余裕があるので「ひとごみしんどい」というものぐさエンジニアの方にも来やすいのではないでしょうか? 技術書典はエンジニアに注目されているイベント
ソフトウェアエンジニアが知っているべきSOLID原則についての記事です。SOLID原則は、5つの原則の頭文字を並べた言葉で、S・O・L・I・Dそれぞれの原則について、5回に分けて説明します。 1) Single Responsibility Principle:単一責任の原則 2) Open/closed principle:オープン/クロースドの原則 3) Liskov substitution principle:リスコフの置換原則 4) Interface segregation principle:インターフェース分離の原則 5) Dependency inversion principle:依存性逆転の原則 今回はSingle Responsibility Principle(単一責任の原則 / SRP)についてです。 なぜSOLID原則が必要なのか?初回なので、なぜソフトウェア
技術書を印刷して、技術書典で頒布するときに部数を考慮するロジックのすべて(2019年9月20日バージョン) はてブのカテゴリーエラーは相変わらずのようなので、これが「生活」なのか「ゲーム・アニメ」なのか、それともちゃんと「テクノロジ」に分類されるのか、わたし気になります! 注意: この記事は技術同人誌という超特異点についての記事なので、間違っても、アニメ・ゲームジャンルのサークルさん、参考にしないでください!極めて高い確率で死ぬ可能性が予見されます。 さて、技術書オンリーイベントの代表格、技術書典に参加するときに考えるべきロジックを、技術書典1から継続参加してるノウハウとして記事にします。 ※その日の天気、内容、告知、配置場所、時の運などによって左右されてしまう傾向があります。技術書典7(2019/09/22)は、台風が西日本あたりに来ていて、天気が荒れている可能性があります。 考えるべき
5/25にDMMグループの株式会社Algomaticにジョインしました。 LLMとは、Large Language Model(大規模言語モデル)の略であり、文字列を入力したら、統計的予測と乱数に基づいて、その続きの文字列を返してくれる、いわゆる生成AIの一つで、みなさんご存知の ChatGPT もLLMを応用したアプリです。 Algomaticは、LLMをはじめとした生成AIを活用するサービスを開発・提供するためのスタートアップで、4月に設立したばかりの会社です。
次のページ
このページを最初にブックマークしてみませんか?
『erukiti|note』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く