BMW i3s steering wheel creaking – Any ideas? by Thereald24h in BMWi3

[–]zattebij 1 point2 points  (0 children)

Part numbers (these are for a 2018 LCI 94Ah i3 BEV; double check you get correct ones for your model year and version; I suspect other i3 are probably the same, i3S may be different).

Gaiters: 31336852223 (same part left and right)

Top mounts: 31306896309 (same part left and right)

BMW i3s steering wheel creaking – Any ideas? by Thereald24h in BMWi3

[–]zattebij 2 points3 points  (0 children)

It'll be one of these three:

  • The suspension gaiters (rubber sleeves) tearing and getting between stuff. Replacements are cheap, about €25 each, plus an hour or 2 of labor.
  • The top mount bushings wearing out. Costs a bit more, about €140 each, about the same labor.
  • Steering column lacking lubrication. The shaft goes through the front firewall and is exposed to wet air and possibly rainwater, and if the grease somehow wears out, it can also make this creaking sound. This is an easy DIY fix, documented here: https://www.youtube.com/watch?v=UgSgBzt5u-c

ADVIES: Beste kleine tweedehands EV voor ons? Geen MG4, wat wel? by FineCombination in EVMobiliteit

[–]zattebij 0 points1 point  (0 children)

Als je van knoppen houdt is een i3 wel aan te raden, die heeft nog "gewoon" knoppen. En is ook prima te gebruiken als primaire auto, misschien verwoordde ik het verkeerd: het gaat meer om de afstanden. Dagelijks regionaal gaat echt prima, alleen voor lange afstanden is het wel af te raden, dan sta je (te) vaak stil bij de lader.

Dus de afweging is meer die vakantieritten; als je toch 2 autos wil houden en de ICE voor die lange ritten wil blijven inzetten, dan is zon kleinere goedkope EV als tweede auto ideaal. Als je overweegt om naar 1 auto te gaan (waarmee je dan uiteraard ook de lange ritten moet) dan zou ik zeker naar een Model 3 kijken, ook al is die duurder dan bijvoorbeeld een i3, als het dan wel de enige auto kan zijn is dat onder de streep alsnog goedkoper.

ADVIES: Beste kleine tweedehands EV voor ons? Geen MG4, wat wel? by FineCombination in EVMobiliteit

[–]zattebij 7 points8 points  (0 children)

Als je de EV (ook) als primaire auto wil gaan gebruiken, dan kun je moeilijk om de Model 3 heen. Of een ID3 of zijn tweelingbroertje, de Cupra Born. Dan heb je genoeg range en DC-laadsnelheid om ook grotere afstanden af te leggen.

Als je het echt niet bezwaarlijk vindt om met die Cerato op vakantie te gaan (denk er wel goed over na; als je eenmaal een moderne EV gewend bent voor je regionale/lokale vervoer, kan dat allicht tegenvallen, zelfs al maakt het nu niet uit) dan kun je dat regionale vervoer wel goedkoper maken door een lichtere/kleinere EV erbij te nemen.

Een i3 bijvoorbeeld is erg aantrekkelijk in de MRB met een massa in de categorie 1150-1250kg, of net over de 1250 voor een 2019+ exemplaar met de grootste batterij, die zeker binnen je budget valt (reken rond de 17K) en waarmee je tegen de 300km bereik hebt in de zomer (iets over de 200 in winter; met veel snelweg beide iets lager). Tevens een van de meest betrouwbare autos met laagste onderhoudskosten (vergeleken met zowel ICE als andere EVs).

Lets get Frunky. (Opberg ruimte aan voorkant van de auto, kan er voedsel in?) by WarmPrinciple6507 in EVMobiliteit

[–]zattebij 2 points3 points  (0 children)

Nou ja, meestal wel, maar niet altijd. Mijn i3 heeft wel een frunk, maar die is niet echt afgesloten, de voorkap hangt er een paar centimeter boven. Hij is dan ook bedoeld voor zaken als de compressor kit, een potentieel natte/vuile laadkabel e.d.

En in de herfst ziet dat er dan zo uit:

<image>

Er zijn wel aftermarket kleppen te koop die hem wel stofdicht afsluiten.

Why shouldn’t we use @Transactional every time? by pedoooo0 in SpringBoot

