GIMP 3.0 RC1 will come very soon (this month) & offers a lot of missing features users expect like adjustment layers (I’ve been waiting a decade for this).

Microsoft is the same as the corporate Google overlord. Both entirely evil to the core.

You either create new calendars or you share meetings ad-hoc thru ICS files manually. This probably depends on the type of work you do tho. This would not affect me since I don’t need folks randomly scheduling meetings with me for this to be a thing—instead the “Are you free X?” conversation is quick & painless.

Why assume everyone else has Google?

I mean most calendar apps like the default in LineageOS & ikhal aggregate calendars & have a simple selection + coloring for the two calendars. It isn’t rocket surgery.

You can break those up into private vs. public calendars

This is what CalDAV is for. We don’t need apps. We don’t need Calendly or Google Calendar or some BS.

Embrace your forefather ALGOL: 🤚‍ and, && 👉 ∧

This is so true & unfortunately everyone keeps telling beginners to start at Python

I mean we have a generation that thinks XML is bloated & JSON is superior but those two formats are about the same on performance & compressed size–which was the point. The non-plaintext-readable formats are superior along a lot of metrics but harder to debug & ultimately less common.

Balisage Paper: Fat Markup: Trimming the Fat Markup Myth one calorie at a time

https://www.balisage.net/Proceedings/vol10/html/Lee01/BalisageVol10-Lee01.html

XML is a fine format in comparison to JSON.

margin-inline-start: -1.25rem for the internationally-minded & accessibility-minded developer

Acronyms/intialism use capital letters to encode information about words. Losing that information is a mistake. SᴍᴀʟʟCᴀᴘCᴀsᴇ is now considered a best practice.

…Or I dunno try snake_case or kebab-case 🤷

It’s all proprietary drivel & should be avoided.

Proving that adding the class keyword to the ECMAScript spec was a mistake that leads folks down a path they should not travel 🙃

You can write a stateless server. You can’t do stateless front-end since you have to deal with user interaction.

Microsoft products you can start saying no to: Windows, WSL, GitHub, Sponsors, Copilot, VS Code, Codespaces, Azure, npm, Teams, Outlook, Office, & LinkedIn.

Could be their most used application too https://profanity-im.github.io/

With indentation-based languages the bad coding style we are talking about is putting multiple statements on a line or unindenting a block …& never has that been something I wanted to do. I would rather this aspect be enforced at the language for readability where there is still room in all other aspects to try out other styles.

Folks acting like Python is the only language without semicolons. 😏

I got tripped up so many time in the last 3 weeks using PHP after years in ML family languages. I am already newlining & it’d be poor style to put more than one statement on a line so what is the point of these semicolons?

I’m already annoyed by the end of public static final string that the variable name doesn’t even bother me in these sorts of langauages. All things should be public, static, & final, by default so they aren’t necessary to write. You should only have to write what unsafeties you are opting into.

https://githubcopilotlitigation.com/

Waiting for shell darcs, sharcs

If TypeScript didn’t have terrible type-level ergonomics, this wouldn’t look so bad—even if this toy example is largely just a brain exercise

In my opinion SPAs are simply a progressive enhancement for MPAs which allow even faster page navigation.

While I agree that there is a spectrum (hinting at that with the last paragraph), this is where I hard disagree. To construct something like this, you are making an application massively complex by trying to re-implement everything on both ends. Using something like Astro is only hiding that complexity but it’s still there, & probably full of bugs & tons of JavaScript that most developers wouldn’t even understand their stack or know how to jump into the Astro code. The amount of time saved is largely minuscule in most cases with the assets cached when navigating to a new page. In fact, I just tested two of their showcased sites which loaded slower with JavaScript enabled & the content was pretty obviously 95% static. There’s probably some niche use cases for this, but it’s not a good default IMO.

I admitted it was a spectrum, but this recent article in particular does a good job explaining the axes of static vs. dynamic : online vs. offline. I think you will appreciate it. :)

What some folks are missing is that SPAs are great for web applications & unsuitable for web pages. There is more nuance than “SPA bad”.

Then dealing with a lot of dynamic content, piping thru a virtual DOM DSL is 100× nicer for a developer than having to manually manipulate the DOM or hand write XML where it’s easy to forget all the closing tags (XML is better as a interchange format IMO & amazing when you need extensibility… also JSX just makes it worse). That developer experience (DX) often can lead to faster iteration & less bugs even with a cost to the user experience (UX). But it’s not always a negative impact to the UX–SPAs can be used to keep things like a video or music player on while still browser & using the URL bar as a state reference to easy send links to others or remember your own state.

It’s equally silly that a landing page whose primary purpose is to inform users of content takes 40s to load & shows “This applications requires JavaScript” to the TUI browser users & web crawlers/search indexers that don’t have the scale of Google to be executing JavaScript in headless browser just to see what a site has to say.

The trick is knowing how & when to draw these lines as there’s even a spectrum within the two extremes for progressive enhancement. React isn’t the solution to everything. Neither is static sites. Nor HTMX. Nor LiveView. Nor Next/Nuxt/Náxt/Nüxt/Nœxt/Nอxt.

There’s nothing to test when your data structure can’t represent an invalid state. So many tests are being basic stuff like checking nil & empty lists; basic ADTs can design you out of that whole host of invalid states. Further, if your language only allows side effects at the edges of the application & data types are immutable, you are way less likely to need all these mock utils or get unexpected changes to your data.

If you use your type system to make invalid states impossible to represent & your functions are pure, there less—maybe nothing—to test, which will save you from this scenario.