dan @ dan @upvote.au

Aussie living in the San Francisco Bay Area.

---

Read more

Posts

10

Comments

3,495

Joined

2 yr. ago

In my area (in the SF Bay Area) there's barely any upfront cost, as there's something like $4k in local and state rebates plus the 30% federal tax credit.

Aren't they at least hashed, so WinGet can verify that the package hasn't been tampered with?

Technical users that are comfortable at a command line often use WinGet these days. It works in Windows Sandbox too; you just need to manually install it.

Wow, there really is a game for everything.

I'm glad I'm not the only person that does this.

Usually, feature branches mean that all the work to implement a particular feature is done on that branch. That could be dozens of commits and weeks of work from several developers. The code isn't merged until the feature is complete. It's more common in the industry compared to trunk-based development.

My previous employer had:

• Feature branches for each new feature.
• A dev/trunk branch, where features branches were merged once they were done.
• A beta branch, branched from dev once per week.
• A live/prod branch, branched from beta four times per year.

This structure is very common in enterprise apps. Customers that need stability (don't want things to change a lot, for example if they have their own training material for their staff) use the live branch, while customers that want the newest features use the beta branch.

Bug fixes were annoying since you'd have to first do them in the live branch then port them to the beta and dev branches (or vice versa).

On the other hand, feature flags mean that all the code goes directly into the trunk branch, but it's turned off until it's ready. A basic implementation of feature flags would be a static class with a bunch of booleans that get checked throughout the code, but they're usually dynamic so a misbehaving feature can be turned off without having to redeploy the code.

Some codebases use both feature branches and feature flags.

It caters more for a linear workflow, though. So modern large teams won't find joy with SVN

For what it's worth, I work at a FAANG company and we don't use branches at all. Instead, we use feature flags. Source control history is linear with no merges.

All code changes have to go though code review before they can be committed to the main repo. Pull requests are usually not too large (we aim for ~300 lines max), contain a single commit, aren't long-lived (often merged the same day they're submitted unless they're very controversial), can be stacked to handle dependencies between them ("stacked diffs"), and a whole stack can be landed together. When merged, everything is committed directly to the main branch, which all developers are working off of.

I know that both Google and Meta take this approach, and probably other companies too.

The bottom picture should be SVN. I miss incremental revision numbers.

Are any drink manufacturers fully vertically integrated? I think most of them outsource can and bottle manufacturing, even big manufacturers like Coca-Cola. They're in the business of making drinks, not making cans and bottles (which don't have any special features compared to cans and bottles used by other companies), so it makes sense to use a vendor that has experience in that area.

And probably 90% of them are just building on top of OpenAI's API rather than having their own model, and OpenAI still don't know how to become profitable. It feels like the dot com bubble all over again.

Generally, if it's just a plain word or something you can read easily, then it's safe to keep it. If it's a jumble of seemingly random letters, it's probably a tracking code of some sort.

This is kinda true but also kinda fear mongering. UTM parameters are just to track where you clicked the link from. They're usually not dynamic, and don't contain anything about you personally. The example in the screenshot utm_source=newsletter is probably added to all links in a company's newsletter email, so they can tell that people get to the page via the newsletter.

In addition to this, a lot of movies and TV shows are going to use the same DRM mechanisms, whereas with games it's different for every game. The developers (both of the DRM systems and of the game) learn what works and what doesn't work and adjust the system for their next game.

Edit: Also, games often have anti-piracy measures hidden throughout the game, so whoever is cracking the game likely has to play the game quite a bit to ensure they've caught them all.

This is how I handle it for most software: Read (or at least skim) the changelogs for all minor and major versions between your current version and the latest version.

If you're using Docker, diff your current docker-compose to the latest one for the project. See if any third-party dependencies (like PostgreSQL, Redis, etc) have breaking changes.

If there's any versions with major breaking changes, upgrade to each one separately (eg. 1.0 to 2.0, then 2.0 to 3.0, etc) rather than jumping immediately to the latest one, as a lot of developers don't sufficiently test upgrading across multiple versions.

Take a snapshot before each upgrade (or if your file system doesn't support snapshots, manually take a backup before each upgrade).

...or just don't read anything, YOLO it, and restore a snapshot if that fails. A lot of software is simple enough that all you need to do is change the version number in docker-compose (if you're using Docker).

In addition to backups, consider using snapshots if your file system supports it (ZFS, Btrfs, or LVM).

I use ZFS and have each of my Docker volumes in a separate ZFS dataset (similar to a Btrfs subvolume). This lets me snapshot each container independently. I take a snapshot before an upgrade. If the upgrade goes badly, I can instantly revert back to the point before I performed the upgrade.

The funny part is that Replit has billboard ads along the 101 in Silicon Valley that say "vibe code, safely"

I didn't realise repl.it has pivoted to vibe coding. It used to be similar to CodeSandbox or jsfiddle - a sandbox for writing and running code.

Interesting site, thanks for the link!

There's a few groups like this in Australia, unfortunately.

Australia didn't even have an R18+ rating for games until 2013 (R18+ is similar to AO or NC-17 in the USA). Before then, all games with a higher rating than MA15+ were illegal in Australia. Many games had an Australia-specific version with blood/gore reduced, some things edited out, etc. to reduce the rating. The original release of GTA4 in Australia was heavily censored.

That's what I meant by hiring a self-employed freelancer. I don't know a lot about contracting so maybe I used the wrong phrase.

This is amusing because practically every backend is fiber. You need it for speeds above 10Gbps, and all ISPs will have at least 40Gbps or 100Gbps connections in their data centers, sometimes even faster (QSFP can do up to 400Gbps).