[-] douglasg14b@programming.dev 6 points 6 days ago* (last edited 6 days ago)

They work great when you have many teams working alongside each other within the same product.

It helps immensely with having consistent quality, structure, shared code, review practices, CI/CD....etc

The downside is that you essentially need an entire platform engineering team just to set up and maintain the monorepo, tooling, custom scripts, custom workflows....etc that support all the additional needs a monorepo and it's users have. Something that would never be a problem on a single repository like the list of pull requests maybe something that needs custom processes and workflows for in a monorepo due to the volume of changes.

(Ofc small mono repos don't require you to have a full team doing maintenance and platform engineering. But often you'll still find yourself dedicating an entire FTE worth of time towards it)

It's similar to microservices in that monorepo is a solution to scaling an organizational problem, not a solution to scaling a technology problem. It will create new problems that you have to solve that you would not have had to solve before. And that solution requires additional work to be effective and ergonomic. If those ergonomic and consistency issues aren't being solved then it will just devolve over time into a mess.

[-] douglasg14b@programming.dev 13 points 1 week ago

Because your conservative funded news outlets have a very overt goal here.

[-] douglasg14b@programming.dev 40 points 1 week ago

The CEO is a right wing trump worshiper.

Dig into the company's tweet history, and find archived tweets that were deleted for PR/white-washing reasons.

Long history of this stuff.

[-] douglasg14b@programming.dev 52 points 2 weeks ago

This is what fundamental scientific illiteracy gets you.

When you have no reference point for how the world around you works anything makes sense.

[-] douglasg14b@programming.dev 20 points 2 weeks ago* (last edited 2 weeks ago)

There are markup languages for this purpose. And you store the rich text as normal text in that markup language. For the most part.

It's typically an XML or XML-like language, or bb-codes. MS Word for example uses XML to store the markup data for the rich text.

Simpler and more limited text needs tend to use markdown these days, like Lemmy, or most text fields on GitHub.

There's no need to include complex technology stacks into it!

Now the real hard part is the rendering engine for WYSIWYG. That's a nightmare.


I'm looking for some sort of chores calendar where we can set up scheduled chores each day and assign an owner to them.

If those chores are not done then they start to stack onto the next day.

My spouse and I need to hold each other accountable for the chores and tasks in which we are assigned. And I think a great way to represent that is showing how uncompleted chores stack up, they don't go away, the time it takes to complete them still exists as a form of debt to our free time.

Are there any open source projects that do this sort of thing or help with keeping up with the home, tasks, & household chores?

[-] douglasg14b@programming.dev 7 points 4 months ago

This is a weird take given that the majority of projects relevant to this article are massive projects with hundreds or thousands of developers working on them, over time periods that can measure in decades.

Pretending those don't exist and imagining fantasy scenarios where all large projects are made up of small modular pieces (while conveniently making no mention to all of the new problems this raises in practice).

Replace functions replace files and rewrite modules, that's expected and healthy for any project. This article is referring to the tendency for programmers to believe that an entire project should be scrapped and rewritten from scratch. Which seems to have nothing to do with your comment...?


GitHub: https://github.com/microsoft/garnet

Just saw this today and I am pretty stoked. It's just a drop in replacement and performs > 10x faster under workloads with many client connections. Not that I found redis slow, but in Enterprise workloads that's a lot of money saved. $50k Garnet clusters handling similar workloads for $5k would be significant.

It being essentially entirely written in C# makes it pretty easy to read, understand, contribe to, and extend. Custom functions in C# have a pretty low barrier to entry.

I get that there's probably going to be a lot of hate just because this is released by Microsoft developers.... But in my opinion the C# ecosystem is one of the best to build on.

[-] douglasg14b@programming.dev 14 points 8 months ago

I go full chaos and look up where I last used it when I need a snippet...

[-] douglasg14b@programming.dev 18 points 8 months ago* (last edited 8 months ago)

And what does it imply?

That an AI might be better at writing documentation than the average dev, who is largely inept at writing good documentation?

Understandably, as technical writing isn't exactly a focus point or career growing thing for most devs. If it was, we would be writing much better code as well.

I've seen my peers work, they could use something like this. I'd welcome it.

[-] douglasg14b@programming.dev 7 points 9 months ago* (last edited 9 months ago)

I do feel like C# saw C++ and said "let's do that" in a way.

One of the biggest selling points about the language is the long-term and cross repo/product/company..etc consistency. Largely the language will be very recognizable regardless of where it's written and by who it's written due to well established conventions.

More and more ways to do the same thing but in slightly different ways is nice for the sake of choices but it's also making the language less consistent and portable.

While at the same time important language features like discriminated unions are still missing. Things that other languages have started to build features for by default. C# is incredibly "clunky" in comparison to say Typescript solely from a type system perspective. The .Net ecosystem of course more than makes up for any of this difference, but it's definitely not as enjoyable to work with the language itself.

[-] douglasg14b@programming.dev 13 points 11 months ago* (last edited 11 months ago)

Yeah but the ecosystem drags it about as far down as you can go.

Backend development for large applications relies on stability, the JS ecosystem has anything except stability.This is okay for FE development where you naturally have a lot of churn.

It's a reasonable expectation that a backend built today should be maintenance free and stable over the next 5-10 years if no more features or bugfixes are required. And is buildable, as is, anywhere in that timeframe with minimal or zero additional work.

Additionally, strong backends in the same ecosystem are similar, they use similar technologies, similar configs, similar patterns, and similar conventions. This is not the case for JS/TS backends, there is incredible churn that hurts their long term stability and the low-maintenance requirements of strong enterprise, and even more importantly small businesses backends.

Mature ecosystems provide this by default this is why C#/Java is so popular for these long-standing, massive, enterprise systems. Because they are stable, they have well established conventions, and are consistent across codebases and enterprises.

This is a perspective most devs in the ecosystem lack, given that half of all developers have < 5 years of experience and the vast majority of that is weighted into the JS ecosystem. It takes working with systems written in python, TS, JS, C#, Java....etc to gain the critical insight necessary to evaluate what is actually important in backend development.

Edit: to be clear this isn't just shitting on JavaScript because that's what people do, I work with it everyday, TS is by far my favorite language. 2/3 of my career is with JS/TS. This is recognizing actual problems that are not singularly solvable with the ecosystem that pulls down its liability for backend development. There are languages and ecosystems are much better for your back end it's not that scary to learn a new language (many of my co-workers would disagree it's not scary 😒)

[-] douglasg14b@programming.dev 14 points 11 months ago

If you do this enough you know how to design your solutions to be relatively flexible. At least for your backends.

Your frontend will always churn, that's the nature of the job.


Found this in my feed, it's pretty neat, and at a surface level should make some of the pain points in my location based game much less difficult.

view more: next ›


joined 1 year ago