45 Matching Annotations
  1. Jan 2024
    1. 4) Don’t make people log in to unsubscribe.Your subscriber is already overwhelmed by his inbox. He probably spends about 28% of his workday just managing email, according to a McKinsey Global Institute report. So don’t make it any harder by forcing him to log into an account he probably doesn’t remember creating before he can unsubscribe.
  2. Nov 2023
    1. One more example of a simple approach to this that might help a lot too is add a PORO generator. It could be incredibly basic - rails g poro MyClass yields class MyClass end But by doing that and landing the file in the app/models directory, it would make it clear that was the intended location instead of lib.
    2. So then they put it into lib only to find that they have to manually require it. Then later realize that this also means they now have to reboot their server any time they change the file (after a painfully long debugging time of "why what aren't my changes working?", because their lib folder classes are now second-class citizens). Then they go down the rabbit hole of adding lib to the autoload paths, which burns them because rake tasks then all get eager loaded in production. Then they inevitably realize anything inside app is autoloaded and make an app/lib per Xavier's advice.
    3. I think the symmetry of the naming between lib and app/lib will lead a fresh Rails developer to seek out the answer to “Why are there two lib directories?", and they will become illuminated. And it will prevent them from seeking the answer to “How do I autoload lib?” which will start them on a rough path that leads to me advising them to undo it.
  3. Mar 2023
    1. We now take an opinionated stance on which second factor you should set up first – you'll no longer be asked to choose between SMS or setting up an authenticator app (known as TOTP), and instead see the TOTP setup screen immediately when first setting up 2FA.
  4. Dec 2022
    1. Here are some recommended unsubscribe methods: Include a prominent link in the message that takes recipients to a page for unsubscribing. Let recipients review the individual mailing lists they’re subscribed to. Let them unsubscribe from lists individually, or all lists at once. Automatically unsubscribe recipients who have multiple bounced messages. Periodically send a confirmation message to recipients to make sure they still want to get your messages.
    2. Let recipients easily unsubscribe Always give recipients a way to unsubscribe from your messages. Make unsubscribing easy. Letting people opt out of your messages can improve message open rates, click-through rates, and sending efficiency.
    3. Make sure recipients can easily subscribe
    1. Many mail systems allow recipients to report mail as spam or junk, and mail streams from senders whose mail is often reported as junk tend to have poor deliverability. Hence, the mailers want to make it as easy as possible for recipients to unsubscribe; if an unsubscription process is too difficult, the recipient's alternative is to report mail from the sender as junk until the mail no longer appears in the recipient's inbox.
    1. Let’s say the recipient is considering unsubscribing. He or she may be too busy to search through the email to find the unsubscribe link, so he or she just clicks “Report as SPAM” to stop the emails from coming. This is the last thing any marketer wants to see happen. It negatively impacts sender reputation, requiring extra work to improve email deliverability. With the list-unsubscribe header, you will avoid getting into this kind of trouble in the first place.
  5. Nov 2022
  6. Sep 2021
    1. The question is similar but its in a Rails context. The solutions would answer my question, but I'm almost certain that he could probably leverage Arel to solve his problem. The question I posted was designed purely as a Ruby question so that it was easier to search for. You might want to suggest an edit of the title of his question because it didn't show up when I searched for a solution to my problem.
  7. Aug 2021
    1. Now consider we want to handle numbers in our known value set: const KNOWN_VALUES = Object.freeze(['a', 'b', 'c', 1, 2, 3]) function isKnownValue(input?: string | number) { return typeof(input) === 'string' && KNOWN_VALUES.includes(input) } Uh oh! This TypeScript compiles without errors, but it's not correct. Where as our original "naive" approach would have worked just fine. Why is that? Where is the breakdown here? It's because TypeScript's type system got in the way of the developer's initial intent. It caused us to change our code from what we intended to what it allowed. It was never the developer's intention to check that input was a string and a known value; the developer simply wanted to check whether input was a known value - but wasn't permitted to do so.
  8. Jul 2021
  9. test-prof.evilmartians.io test-prof.evilmartians.io
    1. That's it! Just replace let! with let_it_be. That's equal to the before_all approach but requires less refactoring.
    2. That technique works pretty good but requires us to use instance variables and define everything at once. Thus it's not easy to refactor existing tests which use let/let! instead.
  10. Jun 2021
    1. I've seen (and fixed) Ruby code that needed to be refactored for the client objects to use the accessor rather than the underlying mechanism, even though instance variables aren't directly visible. The underlying mechanism isn't always an instance variable - it can be delegations to or manipulations of a class you're hiding behind a facade, or a session store with a particular format, or all kinds. And it can change. 'Self-encapsulation' can help if you need to swap a technology, a library, an object specification, etc.
    2. Also, Sandi Metz mentions this in POODR. As I recall, she also advocates wrapping bare instance variables in methods, even when they're only used internally. It helps avoid mad refactoring later.
    3. But sure, go ahead and enforce self-encapsulation if you like; it makes it easier to do memoization or whatever later on.
  11. Mar 2021
    1. The number one problem that I see developers have when practicing test-first development that impedes them from refactoring their code is that they over-specify behavior in their tests. This leads developers to write more tests than are needed, which can become a burden when refactoring code.
    1. Unfortunately, given how widely used concat_javascript_sources is, this required changing a lot of tests. It would be nice if we could remove some of the duplication in these tests (so that similar changes would not require updating this many tests), but that can come in another PR.
  12. Feb 2021
    1. Yes, you do face difficult choices (moral) but you don't care about it. All you care are the reputation bars. So... Let's kill this guy, who cares if he is innocent, but this faction needs it or I'm dead. Sounds great on paper but to be honest... you just sit there and do whatever for these reputation bars. If you won't, then you lose
  13. Jan 2021
    1. We informed and documented. We made it easy for you to understand the problem and also to take action if you disagreed. I hope you didn’t read https://linuxmint-user-guide.readthedocs.io/en/latest/snap.html#how-to-install-the-snap-store-in-linux-mint-20. I can’t understand how it could be simpler.
    2. Is it harder to enable it in Mint than it is to disable it in Ubuntu? Not at all. Is how to enable it better documented in Mint than how to disable it in Ubuntu? Absolutely: https://linuxmint-user-guide.readthedocs.io/en/latest/snap.html.
  14. Dec 2020
    1. No more waiting around for pull requests to be merged and published. No more forking repos just to fix that one tiny thing preventing your app from working.

      This could be both good and bad.

      potential downside: If people only fix things locally, then they may be less inclined/likely to actually/also submit a merge request, and therefore it may be less likely that this actually (ever) gets fixed upstream. Which is kind of ironic, considering the stated goal "No more waiting around for pull requests to be merged and published." But if this obviates the need to create a pull request (does it), then this could backfire / work against that goal.

      Requiring someone to fork a repo and push up a fix commit -- although a little extra work compared to just fixing locally -- is actually a good thing overall, for the community/ecosystem.

      Ah, good, I see they touched on some of these points in the sections:

      • Benefits of patching over forking
      • When to fork instead
  15. Nov 2020
  16. Oct 2020
    1. Furthermore, JSX encourages bad non-dry code. Having seen a lot of JSX over the past few months, its encourages copypasta coding.
    2. hyperscript is much simpler to refactor and DRY up your code than with JSX, because, being vanilla javascript, its easier to work with variable assignment, loops and conditionals.
  17. Sep 2020
    1. When a component reaches such a size that this becomes a problem, the obvious course of action is to refactor it into multiple components. But the refactoring is complex for the same reason: extracting the styles that relate to a particular piece of markup is an error-prone manual process, where the relevant styles may be interleaved with irrelevant ones.
  18. Jul 2020
  19. Jun 2020
    1. OK, so what about regular messages? Turns out they are not encrypted after all. Where Signal implements the security and privacy protocols right from the start, Telegram separates the two and offers an additional option. The problem is that not everyone is aware of the Secret Chat option and first-time users may send sensitive information in the regular chat window unknowingly.
  20. May 2020
    1. The "'strict-dynamic'" source expression aims to make Content Security Policy simpler to deploy for existing applications who have a high degree of confidence in the scripts they load directly, but low confidence in their ability to provide a reasonable list of resources to load up front.
  21. Apr 2020
  22. Mar 2020
    1. Earlier this year it began asking Europeans for consent to processing their selfies for facial recognition purposes — a highly controversial technology that regulatory intervention in the region had previously blocked. Yet now, as a consequence of Facebook’s confidence in crafting manipulative consent flows, it’s essentially figured out a way to circumvent EU citizens’ fundamental rights — by socially engineering Europeans to override their own best interests.
    1. The business had a policy that you should report safety incidents when you see them. The process around that was you fill out a form and fax it to a number and someone will take action on it. The safety manager in this company saw that and decided to digitize this workflow and optimize it. Once this process was put into place, the number of safety incidents reported increased 5 times. The speed at which safety incidents were addressed increased by 60%.
  23. Nov 2019