breytex

Same for me. Pixel 8, chrome

Shouldn't the end goal be just to train an ai on all the pdfs and give the doctors an interface to plug in all the details and get a treatment plan generated by that ai?

Working on the data structure feels like an intermediate solution on the way to that ai which is not really necessary. Or am I missing something?

How does this compare to pihole? Do I have to migrate to this?

Can you elaborate on where the author is wrong?

Go to pee even if you don't feel the urge to not feel it 20 min later when you are back in the road.

Heard it the first time when an American from California said it to their kids

1.5 extra hours would be my expectation as well. If we consider a long trip for vacation 3 times a year, the 4.5hrs invested into charging is offset by less day-to-day charging stops with an EV (if you can charge at home), the reduced costs of electricity vs gas and the reduced costs of maintenance.

I would optimize the car choice for the 90% use of daily commute instead of optimizing for the 3-times-a-year vacation trips.

You should checkout https://abetterrouteplanner.com/ for your next trip :)

Did the exact same trip with a Model 3 2021, 1200km ski trip from Germany to Austria. Came back yesterday. I experienced it way differently.

- We were able to make 300km with 90% to 10% battery (to not hurt the battery longevity too much)

- Outside temp was -4 to +2 °C

- Inside temp set to 20°C, seat heating 2/3 for two passengers

- So a we made a charging break every 300km, so approx every 2-3 hours

- Recharging those 80% at a supercharger takes about 30-50min depending on the Supercharger-version.

- We had 0 traffic/wait times at the super chargers (we drove both directions on a sunday)

- We would do a 10-15min break anyway every 2-3 hours to grab a coffee or do magic pee, so the extension of the charging breaks over our normal breaks aren't event that long

- All superchargers had a <5min detour from the Autobahn

Overall we spent approx. 2hrs more on breaks as we would have with a conventional car. I think thats a fair trade-off for 2-3 vacation trips a year, figuring in the time saved for normal refilling stops with a non-EV cars during commutes (when you are able to charge your EV at home).

To me, the future of "driving into holiday fully electric" is already possible with a Tesla LR model. With other EVs without Supercharger-Access/smaller battery/slower charging speeds probably not so much.

You can even save more time by using tools like ABRP[0]. This even gives you better charge-planning with shorter, time-optimized stops also figuring in detour times.

[0] https://abetterrouteplanner.com/

I like to start with code. If you use typeorm and type-graphql you can write a Type once and generate the database as well as the resolvers out of it. You can then even import the same type in frontend (as part of a mono repo). This stack does not need any generation routine for types. You just have to generate a migration if the postgres target schema changes, but that's normal and I don't see a way around this for the future.

I have to object.

I am from germany, and the avg. salary for a decent senior dev here would be between 60 and 80k€ depending on the town you are living in.

Babel is a very complicated piece of software. Even as a senior dev I wouln't feel comfortable to lead-maintain it. You wouldn't find more than a couple of ppl. in Germany who have the skillset and mental strength to maintain a project like that. And those few people would easily be making 150-250k€ as freelance consultants.

I think that 11k$ for maintaining one of the most important OSS projects in the webdev world is more than fair.

I'd expand on one of your best skills you already have. The "stack" gets more and more complicated so "full stack" will stop to be a thing in the future.

If you are already good in react, learn more libraries / frameworks in that ecosystem and increase your day rate. You are a frontend architect now.

I'd start with things like nextjs, Gatsby or Redux saga.

You could also go into the devops side of Frontend. Learn the different approaches of deploying / scaling a Frontend with server-side rendering (vercel, digital Ocean, docker...)

This.

This is indeed the best markdown wysiwyg experience I have ever had. Good job @the authors, and thanks for open sourcing!

Yes. The macbook 15" 2015 was just running at 55°C with zero fan noise when "just" browsing the web.

