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.

Any dogmatic decision could be described as taking the ambiguity out of decisions.

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

We’ve discussed the downsides of having such a policy in this subthread.

I want to have the choice to do a true merge or some other strategy. It’s a downside for me personally. Not having a choice doesn’t help me since it’s a meaningful choice in my book.

As a policy. I leave this decision for others. People who prefer can squash-merge all the time if they want to.

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.

By default it’s an optimization fence if a CTE is referenced 2+ times, and not an optimization fence if referenced 0-1 times. The MATERIALIZED and NOT MATERIALIZED overrides the default.

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.

What's the difference between using Alfred to search vs using the hotkey to open a Dash window in search mode?

I don’t think there really is a significant difference, unless you’re already using Alfred. I’m an Alfred user and it’s kind of the “start everything place” window for me, the system-wide equivalent of a text editor’s command palette, a CLI for the GUI.

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.

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.

I've seen the exact opposite configuration where it's not possible to avoid SSHing from one remote server to another due to network segmentation, as on the network level it's impossible to access any production system directly via SSH but only through a jumphost, which obviously does not have a browser installed.

You don't need the jumphost to do the auth for the target host. You use -J and the auth happens locally and is proxied through.

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.

We are also doing this. I'm amazed at how much some people share of their kids online.

Same here, but I don't expect some sort of magic happening. Big tech likely know every detail of my kids anyway. It's just your social circle and bad apples within that you wanna be sure of.

What arguments have you used to finally convince them?

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.

We do this as well, specifically #1 we do through apple's private shared albums. It's quite good, we've got a big chunk of the family on there, so people comment as I assume they would on Facebook. This has assuaged their (proud grandparents) urge to post photos on their other social media, I think. I'm not on Facebook so I'm not positive what they are doing on there, but the banal comments that show up in the family feed remind me of why I'm not.

I commented elsewhere and mentioned that #1 is the path we took. That said, while we encountered next to no resistance on this policy from our family, we've found that in practice, my mother really thrives on #2, to the point where I'm confident that our broader family/friends group gets pictures directly from her and hardly bothers visiting my private gallery.

Yeah, this has been a source of hurt feelings for my parents, my wife's parents, and the parents of many of our peers... Facebook-addicted Boomers literally crying, "But everyone else gets to put up pictures of their grandchildren!"

Grandparents have shared photos of their relatives, just usually through wallet photos in the past, email maybe later - so it probably feels like a small delta on that. Probably doesn’t help more of their lives are spent online than in person now.

I’d been printing off photos in various sizes (wallet to 8x10) and sending them along to my parents/grandparents - but it does take more effort to follow through. I do post photos of kids to a private account but maybe once or twice a year.

We upload and organize our family photos in a private Flickr album, and the grandparents have access to that. The presentation is beautiful and I update it at least once a month, so they should be able to enjoy it. If they pull up the album on their phone to show off some photos to a friend in-person, like they would've done in the past with a wallet photo, we're fine with that. Unfortunately, what they really want is the shower of Likes and comments from their 1,000+ Facebook "friends" (and God knows who else with their privacy settings).

I was also using iCloud shared photo album which was great until my mother switched to an android phone (in addition, lost true Facetime support which was also a bummer)

Ironically she switched to an android phone because she had too many photos I think and was always running out of storage. Of course the new phone had no photos, and her old phone would have been just fine if she was happy to start over too.

We got the grandparents Aura smart frames. It's trivial to add photos and short videos. They get to see a new pic of the kid almost every day.

As soon as anyone visits their house, they immediately see recent pics of the kid.

It's been a big winner.

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.

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.

> 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

The key diff between 'build' vs 'buy' seems to come down to an accommodation of one-off and sometimes frankly 'wrong' processes.

Using off the shelf prevents accommodating many oddities companies have accumulated (via growth, acquisition, whatever).

Build from scratch seems to always implicitly include "we'll handle every weird-ass edge case anyone might come at us with in the future, because we built it ourself".

There could be a middle ground of "build with certain parameters, but also normalize some existing processes by refusing to spend hundreds of hours building weird accounting processes for 1 customer someone because a salesperson needed to hit their target and told them anything was possible".

Dealt with accounting stuff years ago, and ... there weren't any accounting systems which could simply/easily handle 20 years of homegrown cruft. "If the customer number starts with P or X, and the account rep is Randy, they get a 5% discount until next summer". They had... 5000 customers, and about 30% of them had ad-hoc 'rules' like that. Hundreds of business rules various people just 'knew'. Just documenting and classifying them can take weeks.

I'm not saying no commercial systems can ever support that level of customization, but "we'll import all your stuff with 3 mouse clicks"-style marketing fluff ignores the reality that ... you have to adapt your business some, or you have to build in house. But even building in house, you still need to adapt your business processes to reduce/eliminate ad-hoc rules that people just yell down the hall to the accounting team.

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.

It's never pain that the sales folks have to bear, it seems. :)

Ha. Nope.

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

The biggest problem in "default deny egress" is CDNs. It's a colossal waste of time to set up firewall access lists for your build agents, but even for your production environments - as soon as you have one external API that is hosted behind Cloudflare, Anypoint, Cloudfront, Akamai or one of the hundred other similar services, you may as well give up. Simply because it's extremely annoying to keep up tabs with changing IP addresses.