• 0 Posts
  • 71 Comments
Joined 2 years ago
cake
Cake day: June 13th, 2023

help-circle

  • I’ve worked at several places that didn’t have formatters when I started. they did by the time I left. you can incrementally adopt them and if it’s automated most people at worst don’t care. advocate for things you want

    reassignment and hoisting are the significant ones. behavior around this does just seem more intuitive than otherwise when it comes up, so I think telling especially new devs to use const arrow fn everywhere but classes is a reasonable rule

    hate to break it to you but it behaves like a variable either way. function just behaves closer to a var variable. const fns are less like variables since no assignment. intellisense/devtools all show them just fine. it really is just a minor aesthetic difference on the definition




  • semicolons? quotes? use a formatter and don’t think about it. I think js world has basically done this already.

    const is simpler. why would I declare an array as let if I’m not reassigning? someone can look at it and know they don’t have to think about reassignment of the reference, just normal mutation. ts has the further readonly to describe the other type of mutation, don’t abuse let to mean that.

    const arrow over named function? gets rid of all the legacy behaviors and apis. no arguments, consistent this, and no hoisting or accidental reassignment. the 2 places you should ever use named fn are generator or if you actually need this



  • most things should have an alternate implementation, just in the unit tests. imo that’s the main justification for most of SOLID.

    but also I’ve noticed that being explicit about your interfaces does produce better thought out code. if you program to an interface and limit your assumptions about implementation, you’ll end up with easier to reason about code.

    the other chunk is consistency is the most important thing in a large codebase. some of these rules are followed too closely in areas, but if I’m working my way through an unfamiliar area of the code, I can assume that it is structured based on the corporate conventions.

    I’m not really an oop guy, but in an oop language I write pretty standard SOLID style code. in rust a lot of idiomatic code does follow SOLID, but the patterns are different. writing traits for everything instead of interfaces isn’t any different but is pretty common










  • I have a GL.iNet GL-MT6000, works great. not sure about newer models but people generally seem to like their higher end ones

    it ships with almost vanilla openwrt, and it’s easy to install an upstream build if you’d like. the big advantage of GL.iNet is that it’s officially supported, so I’ve been able to send emails to support about openwrt stuff and they’ve been helpful

    AdGuard works great and is built in to their version, so you wouldn’t even need the separate device for pihole

    I also like supporting a company that supports oss software


  • NixOS, plasma rn but sometimes jump to sway. I’d say distro is more relevant. for the most part I just have an editor and a browser open, DE doesn’t change much about my workflow. NixOS definitely does though

    chosen by my team, company at large doesn’t care but it’s nice for everyone to be on something consistent. company devices

    NixOS is a nice balance of the two

    I generally just copy my personal setup, which I’ve spent a decent amount of time on, but because I enjoy it

    not particularly, but nix supports all of the big ones

    language and stack a little bit, it’s all stuff that has good integration with nix. we deploy nix containers and then have consistent environment everywhere without having to work in a container. my team is a pretty standard team maintaining some full stack web stuff




  • I’m saying we weren’t taught when react was the way people wrote sites. if I was writing a site with pure html, css is great, especially modern css.

    but if I’m already using react and their abstractions, opinions on that part aside, I’d personally rather lean on the react component as the unit of reuse. tailwind removes the abstraction that you don’t need, since many people in react tend towards one scoped css file per component with classes for each element anyway

    at this point I’d be more inclined to say for many sites the api and data fetching things are the content and html+css is presentation. csszengarden is cool but I haven’t seen the html/css split help an end user, or really even me as a developer.