daigoba66

It was a sad day when Rdio was bought by Pandora and shutdown. They were the best.

Also a good explanation of the pattern: https://docs.particular.net/nservicebus/outbox/

> crypto algorithm negotiation

If you control both sides, then you can ignore this part or do it out-of-band.

Though, if you control both sides, then you can use literally anything else too.

Happens a lot, though probably mostly isolated cases. But sometimes it’s a big deal: https://en.m.wikipedia.org/wiki/Flint_water_crisis

Can some explain to me what 25-50+ engineers do all day at these startups?

My experience is probably skewed, mostly working for SaaS companies providing enterprise B2B software, but the product and engineering team represents only 15-20% of the headcount - the customer success team is often 2-3x larger.

Are there any good examples or tutorials for using CSS modules and TypeScript as you described?

> because it'll get corporations to replace the actual IE11 executable with the Edge executable.

I’m probably just cynical, but nothing caused corporations to get rid of IE11 before, and nothing will now.

Working on an enterprise b2b web app, I’m going to have to support IE11 indefinitely.

Two kids, both on formula from day one. It was probably the right choice for a number of personal factors: we both could easily take turns feeding, it’s easy to know and track how much they’re consuming, and simplified things for eventually going to daycare.

There are certainly people who will discourage you from formula. But you have to make your own choice for yourselves and your baby. But frankly neither choice is “bad”.

I’ve migrated several repositories from mercurial, and didn’t bother to rename “default”. It works perfectly fine and no one is ever confused.

We do it the other way (and I’ve always seen it done this way): database change is compatible with current code and new code. So deploy the database change, then deploy the code change. It usually allows you to rollback code changes.

Once upon a time I liked Jira, and most of the products shipped by Atlassian.

While Jira has large admin overhead, it can be configured to make things simple for users. And I still think most hatred of Jira ought to be directed at management for imposing bureaucracy and control through the tool, instead of the tool itself (I see this first hand as my current gig has grown from “startup” to “enterprise” in a few short years).

But Atlassian has made a lot of questionable product decisions over the last many years, mostly in terms of UI/UX. What were once very much developer-centric interfaces are now geared to general enterprise product management. Somehow it’s becoming _less_ functional over time with each major revision.

> my finger is on the remote immediately to jump to the next channel

That’s exactly what I did when watching TV growing up in the 90s, before DVRs.

I guess it’s sort of a form of “channel surfing”.

Before chip embedded credit/debit cards were prevalent, most magnetic strip reader (MSR) peripherals would often operate as a USB keyboard. It allows them to work with web app based POS systems without requiring things like ActiveX.

Put it in the commit message.

Especially for git, because old branches can be cleaned up/deleted which results in a loss of tracking.

The registrar maintains the records that specify which nameservers, i.e. DNS servers, will resolve names for that domain. The registrar simply changes that record to point to nameservers that they operate, and with DNS entries that “take it offline”.

Adding a NOT NULL column with a default value as an online DDL operation is in fact an Enterprise Edition feature.

This is cool.

And another example of a feature that’s only available in Microsoft SQL Server Enterprise Edition ($$$), but effctively free in Postgres.

> Those that haven't experienced this probably just haven't worked in a medium or large corporation.

It’s really an organizational problem, not the tool.

How does it compare to https://www.setcronjob.com?

That’s not always the best advice.

Consider a table that you know will only have a few rows, but is referenced in one or more FK columns. If I use a 64bit integer when 32bit (or smaller!) is enough, I’m now using twice as much space for the FK column. If there are millions of rows, plus indexes, that can add up pretty fast.

Also important is adapting to the existing naming conventions of the database, even if you don't like it. (Unless the existing naming conventions cause more trouble that its worth like requiring quoted identifiers or redundant prefixes/suffixes).

Office 365 and Azure AD integration. These are probably huge money makers.

Use what you know. In my case, probably ASP.NET Core and either SQL Server or PostreSQL.

It’s serious stuff. One violation could easily destroy a startup or small-to-mid sizes software company.

Note that Chrome on an iPhone is still just Safari but with different chrome (no pun intended).

> There might be a better pattern for this, such as making the determination through a xhr request when the username field loses focus.

This is what Microsoft does when logging into their various online sites. And it is not better. There’s not much worse than hitting tab and starting to type a password only to get redirected.

I really like UUIDs for all of the reasons described in the article. But can there can be significant performance related drawbacks:

UUIDs are double the size of 64 bit integers. Which could mean fewer rows on data and index pages, leading to memory pressure, leading to I/O pressure.

UUIDs are also random. I'm not an expert when it comes to PostgreSQL internals. But for MSSQL it's common and recommended to use your PK as a clustered index. The randomness can wreck havoc on the clustered index, causing severe fragmentation due to page splitting. There are some techniques to mitigate the effects of this (decreasing page fill factor, using incrementing UUIDs, using a surrogate IDENTITY clustered key), but each has significant tradeoffs

Don’t store UUIDs as strings.

Use the native UUID data type, which only uses 16 bytes (UUIDs are basically just 128 bit integers). That is still double the size of a 64 bit integer, but the trade off is that it can be random and universally unique.

If it helps, AWS' default auto scaling algorithm specifically takes into account instances which are nearest to their next billing hour and prioritizes those for termination accordingly to, in theory, save money.

But it doesn't feel that old.