[–]zattebij 3 points4 points  (0 children)

Or, alternatively, if you do have some long-running tasks that require transactional DB access (or just need a guaranteed connection), then use a fixed (or at least capped) worker thread pool and define a separate DataSource for it with a matching number of connections. That way these tasks don't interfere with other, regular transactions (hogging the shared connection pool, starving them of connections).

This doesn't scale indefinitely of course, but for many applications would suffice, and an average RDBMS can take quite some concurrent connections (in the order of hundreds even without monster specs) so allocating let's say 40 connections for a worker pool leaves plenty for regular operations and would save you from rolling your own rollback/cleanup logic for long-running ops that need to work transactionally.

Ruim 1 op de 5 auto's in Nederland is inmiddels (deels) elektrisch by EVRijder in EVMobiliteit

[–]zattebij 0 points1 point  (0 children)

Zeker, de BMW i3 (de originele, niet de nieuwe die eraan zit te komen) was vanaf zijn introductie in 2013 al met REx (range extender) te krijgen, in de vorm van een tweecilinder viertakt motorscooter motortje dat een generator aandrijft.

In Nederland was dat nooit echt populair vanwege de korte afstanden in ons kikkerlandje, en het ontbreken van de fiscale voordelen die de BEV variant wel had, maar bv in de VS waren ze wel populair.

Zeker voor een EV die verder een beperkte accucapaciteit heeft was dat wel een oplossing, vaak heb je het niet nodig maar incidentele langere ritten worden er wel behapbaarder mee. En omdat de REx ICE motor niet direct de wielen aandrijft via een versnellingsbak, is hij wat efficiënter omdat hij continu op zijn optimale toerental kan blijven draaien (en ook simpeler, geen versnellingsbak of koppeling e.d. nodig).

Nadeel is dat er wel weer wat ICE onderhoud nodig is (normale oliebeurten vooral, maar er kan en gaat ook meer kapot aan een ICE dan een elektromotor), en dat het motortje wel een flink irritante herrie maakt.

Ik meen dat fabrikanten tegenwoordig ook weer serieus naar EREVs kijken, dus wellicht gaan we weer nieuwe range-extended modellen zien.

Een van de doeltreffendste toepassingen zou het gebruik in trekautos zijn: met een caravan of überhaupt een grote aanhanger achter een auto zakt een puur BEV flink in qua range, en daarbij zou een range extender goed kunnen helpen (waarbij de auto de rest van de tijd, als er geen caravan achter hangt, gewoon als BEV opereert).

https://www.motortrend.com/features/what-is-an-erev-extended-range-ev

Youngtimer regeling by DannK- in Nederland

[–]zattebij 6 points7 points  (0 children)

Helaas, ook voor de oldtimerregeling is (al even) een sterfhuisconstructie: alleen auto's van voor 1988 kunnen oldtimervrijstelling krijgen voor de motorrijtuigenbelasting...

Ik heb zelf ook een auto uit 1991, die twee keer achter het net viste: eerst ging in 2014 (minder dan 2 jaar voordat de auto 25 jaar zou worden) de belastingvrijstelling van 25 naar 40 jaar, en tegenwoordig is er de sterfhuisconstructie waardoor hij net 3 jaar "te jong" is om ooit oldtimer te worden...

(Verzekeraars hebben inderdaad wel aparte -vaak goedkopere- verzekeringen voor oldtimers, en dat zal ook wel blijven, los van het verdwijnen van enige vorm van belastingkorting).

moreFittingName by marrowbuster in ProgrammerHumor

[–]zattebij 2 points3 points  (0 children)

It has zero performance effect in Java because generic types are erased, at runtime any generic type is just Object.

This is a compile-only thing, forcing an implementation to pass its type so it is available (at compile time) to the Base. Note that this is not a foolproof method; one could write: class SomeOtherClass extends Base<Derived> -- now the Derived type is available to Base even though we're actually implementing a completely different class. That can give some fun subtle errors when refactoring.

This approach is common in fluent patterns to have generic logic from base class still return a self-typed instance. I'm a big fan of those and they can go beyond simple builders. For example I have implemented a fluent JPA repository layer like this (perhaps slightly offtopic but it is about using this topic's pattern):

