alertmanager-status VS linaria

I dunno, I don't really mind self-hosting monitoring infrastructure. I basically pay for a website uptime checker to check that Alertmanager is working. If Alertmanager is down, obviously you have to manually check to see what else is down, but it doesn't fail open.

I wrote a little glue to make this straightforward for anyone else who uses Prometheus/Alertmanager: https://github.com/jrockway/alertmanager-status This ensures that the website check checks the health of the whole alerting pipeline; Prometheus has an always firing alert, Alertmanager is set to send that alert to alertmanager-status, and alertmanager-status starts failing its external health check if it isn't seeing that alert firing at the configured interval. If one of [Prometheus, Alertmanager, alertmanager-status] fails, then your website health check fails.

It is quite awkward that the output of "working" and "completely broken" alerting systems have the same visible effect -- no alerts.

For Prometheus users, I wrote alertmanager-status to let a third-party "website up?" monitoring server check your alertmanager: https://github.com/jrockway/alertmanager-status

(I also wrote one of the main Google Fiber monitoring systems back when I was at Google. We spent quite a bit of time on monitoring monitoring, because whenever there was an actual incident people would ask us "is this real, or just the monitoring system being down?" Previous monitoring systems were flaky so people were kind of conditioned to ignore the improved system -- so we had to have a lot of dashboards to show them that there was really an ongoing issue.)

Many things!

jsso2: Identity provider and authenticating proxy for your non-enterprise use cases. WebAuthn only, no passwords! I was tired of typing a password for things like Grafana and PGAdmin, and IP whitelisting my home Internet for things that didn't have built-in authentication. https://github.com/jrockway/jsso2

If I were starting from 0 today, I'd just use Dex and Envoy's built-in OAuth support. OAuth is overly complicated, requiring a bunch of configuration for each app, and a ton of code in each app... but it won. So use that.

jlog: I read a lot of log files in my day-to-day work and really like the idea of structured logs, but found them hard to read. jlog translates timestamps to my local time zone, lets me query them with jq, etc.: https://github.com/jrockway/json-logs Can't live without it, I use it many times every day, and have even convinced other people to use it without writing any documentation. (There are binary releases and a --help though!)

"kubectl jq": I wanted to play with writing Kubernetes plugins, so I made one that is just "kubectl get x -o json | jq". I use it pretty regularly, but the Kubernetes client machinery doesn't give you autocompletion for free, so it's pretty painful to use. When they fix that, I plan to write more kubernetes extensions (including one that invokes jlog on the logs, saving a pipe ;) https://github.com/jrockway/kubectl-jq

alertmanager-status: How do you know if your Prometheus/Alertmanager is working? If it breaks, it won't be sending you an alert, after all. https://github.com/jrockway/alertmanager-status

ekglue: The good parts of Istio, written by someone who read the xDS spec :P https://github.comjrockway/ekglue

For my day job, I work on Pachyderm Hub, which you should totally use if you want to run production-quality data science workloads (data provenance, reproducibility, etc.): https://hub.pachyderm.com/ I could write a lot about it, but basically... we have customers that want to use Pachyderm, but the complexity of Kubernetes stands in their way. How do you store logs? How do you monitor things? How do you give your coworkers access? We solve those problems by letting you click a button in a web UI. (As for why you'd want to use Pachyderm: https://www.pachyderm.com/use-cases/)

The code duplication occurred due to disabling the default code splitting algorithm in Next.js. Previous developers used this approach to make Linaria work, which is designed to improve productivity. However, disabling code splitting led to a decrease in performance.

KumaUI : Another relatively new contender, Kuma uses zero runtime CSS-in-JS to create headless UI components which allows a lot of flexibility. It was heavily inspired by other zero runtime CSS-in-JS solutions such as PandaCSS, Vanilla Extract, and Linaria, as well as by Styled System, ChakraUI, and Native Base. ### Vue

I like Linaria [0] because your IDE typechecks your styles and gives you autocomplete/intellisense when typing styles. With Tailwind you have to look everything up in docs because it's all strings, not importable constants. Leads to a lot of bugs from typos that aren't a thing with type checked styles.

[0] https://github.com/callstack/linaria

And if you're wondering why I'm not using something like Linaria or some other runtime-less CSS-in-JS tool, it's simply because I don't want to have to spend my time setting things up and working around stuff and all that jazz. I just want something that works, and I've already got a personal scaffold for getting SC to work out of the box with Next, so, right now, it's either that or sticking to CSS/SCSS/SASS. For me, that is. I know it's such a small thing, but, honestly, one less headache for me is 2 steps forward.

I know that there are solutions that generate static css files (like vanilla-extract or linaria), but neither of them work with app router currently (1, 2).

If you really want tighter interaction with JS, try a zero-runtine solution like linaria

https://github.com/callstack/linaria is objectively the best. It's 100% styled component compatible, but with zero runtime which not only makes it substantially faster, but also makes it easy to do things like server side rendering, etc.

tags inside SFCs are typically injected as native </code> tags during development to support hot updates. <strong>For production they can be extracted and merged into a single CSS file.</strong></p> </blockquote> <p>There are also 3rd party CSS libs that do the same thing such as <a href="https://linaria.dev/">linaria</a>, <a href="https://vanilla-extract.style/">vanilla-extract</a>, and <a href="https://compiledcssinjs.com/">compiled CSS</a>. Which can be used in the event you're stuck with something that doesn't have baked in support via SFC formats (looking at you React).</p> <p>These are my preferred ways of handing it.</p> <ol> <li>Tailwind</li> </ol> <p>Option 2 is tailwind, which works backwards.</p> <p>That is, instead of the above with extraction where you write the styles, and the framework or libs extract them and replace them with class names, it's the other way around.</p> <p>You're writing class names first (which are essentially aggregated CSS property-values) which then generate and/or reference styles.</p> <p>It has the advantage of being easy to write (assuming you've got editor LSP, linting, etc), but as you've discovered, it's difficult to read / can get really messy really fast.</p> <p>As far as all the other claims on the Tailwind site, it's all marketing, at least 80% bullshit.</p> </div>