A couple years ago I upgraded my desktop hardware, which meant it was time to upgrade my homelab. I had gone through various operating systems and methods of managing my services: systemd on Ubuntu Server, Docker Compose on CentOS, and Podman on NixOS.
I was learning about Kubernetes at work and it seemed like such a powerful tool, so I had this grand vision of building a little cluster in my laundry room with nodes net booting into Flatcar and running services via k3s. When I started building this, I was horrified by the complexity, so I went the complete opposite direction. I didn't need a cluster, net booting, blue-green deployments, or containers. I landed on NixOS with systemd for everything. Bare git repos over ssh for personal projects. Git server hooks for CI/CD. Email server for phone notifications (upgrade failures, service down, low disk space etc). NixOS nightly upgrades.
I never understood the hate systemd gets, but I also never really took the time to learn it until now, and I really love the simplicity when paired with NixOS. I finally feel like I'm satisfied with the operation and management of my server (aside from a semi frequent kernel panic that I've been struggling to resolve).
I recall in the early or mid 2000s using some cheap earbuds plugged into the microphone port of my family computer as a pair of microphones in lieu of having a real microphone nor the money for one. Then I used Audacity to turn the terrible recording into a passable sound effect for the video games I was making.
Not knowing much about how soundcards work, I imagine it would be feasible to flash some soundcards with custom firmware to use the speaker port for input without the user knowing.
I've been wondering for a long time when we might expect to see a stable WebGPU API in all major browsers (mostly concerned with my daily browser, Firefox), so I've been looking for an official message on the topic. Deno claims the spec is ready
> The [WebGPU] spec has been finalized
but the official WebGPU spec [1] still describes it as a draft. Have I misinterpreted something here or is there some missing context around Deno's statement?
I've also been using it for several years and almost completely agree with your sentiment. The only areas that have given me trouble are in the dev tools. On my machines the debugger is significantly slowed down when opening very large JS files, source maps compound the debugger slow down, and I can't always inspect variables' values when using source maps (possibly a build tool config problem).
The chart I'm talking about has multiple names, but is not a simple pie chart. Thanks to funcDropShadow for pointing this out. The names: sunburst chart, multilevel pie chart, and radial treemap.
A pie chart could serve a similar purpose, but can be much easier to interpret. I like this interactive pie chart for profiling Webpack bundle size. I've used it several times at work to help find and reduce bloat in our bundles.
My designers take their own snapshot by cloning their work and using versions in the names of things. Older things are not to be modified with few exceptions. It makes for a good linking experience on my end, but I don't know what that kind of maintenance is like for them.
The content of the series describes creating something like the beginnings of a Deno alternative, upon which the reader could fully recreate Deno or Node.js. It seems to me that the core idea presented is "a JavaScript/TypeScript interface to Rust". The thing that most interests me about something like this is not making yet another alternative to Deno or Node.js, but the potential for adding a scripting language to an application or framework written in Rust. I'm thinking like Python scripting of Blender, Lua as a scripting/modding layer for a game engine, scripting of Tiled with JS, an Electron alternative using GTK, your own browser.
I have memories of illegal immigrant workers from longer than 22 years ago and the USA has had immigration laws for much longer than 22 years. Have I misunderstood your statement?
My android phone's apps must ask for permission to use some of this data (location, microphone, filesystem, etc.), and android provides the options "always", "only when using the app", "this time only", and "never"; which seems to help with this problem, though I'm sure it's nowhere near a silver bullet. When I leave my home I only feel (mostly) untracked if I do so without my phone and only buy things with cash, which is almost non-existent behavior for myself and the people I know.
Over the last decade or so I've switched between Kodi (even back when it was XBMC on a literal Xbox [the original]), Plex, Emby, and Jellyfin; currently settled on Jellyfin for maybe a year and a half. I've also had a great experience with Jellyfin and love that it doesn't hide features behind a paywall. I agree that it has caught up with the competitors in terms of necessary features, but it occasionally feels a little buggy or in need of some UX polish. Perhaps one of my free weekends I'll see if I can contribute.
One of the primary features I appreciate that the others have behind a paywall is the ability to download content for offline use. 1 less reason to open up my network's SSH port to the world. The feature is great for trips where connectivity is limited, or just at a friend's house with terribly unreliable wifi.
I run Jellyfin on an Athlon II X4 (12 or 13 years old) with several other self-hosted services. Transcoding anything above 720p causes the entire system to come to a screeching halt, so I've pre-transcoded all of my content with handbrake to allow direct-play 4k content on all my home devices (Firefox, Shield TV, Chromecast, Android client, desktop client).
I haven't used fp-ts directly, but I use an adjacent package that declares fp-ts as a peer dependency: io-ts. I've almost exclusively for easier type management during deserialization. In vanilla TypeScript I would have defined an interface and a user-defined type guard to handle deserialization:
but user-defined type guards basically duplicate the interface, are prone to error, and can be very verbose. io-ts solves this by creating a run-time schema from which build-time types can be inferred, giving you both an interface and an automatically generated type guard:
Very nifty for my client/server monorepo using Yarn workspaces where the client and server message types are basically just a union of interfaces (of various complexity) defined in io-ts. Then I can just:
This is correct, but I think the point nickdandakis was trying to make is that useEffect does not directly correlate with componentDidUnmount because useEffect's returned callback could be called in the middle of the component's lifecycle, not only when the component unmounts.
For the last few months my team and I have been working on standing up a system of libraries that other teams in our organization will use. From the beginning we decided that documentation was necessary from 2 perspectives:
1. Internal maintenance; to understand the system's depths and how it came to be in its current state
2. External consumption; to see the pieces of the system, how they work together, and how to use them
In my research I stumbled across several viable documentation techniques/patterns that seemed to help us reach our doc goals. We decided to combine 3 of those techniques:
The result feels like more documentation than anyone will ever read, but it has allowed us to create a complete self-service set of documents that should allow our library to be used broadly across the org without our team becoming something like a tool support team.
While demonstrating or describing our system to people across the org (not just devs) we found that pointing to the top 2 levels of our C4 diagrams has been incredibly useful at helping describe the system and the work we're doing in the system. We've also received fantastic positive feedback from our audience regarding the diagrams and their ability to help clarify the concepts being described.
We decided to embed our diagrams directly into our markdown docs. The raw markdown looks like this:
```
## How It Works
A person uses the app, the app is compiled from the code, the code is maintained by developers.
<!--
@startuml example-diagram
!include <C4/C4_Container>
Person(dev, "Developer", "A software developer")
Person(user, "User", "A person that uses the application")
System(app, "Application", "The application")
System(code, "Code", "Code repository")
Rel(dev, code, "Maintains", "Git")
Rel(code, app, "Produces", "Azure")
Rel(user, app, "Uses", "Web Browser")
@enduml
-->
```
This ends up being completely readable as a plain markdown file, but is enhanced by having a markdown preview tool like any of the major Git hosts (GitHub, ADO, etc.) because the PlantUML is hidden, but the diagram is presented graphically as a .png image. It also allows us to keep our documentation close to the code it represents, which has been a huge benefit in the organizing of documentation (vs adding another doc to the pile of outdated docs in our internal wiki).
I might be remembering the timeline wrong, but I was perfectly happy using Firefox when I first heard of Chrome. When I switched from Firefox to Chrome I was very impressed with the improvements in design, performance, and greater set of useful features. Definitely some steps in the right direction, but I believe we had already been saved from IE. These days there are many browsers to choose from (though most seem to be built on Chromium, which we wouldn't have without Chrome) and the competition is fun to spectate.
The big improvement for me that Firefox had over IE was tabs, though I'm sure there were many other UX improvements that my young mind didn't recognize or hold onto.
I've found that code colocation is great, especially combined with a directory structure that mimics the application's hierarchy/layers. At my place is employment we try to follow a principle of "keep related code contained to a single place". On its own this ended up causing some problems with "reinventing the wheel" and a relatively inconsistent experience when crossing borders between team ownership. The big thing that has helped a ton is having a regular meeting with nearly all employees working on the same part of the stack. We used the meeting as a space for talking about what we're working on and even get into the details of "I'm solving problem X by building solution Y." At which point others can chime in with interest in using it for their own upcoming projects, describe how they already have a solution to problem X, or provide suggestions. It's not the only thing discussed in this meeting, but it has been important for improving the consistency and general quality of the product. The resulting code follows the same principle above, but reused code ends up bubbling up to a "common" space in the lowest common shared layer; whether it's a new directory or a new package used by multiple projects.
A couple new problems we're dealing with now:
1. Finding older common things and deprecating them. When it's in a common space it feels like it's everyone's responsibility which means nobody ends up working on it. Maybe more narrow, clear ownership would solve that problem.
2. Someone finds the common thing that almost fits their need, if only it had one more little feature. The problem is when this happens many times and you end up with this complicated beast of an abstraction. This is probably solved by finding ways to decompose the abstraction and by following a principle of "do one thing well" or something about simplicity.
Upon initial login I'm definitely impressed by the interface, the existing content, and the potential to finally brush up on my Japanese.
I ended up linking to my Google account, but I spent a long while trying to "sign up" with my email only to be given an message about failing to meet the password requirements (no mention of character limit and no special characters allowed). At first I thought I just needed to adjust my password generator to get a valid password (usually 64 chars with alpha-numerics and special characters), but even the simplest passwords failed with the same error message.
After going through the "Git Internals"[0] docs, I found that the snapshot mental model has been much more helpful in understanding what my Git commands are doing, how someone's history got into a confusing state, etc. The primary model is that of the Merkle tree, and subsequently hashing, which are very simple and powerful concepts.
I've tried using Amethyst a few times but never finished anything. Upon each attempt I ended up moving to another language/framework due to the frustration of horrible compile times. Also, while there are lots of comprehensive docs, but the docs were written for a variety of versions so there was a lot of friction to get something simple started. It has been several months since my last attempt, so perhaps Amethyst has improved since then. I do love the promises Amethyst makes and for the same reason I'm very interested in Bevy.
I was learning about Kubernetes at work and it seemed like such a powerful tool, so I had this grand vision of building a little cluster in my laundry room with nodes net booting into Flatcar and running services via k3s. When I started building this, I was horrified by the complexity, so I went the complete opposite direction. I didn't need a cluster, net booting, blue-green deployments, or containers. I landed on NixOS with systemd for everything. Bare git repos over ssh for personal projects. Git server hooks for CI/CD. Email server for phone notifications (upgrade failures, service down, low disk space etc). NixOS nightly upgrades.
I never understood the hate systemd gets, but I also never really took the time to learn it until now, and I really love the simplicity when paired with NixOS. I finally feel like I'm satisfied with the operation and management of my server (aside from a semi frequent kernel panic that I've been struggling to resolve).