madarcho

My big issue with the M1 generation is the lack of more E-cores, which get assigned a lot of the OS background tasks. When working at the top of the RAM limit, I'd notice issues around lag to the point that I started looking at CPU stats and found those two measly e-cores completely maxed out for hours on end. Occasionally a crash, though that could be RAM related rather than CPU.

A bit of googling around seems to point that architecture as somewhat of a problem for others, and might be why Apple quickly moved to put more e-cores on the later generations.

Something to consider. Never managed to get proper distinct confirmation that this was the problem, but a (corporate) laptop upgrade did get me out of this pickle.

If SynthID is a google technology, then this is likely just us training their ai again, captcha all over again.

CodeQL was a good help on some projects, but more recently, our team has been increasingly frustrated by the thing to the point of turning it off.

The latest drop in the bucket was a comment adding a useless intermediate variable, with the justification being “if you do this, you’ll avoid CodeQL flagging you for the problem”.

Sounds like slight overfitting to the data!

Where is this worry coming from? (I'm curious, not shutting it down)

I might be biased from having worked with production F#, but it feels more like functional is making its way into C#, as the general industry sees value in functional principles. So F# feels like its more here to stay?

The task sounds similar to descriptions in the API space. People figured LLMs would be awesome at annotating API specs with descriptions that are so often missing. Truth is, everyone is realising it’s a bit the opposite: the LLMs are “holding it wrong”, making a best guess at what the interfaces do without slightly deeper analysis. So instead, you want humans writing good descriptions specifically so the LLM can make good choices as to how to piece things together.

It’s possible you could set it off on the labelling task, but anecdotally in my experience it will fail when you need to look a couple levels deep into the code to see how functions play with each other. And again, imo, the big risk is getting a label that _looks_ right, but is actually pretty misleadingly wrong.

From the wording, they are comparing against all electric vehicles, no specific model year, called to a routine inspection (~MOT).

There is a small note explaining that the Model 3 was introduced in Denmark in 2019 (MY 2020), and therefore 2024 is the first time the M3 has been called to the routine inspection (periodiske bilsyn), hence the specific focus on that model year for this article.

A pleasant surprise seeing an Alastair Donaldson supported paper. What I liked most at Imperial was the amount of professors pushing for things that sat between the fully theoretical world, and the more real engineering world. From a first quick skim this paper seems to hit that right on the head. I've been wanting to see how I could introduce more of the fun of formal verification into my job, so I'll be digging deep into this one for some inspiration.

Well worth a quick trip to the source to see how it's implemented. After all, how would the author get around to packaging 4B if statements, like the OP?

Almost identical pathway here, except with some Spybotics thrown in around the same time as Bionicle. I sometimes wish Mindstorms had that level of world building...

At Unity, Joachim Ante always stayed very close to the underlying engine and its tech, rather than the broader market strategies and moves. Of course, every situation is unique and difficult to compare 1:1.

And we don't necessarily need to step out of the western world to see it. I still remember Authorized Retailers in France before the expansion of Apple stores beyond the US. In Denmark, there is still exclusively these "Premium Authorized Resellers".

Redistribution of taxes, from areas of high densities to lower density prefectures.

Our attention spans have been ruined by the modern age of the internet! If an audience needs to hold a train of thought for more than three minutes, they're gone. Surprise, anecdotes, humor, problem statements, etc... are great tools that stoke the fire of focus.

Another issue is the amount of attention you get to work with. Each surprise moment spurs an increased attention which decays. So, one introduction to the problem is not enough, you have to break things down! Introduce a complication on the original problem, then immediately fix that.

To each their own, but thinking with this pattern for my talks has worked really well for me. Even for mixed audiences (engineers + PMs + management), everyone gets something out of it, and finds their own questions to ask as well. Makes it easier for them to connect it all to their own problems as well.

I imagine a branding change will be in order before actually delivering anything to users?

While I could believe in the artist and their history of fighting off legal challenges, I am sceptical around the ability to (re)build even one of the mentioned tools for the budget. Adobe has an immense moat (hence its complete gall around subscription pricing) for a reason. Otherwise everyone would just be using GIMP.

Exactly the same boat. About to switch to a C# role, so not exactly a world of difference, but I am going to miss F#. I can't help but feel that the success of our small team is majorly down to F# and the traps it helps you avoid.

I had an excellent talk about talks a couple years ago, and have actively been looking for other _fantastic_ ways to achieve the same, "sticky talk" goals.

In particular, it is interesting to see the same point (don't overload on content), but approached very differently (don't recap vs. recap a _lot_).

Hah, this was great!

This is actually my first time looking into the platform. It's interesting to have the ability to peek into the "code". Though I initially felt I agreed with an earlier comment in the chain, "just start with something real", I see my own path with Lego's NZXT visual programming language in Scratch. The visual element seemed to help me build a mental model much better than lines of code, at the start.

I left it up on 18 for others to try and break. Thanks for sharing.

I think I might be in a similar boat. I've an interest in Type Theory, but rarely get to really connect day to day work with the fun bits.

Interestingly I have never heard of Robert Harper, so I will be looking at those lectures with great interest.

Instead, I have Benjamin C. Pierce's fantastic "Types and Programming Languages" book (still working my way through it bit by bit), and I happened to get one of the most impactful talks of my life from Derek Dreyer: How to Give Talks that People Can Follow. I still use those 20 minutes of advice to this day.

I'm strangely excited to see both their names as authors on this article, and I believe that tells me a lot about what kind of passionate speaking I can expect from Robert Harper!

It's counter-intuitive, because of social norms we grow up with. I particularly dislike hello-and-hold as described, but I needed a coworker to show me that I was doing this to others before I reflected on it. It still takes me conscious effort to make sure I don't make the mistake when reaching out to people.

And in my team, we would have taken this into account.

And that starts with a conversation (like the thread OP implied in their answer). Hopefully the conversation would then avoid any pressure on you in saying that the meeting doesn't work for you.

Talk about it. It may turn out that the societal constraints don't enforce the conflict mined diamond. And you may find out more about what it is that is motivating the choice.

But you can't force things and insist that the whole thing is a useless charade. Objectively, sure, but not everything in life has to be.

Few people buy a house outright. Mortgages make the ordeal a little more in reach. Now as to whether banks grant it or not is a different problem...

Your site seems to target specifically teams with messy docker compose setups. Is there a simplified/supported migration or onboarding path?

It started off original enough I felt. It had an idea of its own, but very quickly just ended up copying the style, without really hitting home.

Still, I can't fault the author for giving it practice, and it is amusing enough to read.

Our setup is multiple solutions for each service, and most inherit from "Core" parts. This type def file is about 1000 lines (can't count the number of declarations in there).

What seems to happen consistently: I can delete a label in a type record, no lag. As soon as I finish adding a label (haven't added its type yet), all matter of slow hell breaks loose and there is a 5 second delay before anything shows up. This happens regardless of whether or not the type is used in a low (<20) or high (>100) number of places. The delay is the same in all records.

We use Rider (enterprise license) to develop our F# services. Over the past year, the experience kept improving, small tweaks kept coming, and bugs were sorted out. At the moment, some of our larger shared type definition files are a slow to edit (seems Rider/.net is trying like crazy to look over all the symbols before I've even finished typing), but overall, I had a very good experience with it.

Not aware of any linters out there. Rider might have built in rules to enforce it, but that wouldn't hook into your CI/CD.

Do you think the work stops once the baby is born? This is exactly the effort that these parental leave laws tries to cover.

So the HOTP/TOTP rely on the same secret being stored "plaintext" by both the server and the client? I am guessing this is not as concerning at all, as storing a password plaintext on the server, since this mechanism is used _on top of_ a password...

Abuse email/report to the registrar is also my goto. Usually results in a quick response

Interesting to me, that this is the first time I am hearing of lowered disease risk from regular coffee, which the study points out "has been confirmed in prospective cohort studies in many regions of the world".

The way I understood it, the study aims to correlate benefits with the "plant" contents of coffee. What would be interesting to me is to see more about the effect of the roast. The study touches on it in a couple of points ("Phenolic Phytochemicals in Coffee May Account for Health Effects" where a darker roast produces more phenolic components), but I could do with something more specifically targeting the roast differences.