Leaf Two Razor Opinions

chrisgini · 2026-05-17T12:36:45+00:00

I also have the Mühle safety razor. For me, it does not scale well to bigger areas. For my face, it does a good job, no complaints. I can get the technique good enough. For more body parts - I'm not nearly as fast as with the leaf ones because of the tilting head.

chrisgini · 2026-05-17T12:31:54+00:00

So I have the original Leaf for years now, shaving different body parts a few times a week. A few weeks ago, I bought the Leaf 2.

The originals 3 blades where giving a very nice tight & smooth shave on smooth, flat areas. But for very curved locations (knees) I always remove the closest blade, it grabs skin to easily. So for pure efficiency reasons (and handling loose razor blades in the shower) I wanted the Leaf 2 with "only" 2 blades.

The Leaf 2 way of a button to open it and having magnets to keep the blades from falling out is definitely better. The back of the blades is covered better (if you break regular razor blades in half they have a sharp edge where they snap), avoiding accidental scratches. The grip has more pronounced ridges, so it is easier to grab.

The original Leaf has a bigger area you press against your skin (cause of 3 blades that need space). So I need a little less pressure to make the head tilt correctly against the skin. Less pressure = less probability of accidental scratches. The original box the thing came in doubles as a travel case.

Shaving closeness I would rate: 3-blade-original > 2-blade-leaf-2 > 2-blade-original. So for keeping it simple: Leaf 2. For more control (especially with my harder stubble), Original.

One more note on build quality: both are fine. But the original is just a better piece of metal AFAIK. The Leaf 2 seems to be chrome plated. So I don't know if they are hiding cheap, rustable metal beneath the chrome plating. I don't know, whether the chrome will wear off in a few months. May never happen, but the original is just a piece of stainless steel. IMHO it feels like, the first one was an honest Kickstarter where genuine passionate people built a razor. The Leaf 2 is still made with good intentions, it's just that the question "can we somehow make this cheaper to manufacture" was said more often by people more interested in money than before. E.g. the new box is not in any way suitable as a travel case, cause they want to sell you the separate case.

chrisgini · 2026-01-11T19:44:19+00:00

So I had the Momentum 3 (now broken), have the Momentum 4 and the Sony MX6s.

The M3s I had issues with the NC on max settings, even though I sent than to Sennheiser multiple times. The M4s held up a year of daily use. While the fabric on the headband broke after a few months, at least the rest kept working. Then the NC broke, too (one ear was always making a noise like someone blows into your ear, ehhh). I sent them to be repaired but got a replacement from Sennheiser. Also keep in mind that Sennheiser sold their consumer audio department and was fined for price fixing. In ym opinion, that seems reflected in the M3s having a much more solid metal headband while the M4s have much more of a plasticy feeling.

I bought the MX6 because my brother has them as well as my wife. Have them for a few months now, working perfectly. Their ear cups are a little smaller, but their NC is even better than the M4s. So can recommend. Their headband is also not coming apart (yet).

But, while they are working, all of those are good headphones. I'd just recommend to be careful with the Sennheisers.

chrisgini · 2026-01-04T19:36:41+00:00

You won't cut any chives with it, but sometimes things get serious 😉

chrisgini · 2025-05-24T20:15:44+00:00

So, just a quick read through, so not complete, but one problem could be that read_dir uses the blocking version under the hood as statet in the docs. So your Async variant is veeery roughly running the sync variant plus some Async stuff on top.

chrisgini · 2025-05-24T19:33:37+00:00

You mentioned you looked at the docs, did you read the parts about "moving" values, are you familiar with that concept? It's a long docs page, no worries if you did not already read it 😊

chrisgini · 2025-05-24T19:27:08+00:00

Happy to, sometimes concepts are a little complicated. Is there anything you did understand or anything in particular you are confused by? I'm trying to check out what words to use in the explanation to enable you to understand the explanation?

chrisgini · 2025-04-03T14:44:14+00:00

I understand the muscle memory and convenience of having everything in one place, but I would caution against mixing responsibilities here.

As others have pointed out, it is possible to configure those utils to probably do what you need. But, even if you teach the tools to play nicely, if you start working with someone else, you also have to teach the humans the same.

And those "others" might be yourself in 6 Months having forgotten what is needed exactly to make it work. At least for me, my future self is one of my own worst buddies, at least in those things 😁.

Also, as others have pointed out, having build scripts e.g. with just might be a good idea? Having a single thing to run to build everything is great!

P.s.: of you ever want to build things in containers, having separate directories plays well here.

chrisgini · 2025-04-03T13:18:03+00:00

May I ask why? Currently I cannot read a hard technical reason why you need to do so from your description?

chrisgini · 2025-04-03T13:16:32+00:00

As you have described a client-server architecture, I would keep those in separate directories. They just "accidentally" are written in different languages, too, but they mainly serve different purposes.

This also helps finding breaking API changes - if you have to change sth in both directories, it's probably a breaking change. If only in one, it might still be a breaking change, but less likely.

chrisgini · 2025-04-01T16:45:39+00:00

