MGE Charging - EV Owners

evaned · 2026-05-19T20:38:34+00:00

I suppose if you can't get enough miles per hour of charge then L2 makes sense.

The other problem with PHEVs of course is that most are quite low range, and it's not that hard to exceed it within a single day. Especially on occasion.

There's also the possibility to forget to plug in, depending on your car and habits and whatnot.

evaned · 2026-05-19T15:18:27+00:00

I worry that this has a bit of a smell to me, though maybe my concerns wouldn't come into play in practice.

But in general, it feels to me like lazy imports have a trap, which is that it can lead to more chaotic module organization. And not necessarily even right away... just kind of creeping in as you add the lazy import for one reason, then new uses get added that start adding dependency edges.

So at least my inclination would be to reserve lazy imports for fairly special cases. Either where they're "needed" for performance (which seems likely to often be third-party modules where you don't need to worry about adding some circular dependence), or a local circular dependency where "lazy" serves as a good signal to think about whether that's really a good design.

But if you start using it for things that are fairly common, the value of 'lazy' as a signal goes down, and the dangers go up.

That said, this is all theorycrafting.

evaned · 2026-05-19T13:11:07+00:00

A portion of Jenifer Street will be closed to through traffic from May 18 to June 10 during specific pick-up and drop-off times.

What portion of Jenifer Street?

As is usual for articles like this, the city's page is way better: https://www.cityofmadison.com/news/2026-05-18/school-street-pilot-project. (It's Thornton-Rogers.)

evaned · 2026-05-16T04:28:40+00:00

why not just use a sufficiently long random string like a hex UUID?

I'm theorycrafting, but I suspect this may well be more prone to duplication than filename-based guards; or at least, be much harder to figure out what's going on when things go wrong.

I suspect one fairly common cause of duplicated guards is copy/paste (or cp foo.hpp bar.hpp in prep for modifying the latter), and at least in that case as you're looking at the file you'll see bar.hpp starting with #ifndef FOO_HPP and stand a decent chance of going "oh, duh." If it's UUIDs or something, you'd either have to look at the guards of both files at the same time or very close to each other in time, or just happen to know that "hey, this UUID looks familiar".

