Longwelwind

>The puzzle is to find the flaw in the very compelling line of reasoning above. This includes determining exactly why and under what conditions that step is not correct, in order to be sure not to make this mistake in a more complicated situation where the misstep may not be so obvious. In short, the problem is to solve the paradox. Thus, in particular, the puzzle is not solved by the very simple task of finding another way to calculate the probabilities that does not lead to a contradiction.

Can't you consider that knowledge is a function of previous data? In your example, the 2 individuals actually didn't receive the same amount of data because the English speakers received data previously that allowed him to build some kind of "knowledge" that allows him to solve specific related tasks (understanding a spoken sentence). This would be the equivalent of transfer learning where "knowledge" is a model trained on previous, more general, data.

I don't think that's the way Chesterton's fence is supposed to be used.

The kind of situations where it could be applied is when an individual wants to change a system, i.e., when an developer wants to rewrite a codebase that "is way too complex for what it is", when a employee see a process that doesn't seem to make any sense, when a reformist wants to change the rules of society, ...

It's basically an invitation to consider why the system was put this way, before envisioning how to change it. Instead of designing a new system based on the flaws of the current system, find out why it was designed this way, so you can design a system that solves both the flaws of the current system, and the flaws of the previous system, for which the current system was put in place.

NPM is not a trusted repository, I think. There are no checks done to the content of the packages uploaded by users. It's up to you to make sure that what you add to your project doesn't contain malware/vulnerabilities.

If you use a lockfile, downloading a package from NPM or directly using a random URL is conceptually the same, since they are both untrusted sources. Having a lockfile will ensure that if you download a dependency to review it for vulnerabilities, later re-downloads of the dependency will not have changed files.

> Where do you et these lockfiles files from?

At dev time, you generate a lock file of the hashes of your dependencies. You commit this file to your code repository.

When getting dependencies, the hash of the downloaded dependency is compared to the one in the lockfile.

I don't understand the point of your comment.

You're providing a solution that doesn't fit the initial requirement of a system being trust-less. So, indeed, your solution works, but as you described, it requires trust in the administrators of the website. The idea of web3 is that you wouldn't. "Trust but verify", if you want.

This could be used for Facebook or Reddit (given that they solve or attenuate the issue of fees), where people might have less trust in the administrators.

All those moderator actions you described would still be possible in web3. Moderators would still be able to up a topic, merge a topic, delete topics, ...

But:

  * The fact that the moderators have access to these mechanisms would be known by all users
  * The use of these mechanisms by moderators would be public. If a topic is upped by a moderator, it would be logged in the blockchain. No moderator would be able to do it secretly.

Regarding the fee, it's true that it's a big downside. To get a feasible use case, the devs would need to find a blockchain that reduces them.

If I understood Web3 correctly, it would be exactly like traditional web, except that:

  * The source code of all websites would be open-source, and accessible to anyone. It could still be changed, but it could not be done secretly.
  * All the actions of the users of the websites would be public.

If we take social forums, for example Hacker News, it would mean that:

  * The algorithm behind the front page of social forums would be known. Administrators would have no way of secretly skewing it.  
  * When a moderator would delete a message, they would merely mark them as deleted in the blockchain, and they would merely be hidden in the UI that you use to see the blockchain. The message would still be accessible on the blockchain.

The biggest downside, though, is that there would be a fee to any action done on the website (posting, moderation actions, changing your profile, ...).

I would wager that your self-hosted GitLab has less uptime than GitHub (or the quality of the deployment). We typically underestimate the downtime of the software we deploy ourselves, probably because we're attached to it, or because we're busy fixing it, instead of having to wait.

I'd take the occasional downtimes of cloud solutions, if it means not having to use some of the self-hosted software I had to to use at work.

