Ankhers

I think it depends on what you mean by "cheap foreign engineers." I am born and raised Canadian. I make a decent chunk less than my American counterparts, even when working for the same company. Not because they are necessarily better suited for the job, but literally because of the country I live in. The same is true for engineers all over the world.

So yes, companies absolutely can get cheap(er) labour and have the same, or at least similar, quality.

Are there extensions planned for other browsers? It seems right now when you click on "get jam" button, it takes me to the chrome web store.

That is just saying that they will be giving some donations to the project. I have zero insight into W4 or the Godot Foundation, but they may have already donated. They don't claim to be the sole financial contributor to the project.

This statement is not about people, it is about a C struct.

Not necessarily. A lot of people other than engineers work in AWS, ad tech and twitch.

It really isn't this simple, no. I remember a number of years ago someone tried to do this. Pardon the language, but the "product" was called "Fuck adblock" I believe. It was a piece of JS that you could include on your site that, if I remember correctly, tried to see if certain JS objects existed. If they did exist, you could disable aspects (or the whole thing) of your site. Very soon after, someone released "Fuck fuck adblock" that essentially disabled this piece of JS.

It was a cat and mouse game for a while, but ultimately, if you want to detect if someone is using adblock, you need to do it in JS. And then the ad blockers will just add that piece of JS to their block lists.

You may very well be living in your own circle. My anecdata is that most engineers use VSCode these days. In my current organisation I am the only person that uses Emacs that I am aware of (and I use evil-mode). I know a handful of people use (n)vim. But by far the most common editor I see being used is VSCode.

Not the person you replied to, but I have had some issues with this in the past. Though it is more with how it was done than the approach itself.

In this project I do not believe the IDs were always encrypted when being sent to the user. So we sometimes had to guess whether we received an encrypted ID vs a regular integer ID because it is possible for the encryption algo that was used to return a sequence of numbers.

If this is just for being able to easily switch branches, have you considered using git worktrees? Essentially you have have multiple branches checked out into different directories at the same time. The key point though is that all git refs are still maintained in a single place so you are not actually having full clones for each worktree that you have.

I personally use Emacs and magit which has great support for worktrees. I do not know if the VSCode git integration supports it.

I will agree that not every situation will require multiple kinds of updates. For those situations an `update_changeset` may be considered okay. I now realize how definite my wording sounds. But I just meant that if you have multiple update operations, that should be exposed as multiple changeset functions. If you have multiple update operations but a single update_changeset function, it is possible to send the server data you did not intend to be sent together and now you are changing things that were not originally meant to be changed together. This has happened in previous projects I have worked on and now prefer the be explicit with multiple changeset functions.

I'm not really following this. The only problem the author has is with the name `create_changeset`. It may not be obvious to someone just starting with Elixir and Ecto what that means, but it is a naming convention that most (all?) projects use. You should be able to get the hang of it fairly quickly.

This may just be the simplicity of the example they have, but they also have an `update_changeset`, which I think is an anti-pattern. You should be creating a different changeset for each operation that can be applied to a given schema. In the case of a user, you may be able to change a password, or an email address separately from being able to change a screen name or something. You should be creating separate changeset functions for each of those operations.

The author also puts a foot note at the end stating that they would usually create a `base_changeset` function that can be reused for common parts of a changeset. Please don't do this. Just create multiple reusable functions for each check. For example, you may create private functions in the schema for `validate_email`, `validate_password`, etc. These are the reusable pieces that you most likely want to have and can be used from within any changeset. Then you will be able to mix and match them as needed instead of trying to come up with a truly base changeset that applies to everything and still have a lot of validation rules duplicated between various changesets.

Just my experience when I was trying out OCaml (I was mostly trying it out for frontend using the bucklescript-tea package) was that most people in that space used the ReasonML syntax. I don't remember my exact issues, but I was trying to avoid using the reason syntax because I preferred OCaml's. There were a couple of hurdles I needed to get over before being able to even really begin. This was probably 3-4 years ago, so things may have changed.