The 16" runs at 67°C with 2500rpm when doing the same task. So its neither quite nor cool doing basic tasks. You can turn of turbo boost to get around it, but I was expecting something in the same ballpark in terms of coolness and fan noise for basic tasks without tweaking stuff like this myself.

Google meet / hangouts did not work for me. Zoom did. My client back then did not use zoom, unfortunately.

Also touchpad drivers are all just plain garbage.

Tried to migrate from Mac to Linux half a year ago (before the 16" with the new keyboard was announced, because I hated the butterfly keyboard).

Tried a bunch of dell and Thinkpad devices. Configured a t480s with ubuntu. First meeting where I had to share my screen and I recognized that Chrome is not able to share a dedicated screen of my three monitor setup. You need a script for that, which creates a "fake" webcam, otherwise its only possible to share the three stitched-together screens.

Those are things, I just expect to work out of the box without a script or pulling two monitor cables everytime I want to screen share something.

Bought the 16" Mac a week later, also not happy with that because thermals are just bad, but its better than having to script simple things. Clients don't expect you to "have to script something real quick" during meetings.

As long as Linux does not cover ALL trivial multi media usecases, I don't see myself making the switch.

Author here. We have created this platform in 4 days during our Easter bank holidays. The main stack is React, NextJS, Hasura, Vercel now, Cloudflare Workers and Digital Ocean. We are positive that we can scale to 100.000 concurrent users with this setup on infrastructure for $40/month.

We are a non-profit and our main goal is to make pricing of masks and other protective gear more transparent.

Looking forward to reading your feedback :)

Waiting for BaaS solutions to become mature for a long time now.

Big fan of the direction Hasura is taking. Maybe this could also cover some of the BaaS aspects? E.g. enabling frontend devs to deliver fully-fledged products without much knowledge about backend and databases?

One thing which disturbs me: I have to fill out an entire typeform just to get told that there is no free-tier and I have to pay 30$/month before even testing if this thing covers my most trivial needs. I think that's a dark pattern, I am out, sorry.

You got that wrong. Modern JavaScript / SPAs make it possible to implement something like Outlook right within your browser. No (big) download, no clicking through an installation wizard, no fragmentation of versions for a tool, which forces you to be online anyway.

I don't get all the hate towards SPAs and JavaScript Frameworks here on HN. Everyone is basically complaining about complexity for applications, which are more than just a server-rendered form or message board (which is a way less complex applications compared to outlook or slack, where "realtime notification" is a requirement).

Application programming became easier by a lot, just the application requirements grew at the same speed, resulting in that feeling of stagnation.

With something like zustand[1] or the react context api, its just ~10 lines of code to store the dark-mode boolean somewhere central in the app and connect it to all the components without prop drilling.

[1] https://github.com/react-spring/zustand

https://github.com/react-spring/zustand

I felt exactly the same for many years, but when hooks where introduced, I discovered react-hook-form[1].

It just blew my mind how you can write complex forms with validations in just a few lines of code.

Give it a try.

[1] https://github.com/react-hook-form/react-hook-form

Love it. Thanks for sharing.

But I found one issue which might be a critical one:

When you start broot with "br --sizes", it shows you all the folder sizes. The tree than takes a while to render all the different files and folders, since they probably have to be recursively evaluated in size.

However, when you select a specific file, press space and then `rm` to delete it, the pointer might change to another file randomly. This is because the file list is still not rendered-out because of the file sizes beeing calculated, however, the pointer to the selected file should be persistant or you might accidentaly delete an important file.

Very cool project. I like that you have matched the mac os design. Working on a note app and aiming for a similar UX.

Anyone having an idea how to come close to MassCode's UI with a React.js UI library? Is there anything out there, which is similar?

Does anyone knows a react ui framework which also includes concepts for more high-level interfaces? Not only atoms and molecules, but also "organisms" and "pages" as a compound of several components?

I feel like, a lot of ppl still create horrible UIs based on good components, because they lack the bright overview.