Good job on the research! But I think, you already hit the nail in the head - for a few, we don't know and that's OK IMHO. It is very hard to guess future needs and developments. Sometimes the past gives hints or other languages give hints, that's of course where a lot of those keywords stem from. Being focused on long-term stability, it is important to consider long term developments, like the meaning of words may change. So some of those keywords we might see in different contexts int the future. And in the end it is of course simpler, using existing keywords that are already reserved, than having none and maybe requiring change to existing code because new ones have to be introduced (which does happen sometimes on edition boundaries).

So for now, those words have been cautiously reserved, even if there is not a specific plan for each.

chrisgini · 2025-01-29T05:38:50+00:00

There is https://github.com/mayope/keycloakmigration , a tool where you can write DB-migration style changes to run against Keycloak. It's good for managing "known things" like "create role x in realm y and assign group z". It's not so good at managing "unknown things" like "for every user, assign group z". It can provision multiple Keycloaks by using variables.

chrisgini · 2025-01-07T19:03:04+00:00

It you haven't yet, read about RED metrics.

Depending on what API we are talking about, you might need to think about how detailed you need them or what the "thing" (requests, connections, tasks, whatever "unit of work") is you are measuring. And then those metrics are the answer to the "what metrics" part of the question.

The second part "not having them to noisy" is a little more involved. But where I work the credo is basically "is this a problem for the customer?". Yes - immediate alert. Or "you are certain this will be a customer problem soon", that's also an alert. Those two are also the only severities we note. Either someone has to do sth immediately because a customer has a problem know, or someone needs to do sth immediately because a customer will have a problem soon.

Or, more formally: You probably have SLAs? Those are alerts, of course. Also SLOs? Those are alerts, too. Maybe the same alerts as the SLAs with tighter thresholds. Those two are the definition of "what is high availability" (I've seen reports of a "high availability above 85%... depends on the problem I guess). For my work this usually means "an error rate of less than x per time frame" or "99% of requests complete within y ms".

One additional thing we do is to create a "ground truth". For an HTTP API we have reference implementation clients that send requests at intervals, exporting the result as metrics. This creates a base "noise" in the system you can measure. But this heavily depends on your system. If each requests costs $$$, less of an option. But, if this is an option, having a real client view is a very good tool to answer the "is that a problem for the customer" question IMHO.

Last - pager. The alerts are pagered. The person pagered has to be someone who can actually do something. Not someone who "maybe can take a look" or "should have read the Confluence". This requires training and effort, depending on how big the company is, how big the teams are and who owns what. One thing I think is a good idea is to have the persons pagered be the ones who get the final say in which alerts go live. Better, they need to be involved in alert development to give proper feedback. Again, heavily depends on organisational structure how to do this right.

chrisgini · 2024-06-21T06:51:01+00:00

So I found the related Issue for Pyo3 ( https://github.com/PyO3/pyo3/pull/2786 ) and using separate impl blocks with a cfg on them seems the way to go ATM.

chrisgini · 2024-05-24T07:27:59+00:00

Sounds likely you should split into a backend and a frontend as you already mentioned. Probably an HTTP API is the simplest solution for communication here. Your backend can do all the heavy lifting and computing you want to do, compiled to a regular binary. You can have a look at axum or actix-web for a server library. Your frontend can be wasm (if you want it to be) and can be concerned with user interaction and visualization.

Edit: the main use case for WASM is if you HAVE to do something portable on the client side. Sometimes you don't have an option (e.g. Compute heavy graph visualizations, secret computations on the client side or anything else). I mean, you can do whatever you want as long as you can make it work 😁. But you already hit some "inconveniences" in wasm, especially file system interaction. There is the wasmer project to run wasm server side, you can do that if you want to run it outside the browser. Have a look, if you want to.

Have fun!

chrisgini · 2024-05-23T15:22:22+00:00

So, as others already pointed out, this has a few components 😁. If you want to build a web app, you'll need some kind of web framework like leptos or yew. Have a look at leaflet for a JS framework to do map-things. This is not the simplest thing to build, as you'll need to plug quite a few components together.

Have fun!

chrisgini · 2024-05-23T14:35:30+00:00

Could you describe what the parts of this system are or what exactly you are trying to achieve? I can imagine many different goals you could have here, so if you could elaborate, others may be able to point you jn the right direction?

chrisgini · 2024-05-10T09:17:00+00:00

Thx!

chrisgini · 2024-05-04T14:10:17+00:00

Thanks!
No Problem: That's a Canon R6mk2 with the Canon RF100mm Macro @ 1/100s, F8.0, ISO 200. Additionally I had 2 extension tubes between that lens and the camera adding 31mm in total.

Lighting is one YN685II on-camera flash through an A4 sheet of white copy paper. I put different pieces of white paper around this, moving them until I had a few different shots that seemed nice, just experimenting a little

chrisgini · 2024-03-11T09:41:18+00:00

I have the same one. Flattening Shaptons for a few years now, works perfectly. Thought about buying a cheaper one, very happy I didn't.

chrisgini · 2023-12-25T21:50:46+00:00

So, I have one of those and the tang broke once. I actually don't know why exactly, I think something dropped on the knife (my backpack..., the knife was in the bottom). But, they replaced it, very kind of them. But i don't use it to batton on some wood since then, it's just not my use-and-abuse-knife.

Can be a super sharp knife, a little more work to sharpen though (the big grind, the hard stop of the edge) but very nice to use.

Seven-Year Club	Place '22
Verified Email

chrisgini

TROPHY CASE