clintonb

Dreamweaver had FTP uploads. Frontpage only uploaded to servers that supported their protocol.

Competition matters. Comcast/Xfinity was my only "choice" in Cambridge, MA. It cost about $70 per month for 100Mbps service.

My building in Oakland, CA has multiple options, including fiber. The Comcast folks setup tables at least once per quarter to help customers/residents. The cost was much cheaper. I now have gigabit fiber from Wave, and pay less than I did back in MA.

Unclear if related, but the Terraform Registry is also having issues serving data: https://status.hashicorp.com/incidents/jypswvyh0h3z.

In a wonderful twist, we are relying on a couple modules served from GitHub!

The market is saturated. Four years ago we could buy a new one for $1300 or buy used on Craigslist for $800. We went with Craigslist, and resold six months later for $900 (not a typo).

The bassinet is well-made so it would be silly to throw it out after 2-3 kids. The fact that the resellers are other parents makes me trust a little more that they aren’t selling a broken/dirty bassinet, so why buy new for double the cost?

They are a victim of their own success.

We had a Snoo for our kid. I cannot see how anyone knowing our kid was a poor sleeper when he was born, and improved over six months, would be worth anything to anyone. “Parents are sleep-deprived” is a pretty well-known fact at this point.

Congrats on the release! Any plans for GCP support?

I understand the desire to minimize dependencies and the impact of third-party code. In practice, I’m lazy. I don’t want to build my own integration if someone has already done it.

I also don’t always know how complex my integration will be, and would rather not go back and replace custom code with the SDK, so I start with the SDK.

Input validation is a separate thing. If a user provides bad input, yes, the server should return an appropriate error code and human-friendly message. _Lacking_ sufficient validation is a problem that could result in an internal server error that could be resolved by changing inputs, but the validation doesn’t exist so the server cannot inform you of this.

No. That's payment, not KYC (identity verification).

Is this sarcasm? Most banks don't write software, and the third-party software isn't that great. I don't want my bank involved in this at all.

Google Cloud Monitoring (https://console.cloud.google.com/monitoring), perhaps not what you call it, supports the big three signals—logs, traces, metrics.

My last company used Splunk and SignalFx. They were fine, but I wasn't necessarily in the weeds with configuration and usage. The Observability Team made it easy to use.

My current company, a much small startup, primarily uses Datadog and we are starting to better integrage Honeycomb. We mostly abandoned Google Cloud Monitoring because the UI/UX are not that great. Honeycomb is a paradigm, so took some time for us/me to understand. It's growing on us.

Despite the ability to completely blow up our bill (which is now better controlled), Datadog is a good product that lets us quickly answer questions when things go wrong. It's not perfect, but it's the best we have right now. The UI is intuitive, and facilitates more discovery (esp. for metrics and their attributes).

That sounds like an issue between you and the merchant (Stripe's customer), not Stripe. The quickest path to resolution, if the merchant is unresponsive, is to ask your credit card issuer to block payment to that merchant.

It's tough for Stripe to intervene here because Stripe is not aware of what contracts exist between you and the merchant, or how the merchant is integrated with Stripe. A scammer could initiate service, tell Stripe to remove the card, and still get access to the service (because the merchant isn't listening to web hooks). This is a new fraud vector that ultimately violates the trust between Stripe and the merchant.

They provide Actions _runners_ because GitHub runners are quite expensive (per CPU and GB of memory) compared to the underlying cost of a Kubernetes node on most cloud providers or bare metal. Of course, that assumes you’ve already paid the cost to setup a cluster, which is not free.

I understand, and what I am saying is that it is rare to have retail employees that _only_ do checkout. Nearly everyone performs multiple roles. Eliminating checkout will reduce the overall workload, but won't necessarily reduce headcount, or enough headcount to offset the cost of RFID tags.

Retail employees do more than checkout. You’ll still need them to stock, do customer support, clean, and more.

> So why is it not applied everywhere?

RFID tags are expensive compared to printing barcodes. The volume of products moved in a grocery store is far larger than that of a clothing store like Uniqlo.

I was just thinking about MOPy fish (https://en.wikipedia.org/wiki/MOPy_fish)...and how much it encouraged wasting paper!

I agree that Cloud Run greatly simplifies deployments.

Unfortunately, it only auto-scales based on requests and, eventually, CPU. We are in the process of moving our Temporal workers from Cloud Run to GKE Autopilot, which is ~30% cheaper given we can use arm64 Scale-Out nodes.

I like these nerdy takes. After re-watching Jurassic Park for the first time in years, and with more software engineering experience, I’m curious to read a post-mortem of Jurassic Park.

Do they? Someone tried to solve a large problem with the package manager, and inadvertently created a larger problem. That simply indicates the folks at NPM didn't fully think through the edge cases of their problem/solution.

I'm curious if other package managers have the same problem identified by the author, or are susceptible to the "left-pad" problem?

If you give me the option to more than double my money now versus get dividends over the next few years, I'm taking the money now. The goal of most businesses is to make money. Building with a focus on longevity is just one of many ways to achieve that goal.

…and still struggles to sync one file from my laptop to my phone.

You can definitely export data from Fitbit. I built an app to export intraday data to Apple Health using Fitbit’s REST API.

What exactly is the problem?

> Modern EV’s easily least 25 years.

Source, please?

> I feel like there is a correlation between fast-twitch programming muscles and technical debt.

Being fast doesn't mean you do everything at maximum speed. Usain Bolt doesn't sprint everywhere he goes, but he can sprint quite fast when he needs to do so.

I don’t see it as a failure of the spec, but developers failing to read said spec. By the way, I’m a developer who does want a stable ID for users authenticating via third-parties. The fact is that email addresses and phone numbers can change, and should not be considered stable identifiers. If folks want to extract that information from an ID token, they can; but, don’t use them as a primary key.

No deeper understanding required.

The OIDC spec does provide a stable identifier, and Google implements it properly. My Google Workspace address will always be verified, so your solution doesn’t apply. Changing my email address at Google itself won’t unverify it. Also, you’re still relying on developers to read the docs and properly implement the spec.

The email address is not guaranteed to be stable.