DEV Community: Rogério Rodrigues de Alcântara

FCIS — Functional Core, Imperative Shell

Rogério Rodrigues de Alcântara — Wed, 11 Mar 2026 00:04:17 +0000

DISCLAIMER

NOTE:
This is a few notes regarding what (I think/hope) I have learned this week.

PLEASE: Use it with a grain of salt! YOU HAVE BEEN WARNED!
PS: Any corrections, clarifications, or suggestions would be greatly appreciated! NO, SERIOUSLY!

OVERVIEW

💡 A pattern that splits your codebase into two hard zones:

ZONE src/core/

PURE functions only

No I/O.

No side effects.

ZONE src/shell/

NON-PURE functions only

All I/O lives here.

Causes side effects.

Why Bother?

Testability without ceremony:

Core tests need zero setup - no mocks, no DB, no async. Plain object literals in, assertions out. If a test needs beforeEach or await, the function is in the wrong layer.

Deterministic replay:

Pure functions mean you can log inputs at the shell boundary and reproduce any production bug exactly - no database state, no timing, no environment to reconstruct.

No framework lock-in at the core:

src/core/ has zero runtime dependencies. Switching from Express to Hono, Drizzle to Prisma, or Node to Bun touches only the shell. Business logic is untouched.

Parallel development:

Once core types and signatures are defined, shell and business logic can be built simultaneously. The contract is just data in, data out.

Free documentation:

Pure function signatures are the spec. canTransitionTo(current: TaskStatus, next: TaskStatus): boolean tells you everything - no layer-tracing required.

Safer code review:

Any PR touching only src/core/ cannot introduce a regression caused by I/O, timing, or external state. That's a meaningful trust boundary.

Incremental adoption:

No minimum viable structure. Extract one pure function from a messy handler and grow from there. Unlike DDD or clean architecture, it scales down.

How It Compares

vs. Clean Architecture / Hexagonal Architecture (Ports & Adapters)

Clean Architecture (Robert Martin) and Hexagonal Architecture (Alistair Cockburn) solve the same dependency problem - keep business logic independent of infrastructure - but through abstraction layers: interfaces, ports, adapters, and dependency injection containers.

FCIS gets there through data flow instead. No interfaces. No adapter classes. No DI framework. The core is isolated not by indirection, but because it literally only speaks in plain data types and pure functions.

Clean / Hexagonal vs. FCIS

Isolation mechanism

Clean / Hexagonal: Interfaces + DI
FCIS: Pure functions + data

Boilerplate

Clean / Hexagonal: High
FCIS: Minimal

Testability

Clean / Hexagonal: Good (with mocks)
FCIS: Better (no mocks needed)

Learning curve

Clean / Hexagonal: Steep
FCIS: Low

Best fit

Clean / Hexagonal: Large teams, complex domains
FCIS: Small-to-medium codebases

SUGGESTION

Clean Architecture: is powerful
FCIS is cheaper

Pick the one that matches your actual complexity. :)

vs. Domain-Driven Design (DDD)

DDD (Eric Evans, Domain-Driven Design, 2003) is a design philosophy - ubiquitous language, bounded contexts, aggregates, domain events. FCIS is an architectural pattern. They aren't competitors.

The key differences

DDD encourages rich domain models

— objects that encapsulate both data and behaviour

(Aggregates, Entities, Value Objects with methods).

FCIS enforces the opposite:

data and behaviour are always separate.
A Task in FCIS is a plain type;
canTransitionTo is a standalone function.

You can apply DDD thinking (bounded contexts, ubiquitous language) to an FCIS codebase. But you cannot use rich OOP domain objects in src/core/ without violating the purity constraint.

vs. Layered / N-Tier Architecture

The classic Service → Repository → Database stack organises code by technical role.

Business logic typically lives in a Service class that also coordinates I/O — calling repositories, dispatching events, logging.

The layers are present, but the boundary between logic and I/O is blurry.

FCIS makes that boundary a hard rule. The equivalent of a Service is split in two: pure logic goes to src/core/, orchestration goes to src/shell/. There's no "service that also does I/O" — that's the entire violation FCIS exists to prevent.

vs. Functional Programming `(pure FP)`

Languages like Haskell enforce purity at the type system level - impure code must be declared as such (e.g. IO monad). FCIS is a convention-based approximation of that discipline in TypeScript. There's no compiler enforcement of the core/shell boundary - it relies on discipline and linting.

The tradeoff is pragmatism: you get most of the reasoning and testability benefits of pure FP without leaving the TypeScript ecosystem or retraining your team.

Gary Bernhardt's Boundaries talk (2012) is the canonical introduction to this idea. His framing: push values to the edges, keep the centre pure.

MAIN CONCEPTS

The Core `(src/core/)`

ALLOWED:
- domain types
- validation
- business rules
- data transformations
- pure formatters
FORBIDDEN:
- async/await
- fetch
- fs.*
- console.log
- process.env
- new Date()
- DB calls.

EXAMPLES:

// ✅ Pure validation - returns Result, never throws
export const validateTitle = (title: string) => {
  if (!title.trim()) return fail(Errors.validation('title', 'Cannot be empty'))
  return ok(title.trim())
}

// ✅ Pure business rule - receives `now` as param, never calls new Date() internally
export const isOverdue = (task: Task, now: Date) => {
  return !!task.dueAt && task.status !== 'done' && task.dueAt < now
}

// ✅ Pure workflow - all data arrives as params, returns computed result
export const createTask = (project: Project, input: CreateTaskInput, now: Date) => {
  const title = validateTitle(input.title)
  if (!title.ok) return fail(title.error)
  return ok({ id: randomUUID(), ...input, createdAt: now, updatedAt: now })
}

The Shell `(src/shell/)`

💡 Every handler follows the same 5 steps - no exceptions:

PARSE → extract input from args/env/stdin
FETCH → read required data from DB/filesystem
CALL → pass data to core, inspect Result
ACT → persist what core returned
OUTPUT → print to stdout/stderr

💡 If you're making a business decision in step 4,
move it to step 3.

// ✅ Thin handler - all decisions happen in core
export const taskDoneCommand = async (taskId: string) => {
  // 1. PARSE
  if (!taskId) { printError('ID required'); process.exit(1) }

  // 2. FETCH
  const task = await findTaskById(db, taskId)
  if (!task) { printError('Not found'); process.exit(1) }

  // 3. CALL CORE
  const result = transitionTask(task, { taskId, toStatus: 'done' }, new Date())
  if (!result.ok) { printError(result.error.message); process.exit(1) }

  // 4. ACT
  await updateTask(db, result.value.updatedTask)

  // 5. OUTPUT
  printSuccess('Task marked as done.')
}