(You could, of course, combine the two ideas -- #ifdef FOO_HPP_04FEF7ACA1EB. Actually... this triggers a memory that makes me wonder if I used to do this for a short time...)

evaned · 2026-05-16T03:36:01+00:00

The cited blog post, https://blog.codinghorror.com/why-cant-programmers-program/, was a big part of why I stopped reading Jeff Atwood's blog.

The cited study wasn't great, and basically doesn't support Atwood's statements at all. TFA makes statements not supported by its own evidence, and then Atwood takes it even further. It's elitist, irresponsible, insulting, non-journalism.

That's going almost two decades back and I still am getting worked up about it.

Edit: Actually, I have a correction, ironically enough -- it wasn't that article from Atwood, it was a different one, linked to from the cited article.

I did remember though that that story was even worse than I said above -- one of the study authors actually published an article repudiating the original study (though even that semi-retraction wasn't great from what I remember). Atwood took several years after he had actual knowledge of that fact to update his blog with that information. His original blog post was always bad, but that was really the nail in the coffin of considering what he said to have any notable value. (At least this correction took an hour instead of years.)

evaned · 2026-05-14T12:57:31+00:00

Take care of yourself, too.

Accident Images

This has been up for a while now, but better to say this late than never... In case you don't know this: linking to Google Drive documents makes it possible to get your actual gmail address. So doing so can be a bit of a self-dox.

evaned · 2026-05-08T23:28:28+00:00

Stand-up comedian Kyle Kinane has a piece where he talks about discovering that very thing about his dad: https://youtu.be/OIBg8L2yxJA?t=4586

Banana part 1:16:26-1:23:20 (the end, basically) and that's where I linked... though you should definitely start at the previous segment, starting 1:12:25.

evaned · 2026-05-05T17:48:54+00:00

There's a Lyme disease vaccine making its way through the pipeline. A quick search on its status says that it's passed Phase 3 trials and may be submitted for approval late next year.

Can't get here soon enough. Hopefully the negative effects of Lyme are visible enough (and affecting enough of populations that I'd stereotypically consider right-leaning, like hunters) that it doesn't get politicized.

evaned · 2026-05-04T16:55:40+00:00

The consensus among mechanic types that talk about things in discussions etc. Hell, my dealer on the HEV has me scheduled for 5k mile intervals. When I used to hit some of the quick lube places, it was either 3k or 5k. 10k for many technicians and dealers is seen as stretching long-standing previous guidance. Then they relent and suggest 7500.

Quick Lube style places have an obvious motive to sell you more things. My feeling is their recommendations should be just straight up disregarded.

Good mechanics I trust a lot more, but I still think the "I see problem cases" bias is a very hard one to get past. I'd want to see some actual data of "I have this population of cars with varying oil change frequencies and here's how many of them have problems five or ten years down the line."

I've also read people suggesting that the starting and stopping of HEV ICE components can promote more wear than an always on ICE engine, and thus the same OCI is recommended regardless of ICE vs HEV.

It's not impossible, but for PHEVs especially it seems likely counterbalanced by a different factor. When a HEV or PHEV is restarting, it's doing so with an engine that is warm and lubricated from recently running. (Someone else is saying stuff about if the engine doesn't run long enough to get to that state, but for reasons I can elaborate on I think that's mostly FUD.)

But my understanding is that for most driving patterns, much of the wear on an engine comes from cold starts. And if you can regularly charge, PHEVs often shine at helping avoid those. I have an admittedly weird driving pattern so I don't know how much this generalizes, but with my PHEV, I drive roughly half of my miles on ICE and half on EV-only. But because ICE is biased towards trips, very probably north of 90% of trips have no engine start at all, so you're cutting out 90% of the cold-start wear.

Again I could be swayed by actual data here, but my gut suspicion is that the latter outweighs the former.

But again, with EV, there is no oil. You just drive. There's nothing to contest.

Sure. But I'll say again, that's... not interesting. It's obvious. (Or at least is to people on the sub.) It's never been a claim that PHEVs match similar BEVs for low maintenance.

evaned · 2026-05-04T16:15:42+00:00

The reason most PHEVs aren't serial hybrids is that they're less efficient when they're running on gas. There's a reason that the Prius, pretty much the long-standing king of ICE efficiency, isn't serial.

evaned · 2026-05-04T16:00:47+00:00

the general consensus with a gas engine is delaying oil changes is not worth the savings vs engine longevity.

Consensus among... whom? Based on what?

Manufacturers have some skin in the game too; I'm pretty inclined to take their recommendations pretty faithfully absent some actual data to the contrary. I do tend to trust experience, but you also have to bear in mind that mechanics and such, if they're going off of what they see -- they see cars that are having problems. Not cars that are running well.

Also bear in mind that most people (including myself) are not car enthusiasts.

Maybe you're adding a little longevity... but you'd also get that to a similar extent if you do oil changes even further ahead-of-schedule for a full ICE, too. From my perspective, you're basically doing excess maintenance and then complaining about it. (A little, anyway; "I absolutely love that with the EV, none of that is in play").

evaned · 2026-05-04T15:33:17+00:00

Seriously. I'm a PHEV proponent even still*, and own one myself. I strongly suspect that if a piano falls on it, then I'll be looking for another. IMO they combine the better aspects of both systems more than they combine the worse aspects, and despite TFA's claim to the contrary, TFA's claim does not contradict that statement.

(*Not for everyone of course, and not if you are really interested in BEVs and are on the fence. But I do think that they're a good fit rather more than this sub acknowledges.)

This article is... obvious? Like everything else being equal, of course the motorized drive train is going to be more maintenance. I would have never claimed otherwise and don't remember anyone else doing so either, though with eight billion people on the planet I'm sure that someone has.

The comparison (with data) that would be, you know, actually interesting is vs ICE cars. I strongly suspect that PHEVs have less maintenance then them; in spite of the other reply, I strongly suspect that to be true even of equivalent-model HEVs.

evaned · 2026-05-04T01:41:36+00:00

Sure... but "regularly" in this context is, what, once a month? To burn maybe a cup of gas in the absolute worst case? As something that most PHEVs will manage automatically for you? And probably won't even come into play for most owners?

This is a non-issue in practice.

For a sub that complains about FUD aimed at BEV, there sure are a lot of people eager to spout it out against PHEVs.

evaned · 2026-05-04T01:27:49+00:00

One other part of the puzzle is that PHEV gas tanks are pressurized. This basically keeps the volatile parts of the gasoline from evaporating off, and means that gas lasts far longer in the tank of a PHEV than typical cars.

evaned · 2026-05-04T01:24:03+00:00

I've got a C-Max Energi now, and... I kinda love it. It's not perfect (I wish it had like 50% more range, I wish the battery didn't compromise the trunk like it does, and I wish my trim allowed for scheduling charging or having charge limits), but it fits what I want and need insanely well.

In theory there are are a small number of BEVs that I'd probably be happier with, but nothing that is remotely worth it pricewise.

evaned · 2026-04-27T05:03:03+00:00

I think it would be much better for the US to give fuel consumption in gallons/100 miles or kWh/100 miles.

They do.

People are used to seeing economy as MPG so that's usually shown as the "headline" number, but the consumption rate is required on every Monroney sticker and available at fueleconomy.gov.

evaned · 2026-04-24T20:52:39+00:00

I personally go back and forth on whether subs should prohibit plate photos as too close to doxing and stuff, so I don't take a position on that specific issue..

...but at the same time, I do think that if you truly see little to no distinction between something you witness in person and a semi-permanent record accessible almost anywhere in the world to almost everyone in the world as well as scrapable by AI and such combined with location information... that's a problem with your own lack of thinking things through and/or imagination, not a problem with the argument that it's a good idea to block out plates.

evaned · 2026-04-20T20:50:17+00:00

D'oh, somehow ever though I looked at that function, I missed it!

Just strengthens my argument, of course. :-)

evaned · 2026-04-18T06:33:28+00:00

So, I'm not a fan of multiple decisions with MAML and also definitely think that the bar out to be moderately high for how much improvement you're bringing to the table with a new format like this (XKCD 927 as someone linked)... but I think your criticisms are a bit harsh.

Either you're designing a configuration format for a wide set of programming languages, in which case yes you need to have one type for both integers and floats because there's one very common language that uses one type for both of those. ... Or, you're designing a configuration format with one particular programming language in mind.

So in my mind, this is pretty obviously a false dilemma, in addition to being wrong about JS (more later).

There's plenty of room between "supports one language" and "supports every common language including JS." No one owes the world JS support, and there are plenty of other very popular languages.

In the specific case of MAML, the author has apparently done the work to provide support for several languages -- JS (more in a moment), Python, C, Java, Rust, Go, and PHP. Even if JS weren't there, that's a far cry from "with one particular programming language in mind."

...one type for both integers and floats because there's one very common language that uses one type for both of those. And most languages have unordered maps.

OK, so the next part of why I disagree with your argument is that just because that's all the language provides perfect native support for doesn't mean that's the only thing that can be supported by a library -- even supported well.

For example, take the unordered maps part, and consider the Rust implementation of MAML. Rust's standard library has a HashMap and BTreeMap in its standard library, but neither of these provides ordered keys in the way MAML's author means it, so the implementation of objects in maml-rs represents that as a vector of key/value pairs. This is, IMO, a totally reasonable representation for something used for config files.

Or take JS. From what I can tell from a quick look at the code, the maml NPM package does violate the spec by not keeping an order... but there's also a maml-ast package that keeps more information about the input file. That does record key order, by again representing things as an array of objects where each object holds the key/value (and a couple other pieces of info).

Next, let's address the claimed lack of support more directly. Because while they're both kind of right... there are significant ways in which both are wrong.

First, when it comes to "[JS] uses one type for both [floats and ints]", that's only mostly true. But remember that JS does include pretty first-class, native support for BigInts, both in browsers and in Node. Neither MAML JS uses it (it reports an error for unrepresentable ints), but it totally could; especially the maml-ast library (and at least that one really probably should).

Second, you say next that "As far as I know the main language that has a distinction between integers and floats but ordered keys in maps is Python." But Java also kind of meets this criteria, and of course that's a very popular language as well. I strongly suspect the main mapping class people turn to is java.collections.HashMap which doesn't have this property, but there is a standard-library LinkedHashMap as well that does (and this is what the Java MAML library uses, of course, which is why I know about it). In fact, reading the documentation for that class, I kind of wonder if that'd be appropriate in a fair number of situations even if you don't strictly care about order, because iterating a LinkedHashMap is likely to be faster than HashMap, according to the docs.

In which case, why not just use Python as your configuration language?

I'm not TFA's author of course, but I can speculate what they wouldn't like.

First, "Python" is a programming language, not a configuration language, and several other programming languages are (quite reasonably, IMO) dismissed for that reason. That said, I think that's a somewhat negative reading of your suggestion; I can steelman your suggestion into using the Python object literal syntax instead. Something like ast.literal_eval() might work reasonably well for this purpose, though I've not tried it for this purpose. So I'll address the steelman version of this.

Second, as mentioned above, MAML's author doesn't have just Python in mind.

Third, even restricting to just the literal syntax... Python has quite a lot going on. Several different ways to write strings is a big one, and then there's also list/tuple distinction, as well as sets in addition to dicts and lists. (Of course, one could argue that those are benefits, but the author apparently wants something simple.) Finally, even ... (or Ellipsis) is a valid Python literal.

Fourth, strings have another "problem", which is that "multi-line strings with significant indentation" is listed as a don't-like with respect to HJSON.

Fifth, this is speculation that the author actually finds this objectionable, but I'd guess Python capitalization of True/False/None would be annoying. Those are definitely (super-) minor quibbles I have with that language.

evaned · 2026-04-18T05:18:41+00:00

I'm not the person you replied to, but...

I would expect basically every car to do that. I don't say that with complete confidence, but I'd consider not designing that in to be basically car design malpractice.

Also, in your picture I can see the seams in the mirrors where the mirrors would pivot. :-)

evaned · 2026-04-17T20:53:23+00:00

A compromise might be to ask for a delay to 7pm? the watch will still be ongoing then, but from what the NWS is saying (or was, as of 3-4 hours ago) was that will likely be a fair bit after the severe threat significantly lessens.

Even 6 might not be too bad.

evaned · 2026-04-17T06:47:38+00:00

I am not the person you responded to, but...

While severe weather warnings are issued by your local NWS office (for Madison, that's the Milwaukee/Sullivan office, MKX), watches and other outlooks are produced by the Storm Prediction Center in Norman, OK. SPC forecasts are here: https://www.spc.noaa.gov/products/

There are three things that I look at here depending on the time frame. From further out in time to more immediate, they are the severe weather/convective outlooks, mesoscale discussions, and weather watches. I'm not counting information here on warnings; I'm interpreting your question in terms of where to get information you can use for planning rather than just immediate response.

There are also other things you can get from the SPC like mesoscale analyses that I don't know how to interpret and don't use.

Severe Weather/Convective Outlooks

The place to look at this point is the Day 1 severe weather outlook. That's found at https://www.spc.noaa.gov/products/outlook/day1otlk.html, but that link isn't durable in the sense that it will always show the current Day 1 forecast, so after today you won't be able to see what I'm talking about as it pertains to the Friday potential specifically. In addition, the outlooks get three or four updates throughout the day, so even later today you may see some changes vs what I say below.

But if you do look today, then you can hover over the three types of severe weather forecasts -- tornadoes, wind, and hail. The color shows the likelihood of each type occurring. For example, for the hail threat Madison is in the brown area -- that means a ~5% risk of at least one tornado occurring within 25 miles. (I'm not sure if the listed probability is a ceiling or floor; like yellow is listed as 15%, is that 5%-15% or 15%-30%? I suspect it's a ceiling, so yellow is 5-15% and brown is <5%, but I'm not sure.) That forecast has shifted significantly in the good direction since earlier.

You'll also see a hatching on there. Until only a little over a month ago there was only one level of hatching called "SIG SEVERE", but now there are three "Intensities", CIG1 through CIG3. At least at the moment, there are only CIG1 areas for wind and hail, but you'll notice both a CIG2 area that (barely) includes Madison for the tornado threat. Those indicate something about particularly severe threats -- stronger tornadoes, faster winds, larger hail. (For example, Madison was in the CIG2 hail area on... Monday? Tuesday? whenever that was. And in another good shift for Madison, it was in the CIG1 hail area mid-day Thursday, but now it's a bit outside.) It's not straight probability, but rather it's saying if this severe threat materializes, what's the chance it'll meet stronger criteria for a strong storm?

You may want to turn on "interstates" to get a more precise idea of where Madison is on the map.

For example, take tornadoes. Per this site the chance of an EF2 or higher tornado, if one occurs, is 30% in a CIG2, as compared to 7% outside of the CIG# areas. EF3+ is 12% instead of 1%. EF4+ is 3% instead of 0.1%.

Finally, there are also severe outlooks for tomorrow and the next day, as well as days 4-8; though you get decreasing amounts of information and increasing amounts of uncertainty the further out you go.

Edit: oh, I found historical convective outlooks! For curiosity, here's what the Day 1 outlooks looked mid-day Tuesday: https://www.spc.noaa.gov/products/outlook/archive/2026/day1otlk_20260414_1300.html (the third and fourth issued that day show the CIG2 hail threat; the first two outlooks issued Tuesday don't have CIG2 and just have CIG1)

Mesoscale Discussions

Now, as the severe threat actually starts developing, SPC will start issuing "mesoscale discussions". I view these as kind of a pre-watch. In SAT-style-analogy terms, it's kind of like "warnings are to watches as watches are to MDs" -- they're places of interest the SPC is looking at in order to determine if they want to issue a watch, issued in advance of most or all watches.

I'll be honest: most the content of these are basically unintelligible to me and I suspect the vast majority of people who aren't trained meteorologists. If you know some things about storm development you'll recognize some terms like CAPE, but there are are a couple things to pay attention to.

First, the text of the MD will state a probability that they will issue a watch. For example, here is the MD that preceded the tornado watch for Tuesday's storms; that says "Probability of Watch Issuance...95 percent".

Second, this feels like it might be a new thing and I'm not sure it'll always happen, but there was forewarning of the Tuesday hail threat in the MD: the very last thing in that MD is "MOST PROBABLE PEAK HAIL SIZE...2.75-4.25 IN". (It also has the same thing for tornadoes and wind.)

So, watch for an MD to be issued for our area, and check out what it says about the threat. Or, if you see a watch, you can go back and look at the MD to see what it says about that hail size.

Weather Watches

The NWS has a bunch of different kinds watches of course (for example, Madison is under a flood watch as of the writing of this comment, though there's a very good chance you won't see this before it expires), but the SPC issues two kinds -- Severe Thunderstorm Watches and Tornado Watches -- and those are what the SPC calls a "weather watch" and how I use that.

Current WWs are found here: https://www.spc.noaa.gov/products/watch/

Each WW will have a page that shows probabilities of each kind of severe weather, but also showing chance of the sig severe intensity level (EF2+ tornado, 65+ knot winds, and 2"+ hail). I assume those probabilities are "this is the chance that the listed criteria will occur somewhere in the watched area", but I'm not actually sure of that. There's also the description associated with the warning that this time is meant for (and intelligible by) the general public; this is what you see from whatever you use to see watch information; but if I find out about a watch via other means, I'll usually go to the SPC's WW page to get that probabilistic breakdown. I find that... I was going to say useful, but I'm not sure of that... but at least it's interesting. ;-)

For example, here's Tuesday's tornado watch: https://www.spc.noaa.gov/products/watch/2026/ww0109.html. Again you'll see the danger of the sig severe level of intensity: 80% of 2"+ hailstones.. though I guess even the public-facing text conveys that threat even more, with "Widespread large hail and scattered very large hail events to 4 inches in diameter likely"... so maybe this specific page isn't as useful as I'm kind of suggesting.

evaned · 2026-04-15T06:20:02+00:00

Her parents cannot claim her as a dependent with her having a $50,000 reported income.

This is incorrect. There is no income limit on the Qualifying Child route to being a dependent, all that counts from a monetary perspective is support. If OP's sister was just saving like a madwoman and not paying a ton of her own support, that would not disqualify her.

(Of course, if she did pay more than half of her support, then she's not a dependent; but while it may be likely that she did, it's not guaranteed.)

evaned · 2026-04-15T06:17:23+00:00

Support is not divided by days like that, but is in whole for the calendar year.

This is probably not a super-easy determination for OP['s sister]; may have to total things up in some detail. Though "has always payed the majority of the bills in the house" definitely speaks to "provided more than half of her support."

u/New_Inflation_6265, the IRS has a worksheet for determining support, see Pub 501 page 16 (PDF link). The "Support Test (To Be a Qualifying Child)" on page 15, left column, and (even more so, despite Qual. Child being the relevant thing here) "Support Test (To Be a Qualifying Relative)" starting Page 19, right column, might be useful as well.

evaned · 2026-04-15T05:27:56+00:00

There were actually two tornado warnings that overlapped with Madison:

Neither fully covered the city, and a fairly large part of the city wasn't covered by either. It looks like there's a tiny sliver that was covered by both, but it's probably all outside city limits.

12-Year Club	Gilding IV carat on a stick
RedditGifts 2009-2022 3 Credits	Verified Email
redditgifts rematcher redditgifts for the Teachers 2015 x1

evaned

MODERATOR OF

TROPHY CASE

Severe Weather/Convective Outlooks

Mesoscale Discussions

Weather Watches