Amazing. I zoomed in with my phone on the generated image and was surprised to see I could just make out the text! https://storage.j0.hn/subpixelfont.png - Also wow my screen is dirty af
Instead of pleading to the TypeScript gods, why not make a deal with the JavaScript deities? Let's get type-checking into JS!
If I want runtime types, I reach for type guards. If I need to do this a lot, then I reach for io-ts or zod and pretty much exclusively write types as validators/codecs/schemas or what-have-you.
I don't think TS - as a specification, type-checker, community, or otherwise - needs to concern itself with runtime validation UNLESS JS gets some agreed upon way to do it.
As an RV-driver, I try my best to use the pull outs when I can. There are a few complications, though.
First is the visibility of these pull-outs is often very poor. You'll be driving through long winding roads and then all of the sudden the pull-out appears. In an RV, you can't just slam on the breaks and swerve into the pullout, ESPECIALLY if you're going downhill.
Second, often times (in the USA at least), these pull-outs have rough terrain going in an and out of them. There will be a little bump or uneven ground that most vehicles wouldn't mind hitting every now and then, but in my rig, that causes the whole thing to sway back and forth (Class-C built on a Mercedes Sprinter). I REALLY need to upgrade the suspension.
Third is time. Since I'm slower than everyone else, people tend to pile up behind me pretty quickly. Pulling into the pull-out, coming to a complete stop, waiting for everyone to pass, then getting back up to speed takes a long time. If I did this every time there was a car behind me, it would take forever. So, I tend to wait until there's more than a few cars behind me before pulling off.
Fourth is my wife. She says I have "overly-considerate disorder" and I need to make our safety #1 and stop caring about other people so damn much.
I think it's less about the game mechanics and more about the viscerality. Board game players tend to prefer physical representations they can feel and fiddle with.
I used this project as a training ground for a ton of different ideas and technologies. From server rendered react to typescript and design systems to how the hell kubernetes works. I went from dokku, to lando, to trying to figure out Consul and Hashicorp stuff to managed K8s on digital ocean. I decided to try to only write SQL and create my own typesafe patterns with TypeScript. It didn’t work out all that great but it wasn’t all that bad either.
This is half baked because I had so many more plans for a product no one asked for. Definitely one of the best learning experiences I had. I started with a monorepo of modules and realized that was a stupid idea for an app. I developed some strong opinions along the way. Oh I reimplemented email auth for the nth time but this time I used postgres’s built-in crypto functions. Man I like this implementation
I’ve been using self-hosted Matomo for https://www.cannonvoice.com since I launched a couple of weeks ago. Man this is some neato software! On top of that it was super easy to deploy to the K8s cluster that runs the app. +1 would recommend.
To folks saying to “Just use server logs”, it’s simply too hard to connect the dots unless you really know what you’re doing. Digging through my nginx logs to find that the majority of my users are dropping off at the second step of sending an invoice would be nearly impossible. Oh I could connect those logs to my api’s database, now I need a place to aggregate that data together. Maybe I could send all of that data together to elasticsearch and query with kibana. Now I need to learn how To set those things up.
Or I could use Matomo for some analytics real quick
I've been building this product for a while. Even though there aren't any loading indicators, I think it's still good enough to get out there!
I've used this project as a test bed for learning new technologies. And what did I learn? That using Docker and Kubernetes effectively is harder than I thought it would be.
Some maybe interesting things about the technology used:
* It's almost 100% TypeScript
* What's not TypeScript is plpgsql
* Postgres
* Nodejs
* Docker
* Deployed to a Kubernetes cluster
* React on the frontend
* React also renders HTML on the backend (for the PDF generation and emails too)
As someone who has also been using TypeScript for over a year and JavaScript for over 10 years, I've had a different take on it.
Disclaimer, I freaking love JavaScript and TypeScript.
> TypeScript is a hack of epic proportions and every so often the reality rears its ugly head in the form of failed source mapping, version compatibility issues, unexpected types during runtime, poor architectural decisions aimed at pleasing the compiler instead of fulfilling project goals.
This just sounds like JavaScript to me. Maybe TypeScript has helped elucidate those problems for you. TypeScript adds some syntax to help formalize solutions to these problems that existed in JavaScript already.
> TypeScript is a very poor way to model real-world systems because it incorrectly assumes that real-world entities have a fixed type schema
This sounds to me like programmer error. TypeScript provides facilities for unknown structures, or structures that have multiple possible definitions. There is the union type for which we can tell the compiler that a value can be of type `A[ or B[ or C[ or... ]]]`. Perhaps even more powerful is optional types. In interface you'd describe an optional field with a question mark, like `{ foo?: string }`. Alternatively, you could use the union type described above, unioned with `undefined`. These structures help you create types that actually do model the uncertainty of data coming into your program. If you're not using these techniques, then you're missing out! Having the type-checker yell at me because I didn't check for the undefined case is a really really cool thing.
> Why not force the developers to account for as many cases and schemas as possible, it's our job!
I would argue that TypeScript provides the vocabulary for doing just that and that JavaScript provides no such niceties. Sure, you provide run-time checks on a piece of datas validity, but there's no system to check that run-time behavior before code gets merged to master.
If you're not running `"strict": true` and annotating your TS code with optional values when data is coming into your program, you might have a bad time.
The compiler can most definitely type-check that code. It's up to you whether or not you want to ignore certain types errors. Want to ignore monkey-patching related errors? Filter out all lines from tsc that include TS2339.
Super cool. I had never heard of Duktape before. Seems like there should be some work making Electron compatible with Duktape to reduce the memory overhead of some of our favorite Electron apps cough VScode cough Slack.
(This is probably a naive comment. I have no idea if this would work the way I assume it would).
I really wish I did have more than one middle name, both of which starting with `R` (indeed, my middle name does start with R). Maybe then as a J.R.R. Fawcett I could write fantasy novels.
Names are hard. My name is John. Programmers get really confused when I tell them that. "Did you know there's another programmer named John? You probably should have researched names before you decided to go with that one"
Seems like Habitat (which looks awesome by the way) relies on Docker. Which, if you consider performance heuristics in the article (size, cold/hot start time), may be a non-starter for what they're trying to do.
Very nice job! I'll definitely be trying this out in a personal project.
How's your experience been with TypeScript and oao? I've got a very large monorepo (using yarn workspaces) of TypeScript modules and it's been sort of a PITA. For instance, a typical yarn install will unnecessarily duplicate some dependencies across packages causing tsc to complain about duplicate identifiers. Running yarn --check-files fixes this, but it's still annoying. Also, following symbols with yarn workspaces is sometimes annoying since linked packages will use "main" and "types" fields in the package.json, thus following a symbol takes you to the generated type definition. I have a generated tsconfig.json that sets paths to their appropriate package paths to fix that. Again annoying.
That seems right. Should probably be longer. Each second, a new chunk is emitted with the appropriate html to hide the old clock element and show the new.