72 karma · joined March 27, 2012
How to call it then : Yanked hard vs yanked soft ?
You see false low glucose figures, that last, you start reducing your slow acting insulin, you skip some fast acting insulin. Within 24h, ketoacidosis starts and you can start feeling nauseous. At some point, if you eat, you vomit. You are cornered: you don't have the carb intake to inject insulin, and you can't eat. Even worse, at some point, if you drink, you vomit, so you dehydrate, and it's a matter of hours to live. Shit happens fast, things can get critical is a few days.
Diabetes management is complicated, this is far from exact science, and having a good knowledge of everything is hard. I was already bitten by this cycle of nauseous feeling with slow acting skipped a few month after my diagnosis. I learnt to never ever skip slow acting insulin, even when blood sugar is through the floor. Prepare some apple juice and still go on.
I have Freestyle Libre 2, and it is quite a disappointing thing software-wise. I have to reverse engineer another app to get an API for my data, I have to go through Internet to get my blood sugar level (for a standalone display for example, so I can't make one that works "off grid", like... in my plane), they do sparse updates, they lag behind OS version by dizains of month for their apps, they have 10s of apps/websites, it is hard to understand. So I'm not surprised by poor bug management.
I wish some big names invest in a CGM device. Don't make it medical (even medical grade ones like Abbott & co say you have to check with a finger thingy device, so why bother), make it $500 one time plus $10-20/month, make it open about the data and you'll get everyone. Maybe no one want to invest because in 10/20 years Diabetes will be a thing of the past?
The move is so we can avoid allocating a string each we declare and use it since it will be frozen by default. It is a big optimization for GC mainly. Before we had to do such optimization by hand if we intend not to modify it:
# before
def my_method
do_stuff_with("My String") # 1 allocation at each call
end
# before, optim
MY_STRING = "My String".freeze # this does 2 allocations with 1 at init being GC quite early
def my_method
do_stuff_with(MY_STRING)
end
# after
def my_method
do_stuff_with("My String") # 1 allocation first time
end
But this move also complicates strings manipulation in the sense of it will lean users toward immutable ops that tend to allocate a lot of strings. foo.upcase.reverse
# VS
bar = foo.dup
bar.upcase!
bar.reverse!
So now we have to be deliberate about it: my_string = +"My String" # it is not frozen
We have frozen string literals for quite a while now, enabled file by file with the "frozen_string_literal: true" comment and I've seen it as the recommended way by the community and the de-facto standard in most codebase I've seen. It is generally enforced by code quality tools like Rubocop.So the mutable vs immutable is well known, and as it is part of the language, well, people should know the ins and outs.
I'm just a bit surprised that they devised this long path toward real frozen string literals, because it is already ongoing for years with the "frozen_string_literal: true" comment. Maybe to add proper warnings etc. in a way that does not "touch" code ? I prefer the explicit file by file comment. And for deps, well, the version bump of Ruby adding frozen string literals by default is quite a filter already.
Well, Ruby is well alive and it is what matters)
The ecosystem, toolchain and all do a lot. It is really missed when I do other languages, and I wish to find the same way of developing elsewhere. I currently do C for embedded in an horrible IDE, and I want to bang my head against the table each time I had to click on something on the interface.
(btw Python is a nightmare for me)
I like the game though, but I use the PWA made by Opera team at https://2048-opera-pwa.surge.sh/
- We are also designing and developing a more advanced family of microcontrollers, RP235x, which we expect to launch in the second half of 2024, as well as chipsets for use in our SBCs and compute modules for release thereafter.
- We continue to invest in the design and development of new SBC products, including successors to Raspberry Pi 5 and Raspberry Pi Pico, that will incorporate future semiconductor products, including RP235x. We intend to develop new products that address customer requirements such as industrial temperature tolerance and onboard non-volatile storage. We also intend to continue working to extend the long-term availability of our older SBCs
This means on-board flash !
- We are designing and developing a family of microcontrollers, RP235x, which will serve as successors to RP2040, and which we expect to launch in second half of 2024. RP235x products are designed to operate at higher speeds, use less power and provide greater security than RP2040.
For me, the main thing keeping at being good at the closed loop system is delay. In the pancreas, « measure » and delivery happen at the blood level. It is instant. With CGM and pen or pomp insulin delivery, it is in the superficial higher layers of the skin for which you have 15min delay to and from blood.
We don't know what happened there. Did they have money issues?
Sometimes that means: Electricity produced at x$: sells for -5$ (I pay you to use it)
Type 1 is not preventable, but detecting it is important as it could arise in infants (half of cases). Consequences are kind of hard if ignored / not detected. Then proper glucose monitoring can be set.
And more generally, detecting glucose level from urine is a bit late for any kind of diabetes. So pretty useless for Type 2 monitoring I think.
At Electra, we're building a fast charging network for electric vehicles in France. We're a product company and are focusing on delivering the best user experience possible, from a top-notch App to what happens on the station. Our approach is technological with advanced features like booking, smart assignment of chargers and load balancing. The stations will be 100% ours and the first ones are planned to go live in 2021Q4.
To reconcile environmental values and work. EV geeks accepted! :-)
We are building a senior team and have these open positions:
* Senior Ruby/React Full-stack Engineer: https://jobs.makesense.org/jobs/smnN9zk5LPiMZjo6YJM9
* Lead Ruby/React Full-stack Engineer: https://jobs.makesense.org/jobs/BTPoBrfV75GTwqEZZTCZ
* Senior iOS Engineer: https://jobs.makesense.org/jobs/9mBQKOvUU1tqNvbQ7tjH
* Senior Android Engineer: https://jobs.makesense.org/jobs/il6DleKLaUAWoiU77Kxr
* Electronic / IoT Engineer
Expected candidates are perfect English speakers, and also French speaking or willing to learn it.Application and more info through the job offers, or job@go-electra.com (NO agencies, tech recruiters, freelances...).
Feel free to reach me, I'll happily share more details with you. And follow us on https://www.linkedin.com/company/electra-charge/
See the responsive part in https://flif.info/example.html
We can imagine decoding taking into account battery save mode, bandwidth save mode...
No, cul de sac means dead end (as in a road that ends)
Do you plan to support webmock and httplog ? Or add support for httpx into those ?
Can't integrate a networking lib that can't be mocked in my specs.
Cheerz is a printing app, used by millions of users in Europe, thanks to its simplicity and innovation in the customer experience.
Cheerz, that's also >60 people from 14 nationalities (French, Italian, Spanish, Austrian, German, Russian, ... and even Kazakh) at the two-floors-with-terrasse-and-view-on-Sacré-Coeur main office in the center of Paris, and >50 people at our factory in the north of Paris. This year, we're recruiting >30 new cheerzers at key positions. The engineering & product team (22 people) is recruiting to move faster. Tech wise, the backend services are built with Ruby, Rails & Postgres. Frontend apps are built with Typescript & React (& Vue as legacy).
We're looking for those talented people:
* one senior and one junior Backend Engineers (Ruby)
* one senior and one junior Frontend Engineers (React)
* one Lead Developer Android (will also be the manager for the Android team)
* one junior QA Engineer
* one Head of Product
I'm the Lead Developer & manager for the Back & Front teams, feel free to get in touch with me at maxime _at_ cheerz.com if you're interested or for any question.
Cheerz is the fastest growing company in the printing industry, used by millions of users in Europe, thanks to its simplicity and innovation in the customer experience. Cheerz, that's also >60 people from 14 nationalities (French, Italian, Spanish, Austrian, German, Russian, ... and even Kazakh) at the 2-floors-with-terrasse-and-view-on-Sacré-Coeur main office in the center of Paris, and >50 people at our factory in the north of Paris. This year, we're recruiting >30 new cheerzers at key positions. The engineering & product team is 21 people. Tech wise, the backend services are on Ruby, Rails & Postgres. Frontend apps are Typescript with React & Vue (legacy).
For my team of currently 6 people, we're looking for 4 new talented people:
* one Senior Backend Engineer (Ruby)
* one Junior Backend Engineer (Ruby)
* one Senior Frontend Engineer (React)
* one Junior Frontend Engineer (React)
Other openings:
* Lead Developer Android
* QA Engineer
* Head of Product
Details on all openings on https://cheerz.welcomekit.co and some articles on https://medium.com/cheerz-engineering
I'm the Lead Developer for Back & Front, feel free to get in touch with me at maxime.g [arobaz] cheerz.com for any question.
It seems it misses an "automatically" installed flag in order to remove the deps I didn't have specifically installed myself in the first place. Would be very great for brew to have that.
Now I avoid trying new apps through brew.
An indication of the formula downloading a pre-built binary or compiling it would be nice too, btw.