AWSによるクラウド入門 少し前に話題になっていた東京大学の講義資料をやってみたので、内容、感想などメモ。 講義で使用するソースコードはすべて Python で書かれていますが、自分が実際に使うとしたら TypeScript で書くだろうなと思ったので TypeScript で写経しました。 が、CDK のコードはすべて TypeScript で書けましたが、Lambda 関数や動作確認用のスクリプトなどを全て置き換えるところまでは至らず、Python のままです。 写経したリポジトリは https://github.com/zaki-yama-labs/intro-aws に。 学べること 本講義資料には全部で5つのハンズオンがあります。 各ハンズオンで利用する AWS のサービスについては以下の通り。 全般 AWS CDK: Cloud Development Kit CloudFor
2024-11-15 開発生産性Kaigi https://developer-productivity-engineering.connpass.com/event/332852/
自分は機械学習を学びたい全ての人類に（CourseraのAndrew Ngのコースをやった後に）Andrew NgのStanfordのCS229の講義を見ることをオススメしてるんですけど、その講義の2018年度バージョンが公開され… https://t.co/OUokFft3ea
Webアプリケーションを実装していると高確率で CORS の問題にぶつかります。CORSがどのようなものかはリンクしたMDNなど既存の解説を読むのが手っ取り早いと思いますが、「なぜそのように設計されたのか」という観点での説明はあまり見ないため、昔の資料の記述や現在の仕様からの推測をもとに整理してみました。 CORSとは 現代のWebはドメイン名をもとにした オリジン (Origin) という概念 (RFC 6454) をもとに権限管理とアクセス制御を行っています。その基本となるのが以下のルールです。 Same-origin policy (同一生成元ポリシー): 同じオリジンに由来するリソースだけを制御できる。 上記Wikipedia記事によるとSOPの概念は1995年のNetscape 2.02に導入されたのが最初のようです。当時のドキュメンテーションを読む限り、これはウインドウ越しに別
One of the key elements of Google's software engineering culture is the use of design docs for defining software designs. These are relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project. The design doc documents the high level implementation strategy and key design decisions with emphasis on the trade-of
データ構造とアルゴリズムの学習の一環として『みんなのデータ構造』を読んだ。これまでで最も良いデータ構造の学習になった。 みんなのデータ構造 作者:Pat Morin発売日: 2018/07/20メディア: 単行本（ソフトカバー） 日本語訳がWebで公開されているので気になる方は無料で読める。が、著者や訳者や出版社応援の意味も込めて購入すると良いと思います。また、ラムダノート社のサイトから買うと紙書籍と電子書籍のセットがお得。 内容 データ構造とアルゴリズムに関連する本はアルゴリズム寄りのものが多いが、データ構造に焦点を当て続けていることが本書の特色。 内容の依存関係 p.21より 大学の教科書のように、正確性を優先したハードコアな内容。 アルゴリズムの内容も少しだがある。「11章 整列アルゴリズム」ではそれまでの章で学んだデータ構造がどのように使われるかを一瞥でき、「12章 グラフ」では深
企業でWebアプリケーションエンジニアとして働き始めて2年と4ヶ月ほど経ちました。様々な仕事を経て、自分が向いていることや楽しく感じることが徐々に明らかになり、数年後になりたい像がぼんやりと浮かび上がってきました。そして、その将来像が世間的には「エンジニアリングマネージャー」（以降EM）と呼ばれていることもわかってきました。この記事では、EMについて自分が周囲から受け取った知識を整理するとともに、そこに向けてどんな戦略を取ろうとしているかをまとめてみます。マネージャーというとネガティブなイメージも拭えませんが、EMは年を重ねて吸い込まれるものではなく、積極的に取りに行くに値する面白いポジションであると思います。この記事を読んでEMに魅力を感じる同世代の仲間が増えると嬉しく思います。 EMについての理解 エンジニアリングマネージャーという職務についてのオーバービューは、広木大地さんによるエン
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
概要 Go言語とは バージョン インストール Hello world Print・Println・Printf 変数(var) 定数(const) コメント 行末のセミコロン キーワード 演算子 型(type) 型変換 リテラル・値 エスケープシーケンス 配列(array) スライス(slice) マップ(map) 制御構文 If文(if) Switch文(switch) For文(for) Goto文(goto) 関数(func) 構造体(struct) インタフェース(interface) interface {}型 ポインタ(pointer) 領域確保(new) 遅延実行(defer) インポート(import) モジュール(module) パッケージ(package) ワークスペース(workspace) ゴルーチン(Goroutine) リンク 概要 Go言語とは Google
あけましておめでとうございます、になるはずだったのですが、後から読んだ『Googleのソフトウェアエンジニアリング』の方を先に記事にしたので新年2本目の更新です。 ky-yk-d.hatenablog.com さて、本題。最近のお気に入りポッドキャストであるe34.fmで激賞されていた『A Philosophy of Software Design』を読みました。初版は2018年に出ていて、今回は2021年に出た第2版を読みました。 スパゲッティコードを想起させる装丁 A Philosophy of Software Design, 2nd Edition (English Edition) 作者:Ousterhout, John K. Amazon scrapbox.io どんな本？ 書籍のテーマはソフトウェアの複雑さです。複雑さとは、システムを理解したり変更したりするのを困難にさせるも
「理系に女子が少ない理由」がTwitterで話題になってる。 高専から大学の工学部（機械系）に編入して現在大学院生の女のポエムを書く。 同級生は話してみれば気のいい人達ばっかりだったけど、ほぼ男子校だから笑とか高専病wとかたまに溢れる非モテユーモアは聞いてて辛かった。 私（女子）の存在を透明化してることへの怒りはもちろんあるけど、それより互いに呪いを掛け合ってダークサイドに堕ちてく男子達の様子がとにかく痛々しくて悲しかったからだ。 「女子が少ないのは女子が少ない（というイメージがある）からだ」って意見をひとつの真とするなら、このユーモアはもうやめた方がいい。 誰も幸せにしない。 Twitterで男性っぽい人が「理系に女子が少ないのはチー牛とかキモオタが嫌だから！キラキラしてないから！」とかツイートして、男性っぽい人がそれにいいねやリプライで賛同してるのをよく見る。 でも女子の気持ちが知りた
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Webサービスのフォームに住所を入力するとき、丁目や番地などを入れる欄について、数字やハイフンを全角で書かなければいけない「全角縛り」をやっているフォームをよく見ます。半角文字を入力してしまってエラーになったり、咄嗟に変換方法を思い出せなかったり、全角と半角の見分けが付きづらかったり、「全角縛り」であることが明示されていなかったり、「ハイフン」としてどの文字を使うべきかわからなかったり……と、鬱陶しさを感じることが多くあります。 「住所は全角のみ」（数字やハイフンも絶対に半角を受け付けない）という仕様がどういう経緯で生まれて、どう広まっ
Hamee様 開発合宿 2021年（前半戦）の資料です。 # 参考リンク - https://speakerdeck.com/soudai/engineer-life-hack - https://www.shinryo.com/special/contents01_3.html - htt…
はじめに 最近ついに、Google Meet に背景ぼかし機能が利用可能になりましたよね。日本語だとインプレスのケータイ Watchの記事などで紹介されてます。確か 2020 年 9 月末前後で順次リリースされていたと記憶しています。 このときは「背景ぼかし」の機能しかなかったのですが、最近（私が気づいたのは 2020/10/30）更にアップデートされました。アップデートで「背景差し替え」機能が付いて、ぼかし機能もぼかし効果が強弱 2 つから選べるようになりました。まだ日本語のニュース記事は見てないですが、Googleによるアップデートの発表はちゃんとされています。 そして、Google AI Blog でBackground Features in Google Meet, Powered by Web MLという記事が公開され、実装についての解説がされました。 この記事はその解説記事を
10月1日に適当に書き散らした文章(anond:20211001193856)が2週間以上してからTwitterでリツイートされているのを発見。 はてブを見るとまさかの500越えでびっくり。ブコメを一通り読んだが、言いたいことをわかってくれてるなという人もいれば、全然話がかみ合わないなという人、こんな視点があったのかという人もいて面白かった。 そのうえで、もうちょっと追加で書きたい気分になったので電気自動車の普及プロセスを考えるうえでケーススタディになりそうなディスプレイ産業の話をもう少し書いてみる。 なぜiPhoneXの有機EL採用のインパクトが大きかったのかブコメでも指摘があったが、iPhoneXの前にサムスンがGalaxyで有機EL採用していただろうという話。そのことは当然知っててiPhoneXで有機ELが普及したと書いたわけだけど、その理由はなぜか。 年間の携帯電話生産台数って、サ
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 不定期連載を始めます IIJ-II 技術研究所 技術開発室の山本です。私はプログラミング言語HaskellでHTTP/2とTLS 1.3を実装した後、もっぱらQUICを実装することに時間を費やしてきました。 ご存知の方もいらっしゃると思いますが、今年の5月にQUICの仕様がRFC9000として公開されました。このRFCは実によく書かれているので、読みこなせばQUICの全容が掴めるでしょう。 しかし仕様は膨大ですし、実際に実装してみて初めて腑に落ちることもあります。そこでこの機会に、実際にQUICを実装した経験者目線で、QUICの解説をしていきたいと思います。なんとなくTCP/IPを分かっている方が、ある程度QUICの理解ができることを
今年から、できるだけシェルスクリプトを書くのをやめようとしている。私が毎日 zsh に打ち込んでいるのも広義のシェルスクリプトだし、自分用の雑なスクリプトを書くことはあるけれど、チームの他の人も将来に使ったり改変したりするようなものは、なるだけ他の言語を使っている。 シェルスクリプトを書くのは難しいし、その難しさは、学ぶに値しないといったら言い過ぎかもしれないけれど、2021年に初心者が取り組むべき問題とは言い難いと思う。 シェルは悪いプログラミング言語である Bash Strict Mode とかを使ってみても、シェルスクリプトには落とし穴が多すぎる。自分で書いたものを自分で使っている分には大丈夫なのだけど、スクリプトがチーム内で使われるようになると、考慮していなかったところ、例えばファイル名に空白文字が含まれるとか、そういうレベルの微妙なところで、ちゃんと書かれていないスクリプトは壊れ
単一責任の原則（Single responsibility principle）について、もう一度考える はじめに オブジェクトの広場をご覧の皆様ならば、「SOLID原則」という言葉を聞いたことがあるかもしれません。 SOLIDとは、以下の5つのソフトウェア設計原則を並べたバクロニムです。 Single Responsibility Principle：単一責任の原則 Open/closed principle：オープン/クロースドの原則 Liskov substitution principle：リスコフの置換原則 Interface segregation principle：インターフェース分離の原則 Dependency inversion principle：依存性逆転の原則 ソフトウェアエンジニアが知っておくべき設計原則のセットとして、Clean Architecture や
ドキュメンタリアンとは、役職に関係なく、ソフトウェア業界でドキュメントとコミュニケーションに関心を持つ人のことです。 www.writethedocs.org はじめに これは主に『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』の書評です。私はSreakeにてSREという役職についています。SREはサービス概要、アーキテクチャの解説や図、各種構成図、各種手順書、ポストモーテム、ポリシー、SLA(SLO) … その他の様々な場面でドキュメントを書く必要があります。しかし、ドキュメントは価値が見えにくく時間と労力がかかり品質担保の面で重要度がとても高いのにその場での価値が見えにくいので浸透しにくいです。そのため、エンジニアとしてモチベーションが保ちづらいです。2021年 State of DevOps 2021 にもドキュメントに関する言及があり今後、
パッと見える視界の中に絶対とは言えないまでもほぼ確実に存在するものがある。空気や水、都市においては接着剤もその一つだろう。専門家と一緒に街を歩くシリーズ、なんと今日は接着と接着剤を見て歩くのである。 50年接着剤メーカーにいる専門家と歩く 今回一緒に渋谷を歩いてくれる木村修司さんは接着剤メーカー・セメダイン勤続50年超の最古参社員だそう。検索をすると「接着剤博士」という異名まで出てくる。 接着剤について聞くうえではうってつけの方である。 一方、不安もある。街の接着剤を見ると言ってもそんなに話すことがあるのだろうか。違いが微妙すぎやしないか。だが聞いてみるとおもしろい話がたくさんあった。 セメダインの木村修司さん（左）デイリーポータルZ林雄司（右） ビルのガラスは接着剤でついている 渋谷の駅前からスタートです 林：たとえばこの景色で接着剤使ってるところって考えると…。 木村：いっぱいあります
PythonだってGUIを作りたい Pythonで書いたプログラムを実行して使う場合、**『GUIで入出力できたら便利なのに…』**と思うときはありませんか？ 誰かにプログラムを配布する場合でも、CUI(コマンドラインから入出力)はあまり親切とは言えません。 特にITスキルの高くない人にとっては、CUIは拒絶反応を起こすこともあります。 Pythonでも簡単にGUIを作れたら… そんな場合、PySimpleGuiを使ってみてはいかがでしょうか？ PySimpleGuiは誰でも簡単にGUIを実装できるのが特徴で、PySimpleGui公式ドキュメントによると、PySimpleGuiはすぐに習得でき、コード量も他のGUIライブラリ(Tkinter、Qt、WxPythonなど)の1/2～1/10程度で済むとのこと。 百聞は一見にしかずなので、まずは下記のコードと実行結果をご覧ください。 impo
ITエンジニアが投票した「ITエンジニア本大賞2021」ベスト10発表。「オブジェクト指向UIデザイン」「Clean Agile」「思考法図鑑」など 「ITエンジニア本大賞」は翔泳社が主催するイベントです。ただし、対象となる書籍は出版社を問わず技術書、ビジネス書全般です。刊行年も関係なく、これまで大賞に選出された書籍を除き、この1年を振り返っておすすめしたい書籍を投票します。 今回発表されたのは技術書部門とビジネス書部門のそれぞれ10冊。 このなかから特に投票の多かった技術書3冊、ビジネス書3冊について、同社が2月18日、19日に開催するオンラインイベント「Developers Summit 2021（デブサミ2021）」において、書籍の著者、編集者、翻訳者などによるプレゼン大会が開催され、特別ゲストとイベント観覧者による最終投票を経て技術書・ビジネス書の各大賞が決定されます。 技術書部門
技術者（エンジニア）という言葉を多用するのは良くないと思う。 最近、特にコンピュータ関連の職業に携わっている者のことを総称してエンジニアなどと呼ぶようになってきている。 しかし、ここ数年間コンピュータ界で色々な仕事や経験をしてきた結果、以下のようなことがわかった。 まず、技術者（エンジニア）と呼ばれる人たちは、２種類に分けることができると思う。 1. 本当の意味での技術者 通常、大勢の人たちが無理だと思っていたり、どれだけ試行錯誤してもうまくいかないような (たとえばコンピュータに関連する) 技術的な難題を、人並み外れた凄まじい問題解決能力で解決し、たちどころに目的を達成してしまう能力を持つ特殊な人たちのこと。多くの場合、置換不可能である。誰でも勉強すればなれる訳ではない。 2. 作業員的な技術者 上記を除いたその他大勢の、コンピュータに関する仕事に携わっている人たちのこと。たとえば特殊な
追記 2022/11/12 追記 この記事読んで、DI 便利だなって思ったらこちらも併せて読んでみてください。クリーンアーキテクチャーの開設の中で依存性逆転の説明が出てきます。難しいかもしれませんが、一度理解すればつぶしが効く考え方なので腰を据えて読んでみてください。 本文 ここでは、最近のそこそこの規模のアプリだと大体使われてる（と私は思ってる）Dependency Injection（DI）について、何故使ってるのか？というのを私の理解で書いていきたいと思います。 今回の対象言語は C# ですが、DI 使ってる言語であれば大体同じ事情なのかなと思います。 単体テストしたいよね アプリケーションを作るとうまく動いているかテストをすると思います。 たとえ、そのアプリがハローワールドだとしても動かして目視で確認してると思います。 もうちょっとアプリの規模が大きくなってくるとクラス単位やクラス
速くて安いWebサイトを目指して作ったときのポイントです。 追記 2/20：Cloudflare Pagesの毎月の無料枠のビルド回数が誤っていたので修正しました（50→500）
弊社では2019年3月ごろから「無人化システム」の駆逐を進めています。本記事ではこの取り組みを、組織マネジメントとエンジニアリングの側面から紹介します。 恐怖の無人化システム 「無人化システム」は社内の独自用語なので、まずは言葉の意味から説明します。 無人化とはなにか 無人化の前に属人化について触れておきましょう。weblio辞書から属人化について引用します[1]。 ある業務を特定の人が担当し、その人にしかやり方が分からない状態になることを意味する表現。 無人化は属人化の進化系です。無人化とは「属人化していた業務の担当者がいなくなってしまい、誰にもやり方が分からない状態になること」と定義できます。誰がどう見てもダメな状態ですね。 無人化システムとはなにか システム運用が属人化し、かつその運用者が退職するとシステムが無人化します。我々の会社ではこのようなシステムを『無人化システム』と呼んでい
自分が良い Design Docs(Software Design Document)を書くために、読んだ/参考になったリソース集 一覧 Design Docs とは Design Docs at Google デザインドック(Design Doc)について デザインドックで学ぶデザインドック 残業も減らせる!? 上級エンジニアになるための Design Doc 超入門 「Design Doc」って何なのか？ What Is A Design Doc In Software Engineering? (full example) What is a Design Doc: Software Engineering Best Practice #1 https://github.com/kaiinui/note/blob/master/Design--Designdoc.md Googleの
工場訪問や部品・技術の紹介等を行います。 ・機種名、部品名、合金名、企業名で右の記事検索をしてみてください。 ・ロシア、ウクライナの話題は多めです。 ・航空部品の販売には応じられませんが、交換には歓迎です。買取もします。 航空機でなくても鉄道等の部品も歓迎です。 ・研究・教育目的で使用されたい場合は、内容によっては貸し出し等の協力をさせていただきます。
大学在学時に、ソフトウェアVPN（Virtual Private Network）の「SoftEther VPN」（以下、SoftEther）を開発したことで広く知られる登 大遊氏。SoftEther開発後も中国の検閲用ファイアウォール「グレートウォール」へのハッキングなどで話題を集め、現在は東日本電信電話（NTT東日本）のビジネス開発本部 特殊局員、情報処理推進機構（IPA）の産業サイバーセキュリティセンター サイバー技術研究者、筑波大学の客員教授などを務めている。 登氏が、ゲットイットが開催したWebセミナーで、日本のITエンジニアに必要な「トライ&エラー（トライアルアンドエラー）の思考法」について話した。ゲットイットは、リユースIT製品の販売やレンタル、メーカーサポートが終了した製品の保守をサポートするIT機器保守（第三者保守）など幅広い役割で、NTTグループをはじめとする多数の企業
Agile Studio プロデューサーの木下です。2020年の3月に公開した『リモートアジャイル開発のノウハウ集（第1版）』に続き、このたび第2版を公開しました。こちらからダウンロードいただけます。...
Author: @urahiroshi, Engineering manager of Web Platform team 2022年8月4日、メルカリで “web-2” と呼ばれるサーバがシャットダウンされました。これはメルカリWeb版の開発に携わっているチームにとって、一つの区切りとなる出来事でした。 web-2はPHPで記述されたwebサーバで、2015年から https://www.mercari.com/jp/ 配下のコンテンツを配信していましたが、現在では複数のWebマイクロサービスがその機能を担っており、 https://www.mercari.com/jp/ 配下のページは後継となるWebマイクロサービスが配信するページへリダイレクトされています。 メルカリWebのマイクロサービス化に向けた開発が始まり、最終的にweb-2がシャットダウンされるまで、実に4年以上の期間がかか
社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて
コードを書く仕事をしてると、読むことも多い。読んでる時間のほうが多いかもしれない。いま書かれてるコードを読むことも、もちろん多いし、何年も前に書かれたコードを読む機会も割とよくある。 コードを読むと、そのコードを書いた人の考えや、そのときの状況が感じられて、おもしろい。特に、何年も前に書かれたコードを読むときは、コーヒーを片手に（そのときはこんな感じだったんだろうなぁ）って想像しながら読んで楽しい。 ふと、どういうコードから、自分がどういうことを想像するのかを書いてみようと思った。 前提 今、目の前で書かれているコードを読んでレビューしてるときの話じゃなくて、何年も前に書かれたコードを読むときの話をしようと思う。だから、そのコードが良いとか良くないとか、こうするべき「だった」とかは考えない。今後の自分がどう書きたいかなぁ？くらい。 また、そのコードを書いた人が良いとか良くないとかでもない。
そもそも、べき等性とは、どういうことを言うのでしょうか ? これは「ある操作を 1 回行っても複数回行っても結果が同じである」ことをいう概念です。 例えば、注文処理を考えます。画面インターフェースで、注文確定 / 送信ボタンを押すという操作で二度三度押してしまうユーザーがいます。これで同じ内容の注文が複数回登録されてしまったら問題です。こういったケースでは、画面側で連続して押せないような実装を追加したり (①)、サーバー側で同じ注文の処理であることを認識して適切に一つの処理と判断するようなこと (②) が必要です。 この例では、画面側の制御を入れたほうが簡単なように見えます。しかし、現実には画面とサーバーとの間のネットワークの問題や画面以外からの HTTP コールなどを考えると、このような重複リクエストが起こってしまうという可能性はゼロではありません。 このようなものへの対処として、サーバ
睡眠は大切とよく言われますが、睡眠不足が開発者に与える影響をまじめに調べた面白い論文が、ソフトウェア工学のトップ論文誌 IEEE Transactions on Software Engineering に掲載されていました。ソフトウェア工学研究室助教の Raula 先生から教えてもらいました。 Need for Sleep: The Impact of a Night of Sleep Deprivation on Novice Developers’ Performance - IEEE Journals & Magazine この論文での被験者はイタリアの大学生 45人。Test-First 開発でプログラムを書かせるタスクを行ってもらっています。23人には実験前日に睡眠を控えてもらい、平均で直近20時間程度は寝てない状態になっています。対照群は、前日に平均で6.5時間、通常通り寝た
『ソフトウェアアーキテクチャの基礎』 - Techmee vol.2 での発表資料です https://timeedev.connpass.com/event/254336/ 動画: https://youtu.be/ydQ2xoc49Lc #Techmee
600ページを超える書籍である「データ指向アプリケーションデザイン」の要点を最近の話題を交えながら解説します。 Data Engineering Study #18 の発表資料です プレゼンテーション https://www.youtube.com/watch?v=ZiKWXc0fSCw …
2022年度リクルート エンジニアコース新人研修の講義資料です
ビジネスリーダーをはじめ、ソフトウェアプロジェクトの関係者にとって、ソフトウェア開発上の関心事は、開発の進捗とシステムトラブルだ。ソフトウェアの内部品質や開発プロセス上の問題や課題なんて、開発者以外に興味を示す人などほとんどいない。だから、関係者ばかりか開発者自身も、開発の進捗とシステムトラブルにばかり注意を向ける。 そのような状況に、一部の優秀な開発者は我慢ならない。憂いている。「このままではまずい、積み上がった問題に取り組むために時間が欲しい」「まとまった時間でなくても、継続的に取り組むための少しの割り当てでも構わない」と。そんな願いも虚しく、使える時間はすべて、担当する開発を進捗させることにのみ費やすことを強いられる。 私たちエンジニアリングマネージャーやテックリードは、このような状況を見て見ぬふりをしていないだろうか。開発の進捗やシステムトラブル以外にも注意を向けるべき対象がある。
プログラミング上達したいんだったら、四の五の言わずに、 ・クリーンアーキテクチャ ・レガシーコード改善ガイド ・アジャイル・サムライ ・リファクタリング 系のどれか を、全部最低5回読み返して欲しい。それでプログラマとしては圧倒的に成長できるんだから、マジで読んで — Next.js + Hasura 最速プロトタイピング本 @技術書典9 出す予定 (@erukiti) July 27, 2020 先日、こういうツイートをしたらバズってしまいまして。これらの本を理解できるまで読みこめばプログラマとして成長できますよーというもので、 ・ クリーンアーキテクチャ ・ レガシーコード改善ガイド ・ アジャイルサムライ ・ リファクタリング 系のどれか（例えばリファクタリング第二版） の4冊を挙げました。いろいろな人の感想を読んで、補足が必要そうだなと思ったので記事として書きなおしています。 この
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く