ERROR HANDLING

💡 Use Result - never throw for expected failures.

type Result<T, E = AppError> = { ok: true; value: T } | { ok: false; error: E }

const ok   = <T>(value: T): Result<T, never> => ({ ok: true, value })
const fail = <E>(error: E): Result<never, E> => ({ ok: false, error })

Expected failures are values. Thrown exceptions are for truly unexpected crashes only.

TESTING

💡 No setup. No mocks. No async.

// ✅ No setup. No mocks. No async.
it('rejects empty title', () => {
  const result = validateTitle('')
  expect(result.ok).toBe(false)
})

it('blocks invalid transitions', () => {
  expect(canTransitionTo('done', 'todo')).toBe(false)
})

it('returns a new task without mutating the original', () => {
  const task = makeTask({ title: 'Original' })
  const updated = applyTaskUpdate(task, { title: 'Updated' }, new Date('2024-06-01'))
  expect(updated.title).toBe('Updated')
  expect(task.title).toBe('Original')
})

Bu, when NOT TO USE IT?

💡 NOTE:

When the business logic is the I/O - e.g. a file watcher, a sync tool. The core/shell distinction collapses when there's nothing to separate.

When the team is deeply invested in OOP/DDD and the retraining cost outweighs the benefit.

Pre-Commit Checklist

[ ] No async/await in src/core/
[ ] No imports from src/shell/ in src/core/
[ ] No console.log, process.env, fs.*, fetch in src/core/
[ ] new Date() only in shell, passed as param into core
[ ] All expected failures return Result, nothing throws
[ ] Shell handlers follow parse → fetch → call → act → output
[ ] Core tests: no mocks, no DB, no async

REFERENCES

Boundaries - the canonical source for FCIS thinking
Clean Architecture - dependency rule, layers, and ports
Hexagonal Architecture - ports & adapters original essay
Domain-Driven Design - aggregates, bounded contexts, ubiquitous language
Simplify & Succeed: Replacing Layered Architectures with an Imperative Shell and Functional Core - practical TypeScript walkthrough
Railway Oriented Programming - the Result pattern in depth

Adding Zsh Completion for `gh copilot`

Rogério Rodrigues de Alcântara — Thu, 03 Oct 2024 23:07:58 +0000

You are not alone if you are using the gh copilot CLI and have noticed the lack of Zsh completions.

To address this issue, I (err.. GPT, actually) created a completion script to enhance the command-line experience.

Below is a quick guide on setting it up, including a tip on enabling autocompletion for aliases.

Add a few aliases (optional)

Somewhere on your ~/.zshrc, add:

# GitHub Copilot
# Use Copilot with the GitHub CLI to get suggestions and explanations for the command line
# https://docs.github.com/en/copilot/using-github-copilot/using-github-copilot-in-the-command-line
if (( $+commands[gh] )); then
  # GitHub Copilot
  alias ghcp='gh copilot'

  # Explain a command
  alias cpe='ghcp explain'

  # Suggest a command
  alias cps='ghcp suggest'
fi

After reloading the shell, you should be able to run ghcp --help:

$ ghcp --help
Your AI command line copilot.

Usage:
  copilot [command]

Examples:

$ gh copilot suggest "Install git"
$ gh copilot explain "traceroute github.com"


Available Commands:
  alias       Generate shell-specific aliases for convenience
  config      Configure options
  explain     Explain a command
  suggest     Suggest a command

Flags:
  -h, --help              help for copilot
      --hostname string   The GitHub host to use for authentication
  -v, --version           version for copilot

Use "copilot [command] --help" for more information about a command.

However, when running ghcp <TAB>, nothing happens...

Yet!

Create the Completion Script

First, create a new file for the completion script and name it _ghcp. Place the following content inside:

#compdef ghcp

local context state line
typeset -A opt_args

_arguments -C \
  '-h[help]' \
  '--help[help]' \
  '--hostname=[The GitHub host to use for authentication]:hostname:' \
  '-v[version for copilot]' \
  '--version[version for copilot]' \
  '1:command:->command' \
  '*::args:->args'

case $state in
  command)
    local -a commands
    commands=(
      'alias:Generate shell-specific aliases for convenience'
      'config:Configure options'
      'explain:Explain a command'
      'suggest:Suggest a command'
    )
    _describe -t commands 'copilot command' commands
    ;;
  args)
    case $words[2] in
      alias)
        # No additional arguments for 'alias'
        ;;
      config)
        # No additional arguments for 'config'
        ;;
      explain)
        _message 'Provide the command you want to explain'
        ;;
      suggest)
        _message 'Provide a description of what you want to do'
        ;;
    esac
    ;;
esac

# Associate the completion script with the alias
compdef _ghcp ghcp

Install the Completion Script

Next, you must place the _ghcp file in a directory that's part of your $fpath. Here's how you can do it:

1. Create a Completions Directory

If you don't already have a custom directory for Zsh completions, create one:

$ mkdir -p ~/.zsh/completions

2. Move the Script

Move or copy the _ghcp file into this directory:

$ mv _ghcp ~/.zsh/completions/

3. Update Your $fpath

Add the completions directory to your $fpath by appending this line to your ~/.zshrc:

$ fpath=(~/.zsh/completions $fpath)

4. Ensure the Script Is Executable

Make the completion script executable:

$ chmod +x ~/.zsh/completions/_ghcp

5. Enable Alias Completion

If you use aliases for gh copilot (like ghcp), Zsh must be configured to handle completions for aliases. Add the following line to your ~/.zshrc:

$ setopt complete_aliases

Alternatively, you can explicitly associate the completion script with your alias by adding:

$ compdef _ghcp ghcp

6. Reload Zsh Configuration

Apply the changes by sourcing your .zshrc or restarting your terminal:

$ source ~/.zshrc

Is that so?

Well, let's try typing ghcp <TAB> and.. voila!

You should see the available subcommands and options auto-complete for you.

Summary

Having shell completions can significantly speed up your workflow by reducing the need to remember every command and option.

Enabling alias completion ensures that your custom shortcuts benefit from the same convenience.

That's all, folks!

Convert insert mutation to upsert

Rogério Rodrigues de Alcântara — Wed, 18 Sep 2024 12:52:46 +0000

Upsert operations are crucial for maintaining data consistency.

In this quick post, we’ll walk through implementing an Upsert operation in Hasura using PostgreSQL and GraphQL.

Given some tables, i.e.:

