Decentralized Architecture: https://positive-intentions.com/blog/decentralised-architecture

While my approach here could be considered overly complicated (because, well, it is), I'm trying something new, and it's entirely possible this strategy won't be viable long-term. My philosophy is "there's only one way to find out." I'm not necessarily recommending this approach, just sharing my journey and what I'm doing.

Potential Benefits

I've identified some interesting benefits to this approach:

• Statics as Chat App Infrastructure: https://positive-intentions.com/blog/statics-as-a-chat-app-infrastructure

While I often see module federation and microfrontends discouraged in online discussions, I believe they're a good fit for my specific approach. I'm optimistic about the benefits and wanted to share the details.

When serving the federated modules, I can also host the Storybook statics. I think this could be an excellent way to document the modules in isolation.

Modules and Applications

Here are some examples of the modules and how they're being used:

• Cryptography Modules: https://cryptography.positive-intentions.com/?path=%2Fdocs%2Fcryptography-introduction--docs
• P2P Framework: https://p2p.positive-intentions.com/?path=%2Fdocs%2Fe2e-tests-connectionstatus--docs

This setup allows me to create microfrontends that consume these modules, enabling me to share functionality between different applications. The following applications, which have distinct codebases (and a distinction between open and closed source), would be able to leverage this:

• P2P Chat: https://chat.positive-intentions.com/
• P2P File Transfer: https://file.positive-intentions.com/

Sharing these dependencies should make it easier to roll out updates to core mechanics across these diverse applications.

Furthermore, this functionality also works when I create an Android build with Tauri. This could streamline the process of creating new applications that utilize these established modules.

Considerations and Future

I'm sure there will be some distinct testing and maintenance overhead with this architecture. However, depending on how it's implemented, I believe it could work and make it easier to improve upon the current functionality.

It's important to note that everything about this project is far from finished. Some might view this as an overly complicated way to achieve what npm already does. However, I think this approach offers greater flexibility by allowing for the separation of open and closed-source code for the web. Of course, being JavaScript, the "source code" will always be accessible, especially in the age of AI where reverse-engineering is more possible than ever before.

So i want to achieve many types of hobbies. For the longest time ive wanted to make games but im honestly unsure where to start, what tools to pick up, and what to learn especially sense i want to attempt to learn for free without having to pay for anything.

Ive been told gamedev is like learning a new language in a way. I could use a point in a starting direction if possible.

I also have a dumb question but i cant really make out a different between the definitions of coding and programming, what is the difference if any?

“Compile-time hierarchy of encapsulation that matches the domain model was a mistake.”

https://en.wikipedia.org/wiki/Casey_Muratori

Coders spent more time prompting and reviewing AI generations than they saved on coding. On the surface, METR's results seem to contradict other benchmarks and experiments that demonstrate increases in coding efficiency when AI tools are used. But those often also measure productivity in terms of total lines of code or the number of discrete tasks/code commits/pull requests completed, all of which can be poor proxies for actual coding efficiency. These factors lead the researchers to conclude that current AI coding tools may be particularly ill-suited to "settings with very high quality standards, or with many implicit requirements (e.g., relating to documentation, testing coverage, or linting/formatting) that take humans substantial time to learn." While those factors may not apply in "many realistic, economically relevant settings" involving simpler code bases, they could limit the impact of AI tools in this study and similar real-world situations.

Found this article via a comment on Lobsters for a completely different article. It's not exactly the type of knowledge I see myself using in the immediate future, but I think it's still interesting and educational to think about.

What I often have to do is to copy something from my editor to the browser and vice versa. But this seems not so easy in some editors. I feel I have to add that I'm on wayland under hyprland.

In some Editors it's super easy like GNOME Text Editor or nano, you mark some code in the text editor with the mouse and then in the browser you press the middle click on the mouse where you want to paste it, done. You could do it with ctrl-c and ctrl-v but with the mouse only it's just so much faster. And it works both ways browser <--> editor

But in VSCodium I can do that from editor -> browser, but I can't do it from browser -> editor, I have no idea why.

In neovim it's the opposite I can do it from browser -> editor, but I can't do it from editor -> browser.

Any ideas what is going on?

I just read "Google Continues Working On "Magma" For Mesa Cross-Platform System Call Interface" on Phoronix and didn't get it. That made me realise my knowledge and understanding of these things is barely existent. I did write an MS paint clone on linux in C++ a really long time ago and the entire thing was with opengl (it looked like crap), but since then... nothing.

