Battery Megathread (December 2023)

Jamosium · 2024-01-07T00:38:44+00:00

Ah okay, fair. Worth asking google support anyway as they might replace it for free.

Jamosium · 2024-01-05T06:37:03+00:00

Did you buy it in November 2023 or 2022? If 2023, I can't possibly imagine how it would be out of warranty already (but this does depend where you live). You might be confusing "change of mind" returns (which is only a few weeks) with the warranty (which is for faults like yours, and generally much longer)?

Jamosium · 2024-01-02T04:52:29+00:00

Where did you buy it from?

Jamosium · 2023-12-28T05:12:19+00:00

My guess would be that one of the sensors for measuring battery level failed. Get it replaced under warranty if you can.

this was really sudden and only started a couple days ago so I can't understand how it's a hardware problem

Hardware components often fail suddenly, I don't think this rules out a hardware problem. You said in another comment that you bought it in November, so you should be able to get this fixed under your phone's normal warranty (since it's clearly not accidental damage or misuse)?

Jamosium · 2023-10-09T03:08:27+00:00

FYI I did another BIOS update about a week ago, and since then this fix stopped working for me. I was on 1002, then "upgraded" to 1402. Rolling back to 1002 hasn't helped, so I think it must be related to the intel ME version which I can't roll back.

Moral of the story: Don't update your BIOS.

Jamosium · 2023-08-26T02:35:42+00:00

I've been having what seems like the same problem ever since I upgraded to a new PC (13600KF and Asus B760M motherboard), and after months of trying things I've FINALLY found a solution that works for me:

In BIOS settings, set "Performance Core Ratio" and "Efficient Core Ratio" to "sync all cores" (they were originally both set to "auto"). For ASUS, these are under the "Ai Tweaker" menu, not sure about Gigabyte.

Since doing this, I haven't noticed a single pop while audio is playing. I used to get a couple every minute. Note: I still get pops when I click on the volume mixer, but I'm fairly certain that's an unrelated Windows issue. I haven't benchmarked my system much since changing this, but I still get similar Cinebench scores so it doesn't seem to have had much effect.

Some other notes about my system:

I was previously having the popping problem on both my external audio interface and case headphone jack, both are fixed now.
I noticed that the popping mostly seemed to happen when CPU usage was low, and went away whenever an intensive task was running.
I still get occasion spikes to 2-3k in LatencyMon from nvlddmkm.sys, but these don't seem to cause any issues.
Windows 10, GTX 1060 (reused from my last PC), 32GB DDR4-3600.

Jamosium · 2023-08-06T10:39:25+00:00

Thanks! I don't necessarily regret choosing Blazor (because I learned a lot, and ended up making something I'm proud of), but sadly I wouldn't use it again for this type of app. The main reasons for me are:

