I think it's important to share the difficult / hard experiences of having kids as much as the good ones. I've noticed that there is a huge bias towards only sharing the good moments and white-washing all of the bad as something you can "laugh about later." To be frank, not enough people were honest with me about what it would be like having kids before I had them - and I was incredibly upset when I realized that (several years into being a parent).
I now make it a point to be honest with people when they ask "Should we have kids?" and tell them about how hard it can be, etc. Most importantly, I tell people that they shouldn't have kids unless they would still want to do it if their experience doesn't land in the middle of the bell curve. We tend to romanticize the decision, and expect that everything "just gets even better" with kids. There are all sorts of ways your experience can be less than ideal. Unless you're evaluating your decision with those potential outcomes in mind, you're doing yourself, your partner, and even your future children a disservice.
Anyone else surprised that the download links are plain HTTP without SSL? I know it's a page that in the past I would have typically not worried about securing - but nowadays it's SSL everything or else your browser yells at you.
Yeah, this is bad. The page almost seems like someone’s pet project that didn’t have any explicit funding and they got bored or left Netflix in 2020. I’m not sure how that would explain the lack of SSL cert except for just general lack of thoroughness.
I think you're looking at OTel from a strictly infrastructure perspective - which Cloudwatch does effectively solve without any added effort. But OTel really begins to shine when you instrument your backends. Some languages (Node.js) have a whole slew of auto-instrumentation, giving you rich traces with spans detailing each step of the http request, every SQL query, and even usage of AWS services. Making those traces even more valuable is that they're linked across services.
We've frequently seen a slowdown or error at the top of our stack, and the teams are able to immediately pinpoint the problem as a downstream service. Not only that, they can see the specific issue in the downstream service almost immediately!
Once you get to that level of detail, having your infrastructure metrics pulled into your Otel provider does start to make some sense. If you observe a slowdown in a service, being able to see that the DB CPU is pegged at the same time is meaningful, etc.
Agree with you on this.
OTel agents allows exporting all host/k8s metrics correlated with your logs and traces. Though exporting AWS service specific metrics with OTel is not easy. To solve this SigNoz has 1-Click AWS Integrations: https://signoz.io/blog/native-aws-integrations-with-autodisc...
Also SigNoz has native correlation between different signals out of the box.
Not confusing anything. Yes you can meter your own applications, generate your own metrics, but most organizations start their observability journey with the hardware and latency metrics.
Otel provides a means to sugar any metric with labels and attributes which is great (until you have high cardinality) but there are still things that are at the infrastructure level that only CloudWatch knows of (on AWS). If you’re running K8s on your own hardware - Otel would be my first choice.
> And I'm actually quite happy that most Deno projects don't have a custom testing and linting setup.
I feel similarly. The standard configurations (e.g. tsconfig, linting, formatting) and bolts-included tooling (test, lint, fmt, etc.) are what make Deno so great for developers.
I've started using Deno in my spare time for various projects - and it just _feels_ more productive. I go from idea to testing TypeScript in minutes - which never happened in Node land.
> The standard configurations (e.g. tsconfig, linting, formatting) and bolts-included tooling (test, lint, fmt, etc.) are what make Deno so great for developers.
And that's great for greenfield projects - although there's competition with Biome and Vite / Vitest for a lot of those - but the vast majority of Node use today is existing projects, and at least at one point Deno (and Bun, maybe others) were marketed (I think?) as a drop-in replacement for NodeJS. But maybe I'm misremembering.
> Server authors working on large systems likely already have an OAuth 2.0 API.
I think this biases towards sufficiently large engineering organizations where OAuth 2.0 was identified as necessary for some part of their requirements. In most organizations, they're still using `x-<orgname>-token` headers and the like to do auth.
I'm not sure that there's a better / easier way to do Auth with this use case, but it does present a signficant hurdle to adoption for those who have an API (even one ready for JSON-RPC!) that is practically ready to be exposed via MCP.
> I think this biases towards sufficiently large engineering organizations where OAuth 2.0 was identified as necessary for some part of their requirements. In most organizations, they're still using `x-<orgname>-token` headers and the like to do auth.
I don't think that's it. Auth is a critical system in any organization, and larger organizations actually present more resistance to change, particularly in business critical areas. If anything, smaller orgs gave an easier time migrating critical systems such as authentication.
Everyone I know who uses Teams does not like it. Is that selection bias based on my personal network of technically savvy peers and professionals, or is it founded in a broader experience?
More importantly, does Microsoft really believe this is a winning product? Are they that out of touch with their customer base?
I’ve never met anyone who chose to use Teams. My organization forces me to use it. I don’t like it, but to its credit, it is better than “Skype for business.”
It’s strange to me how companies take these huge messaging brands and then just burn them down (Skype, MSN Messenger, Yahoo Messenger, Google’s chatbominations, even AIM). As a user, they don’t fizzle out due to user disinterest, it’s always the owner just sort of doing away with it for something new.
Is there just not a financial model here? Cheap to run and lots of users but no money. Skype seemed to be profitable back when I would use it for international calling.
The issue is that they have working tools which work in one period, but fail to adapt to change.
AIM, Yahoo, MSN etc. were mostly plain text systems, built around presence and a single client. Then came mobile phones, with unreliable connections, with messengers which allowed integrating pictures etc. and easy sign up (iMessage by using apple ID, which every iPhone user has; Whatsapp by using phone number which directly linked the contacts), which worked without battery draining connection.
Skype originally worked by making random clients "super nodes" which coordinated the network, without needing a big data center managing it all. Making phones super nodes wasn't an option so they had to change their protocol in big ways.
So adapting was a cost and changed user experience, while newcomers grew.
In case of Google there was the addition of missing strategic leadership, where each team built their own new messenger, but nobody maintained any old one.
Accidental Tech Podcast episode 581 [1] had a great conversation about the reason why Teams is winning: Microsoft was using their dominant position in office applications to win market share.
Specifically, they would offer Teams for free in a bundle with Office (which basically every company buys anyway). Every manager could strike Slack from their expenses, replace it with Teams and claim great success.
Microsoft has since been forced to change their tactics [2-3], but the damage is done.
This was obvious, at least to me. MSFT has always offered Teams as a "free" add-on to O365 licenses. Google does the same with Meet and Workspace licenses.
It's a real shame, given that Zoom is leagues better than both solutions. But "free" is free :(
Zoom? Better?
Maybe to have a videocall.. but add a couple hundred users to a call .. and you start hitting limits.
Granted, those are not very common but I think the killer feature of slack and teams is discoverable channels. Dont get me wrong Teams UX and performance is terrible in MacOS the whole experience is like taking a school bus to a freeway.. but feature-wise is very complete IMHO and it can handle 500+ user video calls with no problem.
I think this is exactly why it's getting all the hate. People being forced to migrate from Slack to Teams. Not only do they lose years of archives, but the UX and features are a huge downgrade for such an essential tool.
If it was zoom -> teams, i don't think anyone would care so much.
Most basic communication needs, if your basic needs don't include messages being communicated reliably.
Some people use these products to go through the motions of appearing to do work, and don't seem to be aware how ineffective they're being.
Whether MS office suites slot right in because the org is already dysfunctional, or whether the org is dysfunctional because MS office suites have made them that way over the years, I don't know.
I haven't used Zoom extensively, so I cannot comment on its performance. I just had a meeting this morning on Teams using video, and my MBP battery went from 95% to 49% in about 25 minutes (it normally lasts for about 5-6 hours under normal workflow). That was after I had to restart Teams the first time I picked up the call, because it hung and didn't display the conference window.
I find Teams performance atrocious for modern standards. It's not great on W10, but on my Mac is horrible. The conversation buffer is abysmal, having to refresh a million times if you need to scroll up in the conversation history.
Most of my peers use windows, and have constant crashes, incorrectly identified input devices like mics and cameras, sluggish performance when sharing screens, etc...
As of right now, search appears to be completely broken. I can see that the keyword I'm looking for is in the messages. But it won't show up via search (either from the top bar, or from the helpful "press ctrl-f to search within this channel" right-side-bar.)
The UI is aggressively debouncing, so it won't search again unless I change the query.
The UI message is "We couldn't find any results in this channel. Check for spelling, try another search keyword, or search in another channel."
Looking into the network response, I see some fun JSON:
It is not the best, but it offers just enough and is good enough that you dont want to spend on a separate dedicated product.
Especially as teams comes as a part of a bundle and is integrated with it.
I hate skype's interface (the is just so bad, even sharing screen), I also hate the sharepoint integration, but reality is that if you look at costs you will use it
Different thing is that windows 11 taskbar now has space for 11 windows open.. wow this is bad for any officr work
My guess is that for the VCs and PMs at Teams, it is easier to play politics and ensure your product is tightly integrated and coupled with other MS products, than to build an actual quality product.
It speaks of the culture at MS really, but it's amazing how a revenue and cash rich company can keep a dogshit product going.
I despise teams, all my colleagues despise teams, all my friends despise teams. It's a product that all users hate with amazing uniformity. But MS bundles it with Office, which makes demure and uninspired IT departments use it because it's less work.
I now make it a point to be honest with people when they ask "Should we have kids?" and tell them about how hard it can be, etc. Most importantly, I tell people that they shouldn't have kids unless they would still want to do it if their experience doesn't land in the middle of the bell curve. We tend to romanticize the decision, and expect that everything "just gets even better" with kids. There are all sorts of ways your experience can be less than ideal. Unless you're evaluating your decision with those potential outcomes in mind, you're doing yourself, your partner, and even your future children a disservice.