• 43 Posts
  • 107 Comments
Joined 1 year ago
cake
Cake day: July 29th, 2023

help-circle


  • You just referenced two languages that don’t have proper sum types. lol.

    You’re complained about “Proper HTTP implementations in proper languages”.

    I provided two concrete examples of two of the most popular and production-grade programming language ever developed.

    I can provide more.

    You then tried to weasel out by moving your goal post from “Proper HTTP implementations in proper languages” to “languages that don’t have proper sum types”.

    I won’t waste more of my time with you. Whatever you’re posting lacks relevance and does not justify any attention from anyone.


  • I would only recommend a monorepo if you’re a company with at least 5,000+ engineers and can dedicate significant time to internal infra.

    It’s funny because at least one FANG does not use monorepos and has no problem with them, in spite of being at the same scale or even perhaps larger than Facebook.

    I wonder why anyone would feel compelled to suggest adopting a monorepo in a setting that makes them far harder to use and maintain.



  • I’m inclined to interpret monorepos as an anti-pattern intended to mask away fundamental problems in the way an organization structures it’s releases and dependency management.

    It all boils down to being an artificial versioning constraint at the expense of autonomy and developer experience.

    Huge multinationals don’t have a problem in organizing all their projects as independent (and sometimes multiple) source code repositories per project. What’s wrong with these small one-bus software shops that fail to do that when they operate at a scale that’s orders of magnitude smaller?


  • Proper HTTP implementations in proper languages utilize header-name enums for strict checking/matching (…)

    I don’t know what you are talking about.

    Java provides java.lang.Object.HttpHeaders, which is a constants class that provides static final String fields for the popular request and response headers.

    .NET does the exact same thing with it’s class Microsoft.Net.Http.Headers.HeaderNames.

    I can go on and on.



  • Also, TIL that the IETF deprecated the X- prefix more than 10 years ago. Seems like that one didn’t pan out.

    Can you elaborate on that? The X- prefix is supposedly only a recommendation, and intended to be used in non-standard, custom, ah-hoc request headers to avoid naming conflicts.

    Taken from https://datatracker.ietf.org/doc/html/rfc6648

    In short, although in theory the “X-” convention was a good way to avoid collisions (and attendant interoperability problems) between standardized parameters and unstandardized parameters, in practice the benefits have been outweighed by the costs associated with the leakage of unstandardized parameters into the standards space.

    I still work on software that extendively uses X- headers.















  • the whole point of agile is to be short term

    Not really. The whole point of Agile is to iterate. This means short development cycles which include review and design rounds to adapt to changes that can and will surface throughout the project. The whole point of Agile is to eliminate problems caused by business, project, and technical goals not changing because planning is rigid and can’t accommodate any changes because the process does not have room for those.

    This is why this whole “things need to be planned” crowd are simply talking out of ignorance. Agile requires global planning, but on top of this supports design reviews along the way to be able to face changing needs. This requires planning in short-medium-long terms.

    Don’t blame Agile for your inability to plan. No one forces you not to plan ahead.


  • The primary problem is using agile all the time instead of when it is actually intended to be used: short term work that needs to be done quickly by a small team that are all on the same page already.

    I think you got it entirely backwards.

    The whole point of Agile is being able to avoid the “big design up front” approach that kills so many projects, and instead go through multiple design and implementation rounds to adapt your work to the end goal based on what lessons you’re picking up along the way.

    The whole point is improving the ability to deliver within long term projects. Hence the need to iterate and to adapt. None of these issues pose a challenge in short term work.