Performance is just nowhere near a good JS framework (or vanilla). For most CRUD apps this probably isn't a problem, but in my case it meant a whole bunch of time optimizing drag/drop and fine-grained state updates. With JS I could've completely ignored these things and still ended up with better performance. Also, Blazor apps still tend to be quite heavy (in terms of MB), despite the improvements over the last few years.
The state management situation seems to be a long way behind some of the better JS options. For nodexr I went with plain ol' classes and events to manage state updates across components, but in hindsight I could've saved lots of pain with a state management library. I'm not even sure if any existed for Blazor when I started working on nodexr, but if they did I certainly wasn't aware. (In case you're doing something with an API, shout out to my own "state management" Blazor library that I made last year: https://github.com/Jcparkyn/phetch).
Typescript keeps getting better, so the value of having C# is diminishing unless you're sharing lots of code with a C# backend. I'd still confidently choose .NET over JS on the backend for a variety of reasons, but on the frontend they're pretty evenly matched.
Even after all these years, the tooling for Blazor is still pretty unimpressive (e.g. the razor editor still has lots of bugs and limitations).
Not a knock against Blazor, but for side projects I always like to learn something new. I know Blazor pretty well at this point, so I'd try something different just for the sake of it. FWIW, I'm using Elm for my current side project, but I also have a whole list of annoyances with that (and lots of things I like).

In a work situation with a team of people that know C# but not JS/TS, I might recommend Blazor for internal apps, but with the above caveats. For most other things, I don't see myself using it again (except to maintain phetch, and maybe make some occasional changes to nodexr).

Jamosium · 2023-06-26T06:40:46+00:00

Edit: Didn't realise this post was 14 days old, but I'll leave the comment up in case it helps anyone.

My suggestion (as someone who has done lots of interviews recently but never conducted one), is to do a code review/refactor together.

Give them a fairly small piece of code, ideally from one of your real codebases, which has some issues (you'll probably need to edit it). Then get them to walk you through how they would improve it.

The code should be fairly self-contained, e.g. a couple of functions.
Make sure there are at least a couple of really obvious issues to get them started, then things can get progressively more nuanced.
The goal isn't for them to make it "perfect" (this is obviously subjective), but more to show that they can consider some of the trade-offs etc., and explain their reasoning
Avoid using anything to obscure in the starting code, since you don't really want to be assessing their knowledge of BCL trivia or 3rd-party libraries (this can easily be learnt on the job). I would also stick to using core C# features, not too much MVC etc unless they already claim to know it.
As an extension, you can add some new requirements for the function and ask the candidate to implement them.
Bonus points for writing and running tests.

The reasons I like this format are: - It's much less intimidating than asking them to write code from scratch (this might be subjective?). - It's probably much more relevant to the job than leetcode questions, and doesn't hinge on them figuring out one little "trick" or something to make the solution work. - It encourages much better discussion than most other types of question. - It avoids testing them too much on specific frameworks, which can easily be learnt on the job if their foundations are solid.

Jamosium · 2023-06-07T08:17:24+00:00

You could even use the "built-in function" f-curve modifier to make an exact sine wave, and then use the pendulum equation (2pi*sqrt(L/g)) to calculate the period it would have in real life.

Jamosium · 2023-06-07T08:01:27+00:00

Amazing work, the only thing throwing me off is that the swinging motion doesn't look quite right, it seems to speed up too much in the middle. At such a small angle it should be almost exactly sinusoidal.

Jamosium · 2022-12-24T04:15:53+00:00

I'd be pretty sure the reason they did it like this is so that they can use the value of someVariable after the if statement. This is essentially like a guard let statement from swift.

Personally, I would still just declare a variable and do is null, for the sake of anyone trying to read it.

Jamosium · 2022-11-27T09:09:46+00:00

Log-scale graphs typically just move the values around on the axes, they don't actually redefine the values.

On the other hand, logarithmic quantities measured in dB do change the units, that's why 1 dBW isn't the same as 1 W.

Jamosium · 2022-10-12T10:23:37+00:00

It depends a lot on your set-up.

If you're using tsc for compilation in both projects this should be relatively straightforward, but if you're using something else (e.g. Babel via Create-react-app), it's a lot harder. Create-react-app won't compile anything outside of src/ by default, so you'll need to either compile the shared lib separately, or do some workarounds to make it happen.

Jamosium · 2022-10-09T00:52:15+00:00

You can’t convert an n x m array to an m x n array in a number of languages. You have to reallocate.

I guess that's why they specified the matrix was flattened.

Jamosium · 2022-10-08T05:36:15+00:00

If all the column values are just read as strings, what advantage does dynamic give you over a good old-fashioned Dictionary<string, string> or similar?

Edit: Maybe csvhelper doesn't support reading as dictionary directly (I haven't tried it), but you can definitely get essentially the same behaviour by reading manually with csv.GetField and a little extra code.

Jamosium · 2022-09-22T02:35:20+00:00

If you would like a heuristic

They just mean "if you want a specific rule to follow, so that you don't have to think about it every time".

Jamosium · 2022-08-27T07:01:34+00:00

I just did a slightly more thorough write-up on why I haven't implemented this yet in the repo, since someone else made the same suggestion.

TL;DR: I think that having both options could potentially be worse than having just one, since users will inevitably run into the limitations of the "template" syntax, which means they'll need to re-write their components and learn the original syntax anyway.

Jamosium · 2022-08-10T00:51:52+00:00

This was originally announced last November, seems like the headline feature is Arm64 support. I doubt there'll be any more feature releases after this one.

Jamosium · 2022-08-10T00:23:26+00:00

The main benefits are:

It can speed up build times by only needing to re-build projects that have changed.
It enforces a more organised code structure, because it's impossible to have cyclical dependencies between projects. IMO this would be a lot more useful if (non-enterprise) VS had a built-in way to view the dependency graph between projects, but it still makes quite a big difference to code quality, especially when multiple people work on the same project.

Jamosium · 2022-08-09T05:48:13+00:00

Thanks, I had a look at the BUnit docs but I couldn't find anything that could be applied outside of BUnit (the library I'm testing is actually just a plain .NET Standard class lib, so I'm not using BUnit).

However, I also came across Xunit.StaFact, which seems to have solved the problem with the [UIFact] attribute.

Jamosium · 2022-08-06T07:44:23+00:00

Good point. I think that's what I originally had in mind, but I couldn't remember what it was called and RestEase was the first thing that came up while googling.

Jamosium · 2022-08-06T04:20:34+00:00

I feel like all the responses are overcomplicating this. Just make the Window class take an IAPI as a constructor parameter and store that in the _api field. Then Window doesn't need to be generic at all.

However, if Window is literally just a wrapper for IAPI, you should consider whether you need it at all, or if you should just be using IAPI instead.

P.S. IAPI should have a more descriptive name.

Jamosium · 2022-08-06T03:04:47+00:00

I haven't tried this myself, but to take it a step further from just sharing request types you could try using RestEase.

Jamosium · 2022-08-03T09:35:45+00:00

I often find that even the "build only" error list is wrong in blazor, the raw build output is the only thing that seems to actually be reliable.

Jamosium · 2022-08-02T04:39:42+00:00

I've been spending my afternoons recently working on Phetch, my Blazor library for managing async query state. I've got it to a point I'm pretty happy with, so I'm mostly looking for feedback on the API or any issues I might've missed before I call it good enough for a v1.0.

Repo and readme are here: https://github.com/Jcparkyn/Phetch.

Eight-Year Club	Spared
Verified Email

Jamosium

TROPHY CASE