> - In the middle I tried to implement a full scale map editor. I managed to build a simple yet working one, but dropped the project once I realized that it needs a lot of work to write my own GUI (back then I'm using C++ and SDL2).

Sharing my slightly unrelated experience, but Tiled2D is a nice piece of software to achieve this.

I've used it for one of my personal project, where I wanted to make a digital adaptation of a board game, and I needed to "digitalize" the game board[1]. I don't use the tiles or the tile grid at all, but just the "polygon" feature that allows me to draw the borders of the different regions. It's not at all why the software has been written, as the polygon is supposed to be a small feature to define areas in a tiled game, but it gets the job done.

[1] https://github.com/Longwelwind/swords-and-ravens/blob/master...

I'm not a solo-preneurs, but I have some open-source projects (mainly a live one, and one that I'm currently developping).

Here are the list of DevOpss flow I've done:

* One project is a website. I have a pipeline, triggered when something is merged to master, that builds Docker images, pushes them to a Dokku instance and deploy them.

* One project is a JS library. I have a pipeline, triggered when a git tag is created, that packages the library and uploads it to npm. I use Netlify to host the documentation website of it.

* For this same project, I'm planning to have a pipeline triggered for each PR to run the linter and tests.

I work as a DevOps/MLOps, and I'm quite comfortable with CI tools in general. I hate doing things manually and I love automating, so it comes quite naturally for me to do it. Once it's set up, it rarely needs to be changed.

Isn't an heuristic the exact definition of an intuition (i.e. a way to evaluate a complex situation using simpler rules that woks most of the times)?

I'm building a project where my service would plug with the (unstrusted) JS code of users.

I first thought it would be easy to sandbox and have something decent running, but after making some research on sandboxing, I realize how hard it is, and the many ways bad actors can exploit a service running untrusted code.

Kudos to GitHub and GitLab for taking the challenge of providing a RCE service with a free plan.

>If you believe REST is not a good idea then you never had to deal with versioning and struggling to keep clients and servers you don't own to play nice.

Sincere question: how does HATEOAS helps with this?

The only thing that HATEOAS helps with, is when the URL pointing to an entity changes, which is the most simplest change someone can make to its API.

But if an API ever changes the relationships between entities (new entities, 1-1 relationship changed to a 1-m relationship, ...) then HATEOAS won't help at all. You'll still need to change the logic of your client to take into account the modifications.

I've always felt like nobody bothered supporting HATEOAS because it's practically useless. The only use-case where it can be used is if you want your API to be crawled by a search engine. Then the search engine could crawl between entities thanks to the links you provide.

My comment was about whether it's worth supporting multiple values for the "Accept" header, not the "Content-Type" header.

What is the usefulness of this feature?

The only advantage I see is that your clients can choose the format they want to work with, but since the serialization format is just a message format that has no impact on the code, and that most of them have a bijective transformation between them, I don't see the point.

If it feels like a lot of work (Or the added complexity of a moving part, if using the tool you linked) for next to no impact.

I don't understand how the page contradicts itself?

538 has a rundown on why the Shy Trump Voters theory doesn't seem to exist in practice: https://fivethirtyeight.com/features/trump-supporters-arent-...

I spent the last 2 years making an online adaptation of a board game. I chose Typescript mainly because I was comfortable enough in this language and I don't regret this choice.

Typescript is, for me, the right balance between the strictness required to manage a mid-size codebase, and the looseness necessary to be productive (I definitely don't want to manage low-level things like memory when coding the gameplay of the board game).

On top of that, if your project is open-source, using JS/TS makes it more likely that someone can contribute to the project, compared to Rust, which has a higher learning curve.

Being able to easily share code between the client and the server is a big bonus too. The article points that with WebAssembly, it's possible to do it with any language, but I'm not sure it's stable enough to be used yet.

I'm thinking of making a library similar to boardgame.io (because I think there are some parts that could be done better), and I'll most probably keep Typescript for it.

Curious to see how using Rust for this will play out!

Fair enough!

I can understand the reasoning if you need to code a client in a different language, then you would effectively need to code the whole game once again. I feel like it would quickly bore me to code the rendering of each set of moves for each possible action. I feel like it's easier to have access to the complete state of the game client-side when you need to code a UI. There might be a solution if the server broadcasts the diff of the game state to the clients after each action has been performed (instead of letting the clients re-apply the action on their game state), but I'm not sure it would be nough.

How do you handle state synchronization, though? When a player makes an action, how do you propagate the changes to the game state?

I spent the last two years coding a reimplementation of A Game of Thrones: The Board Game[1], and I would use this paradigm if I had to recode it. Sharing the code between the client and the server brings a lot to the table.

Having to wait for the server for the set of legal moves feels like a hack. It's way simpler to have the client have its own copy of the game state, and allow "query" methods (methods that fetches data about the game state but don't modify it). This allows you to make _powerful_ UI, which can show any kind of information the user needs about the game like predictions about what would happen if a move is done, computing things so the user doesn't need to.

