15 Matching Annotations
  1. Jun 2023
    1. it still strikes me as something people believe in the abstract, rather than know from hard experience. I've always found that if you look behind/under widely held beliefs, you can find useful gems.
    2. Python essentially doesn't have private methods, let alone protected ones, and it doesn't turn out to be that big a deal in practice.
  2. May 2023
    1. However, it's difficult to rely on a case-sensitive email address in the real world because many systems (typically ones that have to handle data merging) don't preserve case. Notably systems that use email addresses for user IDs, or any system that has to collate data from multiple sources (CRMs, email broadcast systems, etc) will either normalise case or treat them case-insensitively.
    2. However, for all practical purposes in the modern age, I believe you can consider email addresses to be case insensitive.
    1. a SHOULD is always trumped in RFCs by a MUST. The fact that hosts SHOULD do something means that they might not and I just wanted reassurance that, in reality, the SHOULD is a bit more widely adopted than its definition implies.
    1. So yes, the part before the "@" could be case-sensitive, since it is entirely under the control of the host system. In practice though, no widely used mail systems distinguish different addresses based on case.
  3. Jan 2023
  4. Nov 2022
    1. You can definitely set the Return-Path header as a sender. But yes, some receivers might rewrite it (But not always ), or depending on who you're sending through, it might be re-written by them. For instance when using MailGun to send bulk email you have to do things just right in order to set a Return-Path that will be preserved. I know this contradicts the RFC you cite, but it's in practice true.
  5. Jul 2022
    1. It really slows down your test suite accessing the disk.So yes, in principle it slows down your tests. There is a "school of testing" where developer should isolate the layer responsible for retrieving state and just set some state in memory and test functionality (as if Repository pattern). The thing is Rails is a tightly coupled with implementation logic of state retrieval on core level and prefers "school of testing" in which you couple logic with state retrial to some degree.Good example of this is how models are tested in Rails. You could just build entire test suite calling `FactoryBot.build` and never ever use `FactoryBot.create` and stub method all around and your tests will be lighting fast (like 5s to run your entire test suite). This is highly unproductive to achieve and I failed many times trying to achieve that because I was spending more time maintaining my tests then writing something productive for business.Or you can took more pragmatic route and save database record where is too difficult to just 'build' the factory (e.g. Controller tests, association tests etc)Same I would say for saving the file to the Disk. Yes you are right You could just "not save the file to disk" and save few milliseconds. But at the same time you will in future stumble upon scenarios where your tests are not passing because the file is not there (e.g. file processing validations) Is it really worth it ? I never worked on a project where saving file to a disk would slow down tests significantly enough that would be an issue (and I work for company where core business is related to file uploading) Especially now that we have SSD drives in every laptop/server it's blazing fast so at best you would save 1 seconds for entire test suite (given you call FactoryBot traits to set/store file where it make sense. Not when every time you build an object.)
  6. Feb 2022
    1. The problem almost certainly starts with the conception of what we're doing as "building websites".

      When we do so, we mindset of working on systems

      If your systems work compromises the artifacts then it's not good work

      This is part of a broader phenomenon, which is that when computers are involved with absolutely anything people seem to lose their minds good sensibilities just go out the window

      low expectations from everyone everyone is so used to excusing bad work

      sui generis medium

      violates the principle of least power

      what we should be doing when grappling with the online publishing problem—which is what this is; that's all it is—is, instead of thinking in terms of working on systems, thinking about this stuff in such a way that we never lose sight of the basics; the thing that we aspire to do when we want to put together a website is to deal in

      documents and their issuing authority

      That is, a piece of content and its name (the name is a qualified name that we recognize as valid only when the publisher has the relevant authority for that name, determined by its prefix; URLs)

      that's it that's all a Web site is

      anything else is auxiliary

      really not a lot different from what goes on when you publish a book take a manuscript through final revisions for publication and then get an ISBN issued for it

      so the problem comes from the industry

      people "building websites" like politicians doing bad work and then their constituents not holding them accountable because that's not how politics works you don't get held accountable for doing bad work

      so the thing to do is to recognize that if we're thinking about "websites" from any other position things that technical people try to steer us in the direction of like selecting a particular system and then propping it up and how to interact with a given system to convince it to do the thing we want it to do— then we're doing it wrong

      we're creating content and then giving it a name

  7. Aug 2021
    1. therefore in practice it's a bit academic to worry about which lines inside that block the compiler should be happy or unhappy about. From falsehood, anythihng follows. So the compiler is free to say "if the impossible happens, then X is an error" or "if the impossible happens, then X is not an error". Both are valid (although one might be more or less surprising to developers).
    1. when you're reading some fresh code in your browser, do you really want to stop to configure that test harness

      Running the tests should be as easy as opening something in the browser.

  8. Mar 2021