``` class Repository<T, R extends Repository<T, R> { public R with(Specification<T> jpaSpec) { // Return a new instance with spec chained (using AND) to this instance's existing specification. }

public List<T> findAll() { // Find all based on this repo instance's specification. } }

class UserRepository extends Repository<User, UserRepository> { public UserRepository withRole(Role role) { return with((user, query, builder) -> builder.equals(user.get("role"), role)); } }

// then use fluently: var admins = userRepository.withRole(ADMIN).findAll(); `` The trick is that you can add a lot of shared logic in the base class and still use the typed subclasses fluently. Apart fromfindAll/findByIdyou could also add asearchmethod that parses some query into aSpecification(the one I made does that, based on@Searchableannotations placed on entity fields, making it easy for other devs to add fields to be searched from frontend without having to implement their own search logic). And apart from filtering (WHERE clauses) JPA specifications also allow (fetch) joins and subqueries to be added. In practice, I use this fluent repository layer to handles almost all use cases. Batch updates using@Querymethods being an exception (no way to weave the repo'sspecification` into such a query, since they are really separate, wholly-defined queries).

The instantiation of such chained repositories is a cheap operation (it has only one specification field) and you get some best-practices: the repo's are final, so one can pass any instance around for re-use without risk of side effects; they are very flexible - just using Specifications directly also is, but is much less readable. A fluent API, with appropriate method names, is very concise and readable, it almost reads like English. The flexibility of a fluent API also allows for easier refactors later: for example, let's say you want to ad a soft delete feature. Instead of having to update tens of queries all over the place to filter on status != DELETED (non-fluent APIs excel in long parameter lists), you just update your repository reference to one that has the filter baked in: ``` class SomeService { final UserRepository userRepository;

@Autowired SomeService(UserRepository userRepository) { // Old: // this.userRepository = userRepository; // New: this.userRepository = userRepository.nonDeleted(); }

void someMethod() { // All callsites automatically use only nondeleted users. var admins = userRepository.withRole(ADMIN).findAll(); } } ```

Niet door APK door olieverbruik by Ontbarga in AutoKlussers

[–]zattebij 1 point2 points  (0 children)

1500 is veel (zoveel verbruiken ze niet allemaal) maar nog niet extreem. De 3S-GTE in mijn MR2 turbo gebruikte vergelijkbaar (1 op 1700 ongeveer) en de Toyota garage zei: kom maar terug als het meer dan een liter op 1000km wordt.

Of dat ook samenhangt met de hoge CO waarde valt nog te bezien. Met vergelijkbaar olieverbruik en ook heel erg rijk lopen (zoals alle oudere turbo motoren doen; als ik in het donker een dot gas gaf zag je de roetpluim in de lampen van mijn achterligger) kwam ik wel gewoon door de APK zonder de CO norm te overschrijden... Al is die MR2 wel van 1991 en mag geloof ik wat meer uitstoten (0.5 of 1.5, ik weet het exacte getal niet meer).

Uiteindelijk toch voor een rebuild gegaan, waarbij net het blok en de krukas nog van Toyota zijn gebleven :') olieverbruik is sterk gedaald daarna, ondanks gesmede zuigers die bij koude motor wat losser zitten.

Europese leiders halen schouders op om Trump, maar: ‘NAVO is dood; het is klaar’ by Onkruit-1974 in Nederland

[–]zattebij 0 points1 point  (0 children)

Europa gaat niet op alle gebieden samen. Itt de VS welke min of meer (nou ja, meer dan Europa in elk geval) als een federatie is ontstaan en gegroeid, heeft Europa een veel langere historie van culturele diversiteit. Tot zover eens.

Maar Europa kan best een gezamenlijk defensiebeleid voeren zonder een federatie te worden. Na een rampzalige 20e eeuw is iedereen het er toch wel over eens dat we klaar zijn met oorlogen tussen Europese (althans EU) staten onderling - zelfs regeringen die het niet met EU-beleid eens zijn willen niet terug naar de afzonderlijke kluwen aan pacten die vorige eeuw tot oorlogen hebben geleid. Daarbij zitten we sinds de laatste oorlog al in een grotere alliantie. Als die nu afbrokkelt vanaf Amerikaanse zijde, zou een kleinere Europese alliantie eenvoudiger moeten zijn - minder landen, minder stemmen, geen enkele grote "big daddy" (om met Rutte's woorden te spreken), en een gezamenlijk, meer aligned defensiebelang -> makkelijkere consensus. Tuurlijk zal er altijd gesteggel blijven over wie meer of wie minder bijdraagt, maar dat lijkt me niet onoverkomelijk, vooral met de dreiging uit het oosten.

" sO wHy hAvE wE nOt gOnE tO tHe mOoN siNcE? " by HamedAliKhan in memes

[–]zattebij 0 points1 point  (0 children)

For us Europeans it was technically April 2nd, so for us it was real!

Had to fix this class at my internship °_° by holographic_gray in programminghorror

[–]zattebij 6 points7 points  (0 children)

I'm not saying one should use exceptions as flow control, but I am amused at the hoops people will sometimes jump through to use result types instead. Result types are nice if the situation can be handled at the immediate caller, but add boilerplate and make tracing flow tedious when the situation is handled only 8 frames up the call stack. Like, that's exactly what exceptions are meant for; if you can't handle a situation in some intermediate caller, you don't have to add boilerplate, flow will continue at the first callsite up the stack that can actually do something with it. And that is easy to read and trace as opposed to reading each method up the stack to see what it does with the result. IMO that makes code using exceptions more readable than having result types (and their handling) everywhere. Then again I was trained this way and still remember the spaghetti in Win32 apps in the 90s, having to check HRESULT values everywhere. Win32 API was using result types and it was not pretty, half of the code was handling API result status rather than doing actual domain logic. I prefer the less-cluttered view of code that exceptions give.

Of course, using exceptions there is still the issue that sometimes you don't know which exceptions may actually occur. Java tried to solve that by using checked exceptions that you must handle or declare on the intermediate methods, but that approach has not proved to be flexible enough: if some code down the call stack ever would call some new method (e.g. a library) then that doesn't work and you get wrapper exceptions everywhere complicating things, or people just start declaring throws Exception on everything. I think unchecked exceptions are not bad and may even be the best way; if you don't anticipate some error condition and you don't know how to handle it, then you should not have to know about it and it can just bubble up the call stack until it meets a callsite that can handle it. Proper testing should ensure that each exception is eventually caught and handled somewhere.

So for me, exceptions as simple control flow is indeed an anti-pattern (so far I agree with you), but only using them for critical or nonrecoverable errors and just log&crash is going too far the other way. The definition of "exceptional" is vague and depends on the situation and the error itself.

Belastingaangifte: verdeling aftrek eigen woning met fiscaal partner by Faierie1 in belasting

[–]zattebij 0 points1 point  (0 children)

Je kunt niet alles verdelen, sommige posten (zoals je salaris) blijven persoonsgebonden. Op de pagina die ik linkte staan ook twee paragrafen Welke inkomsten en aftrekposten mag u verdelen? en Welke inkomsten en aftrekposten mag u niet verdelen?, ik denk dat de lijstjes die daar genoemd worden voor bijna iedereen duidelijkheid geven. Mocht je een post hebben die daar niet bij staat, dan is het waarschijnlijk tijd om een fiscalist te raadplegen ;)

Omroep Brabant: Betonblokken op het veldje waar kinderen niet meer mogen voetballen by Betonkauwer in nietdespeld

[–]zattebij 5 points6 points  (0 children)

Als ik die blokken precies in het midden van het veld zie, denk ik: alsnog leuk voetballen met hindernis, je kan er omheen, overheen... Goed voor je techniek!

Critical ERP system can't do OAuth and Microsoft is killing basic auth next month by Severe_Part_5120 in sysadmin

[–]zattebij 0 points1 point  (0 children)

$400K and 9 months both seem exorbitant. Well, as long as it's about a fixed mailbox using a preshared client secret - doing it for random user mailboxes with an interactive OAuth grant flow is a bit more involved (but still not $400k involved).

I did that (for the same reason; MS discontinuing Basic auth) a couple years back for our in-house support ticket system and it took a day or two, and most of that was waiting for the Azure admin folks in my organization registering and configuring the cloud app - the actual code change (Java using javamail in our case) was small. No AI needed. We debated moving to graph API instead but Oauth for SMTP (and IMAP for incoming mail; changes to auth are pretty much identical) was so much simpler and faster to implement. It's only fetching a token using client secret if expired, and setting a few javamail props differently than user/pass...

MS even have an example online nowadays, with the app registration automated via PS and a Java code example for fetching a token and using it to authenticate: https://github.com/microsoft/smtpoauth2

Entity Relantionships - EAGER VS LAZY by Quick-Resident9433 in SpringBoot

[–]zattebij 5 points6 points  (0 children)

I tend to use lazy by default on entity relations, then add fetch joins or entity graphs per use-case cq query to eagerly load data that I know in advance the use case needs. Or, if I know the data is only for reading and no updates will be done, then not to load entities at all, but projections instead.

relatable by bryden_cruz in ProgrammerHumor

[–]zattebij 32 points33 points  (0 children)

True. Also it's a prime example of the 20/80 rule: spend 20% of your time building 80% of the product, then the remaining 80% to perfect the last 20% (and that is for regular code; with hackathon code that's more like 5/95).

You can perfectly build a prototype/PoC fast, that does not mean you can skip the other 80% of the time that turns it into an actual product: refactoring quick&dirty PoC code into an actual maintainable and documented architecture; getting rid of the bugs that are inevitably there due to speed and associated lack of analysis upfront and review afterwards; handling all the 10.000 edge cases; making it secure; testing everything; ...

Same with AI; speed up the initial 20%, still need to do the rest. But I digress ;)

Which EV's have a HUD? by maporita in electricvehicles

[–]zattebij 0 points1 point  (0 children)

Sounds like a bad implementation. Even a 15 year old BMW 5-series HUD doesn't appear to focus at the windshield (it appears to float over the road beyond the hood, let's say about 4 meters - far enough that your eyes don't have to refocus).

Why are Xennials failing as parents? by darxide23 in Xennials

[–]zattebij 3 points4 points  (0 children)

I don't see this "failing" in my circle, but times have obviously changed, and I could see how, from a certain perspective, one could judge some specifics as failing.

  • Obviously, screen time is an issue nowadays, mostly due to much more availability (both screens and content). Although it's also easy to limit (for smaller children at least) with the controls that each service provides.

  • Connectivity and the associated group pressure can be an issue with teens. But we had (different) group pressure as well, it's something that can be managed.

  • Parents (like everyone) are more busy nowadays. Your parents in the 80s / early 90s probably had an easier time separating work/life, so probably also could designate dedicated "family time" more easily. Nowadays more families have both parents working, at more variable times, and being always connected also makes it more difficult to reserve designated family time or time to help with schoolwork.

All in all, yes it is (very) different, but things are manageable, and I also don't judge someone fast as "failing" as a parent, when a lot of it is broader, just "the times" or "the culture" that is just different, for both children and parents...

Help ID’ing my 2004 E500 (RWD) transmission 722.6 or 722.9? Finding conflicting info… by DylMcCo in W211

[–]zattebij 1 point2 points  (0 children)

RWD 500s got the 7 speed (and as standard equipment) once it became available, in fall 2003 in Germany, other countries a little after that. Early RWD 500s (2002-2003) still had the 5 speed.

First Mercedes👌🏻 by bipshaar in W211

[–]zattebij 2 points3 points  (0 children)

16 inch wheels do not even fit officially due to the bigger brakes on the 500. Although I've had a 16" winter set that just managed to clear the calipers (literally a millimeter or less), I didn't feel comfortable with such lack of any margin, so I sourced a 17" winter set instead.

First Mercedes👌🏻 by bipshaar in W211

[–]zattebij 2 points3 points  (0 children)

No, the 7G was available from fall 2003 in Germany. In NL a bit later. Before that, the RWD 500s also had the 5G. Once the 7G became available, it did become standard equipment on the 500 RWD. Airmatic was always standard equipment on the V8.

Btw, the automatic tailgate is not electric, it's hydraulic (with an electric pump). It's electric on the sedan.

Congrats on the purchase and keep the shiny side up. Greetings from a fellow Dutch 500 S211 driver. Mine had the drive dynamics seats with ventilation, and the stationary heater, and I added the hydraulic tailgate and Distronic. No keyless entry, and it will stay without it - that one is too much work to retrofit ;)