If I had to redo it, I would use a paradigm similar to how boardgame.io[2] works, which is similar to how fixed lockstep works. The server and the clients all keep a full state of the game and when a player makes an action, it is transmitted to all the actors, who apply this action to their own state of the game. Since the game rules are deterministic, the final state of the game will be the same for each actor. The only 2 complex to handle are randomness and secrets (the former can actually be solved by the later), but overally, the complexity is managed elegantly and you can separate networking code from gameplay code easily.

Actually, one of my future possible project would be to make a library similar to boardgame.io, but less opiniated, and in the future, offer a platform to easily host and launch a game coded with it.

[1] https://boardgame.io/

[2] https://swordsandravens.net/

I've been using a similar tool: https://simpleanalytics.com/.

I wish they'd offer more plans between the first 2 cheapest, though. My open-source project is hitting the basic plan limits and the next offer is too expensive for me.

This is good at first, but I deployed on a very small machine, that couldn't handle the live application + the Docker image being built, thus why I wanted to build the image in my CI pipelines.

I've been using Dokku for a side-project, and it's a really nice tool! My only gripe with it is that it's not easy to deploy an existing docker image. You have to pull it, then transmit it over ssh with "docker save" and "docker load".[1]

Migrating the docker image building from the dokku server to a CI would be easier to do without this. On top of that, deploying an existing software into your machine would be easier.

[1] http://dokku.viewdocs.io/dokku/deployment/methods/images/#de...

I feel like your post describes exactly what Kubernetes and container images would bring to your infra.

If you were to deploy a solution like you described, you would get something more complex than simply running Kubernetes, except worse. I suspect that you believe your solution would be simpler only because you are more comfortable with those technologies than with k8s. The more I read criticism of k8s, the more I'm persuaded that what people calls "old boring technologies" truly is "technologies I'm comfortable with".

On top of that, you'd need to separately document everything you do on your infra. The advantage of Docker images over AMI is that you have a file that describes how the image was built. With an AMI, you would need to hope that the guy who created the AMI documented it somewhere (or hope that he has not quit). Same goes for k8s, where configurations are committed into your repository.

At the end of the day, k8s stays a tool that you should use only when needed (and also if you have the capabilities of using it), but I think you shouldn't discard it simply because you are capable of producing the same result by other means. You get a lot more by using k8s, in my opinion.

Yes, it is!

I've been working on a free and open-source online implementation of the board game "A Game of Thrones (Second edition)": https://swordsandravens.net/

The game can be daunting and long (~4 hours), but the gameplay is very cool!

In OBS, a Scene is an arrangement of video inputs, images, texts written on the screen, ...

If you're a teacher and you're going through a PDF exercise opened on your screen while drawing things on a whiteboard behind you, you may want to have 2 scenes:

* One with the opened PDF in full screen, with your camera feed in the bottom-right of the video, in small.

* One with the camera feed in full screen, where viewers can clearly see what you're writing

You'd then be able to switch between those 2 scenes at will depending on what you're currently doing. You'd show the first scene when you're reading the exercise out loud and then switch to the second scene when you're resolving it on the whiteboard.

In the JS community, it means a library that can run client-side (in the browser) or server-side (in NodeJS).

I'm not sure this is the issue you are referencing, but you can use multi-stage Docker image builds to avoid bundling the JDK in the final Docker image:

  FROM openjdk:jdk AS build
  
  COPY . .
  RUN mvn package

  FROM openjdk:jre

  COPY --from=build ./somepath/app.jar .

  CMD java app.jar

The first stage (defined by the first FROM) is only used to build the ".jar", the second stage will only contain the JRE and the ".jar" copied from the first stage.