Not really. If I'm using a linter, I go and configure the strictest possible ruleset, and only disable rules when justified on a need-by-need basis. It's just a matter of discipline.
427 karma · joined October 5, 2021
But yea, this will work as long as you have imagemagick and Nautilus installed.
Having used dwm-like tiling window managers for most of the time, I don't really care for the scrolling or dynamic workspace aspects of niri at all - in fact, I kinda dislike them (or haven't gotten used to them, at least). To me, it kills the point of a keyboard-centric desktop environment - which is the speed and lack of friction in making the window you want appear in front of your eyes.
Despite that, I still really like it. Mostly because I have so much more faith in its development. The documentation is excellent. The configuration file is sane, and not as arcane and ad hoc as the hyprland.conf format. The source repository looks well-maintained. Being written in Rust rather than C++ means onboarding new developers is easier. The discourse is more measured, owing to the lack of a somewhat stubborn lead maintainer in the case of Hyprland.
The surrounding ecosystem seems to be flourishing as well, with projects like Noctalia Shell, DankMaterialShell, and niri-flake natively supporting niri.
And perhaps most importantly, the out-of-the box experience is really nice. You have proper monocle and tabbed layouts without any compromises - features Hyprland has still not developed, where they are only possible with scuffed C++ plugins, or where its BDFL has stated they will never be introduced. Most features one would expect from a WM are already there and well-documented, which can't be said about Hyprland.
"GitHub actions bad" is a valid take - you should reduce your use to a minimum.
"My build failed because of GitHub actions couldn't install a dependency of my build" is a skill issue. Don't use GitHub actions to install a program your build depends on.
That may be true.
> [...] you can't say they violated the GPL.
That does not necessarily follow.
If they used GPL-licensed code in their product, they may be obligated to provide the source code to that product's consumer.
Anyone can fork it and quickly add the i18n (or just translate into a different language) for their own purposes. People will likely want to contribute i18n. People may fix or improve things for you.
Of course, it's entirely up to you - but I've appreciated half-complete software countless times before.
Embracing a functional style in TypeScript is probably the most productive I've felt in any mainstream programming language. It's a shame that the language was defiled with try/catch, classes and other unnecessary cruft so third party libraries are still an annoying boundary you have to worry about, but oh well.
The language is so well-suited for this that you can even model side effects as values, do away with try/catch, if/else and mutation a la Haskell, if you want[1].
When it comes to providing an enjoyable blog post reading experience, it really does creep into the "fuck off" territory for me, though.
- Image previews (for file management with dired/dirvish)
- PDF viewing
- In-buffer images (e.g. profile pictures in git log with Magit)
- Browsing simple HTML pages (e.g. API docs)
There's probably more I've yet to discover.
The angle I'd approach it from is this: recording whether an email is verified as a boolean is actually misguided - that is, the intent is wrong.
The actual things of interest are the email entity and the verification event. If you record both, 'is_verified' is trivial to derive.
However, consider if you now must implement the rule that "emails are verified only if a verification took place within the last 6 months." Recording verifications as events handles this trivially, whilst this doesn't work with booleans.
Some other examples - what is the rate of verifications per unit of time? How many verification emails do we have to send out?
Flipping a boolean when the first of these events occurs without storing the event itself works in special cases, but not in general. Storing a boolean is overly rigid, throws away the underlying information of interest, and overloads the model with unrelated fields (imagine storing say 7 or 8 different kinds of events linked to some model).
Because that's my workflow. I produce a few focused and semantically coherent commits that I'd like to apply to the codebase, where each keeps the codebase in a working state. I might be working on more than one thing at once, but I know which commit each set of changes should "live in."
An append-only log of commits is decidedly not something I want. Is jj amenable to this?
You can use Bun to compile to native binaries without jumping through hoops. It's not mature, but it works well enough that we use it at work.
btoa("Hello World")You can easily tell - easily. There is a reason why monitors go 500Hz and beyond now.
I consider 240 FPS at 240Hz to be choppy. I can tell the difference between ~200 FPS and framerates of 300 FPS and beyond at 240Hz - telling the difference between 120Hz and 240Hz would be absolutely trivial.
Also, it means each frame is more recent. Also, higher refesh rates reduce the mean variance between the timestamps of rendered frames offered by the GPU that are drawn on the monitor, meaning the visuals are smoother. The smoothness is pleasing to the eye and makes it easier to focus.
The principle is something I agree with and try to abide by, though.
Vi is incredibly well-suited and ergonomic for text editing, and switching between the modes is efficient, since often times you want to begin typing text as a consequence of some other normal mode operation you'd want to take anyway - e.g. add line below; change until end of line; change in parens; change up to character - and those operations put you immediately into insert mode afterwards anyway.
So I wouldn't let that feature (which enables making common operations more ergonomic) stop you from using vi-style binds.
Though modelessness can be quite nice, and I do see the appeal. Being able to select a region and immediately perform any desired operation is convenient.
What's great is that Emacs is what you make it - you can mix and match the two approaches. I, for example, use vi binds for text editing in Emacs, but maintain modeless binds I can always access when it makes sense. You can have the best of both worlds :)
Let f : (p: String) -> Boolean equal the function that returns True if p is a halting program, and False otherwise
> How do you automate running tests
You just build the Nix derivation that runs your tests, e.g. `nix build #tests` or `nix flake check` in your workflow file.
> deploying to dev on every push
You can set up a Nix `devShell` as a staging area for any operations you'd need to perform for a deployment. You can use the same devShell both locally and in CI. You'd have to inject any required secrets into the Action environment in your repository settings, still. It doesn't matter what your staging environment is comprised of, Nix can handle it.