Introduction
The purpose of this book is to help me not waste my life.
What it means to waste your life probably has a different meaning to everyone. But to me, from a career perspective, if I'm not learning and sharing and creating things, maybe I'm wasting that part of my life. Also, if I'm completely ignoring science and engineering, I'm not living on the level I want to be living at. And then there's probably the most interesting topic, which is how does one live well. That will probably seep in here because I care about it but it may not be the focus.
Wednesday, Nov 01, 2023
Lately I've been getting a lot of questions from my children about Special Relativity and to be honest my answers haven't been as detailed as I'd like. I took a course in modern physics and enjoyed it and did well, but that was decades ago.
So, given that writing is one of the best ways to think and learn, I'd like to write about Special Relativity every day until I feel like I mostly understand it.
Backing out, let's start with the speed of light. When you put Maxwell's equations together and get a wave out of them, that wave has a speed. Specifically, that speed is given by c^2 = 1/ (epsilon_0 mu_0).
The thing that blew me away when I first learned this is that epsilon_0 and mu_0, the permittivity and permeability of free space were old friends by this point, having shown up in equations describing the strength of forces from electric and magnetic fields on charged particles.
So here are these fundamental constants that show up together to give a speed. We're used to speeds changing. But fundamental constants don't change. Or, if they did, that would be a big deal. It would change the nature of interactions between every particle in your body and every other partner. It would change the size of atoms and molecules. It was change energies and binding strengths.
So then the question becomes, what if you take this relationship seriously and say that since epsilon_0 and mu_0 are fundamental constants that don't change if your velocity changes, and since the speed of light in a vacuum is determined by them, the speed of light in a vacuum must also be constant.
A constant speed still isn't that strange. The strange thing is that it goes farther than that. The speed of light doesn't depend on your speed. A ray of light may be traveling northward at c, and you may also be traveling northward but at v1 and I may be traveling southward at v2. In our non-reletivistic vector math, I would perceive the light to be moving faster than you would. Compared to me, the light would be moving at c + v2. Compared to you, the light would be moving at c + v1. But neither of these are allowed by the prinicple that the speed of light you measure does not depend on your own velocity. It just depends on epsilon_0 and mu_0, which as we have said, can't change without many other physical consequences, which are not observed.
So suddenly we find that our most basic velocity math fails. How then do we recover something that works? As a hint for next time, let's note that velocity is always a ratio of distance to time. The only way for velocity to change is for the measured ratio of distance and time to change. In other words, saying that the measured speed of light will be the same for two observers who themselves have different velocities from each other means that somehow either the measured distance traveled by the light between two events or the measured time that has passed between two events or both must be altered somehow.
That's the eye-popping thing about special relativity: it's not too difficult to accept that epsilon_0 and mu_0 are fundamental constants and constant even with a change in relative velocity. But then suddenly by holding them still you end up with the measured velocity of light itself being constant. And the only way that can happen is if space and time measurements change from one reference frame to another.
Wednesday, Oct 18, 2023
I've been playing a little bit with what an app focused on database exploration might look like.
Should it be hosted on a remote server?
Yes, because that will be convenient.
Should it be self host-able?
Yes, because databases can be highly sensitive and many organizations will be hesitant to connect their database to third parties.
Should it be host-able on your own device?
Yes, because you'll want to be able to explore your developer database. That's hard to do and insecure to do if you're not running the explorer from your own developer box.
Should it be a web app?
Yes. There's just no more convenient installation mechanism.
Should it be a native app?
Yes. That's convenient once it's installed and it lets you look at on-box databases more easily.
That's a lot of yes answers! Aren't you spreading yourself thin?
Maybe. I think that the answer is Flutter for the front end and a rust server for the back end.
Both self hostable.
Blog
Wednesday, Oct 04, 2023
One of the stickiest, most durable technologies is the database.
Django: declarative, commented schema
I've been thinking about databases from the perspective of what to use for my next web app projects and started thinking about database management and specifically why I miss Django when I use Rust for web apps.
I think the biggest thing is that Django automatically provides you with a declarative, annotated schema for your database. There's a source of truth for the database and it's the django class modules.
Each model class and each column property can have comment text associated with it that will give guidance to the user.
But the truth is that Django isn't optimized to make a schema easy to explore and understand.
So I'm interested in exploring creating a tool that is optimized exactly for that.
The Postgres information_schema schema
It looks like you can get a wealth of information about tables and columns from a utility table in postgres called information_schema.columns.
Actually that schema as a whole has a bunch of nice things worth exploring.
select * from information_schema.columns;
Monday, Oct 02, 2023
Longevity
One of the things that matter when you create something is whether it will last. Meaning, if you make something today, will it still be usable tomorrow? What about a month or a year from now? What about 10 years from now or 100 years from now?
Some technologies just last longer than others. Some languages are less transient than others. Some storage methods and platforms last longer than others.
Durable formats
From that perspective for languages,
English Text > HTML > Go > Rust > Javascript > nodejs app
Or something like that. Probably a subset of javascript is quite durable. And of course in any programming language you can make something that will decay quickly by choosing churny dependencies.
Durable storages
For storage mechanisms,
b2 > a cd > postgresql > some startup web app
Or something like that. I don't actually know a truly durable way to store data, especially private data. The closest thing to it that I know of is object storage (like s3 or b2). But there's always plan risk (the company may alter the deal around the service) and credit card risk (somehow payment may get disrupted and then the data is lost).
Actually, that seems like a fairly good idea for charity:
Provide durable, inalienable, private storage for every person. Say 1 Gb each, at least at first.
Durable platforms
As a first guess for durable platforms,
Web > Desktop Operating Systems > Mobile Operating Systems
Within Desktop, probably
Linux > Windows > Mac.
But again, I don't know.
Principle vs details
In the end the details of what lasts and what doesn't will matter very much. For this post, I've made guesses, so the details are unreliable. But the principle of thinking about what will last and what won't matters even if I didn't get the details completely correct.
You only have limited time to make things. Maybe it's worth thinking about how what you make can last.
Saturday, Sep 30, 2023
Last night I went on a walk to think about my life. There are so many things to be grateful for --
- a good marriage to a wonderful wife.
- Four happy, healthy, impressive daughters and four happy, healthy, impressive sons.
- gorgeous weather and beautiful, walkable surroundings.
- some measure of financial security.
- a skill set that's in demand.
- interesting people around me to interact with, enjoy, and learn from.
- a good job with interesting work and good people and the opportunity to work flexibly from home.
But despite all of these things I was feeling panicky and frustrated. And the reason was pretty clear -- life was passing by too quickly and it felt like, from a career perspective, I wasn't getting what I wanted to get done, done.
When I sat down and thought about what I want to get done, it wasn't too complicated:
- I want to write regularly.
- I want to write code for my own projects.
- I want to build and write things that I own.
- I want to go back to my roots in physics and biology and engineering.
So then there was just the question of how to make that practical. The most practical thing, I think, is to make this book here and publish it.
So hello world! And here goes!