cuddlecake

> Modern aspect ratio API — no more padding hacks, well unless you need to support Safari 14, which you probably do, but still.

This is what makes me cry at night.

"C is still loved"

Citation needed.

The best way to drive a wedge between young and old developers is to negatively attribute something to a specific age group.

So keep going, you're on the right track.

The underlying concept would be akin to Business Process Modelling.

Using something like https://camunda.com [0], you can execute a business process model. Such a model can include sending emails, waiting for responses, human action, custom API requests, etc.

Camunda is not no-code, but it comes close to what you imagine. I suspect that when the existing API landscape of a company needs to be used for workflows, coding/integration is inevitable.

There's also (truly) no-code platforms like https://bryter.com

[0]: I only know of this because there's a department at my current job that specializes in implementing workflows using camunda. I got explanations for it during moderate drinking, so my recounting of it may be incorrect in parts.

Doesn't seem like a bug indicative of being beta.

The bug could obviously be fixed by looping back to 0, but the correctness is not the important part.

Though, reporting such an issue does not seem to be possible, hmm :(

Ah, thanks for the tip. It will probably not change much for the project I currently work on, with tests using react-testing-library, so JSDOM is required in nearly all test files.

But at least now I know :D

Heh, if push comes to shove, I reckon games will have to add support for `safe-area-inset-top`

webpack is usually fast enough, jest is where I need CPU & RAM.

If I were to write tests, that is.

I am mentoring Junior Developers, working students, trainees and interns who are at the very beginning of their career, they don't have _their_ setup yet. I watch them do something very tedious, and then I point out that there is a shortcut or IDE function for that. They have always been grateful, so far.

> And why does one even need to know vim at this point in time?

I was thinking about this a lot last night. I have learned drumming, bass guitar, guitar and I am learning piano now, so I may not be an authority on practicing, but I know that practice usually leads to a certain degree of improvement.

And very early in my career, I also practiced coding, more specifically I practiced using the IDE, and later I practiced using vim.

Both of these things give me confidence in the "writing and editing" aspects which let me focus on the other aspects of coding, like the abstract/ideas and the stack.

So I don't think it's important to know about vim, but it is important to at some point have deliberately practiced with the tools one uses daily for years to come.

Recording oneself is also a common strategy for improving musicianship.

When I was drumming, it sometimes helped me see exactly where my movements where improper, hesitant, or superfluous/exaggerated.

When I look over junior developers' shoulders while they code, i kind of do something similar, where I point out small improvements in their "movement from one state of code to another", like IDE functions for refactoring, keyboard shortcuts to delete a line or to go back to the previous editing position.

(I always wonder, when is the right time to introduce someone to vim?)

Funnily enough, I have done a session today where I live-coded using the utility types in an effort to explain most of the types listed on that page to a few of my colleagues.

I think, for one given moment in time, Event Sourcing is the hottest thing you can have. Evolution is where the trouble's brewing. You add a column to a table with maybe a default value, all is good. You add a property to an event's payload, you suddenly have to deal with versioning.

Event Sourcing with its current ecosystem and frameworks mainly add technical complexity with very little added clarity of business.

> We had whole versions where it was basically stuffed

A co-worker asked me "uh, why does the app use 120GB for indexeddb?"

Wildest bug I've ever had to deal with. Unfortunately it wasn't even just a safari issue.

> Like the rule that you have to set min-width to 0 or something to get the desired behavior.

Thank you, you're my savior. This is exactly the problem I had on Friday and now I can finally solve it.

  Location: Germany, Stuttgart
  Remote: Yes/preferred
  Willing to relocate: No
  Technologies: Angular, React, NodeJS, Elixir, Kotlin (Functional Programming preference)
  Résumé/CV: On Demand
  Email: idontlikeangulartoomuch at gmail.com

Hi, my name is Alex, and I'm looking for a new job opportunity starting September. Very much preferring to do Frontend work in React (although most of my experience is in Angular). Also very much a fan of Elixir.

Have experience working at a startup, developing a soft real time system for chatting and social media features.

You're trying to reframe my argument in a bad way.

I'm talking about people deciding to use a certain technology with tradeoffs.

You're talking about people going against quality standards of a development team. And that's where I end the conversation, you bore me.

Eh, I'd say it's a valid use case as any.

Maybe someone just didn't have the time confidence or interest to learn CSS. Maybe it's as simple as doing what you want, doing what you can afford to do, etc.

What I don't like is the negative framing of this choice. Bad things will be built, regardless of the underlying tools. Grandparent claimed that using Frameworks results in bad practices. I claim that shaming people and questioning their choices (whether they made them consciously or unconsciously) is a bad practice.

> their grabbing at lowdash debounce or react-virtual because they don't have the confidence to build a leaner version themselves

Yeah let's stop (re-)using open source software and write everything ourselves.

Who needs React when we can have cuddlecake's spontaenously written mini-framework (I lovingly call it anguvuesveact, because I got inspired) that definitely does not provide the required feature set or developer experience to support a productive professional development process, but it's mine.

Now that we have WebAssembly, couldn't we write applications in actual Assembly? It just takes confidence that we can build something lean with it, no other considerations necessary.

Well, uh, I just realized we don't need to rely on Firefox, if we just, uh, develop our own browser, uh, from first principles. A lean one, to be sure, only providing the features we need for our Web App. If we need new features we'll build them along the way.

Ah shit, my DIY lodash (I lovingly call it cuddledash, because I got inspired) has a bug but I'm focusing on the custom browser, so no time to fix that. :/

> React/Vue/Angular will not protect you from bloated, poorly written apps.

Only our self-written lodash lib will protect us, hear hear.

It's kind of gatekeepy insisting on styled components being of lower quality than using pure CSS. Styled Components serves a specialized purpose of styling things on the web.

Maybe less elegant or performant in some respect than pure CSS, but with trade offs that some development teams will happily take.

I also hate the sentiment, that software development needs to adhere to some notion of purity or divine elegance. And yes, I'm using the word divine because people like the grandparent comment keep acting like CSS is the church. It may well be, for some, but there's a reason why CSS is getting new features continuously... Because it's not perfect for every purpose across every development department.

Talking about this makes me sick.

The article "Immutability is not enough" is sub-par in every aspect.

The author never defines, what sort of problems immutable data can help avoid, or what the benefits of immutable data are. And still, after every paragraph, he wonders why functional programming didn't help him avoid bugs in his business logic.

Like, what the hell, the author produced a bug because the order of your operations was wrong? Great, write a test and restructure your code to make it work, at least you know where to look.

Functional Programming does not fix your Game Loop, and it never promised to.

Good thing I knew you're talking about TechLead, so I could avoid clicking the link and poisoning my YouTube recommendations pages

Parent is specifically talking about Django, and I'm not sure if there is anything comparable to Django in the Elixir ecosystem. So, if there is an absolute necessity for time-to-release at all costs, I reckon Django would probably have some advantage over Elixir.

But it's not the world coming to a halt: It's just the next engineer going "uh what the heck is this".

Not sure if I would consider Phoenix basic. As far as I know, it's a wrapper around (and configurator for) Cowboy and Plug. I would consider Cowboy basic and Phoenix advanced.

Una and her content are great.

Checked out the first two chapters on this resource and immediately recommended it to my colleagues as well.

I'm working with Angular on my dayjob, I wish they'd just deprecate the entire framework

Coincidentally, Angular is going to deprecate IE11 support with Angular 12, and remove it with Angular 13

https://blog.angular.io/angular-v12-is-now-available-32ed51f...

If you want type systems, you can probably work with Gleam, in the future, I imagine there could be great interop where you can just drop in a .gleam file in your elixir code base with zero hassle attached, and have parts of your code base that are completely type safe, and let Elixir handle all the risks of IO and other effects.

But, this might just be my wishful thinking.

Yes

> The slow tempo loses you mental oversight of what you are trying to play.

When I was a drummer, I used to think that too, but it turned out to be false most of the time. If I really wanted to make something sound good in a fast tempo, I had to make it sound perfect in a slower tempo.

My teacher used to say "if you can play it fast, make sure you can also play it slow"

But, as always, it depends.