So my understanding is that the graphics card (or CPU if there's no graphics card), writes to a component which is connected to a screen and every cycle (every 1/60 seconds if 60Hz) the contents are sent or read by the screen. OpenGL provided a common interface to do so, but has been outdated since... a while and replaced by Vulkan. Then there are libraries either built on top of are parallel to OpenGL. Vulkan can be parallel or use OpenGL if that's the only one supported IIRC.
However, I'm not sure if OpenGL is implemented at the hardware level (on the graphics card), software level, or both.

Furthermore, I don't understand where Magma, Meta, and MESA come in.

Maybe my core understanding is wrong or just outdated. I can't tell. Can anybody eplain?

Anti Commercial-AI license

cross-posted from: https://lemmy.ml/post/33319577

1. Running Good 1:1 Meetings

"I don't know how to start", "This solution won't work" and "I'm going to do X" are all bad examples of how to talk to your manager (or anyone). When you're talking with other people, you are having the privilege of leveraging their experience to solve your issues.

Problem --> Solution --> "What do you think?"

First, clarify the problem. If you tell (i.e. your manager, but it can be anyone) a solution, they won't know if it's the best way to solve the problem.

Second, tell your manager what your current plan is. Having an existing plan makes the next step much easier for your manager, and makes you look somewhat competent.

Third, ask your manager what they think. Maybe they'll tell you, "Yep, makes sense". Maybe they'll tell you to tweak it. Maybe they'll give you a completely different direction. Maybe they'll ask you why you're even solving that problem, and to go do something else.

I used to hate 1:1s. I had no idea what to talk about. Now, I gather a few of these questions throughout the week, and add it to an agenda. My manager regularly thanks me for having a productive session.

2. Make a Good Plan (& Real Prioritization)

What is the problem you're solving? Why is this an important problem? How do you know when you will have solved it? How are you solving this?

Start every project with a doc explaining these 4 things in under 2-3 sentences. Until you communicate this, you do not have a plan, and you do not have a project.

It's an uphill battle if you cannot do this. I run the System Design Club at Meta. My skip told me it counts as E4 (not Senior level) at best - because it's not solving a real problem.

3. Review Work Better

Everything we talked about above is applicable to how you review other people's work too.

First understand the problem, then understand the solution. Ask questions that make it clear the solution addresses the problem.

When reviewing plans, ask how you know they will be done ("How do you know when you will have succeeded?"). Be sure it's clear how it will be done (no "draw the rest of the f**king owl" memes) - Ensure all the steps, if followed, will resolve the problem. Ask for timelines so you can hold them accountable.

When reviewing code, your goal is to make sure the new code solves the problem, and doesn't add new ones. Don't nit about style, instead call out a problem that arises from their style ("If someone changes ABC, they won't know this breaks"). Don't assume a bunch of logic you don't understand works; ask "How do you know this is going to work?".

4. Being supportive in your messaging goes a long way.

Any time someone asks a question, I preface by saying "Good question - [...]" (ofc I change up the style). This keeps them asking more questions. Whenever giving critical feedback, I start by calling out the good work that was accomplished. This keeps the other person motivated.

I first learned this trick when developing in open source, but saw it pay dividends at Meta. I had one contributor who was writing 90% of the project code - I would continuously praise their PRs and talk about how great they were. When I stopped doing that for about a month, that contributor noticeably dropped off. For some people it's support, and for others it's ego. But it keeps them working hard.

5. The Reality of Looking Good - and Failure

If you are doing well, people will want you on their projects. If you're stuck or confused, they will assume you tried your best, and it's the problem that is hard.

A good engineer might fail a project from time to time, but they have clear and notable success stories too. If you have only failed projects, you are a bad engineer.

Not only do people enjoy helping good engineers - Bad engineers get the plug pulled.

Despite a supportive culture, I have been explicitly told to stop helping person X, because person X is not worth helping. Person X is later removed from the company.

The advice here is to start strong. If you start strong, you will get the support you need to thrive. If you are currently weak, you need to do everything in your power to get strong - Things will naturally feel easier when things are going well, since other people will be helping you.

This post is dense information. Do not expect to walk away remembering all of it. But pick one that applies to your weakness the most - Think deeply about how it can be applied. Then get better.

Hi! I've created this page to showcase the features of Mint (since there are so many) and their corresponding versions in other similar languages.

cross-posted from: https://sh.itjust.works/post/42201485

What's your guys general thought on how everything is web based now? For me, I don't really like it. I would just rather have an actual program that runs. But I am merely a user, not a programmer.

I tried it after using Emacs Magit for about six or seven years, and jujutsu is really easier to use than git and useful if one wants a tidy public history of changes (Linus Torvalds recommendations on that linked here). Plus it is fully compatible to git as backend - other contributors will not even note you are using it.

I am searching for an SQL lite alternative that implements encryption more or less or of the box and has rust bindings. Do you know of any database systems that fulfill that requirement?