30 Matching Annotations
  1. Jan 2024
    1. Introducing relationships between issues will considerably increase the complexity of GitLab. That is not a reason not to do it. But it is a reason for us to be strategic in when we do it, and ensure we have a good design that is scalable and aligns with our other initiatives.
  2. Sep 2023
    1. When building the Droplet Console, we had a few options to support SSH keys-based authentication. The most straightforward way would be to directly allow the customer to specify a private key that is already set up for accessing the Droplet. However, there are some problems with this solution:
  3. Aug 2023
    1. Auto-update aside, you might also have found it hard to find a Chrome binary with a specific version. Google intentionally doesn’t make versioned Chrome downloads available, since users shouldn’t have to care about version numbers—they should always get updated to the latest version as soon as possible. This is great for users, but painful for developers needing to reproduce a bug report in an older Chrome version.
  4. Nov 2021
    1. Calling a software convention "pretty 90s" somewhat undermines your position. Quite a lot of well-designed software components are older than that. If something is problematic, it would be more useful to argue its faults. When someone cites age to justify change, I usually find that they're inexperienced and don't fully understand the issues or how their proposed change would impact other people.
  5. Aug 2021
  6. Jun 2021
    1. I've been thinking more about how to best do this. The preferred way might be to use the same domain and have an application load balancer like nginx split traffic on the URL path (e.g. /api). This is for two reasons. Firstly, you might not necessarily want to cookie the primary/apex domain and have the cookie shared across all subdomains. You also might not want to do CORS because preflight requests add latency and CORS adds complication.
    1. Prettier intentionally doesn’t support any kind of global configuration. This is to make sure that when a project is copied to another computer, Prettier’s behavior stays the same. Otherwise, Prettier wouldn’t be able to guarantee that everybody in a team gets the same consistent results.
  7. Apr 2021
    1. “Who cares? Let’s just go with the style-guide” — to which my response is that caring about the details is in the heart of much of our doings. Yes, this is not a major issue; def self.method is not even a code smell. Actually, that whole debate is on the verge of being incidental. Yet the learning process and the gained knowledge involved in understanding each choice is alone worth the discussion. Furthermore, I believe that the class << self notation echoes a better, more stable understanding of Ruby and Object Orientation in Ruby. Lastly, remember that style-guides may change or be altered (carefully, though!).
  8. Feb 2021
    1. provide interfaces so you don’t have to think about them

      Question to myself: Is not having to think about it actually a good goal to have? Is it at odds with making intentional/well-considered decisions?  Obviously there are still many of interesting decisions to make even when using a framework that provides conventions and standardization and makes some decisions for you...

    1. Consequently, you act irresponsibly when you adopt any programming practice simply because "that's the way you're supposed to do things."
    2. My point is that you should not program blindly. You must understand the havoc a feature or idiom can wreak. In doing so, you're in a much better position to decide whether you should use that feature or idiom. Your choices should be both informed and pragmatic.
    1. Trust me, I thought a lot about #validate and its semantics, and I am gonna make it even more "SRP" by making Form#errors and #valid? semi-public. All that happens via #validate reducing the possible wrong usage for users.
    1. I use <b>s for the decorative portions of the layout because they’re purely decorative elements. There’s no content to strongly emphasize or to boldface, and semantically a <b> isn’t any better or worse than a <span>. It’s just a hook on which to hang some visual effects. And it’s shorter, so it minimizes page bloat (not that a few characters will make all that much of a difference). More to the point, the <b>’s complete lack of semantic meaning instantly flags it in the markup as being intentionally non-semantic. It is, in that meta sense, self-documenting.
  9. Jan 2021
  10. Dec 2020
    1. Some of these are absent-by-design
    2. Like most frameworks that abstract the DOM, Svelte has incompatibilities like the inability to name a prop class because it’s a reserved keyword in JS, and you’ll use on:click not onclick, but these quirks are few in number and reflect carefully chosen tradeoffs. Svelte does its best to harmonize with the web platform, welcoming both experienced developers and newcomers with whatever web knowledge they have.
  11. Nov 2020
    1. I think a casual look at the game could be quick to take fault that some moves are scripted, and perhaps they are.  If play passes to you and there is a stock to be had for free…why _not_ take it? For me, it’s a distraction. The player before you likely considered the options and found the game state to be worth tempting you with that. Those free, or even cheap, stocks won’t gain you the influence in any companies that can make your personal cache more valuable.
  12. Oct 2020
  13. Sep 2020
  14. May 2020