NTARelix

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?

[1]: https://www.w3.org/TR/webgpu/

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).

Correction:

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.

https://www.anychart.com/chartopedia/chart-type/sunburst-cha...

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.

https://alexkuz.github.io/webpack-chart/

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:

interface ClientMessage { content: string }

function isClientMessage(thing: unknown): thing is ClientMessage { return thing !== null && typeof thing === 'object' && typeof thing.content === 'string' }

expect(isClientMessage('nope')).toBeFalse()

expect(isClientMessage({ content: 'yup' })).toBeTrue()

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:

import { string, type } from 'io-ts'

const ClientMessage = type({ content: string })

expect(ClientMessage.is('nope')).toBeFalse()

expect(ClientMessage.is({ content: 'yup' })).toBeTrue()

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:

ws.on('message', msg => {

  if (ClientMessage.is(msg)) {

    // fullfill client's request

  } else {

    // handle invalid request

  }

})

Only thing missing is additional validation, which I think can be achieved with more complicated codec definitions in io-ts.

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:

1. C4 Model (https://c4model.com/)

2. Architectural Decision Records (https://adr.github.io/)

3. arc42 (https://arc42.org/)

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.

> Calls are end-to-end encrypted and use a direct connection between the peers whenever possible, but fallbacks are also in place.

I imagine this means the 2+ clients use XMPP to negotiate direct connections to one another that are better suited for audio/video streaming.

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.

[0]: https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...

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 performed a similar experiment in high school (~2007) but stored it in a plastic bag. After a few months it smelled absolutely horrible so I wrapped it in more bags and kept it hidden in an enclosed space. I decided to open it on the final day of high school about 2.5 years later and to this day I can recall the horrible smell and the texture. It has turned into a black slime as if it had retained or even gained lots of moisture; completely unrecognizable from its original form. Might be the worst smell I can remember to this day. I always heard people say that McDonald's burgers don't decompose, but after that experiment I never believed it because I had proven that it does decompose.

That miscommunication wasn't apparent to me back then, but seems more relevant than ever now. People often like to make bold claims without giving the relevant context or even without actually understanding the context. I see this all the time with news articles or videos making some claim, showing a small bit of evidence, then the information spreads quickly through social bubbles. If I decide to dig through the sources from which the article was derived, I find that there's often a very important piece of context missing. Whether that context was intentionally removed to twist a narrative or if the context was overlooked is not always clear, but it makes it hard to trust so many people and news articles today.

The best remedy for me so far has been to attempt to identify gaps in the knowledge of the people and articles that I'm observing, then try to fill in those gaps.

This article puts to rest my dissatisfaction with the simple claim that they don't decompose because it reveals the primary difference in testing between the conclusions formed by the 2 opposing experiments.

I came here to say the same thing.

I also just hated worrying about which hairstyle to get, how to maintain that style, and when to repeat that process. Now it's a cheap and simple part of my routine that looks and feels great!

Only downside buzzing myself is that I occasionally miss a small spot if I'm in a hurry, but it's never a big deal and it's easy to fix.

Later levels validate against multiple exits and won't let you remove the original exit, so it seems intentional.

I used to have trouble waking up too. What worked for me was having a strict morning routine that I followed the moment I woke up. I found that sleeping 10 or 12 hours wasn't uninterrupted; I'd often wake up briefly in the morning, realize I was very tired, and quickly fall back asleep. Once I had a morning routine, it became my first priority when I woke up to fulfill that routine and would allow me to pull myself out of bed earlier. Typically my routine is to get ready for work Monday through Friday, but this habit of waking up when I've finished sleeping without an alarm also persists through the weekend.

If I stay up later than usual then I'll often wake up at the usual time and just sleep a little less, but sometimes I'll sleep a bit longer. Either way I still feel very tired breaking out of my schedule. I'm also lucky enough to have an employer allows a relatively flexible schedule so I could experiment with this for a while.

Makes me wonder how many of those guides have been paid for, or at least what level of influence advertisers have on them. Nevertheless, I agree that a quality guide is well appreciated, however hard to come by.

I listened to the podcast over the course of a week during my daily commute.

Calabrio | Software Engineer: Frontend, Backend, Full Stack | Minneapolis, MN or Vancouver, BC | Full time | On-site http://calabrio.com/

Calabrio gives you the power of a single integrated solution for call recording, quality assurance, workforce management and analytics. Built for people. Powered by smarter, more intuitive technology. It’s the new way to think about optimization.

We're growing fast and are constantly hiring more developers. Our product is a webapp built primarily on JavaScript and Java. The product can be used in the cloud, on-prem, or in some form of hybrid.

I'm a UI developer in the Minneapolis location working primarily with AngularJS and currently upgrading our UI build from a legacy build system to a more modern build system using NPM/Webpack, Jenkins pipelines, Docker, and Artifactory.

Find jobs and apply here: http://calabrio.com/careers/