zomgwat

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.

Security mailing lists. GitHub has security alerts. Good old fashioned RSS. For example, rubygems.org supports RSS for releases. GitHub Release pages also support RSS. An easy way to create a shared RSS feeds is to create a #news channel in Slack that has all the feeds.

It can be a pain but that pain might be motivation to not pull in dependencies with little thought.

Another option is to use a cloud storage service that supports fine grained access control (e.g. write-only vs read-only) and retention polices.

How does traffic reach or leave the machine if a network level firewall is restricting access? It seems I have a fundamental misunderstanding of something.

If I understand correctly, the attack can be mitigated with the appropriate level of firewall rules. Both ingress and egress traffic should be blocked by default and selectively allowed based on need. In this case, DHCP traffic would only be allowed to 169.254.169.254.

You still have somebody in your network though, so there's that.

I've actually been experimenting with something similar to what adrianpike describes. Basecamp is home to all higher level product/business stuff. In part, that's because everyone in the business has access to Basecamp and uses it on a daily basis.

Concrete development work gets put into GitHub Issues. Most people on the business side don't have access to GitHub and wouldn't be comfortable with it. Smaller stuff may not get a GitHub Issue. It may just live in Basecamp. Technical stuff that the business will never care to see may only live in GitHub.

It's a new process I'm experimenting with. We'll see if it ends up being too disjointed.

I use the Peloton app with my Keiser M3i. I bought the Keiser because I believe it to be a better product. I also didn't want to be bound to both Peloton hardware and software. I had the Keiser for years prior to subscribing to Peloton. I just made up my own workouts. Ultimately, it's easier to just pick a class and do whatever the instructor tells me to. Overall, I'm happy with the decision. I can be a competitive person so I miss the leaderboard stuff at times but not enough to regret my choice.

In practice, it took me a few workouts to translate the resistant callouts from the Peloton to the Keiser. Also, some instructors are better than others about repeatedly calling out cadence and resistance. You can get lost in the workout if the instructor doesn't call them out enough.

Security is another factor in choosing not to use a database for things like queues. I like to keep access to the database as tight as possible. I don’t want to start dishing out network and account access to services just because they need a queue or a distributed lock. I could run a separate database instance but that’s worse than just running Redis.

I agree. I’ll also add that Redis is a level easier to operate than RabbitMQ.

Duo is another option for a nice OpenVPN MFA option.

https://duo.com/docs/openvpn

On the spectrum you've described, I'm progressively shifting from Uncle Bob's end to Carmack's the further I get into my career. I think of it as code density. I've found that high density code is often easier to grok because there's less ceremony to keep in my head (e.g. many long method names that may or may not be named well, jumping around a bunch of files). Of course, there's a point at which code becomes so dense that it again becomes difficult to grok.