baptistejamin

We used Lexical intensively in my company (Crisp), and I can confirm it's definitely not in maintenance mode. What's super cool with Lexical is the package/extension system. For instance, we use the Lexical markdown package a lot; it's not the gold standard yet, but since we have a large user base, over the years we've made a few PRs to the Lexical team, and they approved/reviewed the PRs in 24 hours.

About WordGuard:

There is no community behind it; the guy building it clearly wants no AI involved and even has his own internal Git hosting system.

Finally, there is no single user on WordGuard.

I see virtually no reason to use Wordgard over lexical.

I think MySQL was not the correct tool after all. Click house is a lot more optimized

The best support on earth is when customers don't even need support, and it's the main reason why LLMs won't solve this problem :)

We are really recommending https://www.clever-cloud.com/ . Their stack is awesome, great uptime and great support.

I don’t really understand why this information is now #1 on HackerNews.

Boeing 777 engines are the world’s largest turbofans and pw4000 Engine, involved in this explosion is in production since the 80/90, and is already used on other Airframes like a330.

I know this accident looks impressive, but engine explosions like this one are things that happens years over years.

On Airbus a380, similar explosions occurred.

This kind of explosions looks very impressive, but those are things that happens quite a lot in aviation Industry.

It's why there is a second board to handle critical tasks: https://news.ycombinator.com/item?id=25671318

It's why there is a second board to handle critical tasks: https://news.ycombinator.com/item?id=25671318

Hello! I work on this project.

Don't worry, the breathing system does not rely on the Rasberry at all.

We use an electronic board that was made on purpose by a Medical company and relies on STM32 hardware.

This board sends telemetry to the Rasberry PI and we have a Rust based interface that shows charts and some controls.

If the Raspberry fails, the Firmware still run fine, and you can still change the settings on the machine using physical buttons and a LCD screen that is directly connected to the firmware

You can also find the project on GitHub: https://github.com/makers-for-life/makair

Our initial design was mostly based on 3D printed SLS bio-compatible parts.

The current design is still 3D-printable, but we had to go with metal valves for instance for long term usage, and mass-proction. 3D printed parts just don't scale.

When possible, we replaced some 3D parts with on-the-shelf parts, for instance for the medical 22mm tubing connectors.

1. What we did is we worked on certification and on the eneenering at the same time. We figured out that it was easier to certify an hospital ventilator rather than an emegerncy transport ventilator. An emergency ventilator needs to support 15G (so around 330KG in our case) accelerations. Quite a lot :) So, we choose to the "hospital ventilator" regulations then.

We unit tested everything using a lung simulator (ASL 5000) and that was a great help. When you can try your ventilator in almost real condition, that is change changer.

Then, we tried to make our ventilator exactly as an MVP. We implemented very few features at the beggining. Something very minimalistic. Only pressure control. It was our first version, and was certified for clinical trials in June. First patients in July then.

It's only later than we added new features, LCD Screen, new sensors, new metal valves, to make the ventilator better. We filed all the paper work again, and it got approved in september.

2. We used Slack. It works great, but at some point, we had to work all together. 30 people were lockdown together and worked in March/April on this project. It was a non-stop start-weekend and we slept only 5 hours per night, during more 30 days.

At the beggining of the project, we struggle on two essencial parts : Making the turbine, and the pressure valves.

Multiple engeenering teams work at them same time on different solutions. We used up to 30 3-D printers, lent from people/company.

At the core, we did all the integration tests, and tested all the solutions from the mechanical teams (different turbines / valves), as well as the software, electronics.

At the end, we had the right turbine, the right valves, the right electronics, and we just had to make integrate everything on the software.

3. The hardest thing was the software. Most of us are software developpers and we are used to deploy continuously. You can't do that here. You need the perfect software, immediately.

You can't do an OTA update on all the ventilators.

During the certifiation process, we had to change the software to do many improvements. I think regulatoriy authorities don't understand how software works. That was the hardest part: Explaining them that a software they don't understand is actually safe.

It is something that needs to change, because in the future, we will have more and more sotware in medical devices.

Hello.

I am one of the members of this project.

Your comment is totally accurate and a bad ventilator design or manufacturing can be fatal.

The Norwegian ventilator design was a dead end since the beginning.

Many different makers teams tried to create ventilators around the world by doing mechanization of "Ambubags" (https://en.wikipedia.org/wiki/Bag_valve_mask).

Those makers chose this solution because it was the easiest way to do a ventilator if a few weeks.

This idea is bad because it creates many different problems: - After 30 minutes, patients will start having high C02 levels - It spreads the virus in the hospital room - It can clog

At the beginning of the pandemic, we choose a completely different design and started something from scratch.

Our goal was to make a very safe ventilator, so we could be confident our ourselves, our parents, our family would have to use it.

We asked doctors, specialists, we quickly figured out that the best design was using a turbine design as most emergency ventilators come with turbines.

The big challenge was to finely the pressure very accurately: so we needed valves to manage the airflow.

All the Airflow systems needed to be biocompatible and no pressure valves existed on the market for that purpose.

We tried many ways doing that and engineers in the team found that the best way to make those valves was doing a "Pinch Valve"

The idea is you have a medical-grade flexible pipe, which is pinched using an excentric valve. This way you can finely tune the pressure.

Researchers and doctors tested early prototypes and they found the design was smart and very promising.

It was tested on very complicated lung simulators, and then two pigs.

Following those studies, french authorities started to look at our project and gave us funding (around 500k euros). Allowing us to have access to 2 ASL 5000, the rolls of lung simulators to try our prototypes.

Many different local companies (engineering, manufacturing) help us as well.

A complete team (5 people) made internally all the paperwork for French Health Authorities so they can approve clinical trials.

After a few months, the Makair was approved for Clinical trials and 2 hospitals started to try it on patients.

Meanwhile, we are working on CE marking and production lines. Multiple countries are interested.

If we had to start again, we would choose the same design.

It is something we already tried, but it is not improving anything.

We are enforcing websocket since 4 years now and not using long polling since. It works really great as it is widely supported.

We removed polling from SocketIO because it was just useless since 4 years.

It is a bug with the default Ghost template that we are using. We are currently fixing this issue.

It is a bug with the default Ghost template that we are using. We are currently fixing this issue.

Hello Sean!

You are totally right, in many cases splitting the chat in many sub-parts can improve loading time.

It is something we tried during our optimization batch.

We figured that it wasn’t improving so much the loading time in our case. Saving around 10KB.

In fact our JS size is 80KB and CSS 30KB. The rest are fonts.

We offer an option for our customers to delay the chat. It’s a built-in feature. Not enabled by default.

About landing pages, you are totally right. SVGs make a real difference.

Thank you!

The example about active users was more about KPIs, and not connected users. You can't perform a map/reduce operation.

We used Firebase ACL to prevent from that.

Our backend were already splited.

I worked with several Firebase apps, worked with Firebase protocol to make my own server. It's why we started with Firebase.

I really understand how to use it, how it's works (including server side, internal protocol).

Many people here talk about our example about relationships and we wanted to explain it to beginners, with a simple relation.

In our case, we had many relations, many data.

Thanks. We updated the blog post.

Yes. I checked yesterday before releasing the article. It's still not possible.

We plan a plugin system. The core is all free, and to get special features we have a marketplace. Crisp + Slack, Crisp + Zendesk, etc.