-- a companies table
CREATE TABLE public.companies (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    name VARCHAR(255) NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

-- a customers table
CREATE TABLE public.customers (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    customer_id VARCHAR(255) NOT NULL,
    token VARCHAR(255) NOT NULL,
    company_id UUID NOT NULL,
    acquirer VARCHAR(255) NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

-- a unique constraint for some fields to be used by the mutation's on_conflict clause
ALTER TABLE customers ADD CONSTRAINT customers_customer_id_company_id_acquirer_key 
    UNIQUE (customer_id, company_id, acquirer);

-- an index on the unique constraint for better performance
CREATE INDEX idx_customers_customer_id_company_id_acquirer 
    ON customers (customer_id, company_id, acquirer);

-- a foreign key constraint for company_id
ALTER TABLE customers ADD CONSTRAINT fk_customers_company
    FOREIGN KEY (company_id) REFERENCES companies(id);

And the following executed seed

-- a few existing companies
INSERT INTO public.companies (id, name) VALUES
('a75645ac-b99e-477f-b4a9-b59380b48693', 'Acme Corporation'),
('b75645ac-b99e-477f-b4a9-b59380b48693', 'Globex Corporation'),
('c75645ac-b99e-477f-b4a9-b59380b48693', 'Soylent Corp'),
('d75645ac-b99e-477f-b4a9-b59380b48693', 'Initech'),
('e75645ac-b99e-477f-b4a9-b59380b48693', 'Umbrella Corporation');

Upsert Customer GraphQL Mutation

The following mutation either inserts a new customer or updates the token field of an existing customer if a conflict occurs.

# upsert mutation using on_conflict to handle duplicates
mutation UpsertCustomer($customer_id: String!, $token: String!, $company_id: uuid!, $acquirer: String!) {
  insert_customers_one(
    object: {
      customer_id: $customer_id,
      token: $token,
      company_id: $company_id,
      acquirer: $acquirer
    },
    on_conflict: {
      constraint: customers_customer_id_company_id_acquirer_key,
      update_columns: [token]
    }
  ) {
    id
    customer_id
    token
    company_id
    acquirer
  }
}

Insert a New Customer

When the unique constraint fields do not exist, the mutation inserts a new customer.

- **Query Variables**

    ```json
    {
      "customer_id": "CUST123",
      "company_id": "a75645ac-b99e-477f-b4a9-b59380b48693",
      "acquirer": "ACQUIRER789",
      "token": "TOKEN456"
    }
    ```

- **Response**

    ```json
    {
      "data": {
        "customers": [
          {
            "id": "fd285dfc-b818-4db0-bd15-80cb015983d7",
            "token": "TOKEN456",
            "company_id": "a75645ac-b99e-477f-b4a9-b59380b48693",
            "created_at": "2024-09-17T19:37:44.350509+00:00",
            "acquirer": "ACQUIRER789",
            "updated_at": "2024-09-17T19:40:01.456019+00:00"
          }
        ]
      }
    }
    ```

Update an Existing Customer

Whereas the unique constraint fields already exist, the mutation updates the token field.

- **Query Variables**

    ```json
    {
      "customer_id": "CUST123",
      "company_id": "a75645ac-b99e-477f-b4a9-b59380b48693",
      "acquirer": "ACQUIRER789",
      "token": "TOKEN4567"
    }
    ```

- **Response**

    ```json
    {
      "data": {
        "customers": [
          {
            "id": "fd285dfc-b818-4db0-bd15-80cb015983d7",
            "token": "TOKEN4567",
            "company_id": "a75645ac-b99e-477f-b4a9-b59380b48693",
            "created_at": "2024-09-17T19:37:44.350509+00:00",
            "acquirer": "ACQUIRER789",
            "updated_at": "2024-09-17T19:42:01.456019+00:00"
          }
        ]
      }
    }
    ```

Summary

By following these steps, we can easily implement upsert operations in Hasura, allowing for efficient data management and updates.

References

Simplifying Your Git Workflow with Aliases

Rogério Rodrigues de Alcântara — Thu, 08 Feb 2024 03:18:11 +0000

Simplifying Your Git Workflow with Aliases

Introduction to Git Aliases

Git aliases are a powerful feature that allows you to create custom shortcut commands for longer Git command sequences. They can significantly simplify and speed up your Git workflow by reducing repetitive typing and complexity.

How to Configure Git Aliases

Configuring a Git alias is straightforward. You can define aliases in the .gitconfig file located in your home directory, or you can set them directly via the command line using the git config command.

Setting an Alias via `.gitconfig`

To set an alias in .gitconfig, you need to edit the file and add your alias under the [alias] section. For example:

[alias]
  co = checkout
  br = branch
  ci = commit

Setting an Alias via Command Line

Alternatively, you can set an alias directly from the command line:

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit

This will update your .gitconfig file with the new aliases.

Examples of Git Aliases

Let's explore some practical examples of Git aliases from the attached file, showcasing how they can simplify your daily Git usage:

1. Quick Commit: Instead of typing `git commit -m "Your message"`, use:

cm = commit -m

Usage:

git cm "Your initial commit"

2. Interactive Rebase: Replace the lengthy `git rebase -i HEAD~3` with:

ri = rebase -i

Usage:

git ri HEAD~3

3. Staging All Changes: Use a simple `git aa` instead of `git add --all`:

aa = add --all

4. Viewing Logs: Instead of `git log --oneline --graph --all`, configure:

lg = log --oneline --graph --all

Usage:

git lg

5. Deleting Branches: Replace git branch -d with:

bd = branch -d

Usage:

git bd feature-branch

Useful Git Aliases

To further streamline your Git experience, I've compiled an extensive list of Git aliases that cover a wide range of functionalities, from basic commit operations to advanced log filtering. This comprehensive list is designed to cater to both novice and seasoned Git users.

How to Use the Gist

Explore the Gist: Browse through the list of aliases in the Gist. Each alias is accompanied by a brief description, making it easier to understand its purpose and usage.
Incorporate Into Your Workflow: Select the aliases that resonate with your daily Git tasks. You can add these aliases to your .gitconfig file or set them up using the git config command, as explained earlier in this post.
Customization: Feel free to modify or expand upon these aliases to better fit your personal workflow. Git aliases are highly flexible and can be tailored to meet your specific needs.

Sharing and Collaboration

If you have suggestions or additional aliases that could benefit others, consider contributing to the Gist. Collaboration and knowledge sharing are key to enhancing our collective Git experience.

Final Thoughts

With this extensive list of Git aliases and the foundational knowledge from this post, you're well-equipped to make your Git usage more efficient and enjoyable. Embrace the power of Git aliases and watch your productivity soar!

Remember, the key to effective use of Git aliases lies in identifying the Git commands you use most frequently and simplifying them to suit your workflow.

Tidy Up Your VSCode Explorer with File Nesting

Rogério Rodrigues de Alcântara — Thu, 18 Jan 2024 03:45:25 +0000

Just a quick note of a nifty VSCode feature to streamline the project's explorer view by nesting related files under a single parent file. This is done through the explorer.fileNesting.patterns setting.

It’s a visual aid that keeps your workspace uncluttered.

How to Configure File Nesting

To configure file nesting, access your settings JSON file and add or modify the explorer.fileNesting.patterns. Here's an example that nests common project files under package.json:



"explorer.fileNesting.enabled": true,

"explorer.fileNesting.expand": false,

"explorer.fileNesting.patterns": {

  "package.json": ".babelrc, .browserslistrc, .dockerignore, .editorconfig, .env, .eslintignore, .eslintrc., .gitignore, .graphqlrc., .nvmrc, .prettierignore, .prettierrc.*, README.md, babel.config.json, cypress.json, jest.config.ts, jest.preset.js, nx.json, package.json, tsconfig.base.json, tsconfig.json, workspace.json, yarn.lock, vercel.json, netlify.toml, pnpm-lock.yaml"

}

Benefits of File Nesting

Cleaner Workspace: Reduces clutter by showing only relevant files at a glance.
Improved Focus: Helps you focus on the files you are actively working on.
Better Organization: Groups logically related files together.

Remember, you can always adapt the nesting patterns to fit your project's structure and your personal preferences.

References

VSCode Docs - Explorer file nesting

Some suggestions on GitHub's Pull Request Settings to Think About

Rogério Rodrigues de Alcântara — Mon, 25 Sep 2023 14:26:23 +0000

GitHub offers different ways to merge pull requests into your repository.

Depending on your project’s needs and preferences, you can choose which merge methods to enable or disable in your repository settings. Here are some suggestions of pull request settings on GitHub to consider/think about:

“Allow Merge Commits:” ❌

This means that you cannot use the merge commit method to merge pull requests. The merge commit method creates a new commit that combines the commits from the base branch and the head branch.

“Allow Squash Merging” ❌

This means that you cannot use the squash merge method to merge pull requests. The squash merge method combines all the commits from the head branch into a single commit and adds it to the base branch.

“Allow Rebase Merging” ✅

This means that you can use the rebase merge method to merge pull requests. The rebase merge method applies the commits from the head branch individually on top of the base branch.

“Always suggest updating pull request branches” ✅

This means that GitHub will suggest that you update the head branch of your pull request if there are new commits on the base branch. This can help avoid merge conflicts and keep the commit history clean.

“Automatically delete head branches” ✅

This means that GitHub will automatically delete the head branch of your pull request after it is merged. This can help keep your repository organized and avoid unnecessary branches.

These are some of the pull request settings on GitHub that you can consider or think about for your project.

By choosing the right merge methods and options, you can ensure that your pull requests are merged smoothly and efficiently, while maintaining a clear and consistent commit history.

You can also customize your pull request settings further by using branch protection rules, required reviews, status checks, and more.

The one on Firebase 🔥

Rogério Rodrigues de Alcântara — Thu, 21 Sep 2023 17:33:17 +0000

A curated list of awesome resources on Firebase!

Build extraordinary apps with Firebase

All the tools you need to build a successful app: reach new users, keep them engaged, scale up an infrastructure to meet that demand, in addition to earning money.

Test different variants with ease

Improve your app experience by creating variants of your app and testing them with real users, then use the results to make improvements that drive the metrics you care about, like user engagement and revenue.

Realtime crash reporting

Lightweight, realtime crash reporter that helps you track, prioritize, and fix stability issues that erode your app quality, intelligently grouping crashes and highlighting the circumstances that lead up to them.

Create personalized experiences

Change the look-and-feel of your app, gradually roll out features, run A/B tests, and deliver customized content to certain users, all from the cloud without needing to publish a new version of your app.

Engage active users with contextual messages

Send targeted, personalized, and contextual messages that nudge them through app funnels toward the ultimate in-app action, like subscribing, watching a video, completing a level, or buying an item, triggered based on user behavior.

Re-engage users with personalized messages

Manage and send notifications to your users easily, measuring the effectiveness of your messages, with no additional coding required.

Bring the power of machine learning

A set of tools and services for bringing powerful machine learning features to your app.

Distribute pre-release builds to trusted testers

Manage all of your pre-release testing on Android and iOS in one place.

Prepackaged solutions with extended functionalities

Written, tested, and debugged by the Firebase team.

📉 Predictions

Predict user behavior with machine learning

Increase user retention, reduce churn, and improve in-app purchase revenue with predictive analytics and targeting.

Getting Started with Predictions

Anticipate your users’ actions through machine-learned models of their behavior: which of your users are likely to churn, which are likely to make in-app purchases, and etc.

📈 Analytics

Behavioral analytics and marketing analytics

Provide all the data in one easy place. It's free and unlimited analytics that combines both behavioral analytics -- who your users are and what they do in your app -- with marketing analytics -- which lets you see which campaigns brought users to your app in the first place.

Track events with Google Analytics for Firebase

Events are user interactions that you want to measure. Events can be automatically collected or manually defined by you, used to create audiences and analyze user behavior.

Conversions: events that matter the most

Conversions shows how many conversion events and purchases, along with how much revenue and life-time value were driven by each aspect of your marketing (e.g., campaign, ad network, creative)

Walkthrough the Google Analytics for Firebase dashboard

Get to know all of your reports and settings.

Use audiences and user properties to analyze users

Feature flagging to test new features

Change the behavior and appearance of your app without requiring users to download an app update. Test different features and then analyze the results.

Tracking events

Ever wondered which users are interacting with your app, what part of your app they are spending the most time on, and where they are encountering issues?

Tracking marketing campaigns

Know which marketing efforts get the most new users and which marketing efforts keep them coming back.

How to monitor errors and performance in Cloud Functions with Open Telemetry

Leverage the Google Cloud Platform to adopt a modern observability stack like OpenTelemetry to effectively monitor Cloud Functions.

[PLAYLIST: Google Analytics for Firebase]

Google Analytics for Firebase is a free app measurement solution that provides insight on app usage and user engagement, helps to understand clearly how users behave, which enables informed decisions regarding app marketing and performance optimizations.

Google Analytics for Firebase - YouTube

Google Analytics for Firebase is a free app measurement solution that provides insight on app usage and user engagement. Documentation here: https://goo.gl/7...

youtube.com

🔌 Extensions

Firebase Extensions Hub

Find extensions to build an app quickly and easily

extensions.dev

Quickstart

Get started with the amazing Firebase Extensions

[Firebase Summit "21] Build your retail app step-by-step

Build a web-based coffee retail app with fully functional e-commerce features using Firebase products including Firestore, Authentication, and Extensions.

Connect millions of developers to your product by building a Firebase Extension

Sign up, build, and publish your own extension on extensions.dev for Firebase and Google Cloud developers. This could be either a utility package, an API integration, database functionality, or something else.

📰 Updates

The biggest news from Firebase Demo Day 2023

Top six biggest announcements that include (but not limited to) Duet AI in Firebase, AI-powered automated app testing, Firebase Flutter SDK support for Windows development, Firebase Hosting’s integration with Project IDX, and more.

Firebase Demo Day 2023

Short demos that showcase what’s new, what’s possible, and how you can solve your biggest app development challenges with Firebase.

Firebase Demo Day - YouTube

Join us on November 8, 2023 for a new virtual experience where we’ll unveil short demos that showcase what’s new, what’s possible, and how you can solve your...

youtube.com

Firebase Summit ‘22 Keynote

Latest product updates, shows demos of how it works smoothly with the ecosystem of developer tools to accelerate app development.

Catch up on @ Google I/O ‘23

From new AI Extensions to real-time updates for Remote Config, learn how to make full stack development seamless and simpler.

What’s new in Cloud Firestore at Google I/O ‘23

The latest query features, Eventarc integration that supports triggering in new compute destinations, and Terraform provisioning.

Git-Flow vs GitHub flow

Rogério Rodrigues de Alcântara — Mon, 18 Sep 2023 15:41:27 +0000

A Practical Comparison

When choosing a Git branching model, consider these widely adopted approaches:

The GitFlow ✵

Suited for structured release cycles
Helps manage complex projects with long-lived branches

The GitHub flow ✵

Ideal for continuous deployment and rapid iteration
Streamlined for frequent releases

A quick comparison

Aspect	Git-Flow	GitHub flow
Purpose	Designed for structured, long-term development cycles	Optimized for Continuous Integration and delivery
Main focus	Structured release cycles	Continuous deployment
Main branches	`master`, `develop`, `feature`, `release`	`main`, short-lived feature branches
Complexity	Higher; suited for larger projects	Lower; suited for fast-moving projects
Release strategy	Multi-stage releases (dev, QA, prod)	Direct to production after merging
Best for	Large apps with formal releases	Web apps, startups, frequent releases
Challenges	Can slow down development due to its complexity and multiple branches	Can be too simplistic for large projects
Use cases	Large-scale projects such as operating systems or ERP systems	SaaS platforms, mobile apps with frequent updates, or web services

DECISION TREE

SUMMARY

Both Git-Flow and GitHub flow serve distinct purposes.

For agility, GitHub flow streamlines development and deployment, fostering faster iteration and innovation.

While Git-Flow is structured for enterprise applications, GitHub flow shines for speed and simplicity.

With fewer branches and a direct-to-production process, GitHub flow enables teams to focus on delivering value quickly.

REFERENCES

DISCLAIMER

This content is my own exploration of Git workflows and is open to feedback and new insights.

:wq cheats/code-review

Rogério Rodrigues de Alcântara — Wed, 13 Sep 2023 19:36:36 +0000

The One About Code Reviews

TL;RD

Some best practices for getting great Code Reviews

Keeping the Pull Request small and focused on a single feature or bug fix
Providing clear and concise descriptions of the changes made
Including relevant documentation and tests
Addressing any known issues or potential concerns in the description
Requesting specific feedback or areas of review from the reviewers
Being responsive and open to feedback during the review process
Making changes and updates based on the feedback received
Keeping the Pull Request up-to-date with the latest changes in the codebase.

Some best practices for giving great Code Reviews

Setting clear expectations for the review process
Focusing on the code, not the person who wrote it
Providing specific, actionable feedback
Being respectful and constructive in your comments
Prioritizing high-impact issues over minor ones
Following up on the review to ensure that feedback is addressed
Encouraging collaboration and discussion among team members.

Some common mistakes to avoid

Making the review personal or attacking the author
Focusing on minor issues at the expense of larger ones
Being too nitpicky or pedantic
Not providing enough context or explanation for your feedback
Not following up on the review to ensure that feedback is addressed
Not being open to feedback yourself
Not considering the bigger picture or the project's goals.

My Favorite Resources on Code Reviews

Curated list of tools, articles, books, and any other resource related to code review

Pull Requests, Code Review, and the GitHub Flow • GitHub Universe 2015

Discusses the benefits of using the GitHub Flow for development. GitHub Flow helps to promote collaboration, code review, and continuous delivery.

What are pull requests?

Pull requests are a way to propose changes to a codebase and get them reviewed by other developers.
They are a key part of the GitHub Flow, a development workflow that emphasizes collaboration and code review.
Why are pull requests important?

Pull requests help to ensure that code is of high quality and that it meets the team's standards.
They also help to promote collaboration and knowledge sharing among developers.
How to create a good pull request
- Write a clear and concise description of your changes.
- Make sure your changes are small and focused.
- Test your changes thoroughly before submitting your pull request.
- Be responsive to feedback from reviewers.
How to review a pull request
- Take the time to read and understand the changes.
- Test the changes yourself.
- Provide constructive feedback to the developer.
- Be respectful of the developer's time.
Here are some additional key takeaways from the talk:
- Pull requests should be used for all changes to the codebase, no matter how small.
- Code reviews should be focused on the overall quality of the code, not just on finding bugs.
- It is important to be respectful of the developer's time when providing feedback on a pull request.
- The GitHub Flow is a great development workflow for teams of all sizes.

Code Review is an Architectural Necessity • GitHub Universe 2016

Emphasizes the importance of making code review a regular part of the development process. Code review should be seen as an investment in the quality and maintainability of the software system.

Code review is an architectural necessity because it helps to ensure that code is:
- Correct: Code review helps to catch bugs and errors in code before it is deployed to production.
- Consistent: Code review helps to ensure that code is written in a consistent style and that it follows the team's coding standards.
- Maintainable: Code review helps to ensure that code is easy to read and understand, making it easier to maintain in the future.
- Secure: Code review can help to identify and fix security vulnerabilities in code.
Code review can also help to improve the overall architecture of a software system by:
- Identifying and refactoring potential architectural flaws: Code review can help to identify areas of the code that are poorly designed or that could be improved.
- Ensuring that the code is aligned with the overall architectural vision for the system: Code review can help to ensure that the code is being written in a way that is consistent with the team's overall architectural vision for the system.
Tips for effective code review:
- Set clear expectations for code reviews: The team should have a clear understanding of what is expected of code reviews, such as what types of issues should be raised and how the reviews should be conducted.
- Use a code review tool: A code review tool can help to streamline the code review process and make it more efficient.
- Be constructive in your feedback: Code reviewers should focus on providing constructive feedback that will help the developer improve their code.
- Be respectful of the developer's time: Code reviews should be conducted in a timely manner, and reviewers should be respectful of the developer's time.

Implementing a Strong Code-Review Culture • RailsConf 2015

Code reviews are not about catching bugs.
Modern code reviews are about socialization, learning, and teaching.

The primary purpose of code review: Improve the overall code health of the system being worked on, not to catch bugs or enforce style guides.
Reviewers should favor approving a change, even if the change isn’t perfect: Once it is in a state where it definitely improves the overall code health of the system.
Reviewers should balance out: The need to make forward progress compared to the importance of the changes they are suggesting.
Reviewers should also mentor developers: By teaching them something new about a language, a framework, or general software design principles.
Reviewers should not require the author to polish every tiny piece of a change before granting approval: But they should feel free to leave comments expressing that something could be better, prefixed with something like "Nit: " to let the author know that it’s just a point of polish that they could choose to ignore.
Reviewing code and writing easily-reviewed features are skills: That will make developers better and more productive teammates.

Goldilocks And The Three Code Reviews • JSConf Budapest 2017

Encourages developers to be supportive of each other and to learn from each other's code

The three types of code reviews

Too short: This type of review is too focused on finding bugs, and it doesn't give enough feedback on the overall quality of the code.
Too long: This type of review is too nitpicky, and it can discourage developers from submitting their code for review.
Just right: This type of review is focused on finding bugs and improving the overall quality of the code, but it is also respectful of the developer's time and effort.

How to write a good code review

Focus on the overall quality of the code, not just on finding bugs.
Be constructive and specific in your feedback.
Be respectful of the developer's time and effort.

How to get the most out of code reviews

Be open to feedback and suggestions.
Be willing to make changes to your code.
Ask questions if you don't understand something.

The Science of Code Reviews • DPC2018

Code reviews should be seen as an opportunity to learn and grow, not as a way to criticize or blame developers

Code reviews are an important part of the software development process: They help to improve the quality of the code by identifying and fixing bugs, improving the overall design of the code, and ensuring that the code follows the team's coding standards.
However, code reviews can be time-consuming and inefficient: It can be difficult to know which parts of the code to focus on, and it can be challenging to provide constructive feedback.
Research on code reviews has shown that there are a number of factors that can affect the effectiveness of code reviews. These factors include:
- The size and complexity of the code being reviewed.
- The experience and expertise of the reviewers.
- The process used for the code review.

Based on this research, Kuipers recommends a number of best practices for code reviews

Focus on the most important parts of the code: Not all code is created equal. Some parts of the code are more important than others, and they should be the focus of the code review.
Use a code review tool: A code review tool can help to automate tasks such as identifying potential bugs and code violations. This can save time and effort, and it can help to improve the quality of the code review.
Provide constructive feedback: The goal of a code review is to improve the code, not to criticize the developer. Feedback should be specific and actionable, and it should be delivered in a respectful and constructive manner.

Code Reviews: Honesty, Kindness, Inspiration: Pick Three by Jacob Stoebel • RubyConf 2017

Introduces the Liz Lerman Critical Response process for code reviews. Encouraging to try out this process and see how it can improve their code reviews and their team culture

Code reviews can be both honest and nice: While code reviews should be both honest and kind, they should be focused on inspiring creators to go back to their work, excited to make it better.
The Liz Lerman Critical Response process consists of:
- #1. statement of meaning
- #2. artist questions
- #3. neutral questions
- #4. permissioned opinions

Amazing Code Reviews: Creating a Superhero Collective • GOTO 2019

Many code reviews are superficial, unclear, or unhelpful, which can lead to frustration, wasted time, and missed opportunities
Code reviews are an important step for improving the code health, quality, and knowledge of the system being worked on
How to create a culture of amazing code reviews in software development teams

Key principles and practices of Shopify's code review process

Focus on the intent of the change, not the implementation
Provide actionable feedback that helps the author improve their code and learn something new
Use positive language and empathy to communicate their feedback in a respectful and constructive way
Trust the author to make the final decision on their change
Celebrate the author's work and achievements

Benefits and challenges of this code review process, such as:

Increases the collaboration, learning, and motivation of the team
Improves the consistency, readability, and maintainability of the code base
Requires more time, effort, and skill from both reviewers and authors
Depends on the context, culture, and preferences of the team

Creating Simple and Effective Guidelines for Code Reviews • @newrelic

Simple and effective code review guidelines that will help them to improve the quality of their code

Clear, concise, and easy to understand

They should be written in a way that is accessible to both experienced and inexperienced developers.
Tailored to the specific needs of the team and the project

The guidelines should take into account the type of code being reviewed, the experience level of the reviewers, and the goals of the code review.
Focused on the quality of the code, not on the individual developer

The guidelines should be used to identify and fix bugs, improve the overall design of the code, and ensure that the code follows the team's coding standards.
Updated regularly

To reflect the team's changing needs and practices

Recommendations for code review guidelines

Identifying and fixing bugs
- Look for common bugs such as missing semicolons, unending loops, and missing error handling.
- Be aware of the team's coding standards and ensure that the code follows them.
- Test the code yourself to see if it works as expected.
Improving the overall design of the code
- Look for areas where the code can be simplified or refactored.
- Suggest ways to make the code more readable and maintainable.
- Consider the overall architecture of the system and ensure that the code fits well within it.
Ensuring that the code follows the team's coding standards
- Look for areas where the code does not follow the team's coding standards.
- Suggest ways to make the code more consistent with the team's standards.
- Be aware of any new coding standards that have been adopted by the team.

Code Review As A Gateway • @jetbrains

Overall, code review as a gateway is a valuable process that can help to improve the quality of code, reduce the risk of regressions, and improve collaboration between developers.

Code review as a gateway is a process where a code review is required before any code is merged into the main branch.

This process can help to ensure that the code is of high quality and that it meets the team's standards.

There are a number of benefits to using code review as a gateway

Improved code quality

Code reviews can help to identify and fix bugs in the code, improve the overall design of the code, and ensure that the code follows the team's coding standards.
Reduced risk of regressions

Code reviews can help to prevent regressions by ensuring that new code does not break existing functionality.
Improved collaboration

Code reviews can help to improve collaboration between developers by providing a forum for developers to discuss their code and learn from each other.

There are a few things to keep in mind when implementing code review as a gateway:

Setting clear expectations

It is important to set clear expectations for code reviews, such as what types of issues should be raised and how the reviews should be conducted.
Providing training

It is important to provide training to developers on how to conduct effective code reviews.
Using a code review tool

A code review tool can help to automate tasks such as identifying potential bugs and code violations. This can save time and effort, and it can help to improve the quality of the code review.
Being flexible

It is important to be flexible when implementing code review as a gateway. There may be cases where it makes sense to bypass the code review process, such as for small changes or for changes that are made by experienced developers.

How to Do Code Reviews Like a Human (Part One) • @mtlynch.io

Emphasizes the importance of having a "blameless culture" when it comes to code review.

Focus on finding and fixing bugs, not on blaming the developer who wrote the code.

Code review is a process in which one or more developers review the code of another developer.
Code review can help to improve the quality of the code by identifying and fixing bugs, improving the overall design of the code, and ensuring that the code follows the team's coding standards.
To be effective, code reviews should be conducted in a collaborative and respectful manner.

Here are some tips for doing code reviews like a human:

Set clear expectations for the code review

This includes things like what types of issues should be raised and how the reviews should be conducted.
Be prepared for the code review

This means taking the time to read and understand the code before the review begins.
Be specific and constructive in your feedback

Focus on providing feedback that will help the developer improve their code.
Be respectful of the developer's time.

Code reviews should be conducted in a timely manner, and reviewers should be respectful of the developer's time.

How to Do Code Reviews Like a Human (Part Two) • @mtlynch.io

Emphasizes the importance of creating a positive and supportive culture for code reviews. Code reviews should be seen as an opportunity to learn and grow, not as a way to criticize or blame developers.

How to handle disagreements in code reviews

Be respectful and open-minded

Even if you disagree with a developer's code, it's important to be respectful of their work and to be open to their perspective.
Try to understand the developer's motivation

Why did they write the code in the way that they did? Once you understand their motivation, you can better understand their reasoning and you may be able to find a compromise.
Be willing to compromise

It's important to be willing to compromise in code reviews. Not every change that you suggest will be accepted, and that's okay.
Don't be afraid to escalate the issue

If you can't come to an agreement with a developer, you may need to escalate the issue to a more senior developer or to a manager.

How to give effective feedback in code reviews

Be specific and actionable

Don't just say "This code is bad." Explain why you think the code is bad and suggest a specific way to fix it.
Be positive and constructive

Focus on providing feedback that will help the developer improve their code. Avoid being negative or critical.
Be concise and to the point

Don't overwhelm the developer with a lot of feedback. Focus on the most important issues.
Be open to feedback yourself

It's important to be open to feedback from other developers, even if you don't agree with it.

How to get the most out of code reviews

Be open to feedback

Be willing to listen to feedback from other developers and to make changes to your code based on their feedback.
Be prepared for the code review

Take the time to read and understand the code before the review begins.
Be responsive to feedback

If a developer raises an issue with your code, try to address it promptly.
Ask questions

If you don't understand something in the code, ask questions.

How to Give and Get Better Code Reviews • @medium

Emphasizes the importance of creating a culture of "trust" and "respect" in order to foster effective code reviews.
Encourages developers to be supportive of each other and to learn from each other's code.

How to give better code reviews:
- Try to understand the context and the proposed solution.
- Be specific and actionable in your feedback.
- Focus on the overall quality of the code, not just on finding bugs.
- Be respectful of the developer's time and effort.
How to get the most out of code reviews:
- Be open to feedback and suggestions.
- Be willing to make changes to your code.
- Ask questions if you don't understand something.
Additional tips:
- Set clear expectations for code reviews.
- Use a code review tool.
- Be constructive in your feedback.
- Be respectful of the developer's time.
- Make code review a regular part of the development process.

REFERENCES

:wq cheats/git-commits

Rogério Rodrigues de Alcântara — Wed, 13 Sep 2023 19:30:15 +0000

Git Commits

7 rules of a great Git commit message

#1 Keep in mind: This has all been said before.
#2 Separate subject from body with a blank line
#3 Limit the subject line to 50 characters
#4 Capitalise the subject line
#5 Do not end the subject line with a period
#6 Use the imperative mood in the subject line
#7 Wrap the body at 72 characters
#8 Use the body to explain what and why vs. how

Commit message structure

<type>[optional scope]: <Description>

[optional body]

[optional footer(s)]

Examples

Commit with description and breaking change footer.

feat: Allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in the config file is now used for extending other config files

Commit with ! to draw attention to breaking change.

feat!: Send an email to the customer when the product is shipped

Commit with scope and ! to draw attention to breaking change.

feat(api)!: Send email to the customer when product is shipped

Commit with both! And BREAKING CHANGE footer.

chore!: Drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.

Commit with nobody

docs(CHANGELOG): Correct spelling

Commit with scope

feat(lang): Add Polish

Commit with a multi-paragraph body and multiple footers.

fix(requests): Prevent racing

Introduce a request ID and a reference to the latest request.

Also:
- Dismiss incoming responses other than from the latest request.
- Remove timeouts, which were used to mitigate the racing issue but are obsolete now.

Refs: #123

Use GitHub Copilot for Better Commit Messages in VSCode

Add to settings.json:

    // https://medium.com/medialesson/setting-up-github-copilot-for-better-commit-messages-in-vs-code-82d73fb6b016
    "github.copilot.chat.commitMessageGeneration.instructions": [
        { "text": "Use conventional commit format: <type>[(scope)]: <Subject>\n\n[optional body]\n\n[optional footer(s)]" },
        { "text": "Use types: feat, fix, docs, style, ref, test, revert, chore, ci, build, perf, git" },
        { "text": "Include scope when relevant (e.g.: 'api', 'ui', 'auth', 'admin/users')" },
        { "text": "Separate subject from body with a blank line" },
        { "text": "The subject should use the imperative mood, be capitalised, short, clear, concise, descriptive, meaningful, and communicate the context surrounding a change" },
        { "text": "Limit the subject line to 50 characters" },
        { "text": "Do not end the subject line with a period" },
        { "text": "The body should explain what and why vs. how" },
        { "text": "Wrap the body at 72 characters" },
        { "text": "Reference issue numbers with # prefix" },
        { "text": "Use the footer to reference breaking changes with 'BREAKING CHANGE: <description>'" },
        { "text": "Use the footer to reference issues with 'Closes #<issue-number>'" },
        { "text": "Use the footer to reference links that may exceed 72 characters with 'More: https://very.long.link/lorem-ipsum-excepteur-anim-dolore-et-laborum-officia-nostrud-nisi-tempor-in.-Sint-laboris-ex-ea-ex/'" },
        { "text": "Follow the constraints defined in the gitlint configuration, in order of precedence: ./.gitlint, ~/.config/gitlint/gitlint.cfg" }
    ],

Tooling

References

:wq cheats/solid

Rogério Rodrigues de Alcântara — Wed, 13 Sep 2023 19:12:14 +0000

SOLID

Design principles encourage us to create more maintainable, understandable, and flexible software.

Consequently, as our applications grow in size, we can reduce their complexity and save ourselves a lot of headaches further down the road!

Single-responsibility

There should never be more than one reason for a class to change or every class should have only one responsibility

That is, a class should only have one responsibility. Furthermore, it should only have one reason to change.

Benefits

Testing

A class with one responsibility will have far fewer test cases
Lower coupling

Less functionality in a single class will have fewer dependencies
Organization

Smaller, well-organized classes are easier to search than monolithic ones.

Open–closed

Software entities should be open for extension, but closed for modification

In doing so, we stop ourselves from modifying existing code and causing potential new bugs.

Benefits:

Error Prevention

Minimize the possibilities of error by not modifying existing classes.
Functionality Extension

Easily add new functionalities by adding new classes wherein no current functionality depends on the new classes.
Responsibility Segregation

Promote the Single Responsibility Principle
Class Testing

Unit test each class

Liskov substitution

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it

That is, if class A is a subtype of class B, we should be able to replace B with A without disrupting the behavior of our program.

Benefits

Code reusability

Allows creating a set of related classes that can be used interchangeably without modifying the code. This makes it easier to reuse code and can save us time when we’re developing new features.
Easier maintenance

Avoids introducing conditional logic or type checking to handle different subclasses. This makes the code more readable and easier to maintain. It also reduces the risk of introducing bugs or breaking changes when we add or modify subclasses.
Reduced coupling

Reduces the dependency between classes and make them more loosely coupled. This means that changes in one class will not affect other classes that depend on it. This also makes the code more flexible and adaptable to changing requirements

Interface segregation

Many client-specific interfaces are better than one general-purpose interface

That is, larger interfaces should be split into smaller ones. By doing so, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them.

Dependency inversion

Depend upon abstractions, not concretions

This way, instead of high-level modules depending on low-level modules, both will depend on abstractions.

Benefits

Decoupling

The code becomes more modular and less tightly coupled. This makes it easier to maintain, extend, and test the code. It also reduces the impact of changes in one module on other modules
Reusability:

The code becomes more reusable and adaptable. High-level modules can use different low-level modules that implement the same abstraction without modifying the code. This allows for swapping implementations, mocking dependencies, and supporting different scenarios
Inversion of control

The flow of the application is inverted from low-level modules to high-level modules. High-level modules define the abstractions and own the interfaces, while low-level modules provide the implementations and depend on the interfaces. This gives more power and flexibility to the high-level modules

References

:wq cheat/12factor

Rogério Rodrigues de Alcântara — Wed, 13 Sep 2023 17:33:29 +0000

The Twelve-Factor App

"A methodology for building modern, scalable, maintainable software-as-a-service apps."

Codebase
One codebase tracked in revision control, many deploys
Dependencies
Explicitly declare and isolate dependencies
Config
Store config in the environment
Backing services
Treat backing services as attached resources
Build, release, run
Strictly separate build and run stages
Processes
Execute the app as one or more stateless processes
Port binding
Export services via port binding
Concurrency
Scale out via the process model
Disposability
Maximize robustness with fast startup and graceful shutdown
Dev/prod parity
Keep development, staging, and production as similar as possible
Logs
Treat logs as event streams
Admin Processes
Run admin/management tasks as one-off processes

References

The Twelve-Factor App: A methodology for building modern, scalable, maintainable software-as-a-service apps

DEV Community: Rogério Rodrigues de Alcântara

FCIS — Functional Core, Imperative Shell

Why Bother?

How It Compares

vs. Clean Architecture / Hexagonal Architecture (Ports & Adapters)

Clean / Hexagonal vs. FCIS

Isolation mechanism

Boilerplate

Testability

Learning curve

Best fit

SUGGESTION

vs. Domain-Driven Design (DDD)

The key differences

vs. Layered / N-Tier Architecture

vs. Functional Programming (pure FP)

MAIN CONCEPTS

The Core (src/core/)

The Shell (src/shell/)

ERROR HANDLING

TESTING

Bu, when NOT TO USE IT?

Pre-Commit Checklist

REFERENCES

Adding Zsh Completion for `gh copilot`

Add a few aliases (optional)

Create the Completion Script

Install the Completion Script

1. Create a Completions Directory

2. Move the Script

3. Update Your $fpath

4. Ensure the Script Is Executable

5. Enable Alias Completion

6. Reload Zsh Configuration

Is that so?

Summary

Convert insert mutation to upsert

Summary

References

Simplifying Your Git Workflow with Aliases

Simplifying Your Git Workflow with Aliases

Introduction to Git Aliases

How to Configure Git Aliases

Setting an Alias via .gitconfig

Setting an Alias via Command Line

Examples of Git Aliases

1. Quick Commit: Instead of typing git commit -m "Your message", use:

2. Interactive Rebase: Replace the lengthy git rebase -i HEAD~3 with:

3. Staging All Changes: Use a simple git aa instead of git add --all:

4. Viewing Logs: Instead of git log --oneline --graph --all, configure:

5. Deleting Branches: Replace git branch -d with:

Useful Git Aliases

How to Use the Gist

Sharing and Collaboration

Final Thoughts

Tidy Up Your VSCode Explorer with File Nesting

How to Configure File Nesting

Benefits of File Nesting

References

Some suggestions on GitHub's Pull Request Settings to Think About

The one on Firebase 🔥

📉 Predictions

📈 Analytics

Google Analytics for Firebase - YouTube

🔌 Extensions

📰 Updates

Firebase Demo Day - YouTube

Git-Flow vs GitHub flow

A Practical Comparison

The GitFlow ✵

The GitHub flow ✵

A quick comparison

DECISION TREE

SUMMARY

REFERENCES

DISCLAIMER

:wq cheats/code-review

The One About Code Reviews

My Favorite Resources on Code Reviews

The three types of code reviews

vs. Functional Programming `(pure FP)`

The Core `(src/core/)`

The Shell `(src/shell/)`

Setting an Alias via `.gitconfig`

1. Quick Commit: Instead of typing `git commit -m "Your message"`, use:

2. Interactive Rebase: Replace the lengthy `git rebase -i HEAD~3` with:

3. Staging All Changes: Use a simple `git aa` instead of `git add --all`:

4. Viewing Logs: Instead of `git log --oneline --graph --all`, configure: