• 1 Post
  • 108 Comments
Joined 1 year ago
cake
Cake day: June 20th, 2023

help-circle


  • Unrelated to the article itself but I initially clicked on mobile and was presented with this clearly GDPR-violating prompt:

    Tracking consent prompt with only an "Accept all" button

    Where’s the button to reject tracking? It doesn’t exist.

    For reference this is the correct prompt on admiral’s own website:

    Tracking consent prompt with a "Reject all" button next to "Accept all"

    First time I see GDPR violation this brazen. While writing this comment I finally figured out how to reject consent (clicking on “Purposes” and manually deselecting each purpose).

    I double checked with remote debugging, the button is not just hidden in CSS; it’s missing entirely:

    HTML source showing no reject all button

    For some reason I don’t get a consent prompt at all from my desktop even on a brand new firefox profile – perhaps because of my user-agent?

    Anyways I felt motivated today so I’ve sent an email to their Data Protection Officer and set a reminder for next month in case they ghost me.


  • Yeah as I expected you’re projecting right wing talking points on what I said and answering those instead of anything I -at the very least- meant.

    I just do not think that, in a frictionless vacuum, one can completely dismiss the idea that there can be some, however microscopic and inconsequential downsides to immigration (through no individual fault in the vast majority of the population).

    Do consider that at the very least if Europe hypothetically did away with border checks entirely and strived for massive immigration, the ensuing brain drain would wreak havoc on the Global South (even worse than right now, kinda like happened within the EU with the former eastern block). Regardless of the exact mechanism, mass migration has long-lasting sociocultural impacts and to say these are only positive is pure globalist ideology.


  • You gloss over the part where even with the best intentions imaginable European immigration would have killed 90 % of American Natives with their new pathogens. No matter which way you slice it that is a scenario where European culture becomes the dominant culture, though it would certainly be nice not to have overt genocide and oppression sprinkled on top.

    (Of course that’s not the case right now and the great replacement theory is a fascist invention, if that needs saying)

    Also be careful not to infantilise immigrants. There is a marginal but highly visible issue happening for example where Saudi Arabia is funding Wahhabit (i.e. highly orthodox) mosques and imams in Europe that when combined with depressed socioeconomic opportunities fuels religious antagonism/radicalism particularly amongst particularly vulnerable teenage second generation immigrants. Is it an existential threat to European hegemony or something Europe is incapable of absorbing? Certainly not. Doesn’t mean it’s an issue we have to refuse to acknowledge in the name of our own leftist orthodoxy.



  • You’re describing proper incident response but I fail to see what that has to do with the status page. They have core metrics that they could display on that status page without a human being involved.

    IMO a customer-friendly status page would automatically display elevated error rates as “suspected outage” or whatever. Then management can add more detail and/or say “confirmed outage”. In fact that’s how the reddit status page works (or at least used to work), it even shows little graphs with error rates and processing backlogs.

    There are reasons why these automated systems don’t exist, but none of these reasons align with user interests.



  • I looked into it after this year’s massive price hike… There’s no meaningful alternative. We’re on the FOSS version of GitLab now (GitLab-CE), but the lack of code ownership / multiple reviewers / etc. is a real pain and poses problems with accountability.

    Honestly there are not that many features in Gitlab EE that are truly necessary for a corporate environment, so a GitLab-CE fork may be able to set itself apart by providing those. To me there are two hurdles:

    • Legal uncertainties (do we need a clean room implementation to make sure Gitlab Inc doesn’t sue for re-implementing the EE-only features into a Gitlab fork?)
    • The enormous complexity of the GitLab codebase will make any fork, to put it mildly, a major PITA to maintain. 2,264 people work for GitLab FFS (with hundreds in dev/ops), it’s indecent.

    Honestly I think I’d be happy if forgejo supported gitlab-runner, that seems like a much more reasonable ask given the clean interface between runner and server. Maybe I should experiment with that…


  • All of this has already been implemented for over a hundred years for other trades. Us software people have generally escaped this conversation, but I think we’ll have to have it at some point. It doesn’t have to be heavy-handed government regulation; a self-governed trades association may well aim to set the bar for licensing requirements and industry standards. This doesn’t make it illegal to write code however you want, but it does set higher quality expectations and slightly lowers the bar for proving negligence on a company’s part.

    There should be a ISO-whateverthefuck or DIN-thisorother that every developer would know to point to when the software deployment process looks as bad as CrowdStrike’s. Instead we’re happy to shrug and move on when management doesn’t even understand what a CI is or why it should get prioritized. In other trades the follow-up for management would be a CYA email that clearly outlines the risk and standards noncompliance and sets a line in the sand liability-wise. That doesn’t sound particularly outlandish to me.


  • But a company that hires carpenters to build a roof will be held liable if that roof collapses on the first snow storm. Plumbers and electricians must be accredited AFAIK, have the final word on what is good enough by their standards, and signing off on shoddy work exposes them to criminal negligence lawsuits.

    Some software truly has no stakes (e.g. a free mp3 converter), but even boring office productivity tools can be more critical than my colleagues sometimes seem to think. Sure, we work on boring office productivity tools, but hospitals buy those tools and unreliable software means measurably worse health outcomes for the patients.

    Engineers signing off on all software is an extreme end of the spectrum, but there are a whole lot of options between that and the current free-for-all where customers have no way to know if the product they’re buying is following industry standard practices, or if the deployment process is “Dave receives a USB from Paula and connects to the FTP using a 15 year-old version of FileZilla and a post-it note with the credentials”.


  • Oh I was talking in the context of my specialty, software engineering. The main difference between an engineer and an operator is that one designs processes while the other executes on those processes. Negligence/malice aside the operator is never to blame.

    If the dev is “the guy who presses the ‘go live’ button” then he’s an operator. But what is generally being discussed is all the engineering (or lack thereof) around that “go live” button.

    As a software engineer I get queasy when it is conceivable that a noncritical component reaches production without the build artifact being thoroughly tested (with CI tests AND real usage in lower environments).
    The fact that CrowdWorks even had a button that could push a DOA update on such a highly critical component points to their processes being so out of the industry standards that no software engineer would have signed off on anything… If software engineers actually had the same accountability as Civil Engineers. If a bridge gets built outside the specifications of the Civil Engineer who signed off on the plans, and that bridge crumbles, someone is getting their tits sued off. Yet there is no equivalent accountability in Software Engineering (except perhaps in super safety-critical stuff like automotive/medical/aerospace/defense applications, and even there I think we’d be surprised).


  • I strongly believe in no-blame mindsets, but “blame” is not the same as “consequences” and lack of consequences is definitely the biggest driver of corporate apathy. Every incident should trigger a review of systemic and process failures, but in my experience corporate leadership either sucks at this, does not care, or will bury suggestions that involve spending man-hours on a complex solution if the problem lies in that “low likelihood, big impact” corner.
    Because likely when the problem happens (again) they’ll be able to sweep it under the rug (again) or will have moved on to greener pastures.

    What the author of the article suggests is actually a potential fix; if developers (in a broad sense of the word and including POs and such) were accountable (both responsible and empowered) then they would have the power to say No to shortsighted management decisions (and/or deflect the blame in a way that would actually stick to whoever went against an engineer’s recommendation).



  • azertyfun@sh.itjust.workstoProgrammer Humor@programming.dev<br>
    link
    fedilink
    arrow-up
    19
    arrow-down
    1
    ·
    2 months ago

    > Clicks on <br>
    > Example is <br />


    The actual thing that matters is that the / is ignored so (unlike with XML I believe) you can’t self-close a non-void element by adding a trailing /. But “void elements should not have trailing slashes” is extrapolation on your part; the trailing slash improves readability and is kosher since it doesn’t act as a self-close.


  • There are good sides to DST, such as coming home “earlier” (by the sun clock but not by the social clock) from school or work and therefore having more hours of daylight during the free time after work. These positive effects may go beyond subjective feelings. A study has shown for example that activity increases with longer evening daylight (Goodman et al., 2014) – albeit with small biological effect sizes (≈6% difference in the daily activity between the Standard Time of the year and DST, adjusted for photoperiod). Interestingly these results of the above study were culture-specific: a significant increase was mainly observed in Europe and to some extent in Australia, while no significant effects or even slightly negative effects were seen in the United States and Brazil.

    Fucking duh. This is the sticking point for me, and I am disappointed that the article doesn’t mention the effect of latitude here. Very easy for muricans to say “DST is not useful” when these fuckers never get pitch-black night before 6pm or full daylight before 6am ST.

    Brussels is on the same latitude as Calgary. ST robs every office worker of one hour of useful daylight. That’s it. That’s the whole argument for permanent DST. Businesses will not change their opening hours, so permanent ST means a net loss of one active hour in the day for every office worker. Permanent DST in Europe means someone working 9-6 would not have to drive home at night for 4 months of the year and could maybe even take the dog for a walk in the evening sun.


  • The kind of farming that makes any money isn’t slow work.

    It is, however, tangible work with tangible results. Unlike spending months changing the polarity of nanoscopic silicon structure for the non-appreciation of an utterly clueless salesperson whose braindead ideas will have left the world in a worse state than you found it despite anyone’s best efforts.

    I should seriously get into woodworking. Kidding. Sorta.



  • azertyfun@sh.itjust.workstoProgrammer Humor@lemmy.mlBeing Agile
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    3 months ago

    What kind of non-agile bottom-up software projects have you experienced? Bottom-up waterfall? I guess it’s possible in theory but that would be a sight to behold.

    My only point is that in most situations, upper management are fools that should be left to their devices and should never get a say in development methodologies. By definition if upper management imposes Scrum, it’s a self-defeating prophecy.

    Waterfall Agile Scrum
    Top-down Can be great (esp. with rigid requirements like fintech, for safety-critical systems, or integration with traditional engineering processes with rigid schedules and feature sets) but will probably be more expensive Bad managers trying to make-up for their own lack of foresight Can’t exist (but some companies pretend very hard)
    Bottom-up Probably can’t exist (but I haven’t seen anyone try) Yes Yes

    Your average tech company should be somewhere in the bottom-right, but bad managers are trying to pull the needle upwards to justify their existence or make up for their incompetence. But they still call that “Agile” (which can be true by some definitions of the word) or “Scrum” (which that isn’t, by definition).


  • Good software does not come out of companies without a bottom-up approach to software development. Top-down approaches are either terrible or extremely expensive.

    Agile development is something that at my company we fought for, not against. It’s literally impossible to fight against actual agile development since it has to come from the workers. Agile is not scrum, and neither are a collection of ceremonies. It’s just a framework to give agency to developers.