Writing Toy Software Is A Joy
I am a huge fan of Richard Feyman’s famous quote: “What I cannot create, I do not understand” I think it’s brilliant, and it remains true across many fields (if you’re willing to be a little creative with the definition of ‘create’). It is to this principle that I believe I owe everything I’m truly good at. Some will tell you to avoid reinventing the wheel, but they’re wrong: you should build your
Reinvent the Wheel | Matthias Endler
One of the most harmful pieces of advice is to not reinvent the wheel. It usually comes from a good place, but is typically given by two groups of people: those who tried to invent a wheel themselves and know how hard it is those who never tried to invent a wheel and blindly follow the advice Either way, both positions lead to a climate where curiosity and exploration gets discouraged. I’m glad th
Enlightenmentware
Enlightenmentware ✏ 2024-05-20 ✂ 2024-05-20 UNIX Git Emacs Boost.Graph Bazel Conclusion As programmers, we interact with software tools daily. Most of them can barely get the job done. But occasionally, we discover a piece of software that transcends mere utility. These tools capture our imagination, open new possibilities, and affect how we design our own systems. I call such software enlightenme
状態の広がりと憑依 - 解釈をするために手を動かす
近年の実用に耐えるプログラミング言語には、構造体、クラスや ADT などのデータの塊（以後、単に「オブジェクト」と言う）を定義する機能が備わっています。 そういった言語でオブジェクトの構造を設計するとき、出来上がってきた設計について僕が真っ先に行う（おそらく最も、もっと言うなら唯一の）重要な sanity-check として、「その構造を持つオブジェクトoに仮に認識主体を認めた場合、oのどのプロパティがoの意思によって動きうる（生得的でない）のか1？そもそもoに認識主体を考えられるほどにoが『モノ』の形をしているか？o単体の意思によってプロパティが動きうる空間はどのような形をしているか？その一連の事情は設計・命名・コメントに反映できているか？」というものがあります。 ここで、「oに仮に認識主体を認めた場合」というのは、「もし、あなたがoそのものだったら」と読み替えて貰って構いません。頑張っ
「読みやすいコード」を依存グラフで考える
はじめに こんにちは、ダイニーの ogino です。 この記事では、コードの読みやすさを比較判断するために役立つメンタルモデルを紹介します。 本記事を読むと、「このコードは良い / 悪い」という感覚が身につき、その理由を自信を持って説明できるようになるはずです。 コードの読みやすさとは何か コードを読む時には大抵、何か特定の目的があります。例えば、 API /foo にリクエストした時の動作を知りたい、ある画面で発生しているバグの原因を知りたい、などです。 この時、コードベースの隅から隅まで読み尽くすのではなく、特定のポイントから出発して関連する箇所を芋蔓式に辿りながら読むはずです。 人が一度に理解して覚えておける情報量には限界があるので、辿らなければいけないコード量が少ないほど当然読みやすくなります。 つまり、ある目的に関連するコードの箇所が局所的かつ明示的であるほどコードは読みやすいと
aposd-vs-clean-code/README.md at main · johnousterhout/aposd-vs-clean-code
JOHN: Hi (Uncle) Bob! You and I have each written books on software design. We agree on some things, but there are some pretty big differences of opinion between my recent book A Philosophy of Software Design (hereafter "APOSD") and your classic book Clean Code. Thanks for agreeing to discuss those differences here. UB: My pleasure John. Before we begin, let me say that I've carefully read through
Beautiful Code | IIJ Engineers Blog
2002年から約10年 IIJ技術研究所長. 年を取ってからは古い計算機や昔の計算法に興味が増し, シミュレーターを作ってそのプログラムを書いたり. 近頃はKnuthのTAOCPにあった問題のプログラムなどに挑戦したりしている. 【IIJ 2024 TECHアドベントカレンダー 12/3の記事です】 人生の長い間に亘ってプログラムを書いてきた. 最初は大学院生の時, 記憶装置のない加減乗算だけの計算機を作り, 紙テープから数値と計算の命令を読み入れ, 中間結果は一旦紙テープに書き出し, それをまた読み入れて計算を続けるという代物だったが, 初期のプログラミングの楽しさはあった. やがて研究室で, 今から見るとままごとのような小規模の計算機を組立てると, 私はライブラリプログラムの整備に熱中した. 大学で講義する身分になると, 次々と多くの計算機, 多くのプログラミング言語と付き合うことにな
DDD以外の設計手法についてご教示いただきたく、DDDの主張をある程度正確に理解した上でDDDをこき下ろしているイメージの強いくまぎさんに質問させていただきました。 最近はソフトウェアの設計について調べると、DDDについての記事ばかりで辟易する一方、私がエンジニアになった頃にDDDに勢いがあった影響もあって私自身DDD以外の良い設計とされているものを知らず、DDDに胡散臭さを感じつつもDDDの考え方にとらわれている、毒親の影響を受けた子供のような状態から抜け出せずにいます。 その最たる例がリポジトリパター
DDD以外の設計手法についてご教示いただきたく、DDDの主張をある程度正確に理解した上でDDDをこき下ろしているイメージの強いくまぎさんに質問させていただきました。 最近はソフトウェアの設計について調べると、DDDについての記事ばかりで辟易する一方、私がエンジニアになった頃にDDDに勢いがあった影響もあって私自身DDD以外の良い設計とされているものを知らず、DDDに胡散臭さを感じつつもDDDの考え方にとらわれている、毒親の影響を受けた子供のような状態から抜け出せずにいます。 その最たる例がリポジトリパターンです。 よく依存性の逆転・DIと一緒に語られますが、くまぎさんがおっしゃる通り余計にインターフェースを切るのはイケてないと感じます。また、DI抜きにしても、リポトリパターン由来の様々な問題（N＋1やバルクアップデート、管理画面用のメソッド生やしたくなる問題など）に対する解決策として提示さ
Always use an enum for your status field · Applied Cartography
When I was first starting my career at Amazon — even more bright-eyed and rosy-cheeked than I am now — I was thrilled by the concept of an "architecture review", and by extension the concept of a "Principal Engineer" (Amazon's term for a staff-level engineer, someone beyond career level) who was always treated with some level of mystique and reverence. This person's role, in the abstract, seemed m
"We ran out of columns" - The best, worst codebase
Jimmy Miller"We ran out of columns" - The best, worst codebase Oh the merchants2 table? Yeah, we ran out of columns on merchants, so we made merchants2 When I started programming as a kid, I didn't know people were paid to program. Even as I graduated high school, I assumed that the world of "professional development" looked quite different from the code I wrote in my spare time. When I lucked my
Where Should Visual Programming Go? @ tonsky.me
There’s a wonderful article by Sebastian Bensusan: “We need visual programming. No, not like that.” (the dot is part of the title ¯\_(ツ)_/¯). In it, Sebastian argues that we shouldn’t try to replace all code with visual programming but instead only add graphics where it makes sense: Most visual programming environments fail to get any usage. Why? They try to replace code syntax and business logic
We need visual programming. No, not like that.
SummaryMost visual programming environments fail to get any usage. Why? They try to replace code syntax and business logic but developers never try to visualize that. Instead, developers visualize state transitions, memory layouts, or network requests. In my opinion, those working on visual programming would be more likely to succeed if they started with aspects of software that developers already
アウトプットのお題に選ぶ、奥深い自作「TODOアプリ」。mattn氏が教える、さらなる技術力の向上を目指すためのノウハウとは
TOPコラムITエンジニアの自己発信ストラテジーアウトプットのお題に選ぶ、奥深い自作「TODOアプリ」。mattn氏が教える、さらなる技術力の向上を目指すためのノウハウとは アウトプットのお題に選ぶ、奥深い自作「TODOアプリ」。mattn氏が教える、さらなる技術力の向上を目指すためのノウハウとは 2024年7月8日 mattn 大学卒業後、ソフトウェアハウスやSIerなどでソフトウェア開発に携わる。vi派生のテキストエディタVimの日本語化やプラグイン、Go言語などでOSS（オープンソースソフトウェア）の開発・コミュニティ運営に参加し、2019年からGoogle Developers Expert。2021〜2023年 GitHub Stars。著書に『みんなのGo言語』（2016年、2019年に改訂2版、技術評論社、共著）、『Go 言語プログラミングエッセンス』（2023年、技術評論社
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
A break from programming languages
README.pdf)
Coding Isn't Programming
How types make hard problems easy
Quantus
Everybody Codes
Tiger Style! - ratfactor