zomgwat's comments

Sure. And that’s positive in the context of this thread.

I don’t see it as too dogmatic. I see it as taking the ambiguity out of the decision whether to squash or not. Just always squash into master. There are plenty of options to make creating PRs more lightweight.

Another nice thing with squashing is that merges into master always look the same regardless of individual engineer workflows.

My guess is that the difference is the tax on a annual Pro subscription.

As of PostgreSQL 12, whether the optimization fence is used or not is controlled with MATERIALIZED and NOT MATERIALIZED.

Agreed. I just tried out the Dash hot key and it’s basically the same. I’m tempted to claim the Alfred integration is better but that’s probably just me being a user of Alfred.

For me, the combination of Dash and Alfred is the productivity boost. Alfred makes it very easy to search documentation in Dash. You can have unique keywords in Alfred to target specific packages in Dash. For example, “guava: ImmutableList” or “sidekiq: Client”. I find it especially useful with Dash on a secondary monitor while the editor is on the primary so that both are visible at the same time.

SSHing from one remote server to another won’t be possible in a lot of environments due to network segmentation. For example, it shouldn’t be possible to hop from one host to another via SSH in a prod network supporting a SaaS service. Network access controls in that type of environment should limit network access to only what’s needed for the services to run.

Several things helped her accept the situation.

1. We regularly share photos through private photo albums. This allows her the same exposure to photos of the grandchildren as social media would.

2. We made it clear she's free to share photos with people via direct text messages. It adds a bit of friction and keeps the photos relatively private.

3. Explained that it's the right of our children to control their presence online (with some parental assistance). They aren't old enough to do that so until then, please don't share.

4. Emphasize many times that it's about protecting and empowering our kids. It's not about preventing her from showing off her grandchildren.

My wife and I have done similar. We privately share photos. It took a bit for my mom to get over the fact that she can’t post pictures of her grandkids on Facebook but I was eventually able to explain why in terms she understood.

Check out OneNote. Its shared notebooks should scale to 25-50 users. At a past employer, we used OneNote successfully at that scale instead of a wiki type solution. OneNote has a decent Mac app so it works in environments with both Windows and Macs.

My biggest gripe is the lack of native code block support. There are ok workarounds but something native would be better.

Edit:

> By law we are not allowed to use a cloud solution.

Missed this on my first read. Shared notebooks should be able to be stored wherever you store things in your network.

Exactly this. I also don’t ask permission because I consider this type of refactoring an implicit and fundamental responsibility.

Ha. Nope.

It sounds like we've had very similar experiences. The fact that what you've described is so similar to what I've seen may say something. There are reasons to have a bespoke billing system but people should try REALLY hard to avoid the situation.

Something I saw regularly with one-off style sales deals was not accounting for the collateral damage to business processes like end-of-month accounting. It's not just the development costs for adding support to things like subscriptions. Changes ripple all the way through the business. Updates to the bespoke billing system (and related business processes) end up half-baked because they aren't a core part of the business. I've seen sales deals end up as a net loss over time due to the increased labor costs on the backend. Having some reasonable constraints that an off-the-shelf product will intrinsically enforce can prevent a lot of pain for all involved.

After spending years maintaining a home grown billing system, I recommend against rolling your own. It's frustrating to spend time adding yet another hack to account for some new use case while there is a stack of other priorities waiting (that more directly impact the value of the business). I learned through experience that billing systems are complex and the complexity can sneak up on you over time.

Default deny egress is an important step in limiting impact. It can be tough though.

Regarding Sorbet and Rails, I recommend Tapioca [1].

The Rails app that I worked on had a few edge cases Tapioca didn't cover so I wrote a simple script to load the Rails app and generate RBI files (e.g. generate RBI definitions for fixture methods in ApplicationTestCase). The Tapioca codebase helped provide a path for that [2]. Tapioca also continues to add to their DSL compilers. The work to integrate Sorbet paid off very quickly.

Also, T::Enum and T::Struct are handy in any Ruby codebase.

[1] https://github.com/Shopify/tapioca [2] https://github.com/Shopify/tapioca/tree/main/lib/tapioca/com...

My experience with Tailwind + ViewComponent has been great as well. I've also had a lot of success with adding Sorbet typing to the view components. I often use Sorbet enums as view component options. The extra type safety in the view layer is very helpful.

This has been my experience using Sorbet.

I sometimes get annoyed when I get stuck screwing around with the RBI files. Then I get in the flow and remember how fast Sorbet allows me to move.

I've gotten a lot of value from integrating Sorbet into a non-trival 15 year old Rails app. The gradual nature of the typing is very nice.

I've never written TypeScript but I suspect the tooling around Sorbet is pretty far behind at this point but it's still worth it. For example, there are is a whole class of unit tests that no longer need to be written. In addition to the gradual typing, having access to interfaces, typed structs and enums is all nice too.

I understand your point. I'd expect the old version to have been reviewed when it was introduced into the system just as the new version should be. Of course, that doesn't guarantee something won't slip in.

Running private package infrastructure with audited dependencies isn't a panacea to stopping supply chain attacks. I do believe it's an effective defense-in-depth tactic for the reasons others have discussed.

An additional supporting tactic that should be done is to tightly control egress traffic. Like ingress traffic, all egress traffic should be denied by default. From there, traffic should be whitelisted. That makes it more difficult to exfiltrate data or communicate with command and control infrastructure. Tight control on egress traffic also makes it easier to alert on unexpected connection attempts. That all said, locking down egress traffic can be a pain. It also isn't a panacea. Where there’s a will there’s a way.