And somewhere in that chain, something often goes wrong: an incorrect API key, a missed signing step, a build that worked on one machine and failed on another.

The solution is a properly configured CI/CD pipeline that takes that entire chain out of human hands. And in this article, we're building exactly that using Codemagic.

What is Codemagic?

Codemagic is a dedicated CI/CD platform built from the ground up specifically for mobile applications.

Unlike general-purpose CI platforms, Codemagic understands Flutter natively. It ships with Flutter pre-installed on its build machines, has dedicated support for Apple code signing, and integrates directly with both the Google Play Store and App Store Connect. This means less configuration noise and more focus on what actually matters , which is your deployment logic.

The pipeline we'll be building covers three distinct stages across both Android and iOS:

• A pull request gate that blocks unverified code from reaching your base branch

• A staging pipeline that injects real environment config, builds signed artifacts, and ships them to testers via Firebase App Distribution and TestFlight

• A production pipeline that obfuscates builds, uploads crash symbols to Sentry, and submits directly to the Play Store and App Store Connect

Table of Contents

• Prerequisites

• Understanding Codemagic's YAML Approach

• Pipeline Architecture

• The Helper Scripts

• PR Quality Gate

• Android Pipeline

• iOS Pipeline

• Environment Variables and Secrets Reference

• End-to-End Flow

• Conclusion

Prerequisites

You'll need the following before starting:

• A Flutter app with functional Android and iOS builds

• A Codemagic account with your repository connected

• A Firebase project with App Distribution set up

• A Sentry project configured for your app

• A Google Play Console app with at least an internal track ready

• An Apple Developer account with App Store Connect access

• A Google Play service account with the necessary API permissions

• Familiarity with writing Bash scripts

Understanding Codemagic's YAML Approach

Codemagic offers a visual workflow editor for teams that prefer a GUI – but we're not using that here. The codemagic.yaml approach gives you version-controlled, reviewable, fully reproducible pipeline definitions that live right alongside your application code. Any change to the pipeline goes through the same PR process as any other change. That matters in a team environment.

The file lives at the root of your project:

your-flutter-app/
  codemagic.yaml     
  lib/
  android/
  ios/
  scripts/

Codemagic detects this file when a build is triggered and executes the appropriate workflow based on the rules you define. One file, multiple workflows, all environments – no duplication.

Pipeline Architecture

Before writing any YAML, it helps to define exactly what the pipeline needs to do. The use case here is a team with three protected branches: develop, staging, and production. Each branch represents a distinct stage in the release lifecycle, and the pipeline behaves differently depending on which branch triggered it.

Here is how the three environments map to pipeline behaviour:

PR into develop: When a developer raises a pull request targeting the develop branch, a quality gate workflow fires. It runs code formatting checks, static analysis, the full test suite, and enforces a minimum coverage threshold. The PR cannot be considered clean until all of these pass.

Push to develop or staging: When code lands on either of these branches, the platform-specific build pipelines trigger. They detect the target branch, inject the correct environment configuration (dev or staging API keys), build signed artifacts, and distribute them to the appropriate testing channels: Firebase App Distribution for Android, TestFlight for iOS.

Push to production: When code reaches the production branch, the pipelines switch into release mode. Builds are obfuscated, debug symbols are uploaded to Sentry for crash observability, and the final artifacts are submitted directly to the Play Store and App Store Connect.

Your project structure will look like this:

codemagic.yaml

scripts/
  generate_config.sh
  quality_checks.sh
  upload_symbols.sh

lib/
  core/
    env/
      env_ci.dart       
      env_ci.g.dart     

The Helper Scripts

Rather than cramming logic directly into YAML, this pipeline delegates its core operations to three Bash scripts that live in a scripts/ folder at the project root. This keeps the YAML readable and, crucially, means you can run the exact same logic on your local machine that CI runs – eliminating an entire class of "works on my machine" issues.

Make all three scripts executable before committing them:

chmod +x scripts/generate_config.sh
chmod +x scripts/quality_checks.sh
chmod +x scripts/upload_symbols.sh

generate_config.sh

Injecting secrets safely is one of the hardest CI/CD problems in mobile development. The strategy here avoids committing credentials entirely: a Dart file with placeholder values is committed to source control, and at build time the script replaces those placeholders with real values sourced from Codemagic's encrypted secret storage.

#!/usr/bin/env bash
set -euo pipefail

# Usage: ./scripts/generate_config.sh ENV_NAME BASE_URL ENCRYPTION_KEY
ENV_NAME=${1:-}
BASE_URL=${2:-}
ENCRYPTION_KEY=${3:-}

TEMPLATE="lib/core/env/env_ci.dart"
OUT="lib/core/env/env_ci.g.dart"

if [ -z "\(ENV_NAME" ] || [ -z "\)BASE_URL" ] || [ -z "$ENCRYPTION_KEY" ]; then
  echo "Usage: $0 <env-name> <base-url> <encryption-key>"
  exit 2
fi

sed -e "s|<<BASE_URL>>|$BASE_URL|g" \
    -e "s|<<ENCRYPTION_KEY>>|$ENCRYPTION_KEY|g" \
    -e "s|<<ENV_NAME>>|$ENV_NAME|g" \
    "\(TEMPLATE" > "\)OUT"

echo "✅ Generated config for $ENV_NAME"

How it works:

set -euo pipefail enforces strict failure behaviour. -e exits immediately on any failed command, -u exits on undefined variables, and -o pipefail catches failures anywhere in a pipeline – not just the last command. In CI, silent failures can produce broken builds that look like they succeeded. This line prevents that.

The script takes three positional arguments: the environment name (dev, staging, or production), the API base URL, and an encryption or API key. The ${1:-} syntax defaults to an empty string if an argument is missing, which the validation block then catches explicitly with a clear usage message and an exit code of 2 (the conventional code for incorrect usage).

At the heart of the script, sed performs three placeholder replacements in a single pass over the template file, writing the result to env_ci.g.dart. That generated file must be added to .gitignore. It only ever exists inside a running build or on a developer's local machine after they run the script manually.

The two Dart files involved have completely different roles:

env_ci.dart – committed to source control, contains only placeholders:

// lib/core/env/env_ci.dart
class EnvConfig {
  static const String baseUrl = '<<BASE_URL>>';
  static const String encryptionKey = '<<ENCRYPTION_KEY>>';
  static const String environment = '<<ENV_NAME>>';
}

env_ci.g.dart – generated at build time, contains real values, never committed:

// lib/core/env/env_ci.g.dart
// GENERATED FILE — DO NOT COMMIT
class EnvConfig {
  static const String baseUrl = 'https://staging.api.example.com';
  static const String encryptionKey = 'sk_live_xxxxx';
  static const String environment = 'staging';
}

Add the generated file to .gitignore:

# Generated environment config
lib/core/env/env_ci.g.dart

quality_checks.sh

This script defines what passing quality means for your codebase. Every check it runs is a gate: if any step fails, the script stops immediately and the build fails.

#!/usr/bin/env bash
set -euo pipefail

echo "🚀 Running quality checks"

dart format --output=none --set-exit-if-changed .
flutter analyze
flutter test --no-pub --coverage

if command -v dart_code_metrics >/dev/null 2>&1; then
  dart_code_metrics analyze lib --reporter=console || true
fi

echo "✅ Quality checks passed"

What each step does:

dart format --output=none --set-exit-if-changed .: checks that all Dart files are formatted correctly without modifying them. If any file doesn't match the formatter's output, the command exits with a non-zero code, failing the build. Formatting is non-negotiable here.

flutter analyze: runs Dart's static analyser across the entire project. It catches null safety violations, unused imports, missing awaits, dead code, and a wide range of structural issues before they reach a reviewer's eyes.

flutter test --no-pub --coverage: runs the full test suite and generates a coverage report at coverage/lcov.info. The --no-pub flag skips pub get since dependencies are already installed. The coverage file is used downstream to enforce a minimum threshold.

The dart_code_metrics block is deliberately optional and non-blocking (|| true). The tool may not be installed in every environment, and its findings are advisory rather than hard failures. You can remove the || true later to make it mandatory once your team has adopted the tool.

The final echo line only executes if every step above it passed , because set -e would have exited the script on any earlier failure. If you see it in the logs, the branch is clean.

upload_symbols.sh

When Flutter production builds are compiled with --obfuscate, stack traces in crash reports become unreadable. This script uploads the debug symbol files that Sentry needs to reverse that obfuscation and show readable crash reports.

#!/usr/bin/env bash
set -euo pipefail

RELEASE=${1:-}

[ -z "$RELEASE" ] && exit 2

if ! command -v sentry-cli >/dev/null 2>&1; then
  exit 0
fi

sentry-cli releases new "$RELEASE" || true
sentry-cli upload-dif build/symbols || true
sentry-cli releases finalize "$RELEASE" || true

echo "✅ Symbols uploaded for release $RELEASE"

How it works:

The script takes a single argument: a release identifier. In practice, this is always the short Git commit SHA, passed from the workflow as $(git rev-parse --short HEAD). This ties the uploaded symbols, the deployed build, and the crash reports in Sentry to the exact same commit , which is essential for production debugging.

If sentry-cli is not installed in the environment, the script exits with 0 rather than failing. This makes symbol uploads environment-aware: production machines install the CLI, development environments skip the step cleanly without breaking the build.

Each sentry-cli command uses || true for resilience. Symbol uploads should never block a deployment , if the upload encounters a transient issue, the build should still succeed and the symbols can be re-uploaded manually from the stored artifacts.

The three commands do the following in sequence: releases new registers the release version in Sentry, upload-dif sends the debug information files from build/symbols (generated by --split-debug-info), and releases finalize marks the release as deployed and ready to aggregate crash reports.

The codemagic.yaml Structure

A codemagic.yaml file is organized around workflows. Each workflow is an independent pipeline definition with its own trigger rules, environment configuration, build scripts, and publishing targets. Multiple workflows live inside the same file under a top-level workflows key.

The skeleton looks like this:

workflows:
  pr-quality-gate:
    # triggers on pull requests
    # runs quality checks only

  android-pipeline:
    # triggers on push to develop, staging, production
    # handles Android builds and distribution

  ios-pipeline:
    # triggers on push to develop, staging, production
    # handles iOS builds and distribution

Each workflow can define its own machine type, environment variables, triggering conditions, and step scripts. This is what makes a single codemagic.yaml powerful: you're not managing three separate files, but you still get complete isolation between pipeline stages.

PR Quality Gate

Every PR raised against develop must pass a quality gate before any merge is allowed. This workflow runs on Codemagic's Linux machines since it doesn't need to produce a signed artifact for any platform – it only needs to verify the code.

workflows:
  pr-quality-gate:
    name: PR Quality Gate
    max_build_duration: 30
    instance_type: linux_x2

    triggering:
      events:
        - pull_request
      branch_patterns:
        - pattern: develop
          include: true
          source: true

    environment:
      flutter: stable

    scripts:
      - name: Install dependencies
        script: flutter pub get

      - name: Run quality checks
        script: ./scripts/quality_checks.sh

      - name: Enforce coverage threshold
        script: |
          COVERAGE=\((lcov --summary coverage/lcov.info | grep lines | awk '{print \)2}' | sed 's/%//')
          if [ \((echo "\)COVERAGE < 70" | bc) -eq 1 ]; then
            echo "Test coverage is at ${COVERAGE}% — minimum required is 70%"
            exit 1
          fi
          echo "Coverage at ${COVERAGE}% — threshold met"

    publishing:
      email:
        recipients:
          - your-team@example.com
        notify:
          success: true
          failure: true

Let's walk through what each section is doing.

instance_type: linux_x2

Codemagic offers different machine types for different workloads. For a quality gate that only needs to run Dart tooling, a Linux machine is perfectly sufficient and significantly cheaper than a macOS instance. You reserve the macOS machines for builds that actually need Xcode.

triggering

This is how Codemagic decides when to run a workflow. The pull_request event fires whenever a PR is opened or updated. The branch_patterns block tells Codemagic to watch for PRs targeting develop specifically. The source: true flag means this pattern applies to the target branch of the PR, not the source branch – so any branch raising a PR into develop will trigger this workflow.

environment

Codemagic's Flutter-aware machines come with multiple Flutter versions available. Setting flutter: stable pins the workflow to the current stable channel without requiring any manual SDK installation step. This is one of the areas where Codemagic saves setup time compared to a general-purpose runner.

Quality checks script

The workflow delegates to quality_checks.sh rather than inlining commands. This keeps the YAML readable and ensures the exact same logic runs when a developer calls the script locally. The script handles formatting, analysis, and test execution internally.

Coverage enforcement

After the tests run, lcov parses the coverage report generated by flutter test --coverage and extracts the line coverage percentage. If it falls below 70%, the build fails with a clear message. This threshold is something your team should agree on , 70% is a reasonable starting point for most projects.

publishing

Codemagic has native email notification support built in. Rather than scripting echo statements into CI logs, you declare recipients directly in the workflow and Codemagic handles delivery. Both success and failure states are covered.

Android Pipeline

The Android workflow handles all three environments in a single workflow definition, using Codemagic's environment variable groups and conditional scripting to behave differently depending on which branch triggered the build.

  android-pipeline:
    name: Android Build & Release
    max_build_duration: 60
    instance_type: linux_x2

    triggering:
      events:
        - push
      branch_patterns:
        - pattern: develop
          include: true
        - pattern: staging
          include: true
        - pattern: production
          include: true

    environment:
      flutter: stable
      android_signing:
        - android_keystore
      groups:
        - staging_secrets
        - production_secrets
        - firebase_credentials
        - sentry_credentials

    scripts:
      - name: Install dependencies
        script: flutter pub get

      - name: Detect environment
        script: |
          BRANCH=$(git rev-parse --abbrev-ref HEAD)
          if [ "$BRANCH" = "develop" ]; then
            echo "ENV=dev" >> $CM_ENV
          elif [ "$BRANCH" = "staging" ]; then
            echo "ENV=staging" >> $CM_ENV
          else
            echo "ENV=production" >> $CM_ENV
          fi

      - name: Generate environment config
        script: |
          if [ "$ENV" = "dev" ]; then
            ./scripts/generate_config.sh dev "https://dev.api.example.com" "dev_dummy_key"
          elif [ "$ENV" = "staging" ]; then
            ./scripts/generate_config.sh staging "\(STAGING_BASE_URL" "\)STAGING_API_KEY"
          else
            ./scripts/generate_config.sh production "\(PROD_BASE_URL" "\)PROD_API_KEY"
          fi

      - name: Build Android artifact
        script: |
          if [ "$ENV" = "production" ]; then
            flutter build appbundle --release \
              --obfuscate \
              --split-debug-info=build/symbols
          else
            flutter build appbundle --release
          fi

      - name: Distribute to Firebase App Distribution
        script: |
          if [ "\(ENV" = "dev" ] || [ "\)ENV" = "staging" ]; then
            firebase appdistribution:distribute \
              build/app/outputs/bundle/release/app-release.aab \
              --app "$FIREBASE_ANDROID_APP_ID" \
              --groups "$FIREBASE_GROUPS" \
              --token "$FIREBASE_TOKEN"
          fi

      - name: Submit to Play Store
        script: |
          if [ "$ENV" = "production" ]; then
            echo "$GOOGLE_PLAY_SERVICE_ACCOUNT_JSON" > /tmp/service_account.json
            flutter pub global activate fastlane 2>/dev/null || true
            fastlane supply \
              --aab build/app/outputs/bundle/release/app-release.aab \
              --json_key /tmp/service_account.json \
              --package_name com.your.package \
              --track production
          fi

      - name: Upload Sentry symbols
        script: |
          if [ "$ENV" = "production" ]; then
            ./scripts/upload_symbols.sh $(git rev-parse --short HEAD)
          fi

    artifacts:
      - build/app/outputs/bundle/release/app-release.aab
      - build/symbols/**

    publishing:
      email:
        recipients:
          - your-team@example.com
        notify:
          success: true
          failure: true

Here is what each section is doing and why it's designed this way.

android_signing

This is one of Codemagic's most valuable features. Instead of manually decoding a Base64 keystore and writing it to disk inside a script, you upload your keystore file directly to Codemagic's encrypted key storage under Teams → Code signing identities → Android keystores. You give it a reference name – android_keystore in this case – and Codemagic handles decoding, placement, and key.properties generation automatically before your build scripts run.

This eliminates an entire category of signing-related build failures.

groups

Codemagic lets you organize secrets into named groups in the environment variables section of your team settings. Rather than declaring individual secrets inline, you reference groups. The groups used here are:

• staging_secrets: contains STAGING_BASE_URL and STAGING_API_KEY

• production_secrets: contains PROD_BASE_URL and PROD_API_KEY

• firebase_credentials: contains FIREBASE_TOKEN, FIREBASE_ANDROID_APP_ID, FIREBASE_GROUPS

• sentry_credentials: contains SENTRY_AUTH_TOKEN, SENTRY_ORG, SENTRY_PROJECT

Environment detection with $CM_ENV

Codemagic exposes a special file path via the $CM_ENV variable. Writing KEY=VALUE to this file makes that variable available to every subsequent script step in the same build. This is how the branch name gets translated into an environment label that the rest of the pipeline reads.

Build differentiation

Production builds use --obfuscate and --split-debug-info=build/symbols. Dev and staging builds skip both flags for faster compilation and readable local stack traces.

Firebase distribution

The Firebase CLI distributes dev and staging builds to testers. Because Codemagic's Linux machines come with Node.js available, you can install the Firebase CLI with npm install -g firebase-tools as a setup step if it is not already present, or invoke it via npx.

Play Store submission

Production app bundles go to the Play Store using Fastlane's supply command. The service account JSON is written to a temporary file from the environment variable and passed to Fastlane directly. Replace com.your.package with your actual application ID.

artifacts

The artifacts section tells Codemagic which files to preserve after the build completes. These files become downloadable from the Codemagic build dashboard. The debug symbols are captured here as well, which is useful for manual Sentry uploads if the automated step ever needs to be re-run.

iOS Pipeline

iOS on Codemagic is where the platform's advantage becomes most visible. Apple code signing on a general-purpose runner requires a multi-step keychain dance involving security commands, certificate imports, and provisioning profile placement. Codemagic handles all of that automatically through its native signing integration.

  ios-pipeline:
    name: iOS Build & Release
    max_build_duration: 90
    instance_type: mac_mini_m2

    triggering:
      events:
        - push
      branch_patterns:
        - pattern: develop
          include: true
        - pattern: staging
          include: true
        - pattern: production
          include: true

    environment:
      flutter: stable
      ios_signing:
        distribution_type: app_store
        bundle_identifier: com.your.bundle.id
      groups:
        - staging_secrets
        - production_secrets
        - app_store_credentials
        - sentry_credentials

    scripts:
      - name: Install dependencies
        script: flutter pub get

      - name: Install Fastlane dependencies
        script: |
          cd ios
          gem install bundler --user-install
          bundle install

      - name: Detect environment
        script: |
          BRANCH=$(git rev-parse --abbrev-ref HEAD)
          if [ "$BRANCH" = "develop" ]; then
            echo "ENV=dev" >> $CM_ENV
          elif [ "$BRANCH" = "staging" ]; then
            echo "ENV=staging" >> $CM_ENV
          else
            echo "ENV=production" >> $CM_ENV
          fi

      - name: Generate environment config
        script: |
          if [ "$ENV" = "dev" ]; then
            ./scripts/generate_config.sh dev "https://dev.api.example.com" "dev_dummy_key"
          elif [ "$ENV" = "staging" ]; then
            ./scripts/generate_config.sh staging "\(STAGING_BASE_URL" "\)STAGING_API_KEY"
          else
            ./scripts/generate_config.sh production "\(PROD_BASE_URL" "\)PROD_API_KEY"
          fi

      - name: Build iOS (dev — no signing)
        script: |
          if [ "$ENV" = "dev" ]; then
            flutter build ios --release --no-codesign
          fi

      - name: Build and ship to TestFlight (staging)
        script: |
          if [ "$ENV" = "staging" ]; then
            flutter build ipa --release \
              --export-options-plist=/Users/builder/export_options.plist
            cd ios && bundle exec fastlane beta
          fi

      - name: Build and release to App Store (production)
        script: |
          if [ "$ENV" = "production" ]; then
            flutter build ipa --release \
              --obfuscate \
              --split-debug-info=build/symbols \
              --export-options-plist=/Users/builder/export_options.plist
            cd ios && bundle exec fastlane release
          fi

      - name: Upload Sentry symbols
        script: |
          if [ "$ENV" = "production" ]; then
            ./scripts/upload_symbols.sh $(git rev-parse --short HEAD)
          fi

    artifacts:
      - build/ios/ipa/*.ipa
      - build/symbols/**
      - /tmp/xcodebuild_logs/*.log

    publishing:
      app_store_connect:
        api_key: $APP_STORE_CONNECT_PRIVATE_KEY
        key_id: $APP_STORE_CONNECT_KEY_IDENTIFIER
        issuer_id: $APP_STORE_CONNECT_ISSUER_ID
        submit_to_testflight: true
        submit_to_app_store: false
      email:
        recipients:
          - your-team@example.com
        notify:
          success: true
          failure: true

Here's what is different from the Android workflow and why.

mac_mini_m2

iOS builds require Xcode, which means they need macOS. Codemagic provides Apple Silicon Mac Mini instances. These are meaningfully faster than Intel-based runners for Flutter and Xcode workloads, and Codemagic provisions them on demand without any infrastructure management on your side.

ios_signing

This is the section that replaces the entire keychain setup sequence. You upload your distribution certificate and provisioning profile once to Codemagic's code signing identities under your team settings. The distribution_type: app_store tells Codemagic to use App Store distribution signing, and bundle_identifier ties it to your specific app. Before your scripts run, Codemagic installs the certificate and profile automatically on the build machine.

No security commands, no keychain creation, no Base64 decoding. It's handled internally.

flutter build ipa

On iOS, the build output is an .ipa file rather than an .aab. Flutter's flutter build ipa command produces this directly when provided with an export options plist. The plist tells Xcode how to sign and package the output. Codemagic generates this file automatically based on your ios_signing configuration and places it at /Users/builder/export_options.plist.

Fastlane lanes

Codemagic installs Fastlane via Bundler in the ios/ directory, then calls the appropriate lane based on the detected environment. The beta lane uploads to TestFlight, and the release lane submits to the App Store.

publishing.app_store_connect

Codemagic has a native App Store Connect publisher. Rather than scripting the upload manually, you declare your API credentials in the publishing block and Codemagic handles the submission. The submit_to_testflight: true flag means staging builds are automatically available to TestFlight testers after the build completes. For production, you would flip submit_to_app_store to true instead.

Xcode logs as artifacts

The line /tmp/xcodebuild_logs/*.log captures raw Xcode build logs as downloadable artifacts. When an iOS build fails and the error message in the Codemagic dashboard is not specific enough, these logs are where you find the real cause.

Environment Variables and Secrets Reference

All secrets are configured in Codemagic under Teams → Environment variables. Group them logically so they can be referenced cleanly in the YAML.

staging_secrets group

production_secrets group

firebase_credentials group

app_store_credentials group

sentry_credentials group

For Android code signing, upload your keystore directly under Teams → Code signing identities → Android keystores rather than storing it as an environment variable.

For iOS, upload your distribution certificate and provisioning profile under Teams → Code signing identities → iOS certificates.

End-to-End Flow

With the full codemagic.yaml in place, here is the complete picture of what happens across a typical release cycle.

A developer finishes a feature and raises a PR into develop. Codemagic detects the pull request event and triggers the pr-quality-gate workflow on a Linux machine. The quality checks script runs formatting, analysis, tests, and coverage threshold check. If anything fails, Codemagic marks the build as failed, sends the team an email, and the PR cannot be considered ready. The developer pushes a fix, Codemagic runs again, and only when everything passes does the PR move forward.

Once the PR merges into develop, both the android-pipeline and ios-pipeline trigger simultaneously. Each detects develop as the source branch, maps it to the dev environment, injects placeholder config, builds an unsigned release artifact, and ships it to Firebase App Distribution. Testers have an installable build within minutes of the merge completing.

When develop is merged into staging, the same two platform pipelines fire again. This time real secrets are injected , the staging API URL, the staging encryption key. Android builds are signed with the keystore Codemagic manages automatically. iOS builds go through Fastlane's beta lane to TestFlight. The Codemagic App Store Connect publisher handles the TestFlight upload natively. QA now has a properly signed, properly configured staging build to test against.

When staging is promoted to production, the pipelines enter release mode. Production secrets are injected. Android builds are obfuscated with debug symbols split into build/symbols. iOS builds go through flutter build ipa with obfuscation enabled. Both platform pipelines call upload_symbols.sh with the current commit SHA, linking the Sentry release to the exact code that shipped. The Android bundle goes to the Play Store via Fastlane. The iOS IPA is submitted to App Store Connect via Codemagic's native publisher. The team receives a success notification.

That's the full cycle. No terminal, no manual step, no shared Slack message saying "I think I deployed staging."

Conclusion

The pipeline we just built covers the full release lifecycle: automated quality enforcement, environment-aware config injection, platform-specific signed builds, tester distribution, crash observability, and store submission , all from a single codemagic.yaml file.

What Codemagic brings to this setup is a tighter integration with the mobile ecosystem specifically. The keystore management, native App Store Connect publisher, pre-installed Flutter toolchain, and Apple Silicon Mac instances aren't add-ons you configure , they're part of the platform's core. This translates into fewer steps to maintain, fewer failure surfaces, and a pipeline that's easier to reason about when something does go wrong.

The scripts in your scripts/ folder remain completely platform-agnostic. If your team ever needs to move pipelines, those scripts move with you unchanged. The YAML changes, but the logic doesn't.

What you have at the end of this setup is a release process your team can trust: one where "did it deploy?" is answered by a notification, not a question in Slack.

Also, CodeIgnitor’s MVC (Model-View-Controller) architecture makes the process of organizing code and separating business logic from the user interface a piece of cake, yielding cleaner and maintainable projects.

Whether you’re building a small website or a complex application, CodeIgniter has a bunch of tools, libraries, and helpers that make the development process easier. They help you handle common tasks like database queries, session management, and form validation. Many devs love this tool because of its ease of use, making it an ideal framework for both beginners and experienced coders.

In this guide, I’ll walk you through the process of configuring CodeIgniter step by step, ensuring that you have a fully functional setup for your project on your local development environment.

Prerequisites

Before getting started, make sure you meet the following requirements:

• Basic Knowledge of PHP: Understanding PHP syntax and basic programming concepts will help you follow along more easily.

• Web Server (for example, Apache or NGINX): CodeIgniter needs a server to run. Make sure you have a working server set up on your local machine or hosting environment.

• PHP Installed: You’ll need PHP 7.3 or higher (depending on the version of CodeIgniter you’re using).

• Database System: CodeIgniter supports several databases, but MySQL is the most commonly used. Make sure you have access to a database system and know its credentials.

• CodeIgniter Download: Download the latest version of CodeIgniter from the official website, GitHub repository, or use composer to install it.

How to Use Composer to Install CodeIgniter

Now that you understand the prerequisites and have everything set up, let’s move on to installing CodeIgniter. One of the easiest and most efficient ways to install CodeIgniter is by using Composer, a popular dependency management tool for PHP. In this section, I’ll guide you through the steps to install CodeIgniter using Composer.

First, create a new directory using mkdir my_project then navigate to the directory using cd my_project. Run the following Composer command to install CodeIgniter. You can specify the version you want (e.g., ^4.0 for the latest version of CodeIgniter 4).

composer create-project codeigniter4/appstarter .

This command will download and install the latest version of CodeIgniter 4 and set up the project for you:

After the installation is complete, you should see the CodeIgniter project structure in your directory. To check if everything is working, you can start the built-in PHP server by running:

php spark serve

Output:

Then, open your browser and go to http://localhost:8080. You should see the CodeIgniter welcome page.

How to Install CodeIgniter Manually

If you prefer not to use Composer, or if you’re working in an environment where Composer isn’t available, you can manually install CodeIgniter. This method involves downloading the framework files directly and setting up your project manually. While it requires a few more steps than using Composer, it’s still straightforward and gives you full control over the installation process.

In this section, I’ll walk you through the steps to manually install CodeIgniter and configure it for your project.

Download via Git:

cd /var/www/html
sudo git clone https://github.com/bcit-ci/CodeIgniter.git codeigniter

Or download as ZIP (from CodeIgniter official website): Download here. Extract it in /var/www/html. Whereby you can do so using the terminal or UI.

Extracting the ZIP File via the UI:

If you’re not comfortable using command-line tools, you can easily extract the ZIP file using your computer’s graphical interface. Here's how:

Click on files/Other Locations/computer to access /var/www/html. Copy the .Zip file you downloaded earlier in the created folder and right click. Then click on extract here to unzip it.

Extracting the ZIP File via the Terminal:

If you’re comfortable using the command line, you can extract the CodeIgniter ZIP file directly via the terminal. This method is especially useful for Linux and macOS users or if you're working on a remote server without a graphical user interface.

First, ensure you have unzip installed on your Ubuntu system:

sudo apt update
sudo apt install unzip

Check your permissions to ensure that you have the necessary access to the /var/www/html directory. If needed, use sudo for administrative privileges.

Steps to Extract the File

Assuming your uploaded file is currently located in downloads/data…, move it to /var/www/html:

sudo mv /mnt/data/CodeIgniter.zip /var/www/html

Navigate to the /var/www/htmldirectory:

cd /var/www/html

Extract the ZIP file by using the unzip command to extract the contents:

sudo unzip CodeIgniter.zip

After extracting, set the correct ownership and permissions for web server access:

sudo chown -R www-data:www-data /var/www/html
sudo chmod -R 755 /var/www/html

• www-data (first part) → The user.

• www-data (second part) → The group.

change Codeigniter-develop /bcit-ci-CodeIgniter-bcb17eb/….folder name to just codeigniter

Verify Extraction

Visit your web server's URL (for example, http://localhost) to check if the contents are correctly deployed.

Set Folder Permissions

After installing CodeIgniter, make sure you have the correct permissions for your directories, particularly writable and cache directories. This ensures that CodeIgniter can write logs, cache files, and session data.

Run the following commands to set the correct permissions:

sudo chmod -R 755 /var/www/html/codeigniter

Configure the Base URL

The base URL for your project needs to be set up in application/config/config.php.

Open the config.php file:

sudo nano /var/www/html/codeigniter/application/config/config.php

Output:

Set the base_url as follows:

$config['base_url'] = 'http://your-domain-or-ip/';

Replace http://your-domain-or-ip/ with your actual domain or IP address where the project will be accessible.

After making changes:

• Save the file: Press Ctrl + O (Write Out).

• Confirm the filename: Press Enter.

• Exit the editor: Press Ctrl + X.

Configure the Database (if Applicable)

If your project uses a database, you'll need to set up the database configuration in application/config/database.php.

To do this, open the database configuration file:

sudo nano /var/www/html/codeigniter/application/config/database.php

Configure the database connection by setting the following options:

$db['default'] = array(
    'dsn'   => '',
    'hostname' => 'localhost',
    'username' => 'your-db-username',
    'password' => 'your-db-password',
    'database' => 'your-database-name',
    'dbdriver' => 'mysqli',
    'dbprefix' => '',
    'pconnect' => FALSE,
    'db_debug' => (ENVIRONMENT !== 'production'),
    'cache_on' => FALSE,
    'cachedir' => '',
    'char_set' => 'utf8',
    'dbcollat' => 'utf8_general_ci',
    'swap_pre' => '',
    'encrypt' => FALSE,
    'compress' => FALSE,
    'stricton' => FALSE,
    'failover' => array(),
    'save_queries' => TRUE
);

Replace your-db-username, your-db-password, and your-database-name with your actual database credentials.

Set the Environment

CodeIgniter uses the environment setting to load different configuration files depending on the environment (for example, development, production).

To set the environment, open the index.php file in the root directory of your project:

sudo nano /var/www/html/codeigniter/index.php

Locate the following line:

define('ENVIRONMENT', 'development');

You can set it to production, testing, or development depending on your setup. For development, it should be set to development

Autoload Libraries, Helpers, or Config Files

You can specify which libraries, helpers, or config files to autoload in application/config/autoload.php. Open the autoload configuration file:

sudo nano /var/www/html/codeigniter/application/config/autoload.php

Modify the autoload array to load commonly used libraries and helpers:

$autoload['libraries'] = array('database', 'session', 'form_validation');
$autoload['helper'] = array('url', 'file');

Enable Mod Rewrite (For Clean URLs)

If you want clean URLs, you need to enable mod_rewrite on Apache. Edit the Apache configuration file as follows:

sudo nano /etc/apache2/sites-available/000-default.conf

Ensure that the AllowOverride directive is set to All in the <Directory> section:

<Directory /var/www/html>
    AllowOverride All
</Directory>

Enable mod_rewrite and restart Apache:

sudo a2enmod rewrite
sudo systemctl restart apache2

Verify CodeIgniter Directory Placement

If CodeIgniter is not in /opt/lampp/htdocs, move it there:

sudo mv /var/www/html/codeigniter /opt/lampp/htdocs/

Test CodeIgniter

Open your web browser and navigate to the base URL (http://your-domain-or-ip). You should see the default CodeIgniter welcome page if everything is set up correctly:

Run curl ifconfig.me to find your public IP. If you're hosting CodeIgniter on a local machine (for example, in your home network), use the following command to check your local IP: hostname -I.

Troubleshooting

If you encounter any issues while setting up CodeIgniter, here are some common problems and how to resolve them:

Set CodeIgniter as the Default App

If you want CodeIgniter to load as the default app (instead of the XAMPP landing page if you have XAMPP installed), remove or rename the default index.php in the htdocs directory:

sudo mv /opt/lampp/htdocs/index.php /opt/lampp/htdocs/index.php.bak

Move the CodeIgniter files to the root of the htdocs folder:

sudo mv /opt/lampp/htdocs/codeigniter/* /opt/lampp/htdocs/

Restart Apache

After making changes, restart Apache to apply the configuration:

sudo /opt/lampp/lampp restart

Creating a Controller

To start developing your application, you can create a controller to handle requests.

Create a new controller in application/controllers/ like this:

<?php
class Welcome extends CI_Controller {
    public function index() {
        $this->load->view('welcome_message');
    }
}

Then create Views and Models. Views go into application/views/ and models into application/models/. You can start adding your views and models accordingly.

Conclusion

Setting up a development environment for CodeIgniter on Ubuntu is an essential step to unlock the full potential of this lightweight yet powerful PHP framework.

By carefully following the outlined steps—from installing prerequisites, configuring file permissions, and customizing settings to creating controllers, views, and models—you are now equipped to start building dynamic web applications.

This tutorial discusses everything you need to know to transform HTML elements like a pro.

Table of Contents

1. What is the CSS transform Property?

2. What is the CSS rotate() Function?

3. What is the CSS rotateX() Function?

4. What is the CSS rotateY() Function?

5. What is the CSS rotateZ() Function?

6. What is the CSS rotate3d() Function?

7. CSS Rotate Functions vs. rotate Property: What's the Difference?

8. What is the CSS scale() Function?

9. CSS scale() Function vs. scale Property: What's the Difference?

10. What is the CSS scaleZ() Function?

11. What is the CSS scale3d() Function?

12. What is the CSS skew() Function?

13. What is the CSS translate() Function?

14. What is the CSS translateZ() Function?

15. What is the CSS translate3d() Function?

16. CSS Translate Functions vs. translate Property: What's the Difference?

17. What is the CSS perspective() Function?

18. CSS perspective() Function vs. perspective Property: What's the Difference?

19. What is the CSS matrix() Function?

20. Why Does the CSS Transform Functions' Order Matter?

21. Tools for Converting Transform Functions to matrix()

22. Important Stuff to Know about Transforming Elements in CSS

23. Wrapping Up

So, without further ado, let's discuss the CSS transform property.

What Is the CSS transform Property?

The CSS transform property specifies the transformational effect you wish to apply to an HTML element.

Here's the syntax:

html-element {
  transform: value;
}

The CSS transform property accepts the following values:

• inherit: Transforms the element with its parent element's transform value.

• initial: Transforms the HTML element with its default transform value.

• matrix(): Transforms the element two-dimensionally with a matrix of six values.

• matrix3d(): Transforms the HTML element three-dimensionally with a 4x4 matrix of sixteen values.

• none: Applies no transformation to the HTML element.

• perspective(): Transforms a 3D transformed element with a perspective view.

• rotate(): Transforms the element by rotating it two-dimensionally.

• rotate3d(): Transforms the element by rotating it three-dimensionally.

• rotateX(): Transforms the element by rotating it three-dimensionally along the X-axis.

• rotateY(): Transforms the element by rotating it three-dimensionally along the Y-axis.

• rotateZ(): Transforms the HTML element by rotating it three-dimensionally along the Z-axis.

• scale(): Transforms the element by scaling it two-dimensionally.

• scale3d(): Transforms the element by scaling it three-dimensionally.

• scaleX(): Transforms the element by scaling it along the X-axis.

• scaleY(): Transforms the element by scaling it along the Y-axis.

• scaleZ(): Transforms the HTML element by scaling it three-dimensionally along the Z-axis.

• skew(): Transforms the element by skewing it two-dimensionally along the X- and Y-axis.

• skewX(): Transforms the element by skewing it two-dimensionally along the X-axis.

• skewY(): Transforms the element by skewing it two-dimensionally along the Y-axis.

• translate(): Transforms the HTML element by translating (moving) it two-dimensionally.

• translate3d(): Transforms the element by translating it three-dimensionally.

• translateX(): Transforms the element by translating it along the X-axis.

• translateY(): Transforms the element by translating it along the Y-axis.

• translateZ(): Transforms the element by translating it three-dimensionally along the Z-axis.

Note: The transform property accepts one or more CSS transform functions. For instance, here's a valid transform declaration:

div {
  transform: perspective(370px) scaleZ(5) rotate(17deg);
}

In the snippet above, we assigned three transform functions to the transform property. Let's talk more about some of transform's values.

What is the CSS rotate() Function?

rotate() transforms an element by rotating it two-dimensionally around a fixed point.

Note:

• "Transform origin" is the fixed point around which an element rotates.

• You can define your element's fixed point using the CSS transform-origin property. But the default is center.

Syntax of the CSS rotate() function

rotate() accepts a single argument. Here is the syntax:

element {
  transform: rotate(angle);
}

Note the following:

• The rotate(angle) function is equivalent to rotate3d(0, 0, 1, angle) or rotateZ(angle).

• The angle argument specifies the element's angle of rotation.

• angle can be in degrees, gradians, radians, or turns.

• An angle argument consists of a number followed by the unit you wish to use—for instance, 45deg.

• Your browser's writing direction determines the element's direction of rotation.

• A positive angle will rotate the element clockwise in a left-to-right writing direction. But a negative angle will do a counterclockwise rotation.

• A positive angle will rotate the element counterclockwise in a right-to-left writing context. But a negative angle will do a clockwise rotation.

Examples of the CSS rotate() function

Below are some examples of how the CSS rotate() function works.

How to do a zero-degree rotation in CSS:

img {
  transform: rotate(0deg);
  width: 80%;
}

Try it on StackBlitz

The snippet above used the rotate() function to specify a zero-degree (0⁰) rotation for the image element.

How to do a 45-degree rotation in CSS:

img {
  transform: rotate(45deg);
  width: 80%;
}

Try it on StackBlitz

The snippet above used the rotate() function to specify a forty-five-degree (45⁰) rotation for the image element.

How to do a negative seventy-degree rotation in CSS:

img {
  transform: rotate(-70deg);
  width: 80%;
}

Try it on StackBlitz

The snippet above used the rotate() function to specify a negative seventy-degree (70⁰) rotation for the image element.

What is the CSS rotateX() Function?

rotateX() transforms an element by rotating it three-dimensionally around the X-axis.

A three-dimensional Cartesian coordinate system showing the X-, Y-, and Z-axis

Syntax of the CSS rotateX() function

rotateX() accepts a single argument. Here is the syntax:

element {
  transform: rotateX(angle);
}

Note the following:

• The rotateX(angle) function is equivalent to rotate3d(1, 0, 0, angle).

• The angle argument specifies the element's angle of rotation.

• angle can be in degree, gradian, radian, or turn.

• An angle argument consists of a number followed by the unit you wish to use—for instance, 45deg.

Examples of the CSS rotateX() function

Below are some examples of how the CSS rotateX() function works.

How to do a zero-degree rotation around the X-axis:

img {
  transform: rotateX(0deg);
  width: 80%;
}

Try it on StackBlitz

The snippet above used the rotateX() function to specify a zero-degree (0⁰) rotation for the image around the X-axis.

How to do a 70-degree rotation around the X-axis:

img {
  transform: rotateX(70deg);
  width: 80%;
}

Try it on StackBlitz

The snippet above used the rotateX() function to specify a seventy-degree (70⁰) rotation for the image around the X-axis.

What is the CSS rotateY() Function?

rotateY() transforms an element by rotating it three-dimensionally around the Y-axis.

Syntax of the CSS rotateY() function

rotateY() accepts a single argument. Here is the syntax:

element {
  transform: rotateY(angle);
}

Note the following:

• The rotateY(angle) function is equivalent to rotate3d(0, 1, 0, angle).

• The angle argument specifies the element's angle of rotation.

• angle can be in degrees, gradians, radians, or turns.

• An angle argument consists of a number followed by the unit you wish to use—for instance, 45deg.

Examples of the CSS rotateY() function

Below are some examples of how the CSS rotateY() function works.

How to do a zero-degree rotation around the Y-axis:

img {
  transform: rotateY(0deg);
  width: 80%;
}

Try it on StackBlitz

The snippet above used the rotateY() function to specify a zero-degree (0⁰) rotation for the image around the Y-axis.

How to do a 70-degree rotation around the Y-axis:

img {
  transform: rotateY(70deg);
  width: 80%;
}

Try it on StackBlitz

The snippet above used the rotateY() function to specify a seventy-degree (70⁰) rotation for the image around the Y-axis.

What is the CSS rotateZ() Function?

rotateZ() transforms an element by rotating it three-dimensionally around the Z-axis.

Syntax of the CSS rotateZ() function

rotateZ() accepts a single argument. Here is the syntax:

element {
  transform: rotateZ(angle);
}

Note the following:

• The rotateZ(angle) function is equivalent to rotate3d(0, 0, 1, angle) or rotate(angle).

• The angle argument specifies the element's angle of rotation.

• angle can be in degrees, gradians, radians, or turns.

• An angle argument consists of a number followed by the unit you wish to use—for instance, 45deg.

Examples of the CSS rotateZ() function

Below are some examples of how the CSS rotateZ() function works.

How to do a zero-degree rotation around the Z-axis:

img {
  transform: rotateZ(0deg);
  width: 80%;
}

Try it on StackBlitz

The snippet above used the rotateZ() function to specify a zero-degree (0⁰) rotation for the image around the Z-axis.

How to do a 70-degree rotation around the Z-axis:

img {
  transform: rotateZ(70deg);
  width: 80%;
}

Try it on StackBlitz

The snippet above used the rotateZ() function to specify a seventy-degree (70⁰) rotation for the image around the Z-axis.

What is the CSS rotate3d() Function?

rotate3d() transforms an element by rotating it three-dimensionally around the x-, y-, and z-axis.

Syntax of the CSS rotate3d() function

rotate3d() accepts four arguments. Here is the syntax:

element {
  transform: rotate3d(x, y, z, angle);
}

Note the following:

• The x, y, and z arguments are numbers specifying the x-, y-, and z-coordinates.

• The coordinates are the axis around which the element will rotate.

• The angle argument specifies the element's angle of rotation.

• angle can be in degrees, gradians, radians, or turns.

• An angle argument consists of a number followed by the unit you wish to use—for instance, 45deg.

Examples of the CSS rotate3d() function

Below are some examples of how the CSS rotate3d() function works.

How to do a 70-degree rotation around the Z-axis:

img {
  transform: rotate3d(0, 0, 1, 70deg);
  width: 80%;
}

Try it on StackBlitz

The snippet above used the rotate3d() function to specify a seventy-degree (70⁰) rotation for the image around the Z-axis.

How to do a 70-degree rotation around the X-, Y-, and Z-axis:

img {
  transform: rotate3d(1, 1, 1, 70deg);
  width: 80%;
}

Try it on StackBlitz

The snippet above used the rotate3d() function to specify a seventy-degree (70⁰) rotation for the image around the x-, y-, and z-axis.

CSS Rotate Functions vs. rotate Property: What's the Difference?

CSS rotate functions and CSS rotate property provides two similar ways to specify rotation transformations.

The main differences between the two rotation techniques are as follows:

• The CSS rotate property allows rotating an element without using the CSS transform property.

• The CSS rotate property's syntax is shorter than its function alternative.

• The CSS rotate property saves you from remembering the specific order to position the transform functions.

• Browsers calculate the transform functions' matrix in the order you assigned them to the CSS transform property—from left to right.

• Browsers calculate the transform properties' matrix in the following transformation matrix order:

  1. translate

  2. rotate

  3. scale

Below are some examples.

How to use CSS rotate property vs. function to do a 45-degree rotation

img {
  rotate: 45deg; /* Equivalent to a transform: rotate(45deg) property */
  width: 80%;
}

Try it on StackBlitz

The snippet above used the rotate property to specify a forty-five-degree (45⁰) rotation for the image element.

How to use CSS rotate property vs. function to do a 70-degree rotation around the X-axis

img {
  rotate: x 70deg; /* Equal to a transform: rotateX(70deg) property */
  width: 80%;
}

Try it on StackBlitz

The snippet above used the rotate property to specify a seventy-degree (70⁰) rotation for the image around the X-axis.

How to use CSS rotate property vs. function to do a 70-degree rotation around the Y-axis

img {
  rotate: y 70deg; /* Equal to a transform: rotateY(70deg) property */
  width: 80%;
}

Try it on StackBlitz

The snippet above used the rotate property to specify a seventy-degree (70⁰) rotation for the image around the Y-axis.

How to use CSS rotate property vs. function to do a 70-degree rotation around the Z-axis

img {
  rotate: z 70deg; /* Equal to a transform: rotateZ(70deg) property */
  width: 80%;
}

Try it on StackBlitz

The snippet above used the rotate property to specify a seventy-degree (70⁰) rotation for the image around the Z-axis.

How to use CSS rotate property vs. function to do a 70-degree rotation around the X-, Y-, and Z-axis

img {
  rotate: 1 1 1 70deg; /* Equal to a transform: rotate3d(1, 1, 1, 70deg) property */
  width: 80%;
}

Try it on StackBlitz

The snippet above used the rotate property to specify a seventy-degree (70⁰) rotation for the image around the x-, y-, and z-axis.

Note: A none value tells browsers not to rotate the selected element.

What is the CSS scale() Function?

scale() transforms an element by resizing (scaling) it two-dimensionally from a fixed point.

Note:

• "Transform origin" is the fixed point from which the computer scales an element.

• You can define your element's fixed point using the CSS transform-origin property. But the default is center.

Syntax of the CSS scale() function

scale() accepts two arguments. Here is the syntax:

element {
  transform: scale(x, y);
}

Note the following:

• The x argument can be a number or percentage. It specifies the element's scaling factor along the x-axis.

• The y argument can also be a number or percentage. It defines the element's scaling factor along the y-axis.

• Y-axis' default value is x. Therefore, if you do not provide a y argument, the browser automatically uses x's value.

• Suppose x and y are equal. In that case, browsers will scale your element uniformly and preserve its aspect ratio.

A two-dimensional Cartesian coordinate system showing the X- and Y-axis

Examples of the CSS scale() function

Below are some examples of how the CSS scale() function works.

How to scale an element uniformly along the X- and Y-axis in CSS:

img {
  transform: scale(0.3);
  transform-origin: left;
}

Try it on StackBlitz

The snippet above used the scale() function to specify a 0.3 scaling factor for the image element along the X- and Y-axis.

Note:

• scale(0.3) is equivalent to scale(0.3, 0.3).

• The percentage equivalence of scale(0.3) is scale(30%).

How to scale an element non-uniformly along the X- and Y-axis in CSS:

img {
  transform: scale(0.3, 65%);
  transform-origin: top left;
}

Try it on StackBlitz

The snippet above used the scale() function to specify a 0.3 scaling factor for the image along the X-axis and 65% along the Y-axis.

How to scale an element along only the X-axis:

img {
  transform: scale(0.3, 1);
  transform-origin: top left;
}

Try it on StackBlitz

The snippet above used the scale() function to specify a 0.3 scaling factor for the image along only the X-axis.

Note:

• A scale factor of 1 or 100% tells browsers not to apply any scaling effect on the selected element.

• scale(0.3, 1) is equivalent to scaleX(0.3).

How to scale an element along only the Y-axis:

img {
  transform: scale(100%, 0.2);
  transform-origin: top left;
}

Try it on StackBlitz

The snippet above used the scale() function to specify a 0.2 scaling factor for the image along only the Y-axis.

Note:

• A 100% or 1 scale factor tells browsers not to apply any scaling effect on the selected element.

• scale(100%, 0.2) is equivalent to scaleY(0.2).

CSS scale() Function vs. scale Property: What's the Difference?

The CSS scale() function and the CSS scale property provide two similar ways to specify a scale transformation.

The main differences between the two scaling techniques are as follows:

• The CSS scale property allows scaling an element without using the CSS transform property.

• The CSS scale property's syntax is shorter than its function alternative.

• The CSS scale property saves you from remembering the specific order to position the transform functions.

• Browsers calculate the transform functions' matrix in the order you assigned them to the CSS transform property—from left to right.

• Browsers calculate the transform properties' matrix in the following order:

  1. translate

  2. rotate

  3. scale

Here's an example:

Use the CSS scale property to scale an element nonuniformly along the X- and Y-axis.

img {
  scale: 0.3 65%; /* Equal to a transform: scale(0.3, 65%) property */
  transform-origin: top left;
}

Try it on StackBlitz

The snippet above used the scale property to specify a 0.3 scaling factor for the image along the X-axis and 65% along the Y-axis.

Note: A none value tells browsers not to scale the selected element.

What is the CSS scaleZ() Function?

scaleZ() transforms an element by resizing (scaling) it three-dimensionally from a fixed point along the z-axis.

Note:

• "Transform origin" is the fixed point from which the computer scales an element.

• You can define your element's fixed point using the CSS transform-origin property. But the default is center.

Syntax of the CSS scaleZ() function

scaleZ() accepts a single argument. Here is the syntax:

element {
  transform: scaleZ(number);
}

Note:

• The scaleZ(number) function is equivalent to scale3d(1, 1, number).

• The number argument specifies the element's scaling factor along the z-axis.

Examples of the CSS scaleZ() function

We often use scaleZ() with other CSS functions such as perspective(), translateZ(), and rotateX(). Below are some examples.

How to use scaleZ() with CSS perspective() and rotateX() functions:

img {
  transform: perspective(370px) scaleZ(5) rotateX(17deg);
  width: 80%;
}

Try it on StackBlitz

Here's what we did in the snippet above:

1. We used the perspective() function to define a 370px distance between the user and the z=0 plane.

2. The scaleZ() function specifies a scale factor of 5 for the image along the z-axis.

3. We used the rotateX() function to rotate the image seventeen-degree (17⁰) around the x-axis.

Note:

• List perspective() first whenever you chain it with other CSS transform functions. Otherwise, browsers might transform the selected element incorrectly.

• List the scaleZ() function before rotateX(). Otherwise, the browser will not scale the element.

How to use scaleZ() with CSS perspective() and translateZ() functions:

img {
  width: 40%;
}

.second-image {
  transform: perspective(370px) scaleZ(5) translateZ(30px);
}

Try it on StackBlitz

Here's what we did in the snippet above:

1. We used the perspective() function to define a 370px distance between the user and the z=0 plane.

2. The scaleZ() function specifies a scale factor of 5 for the image along the z-axis.

3. We used the translateZ() function to reposition the second-image thirty pixels (30px) away from its original position along the z-axis.

What is the CSS scale3d() Function?

scale3d() transforms an element by resizing (scaling) it three-dimensionally from a fixed point along the x-, y-, and z-axis.

Note:

• "Transform origin" is the fixed point from which the computer scales an element.

• You can define your element's fixed point using the CSS transform-origin property. But the default is center.

Syntax of the CSS scale3d() function

scale3d() accepts three arguments. Here is the syntax:

element {
  transform: scale3d(x, y, z);
}

The x, y, and z arguments are numbers specifying the x-, y-, and z-coordinates. The coordinates are the axis along which browsers will scale the element.

Examples of the CSS scale3d() function

Below are some examples of how the CSS scale3d() function works.

How to use scale3d() with CSS perspective() and rotateX() functions:

img {
  transform: perspective(370px) scale3d(1, 1, 5) rotateX(17deg);
  width: 80%;
}

Try it on StackBlitz

Here's what we did in the snippet above:

1. We used the perspective() function to define a 370px distance between the user and the z=0 plane.

2. The scale3d() function specifies a scale factor of 1, 1, and 5 for the image along the x-, y-, and z-axis.

3. We used the rotateX() function to rotate the image seventeen-degrees (17⁰) around the x-axis.

Note:

• A scale factor of 1 will apply no scaling effect on the element.

• List perspective() first whenever you chain it with other CSS transform functions. Otherwise, browsers might transform the selected element incorrectly.

• List the scale3d() function before rotateX(). Otherwise, the browser will not scale the element.

How to scale elements three-dimensionally:

img {
  width: 40%;
}

.second-image {
  transform: scale3d(5, 3, 0.05);
  transform-origin: top left;
}

Try it on StackBlitz

We used the scale3d() function to specify a scale factor of 5, 3, and 0.05 for the image along the x-, y-, and z-axis.

What is the CSS skew() Function?

skew() transforms an element by slanting (skewing) it two-dimensionally around a fixed point.

Note:

• "Transform origin" is the fixed point from which the computer skews an element.

• You can define your element's fixed point using the CSS transform-origin property. But the default is center.

Syntax of the CSS skew() function

skew() accepts two arguments. Here is the syntax:

element {
  transform: skew(aX, aY);
}

Note the following:

• The aX argument specifies the element's skewing angle along the x-axis.

• The aY argument specifies the element's skewing angle along the y-axis.

• aX and aY can be in degrees, gradians, radians, or turns.

• An angle argument consists of a number followed by the unit you wish to use—for instance, 45deg.

• aY is an optional argument.

Examples of the CSS skew() function

Below are some examples of how the CSS skew() function works.

How to skew an element along only the X-axis:

img {
  transform: skew(30deg);
  transform-origin: top;
  width: 80%;
}

Try it on StackBlitz

The snippet above used the skew() function to apply a thirty-degree (30⁰) slant on the image along only the x-axis.

Note: skew(30deg) is equivalent to skewX(30deg).

How to skew an element along only the Y-axis:

img {
  transform: skew(0, 40deg);
  transform-origin: top left;
  width: 80%;
}

Try it on StackBlitz

The snippet above used the skew() function to apply a forty-degree (40⁰) slant on the image along only the y-axis.

Note:

• A zero (0) skew degree tells browsers not to apply any skewing effect on the selected element.

• skew(0, 40deg) is equivalent to skewY(40deg).

How to skew an element along the X- and Y-axis:

img {
  transform: skew(30deg, 40deg);
  transform-origin: top left;
  width: 80%;
}

Try it on StackBlitz

The snippet above used the skew() function to apply a thirty-degree (30⁰) slant on the image along the x-axis. And forty-degree (40⁰) along the y-axis.

What is the CSS translate() Function?

translate() transforms an element by repositioning (translating) it two-dimensionally.

Syntax of the CSS translate() function

translate() accepts two arguments. Here is the syntax:

element {
  transform: translate(x, y);
}

Note the following:

• The x argument can be a length or percentage value. It specifies the distance you wish to move the element from its original x-axis position.

• The y argument can be a length or percentage value. It defines the distance you wish to move the element from its original y-axis position.

• y is an optional argument.

Examples of the CSS translate() function

Below are some examples of how the CSS translate() function works.

How to translate an element along only the X-axis:

img {
  transform: translate(150px);
  width: 80%;
}

Try it on StackBlitz

The snippet above used the translate() function to reposition the image 150px away from its original position along the x-axis.

You can also write it like this, specifying the X:

img {
  transform: translateX(150px);
  width: 80%

Note: translate(150px) is equivalent to translateX(150px).

How to translate an element along only the Y-axis:

img {
  transform: translate(0, 55%);
  width: 80%;
}

Try it on StackBlitz

The snippet above used the translate() function to reposition the image 55% away from its original position along the y-axis.

Note:

• A zero (0) translate distance tells browsers not to apply any translating effect on the selected element.

• translate(0, 55%) is equivalent to translateY(55%).

How to translate an element along the X- and Y-axis:

img {
  transform: translate(60%, 300px);
  width: 80%;
}

Try it on StackBlitz

The snippet above used the translate() function to reposition the image 60% away from its original position along the x-axis and 300px from its y-axis.

What is the CSS translateZ() Function?

translateZ() transforms an element by repositioning (translating) it three-dimensionally along the z-axis.

A three-dimensional Cartesian coordinate system showing the X-, Y-, and Z-axis

Syntax of the CSS translateZ() function

translateZ() accepts a single argument. Here is the syntax:

element {
  transform: translateZ(length);
}

The length argument specifies the distance you wish to move the element from its original z-axis position.

A three-dimensional Cartesian coordinate system with a red arrow defining the green plane's translateZ length

Examples of the CSS translateZ() function

We often use translateZ() with the perspective() function. Below are some examples.

How to use translateZ() with the CSS perspective() function:

img {
  width: 40%;
}

.second-image {
  transform: perspective(33px) translateZ(10px);
}

Try it on StackBlitz

Here's what we did in the snippet above:

1. We used the perspective() function to define a 33px distance between the user and the z=0 plane.

2. We used the translateZ() function to reposition the second-image ten pixels (10px) away from its original position along the z-axis.

Note:

• Suppose the second-image's z-axis position is larger than or equal to the perspective() function's argument. In that case, the image will disappear as though it is behind the user. In other words, the selected item disappears when the user is in the same position as the element (or when the element is behind the user).

• The larger the user's distance to the element's z-axis position, the less intensive the perspective effect will be, and vice-versa.

How to use translateZ() with a 70px perspective:

img {
  width: 40%;
}

.second-image {
  transform: perspective(70px) translateZ(10px);
}

Try it on StackBlitz

Here's what we did in the snippet above:

1. We used the perspective() function to define a 70px distance between the user and the z=0 plane.

2. We used the translateZ() function to reposition the second-image ten pixels (10px) away from its original position along the z-axis.

What is the CSS translate3d() Function?

translate3d() transforms an element by repositioning (translating) it three-dimensionally along the x-, y-, and z-axis.

Syntax of the CSS translate3d() function

translate3d() accepts three arguments. Here is the syntax:

element {
  transform: translate3d(x, y, z);
}

Note the following:

• The x argument can be a length or percentage value. It specifies the distance you wish to move the element from its original x-axis position.

• The y argument can be a length or percentage value. It defines the distance you wish to move the element from its original y-axis position.

• z can only be a length—not a percentage. It defines the distance you wish to move the element from its original z-axis position.

Examples of the CSS translate3d() function

Below are some examples of how the CSS translate3d() function works.

How to translate an element along only the X-axis

img {
  transform: translate3d(150px, 0, 0);
  width: 80%;
}

Try it on StackBlitz

The snippet above used the translate3d() function to reposition the image 150px away from its original position along the x-axis.

Note: translate3d(150px, 0, 0) is equivalent to translateX(150px).

How to translate elements three-dimensionally:

img {
  width: 40%;
}

.second-image {
  transform: perspective(300px) translate3d(15%, 45%, 200px);
}

Try it on StackBlitz

The snippet above used the translate3d() function to reposition the image 15% away from its original position along the x-axis, 45% from its y-axis, and 200px from its z-axis.

CSS Translate Functions vs. translate Property: What's the Difference?

The CSS translate functions and the CSS translate property provide two similar ways to specify a translation transformation.

The main differences between the two translation techniques are as follows:

• The CSS translate property allows translating an element without using the CSS transform property.

• The CSS translate property's syntax is shorter than its function alternative.

• The CSS translate property saves you from remembering the specific order to position the transform functions.

• Browsers calculate the transform functions' matrix in the order you assigned them to the CSS transform property—from left to right.

• Browsers calculate the transform properties' matrix in the following order:

  1. translate

  2. rotate

  3. scale

Below are some examples.

How to use CSS translate property vs. function to translate an element along the X- and Y-axis

img {
  translate: 60% 300px; /* Equal to a transform: translate(60%, 300px) property */
  width: 80%;
}

Try it on StackBlitz

The snippet above used the translate property to reposition the image 60% away from its original position along the x-axis. And 300px from its y-axis.

Note: Suppose you wish to translate an element along the z-axis. In that case, set a perspective property on the "parent element" of the element you want to translate. Otherwise, the element will not move along its z-axis.

How to use CSS translate property vs. function to translate an element along the Z-axis

img {
  width: 40%;
}

div {
  perspective: 35px;
}

.second-image {
  translate: 0px 0px 17px; /* Equal to a transform: translateZ(17px) property */
}

Try it on StackBlitz

Here's what we did in the snippet above:

1. We used the perspective property to define a 35px distance between the user and the z=0 plane.

2. We used the translate property to reposition the second-image seventeen pixels (17px) away from its original position along the z-axis.

How to use CSS translate property vs. function to translate an element three-dimensionally

img {
  width: 40%;
}

div {
  perspective: 300px;
}

.second-image {
  translate: 50% 25% 200px; /* Equal to a transform: translate3d(50%, 25%, 200px) property */
}

Try it on StackBlitz

The snippet above used the translate property to reposition the image 50% away from its original position along the x-axis, 25% from its y-axis, and 200px from its z-axis.

Note: A none value tells browsers not to translate the selected element.

What is the CSS perspective() Function?

perspective() transforms an element by adding some perspective effects to it.

Syntax of the CSS perspective() function

perspective() accepts only one argument. Here is the syntax:

element {
  transform: perspective(length);
}

The length argument specifies the user's distance to the z=0 plane.

A three dimensional Cartesian coordinate system with a red arrow defining the distance between the user and the z=0 plane

Examples of the CSS perspective() function

We often use perspective() with other CSS functions such as translateZ(), rotateX(), and rotateY(). Below are some examples.

How to use perspective() with the CSS translateZ() function:

img {
  width: 40%;
}

.second-image {
  transform: perspective(33px) translateZ(10px);
}

Try it on StackBlitz

Here's what we did in the snippet above:

1. We used the perspective() function to define a 33px distance between the user and the z=0 plane.

2. We used the translateZ() function to reposition the second-image ten pixels (10px) away from its original position along the z-axis.

Note the following:

• Suppose the second-image's z-axis position is larger than or equal to the perspective() function's argument. In that case, the image will disappear as though it is behind the user. In other words, the selected item disappears when the user is in the same position as the element (or when the element is behind the user).

• The larger the user's distance to the element's z-axis position, the less intensive the perspective effect will be, and vice-versa.

How to use perspective() with the CSS rotateY() function:

img {
  width: 40%;
}

.second-image {
  transform: perspective(33px) rotateY(-10deg);
}

Try it on StackBlitz

Here's what we did in the snippet above:

1. We used the perspective() function to define a 33px distance between the user and the z=0 plane.

2. We used the rotateY() function to rotate the second-image negative ten-degree (-10⁰) around the y-axis.

How to use perspective() with the CSS rotateX() function:

img {
  width: 40%;
}

.second-image {
  transform: perspective(33px) rotateX(17deg);
}

Try it on StackBlitz

Here's what we did in the snippet above:

1. We used the perspective() function to define a 33px distance between the user and the z=0 plane.

2. We used the rotateX() function to rotate the second-image seventeen-degree (17⁰) around the x-axis.

CSS perspective() Function vs. perspective Property: What's the Difference?

The CSS perspective() function and the perspective property provide two similar ways to add perspective effects to HTML elements.

The main differences between the two perspective techniques are as follows:

• We apply the perspective() function "directly on the element" we want to add some perspective effects to.

• We apply the perspective property "on the parent element" of the element we want to add some perspective effects to.

• The perspective() function works as a transform property's value.

• The CSS perspective property allows you to create perspective effects without using the CSS transform property.

Here's an example:

Use CSS perspective property to add perspective effect to a child element:

img {
  width: 40%;
}

div {
  perspective: 33px;
}

.second-image {
  rotate: x 17deg;
}

Try it on StackBlitz

Here's what we did in the snippet above:

1. We used the perspective property to define a 33px distance between the user and the z=0 plane.

2. We used the rotate property to rotate the second-image seventeen-degree (17⁰) around the x-axis.

Note:

• The CSS perspective property saves you from remembering the specific order to position the transform functions.

• A none value tells browsers not to add any perspective effect to the selected element's children.

What is the CSS matrix() Function?

The CSS matrix() function is a shorthand for the following 2D transform functions:

• scaleX()

• skewY()

• skewX()

• scaleY()

• translateX()

• translateY()

In other words, instead of writing:

img {
  transform-origin: 0 0;
  transform: translateX(100px) translateY(250px) scaleX(2) scaleY(0.9)
    skewX(10deg) skewY(35deg);
  width: 80%;
}

Try it on StackBlitz

You can alternatively use the matrix() function to shorten your code like so:

img {
  transform-origin: 0 0;
  transform: matrix(2.24693, 0.630187, 0.352654, 0.9, 100, 250);
  width: 80%;
}

Try it on StackBlitz

The CSS matrix() function's syntax

The matrix() function accepts six values. Here's the syntax:

matrix(scaleX(), skewY(), skewX(), scaleY(), translateX(), translateY())

You can represent the CSS matrix's values as homogeneous coordinates on ℝℙ² like so:

| scX skX tX | ← x-axis
| skY scY tY | ← y-axis
|  0   0   1 | ← constants

Note the following:

• scX and skX are numbers describing an element's scale and skew linear transformation on the x-axis.

• tX is a number representing an element's translation on the x-axis.

• skY and scY are numbers describing an element's skew and scale linear transformation on the y-axis.

• tY is a number representing an element's translation on the y-axis.

• 0, 0, 1 are constants.

• We do not pass the constants as arguments to the matrix() function because the computer implies them automatically.

Examples of the CSS matrix() function

Below are some examples of the CSS matrix() function.

How to convert scaleX() to matrix() function:

Consider the following transform property:

img {
  transform-origin: 0 0;
  transform: scaleX(2);
  width: 80%;
}

Try it on StackBlitz

Here is the matrix() equivalent of the above scaleX() function:

img {
  transform-origin: 0 0;
  transform: matrix(2, 0, 0, 1, 0, 0); /* scX, skY, skX, scY, tX, tY */
  width: 80%;
}

Try it on StackBlitz

Let's also represent the matrix's values as homogeneous coordinates on ℝℙ²:

| 2 0 0 | ← x-axis
| 0 1 0 | ← y-axis
| 0 0 1 | ← constants

Below is another example.

How to convert translateY() to matrix() function:

img {
  transform-origin: 0 0;
  transform: translateY(250px);
  width: 80%;
}

Try it on StackBlitz

Here is the matrix() equivalent of the above translateY() function:

img {
  transform-origin: 0 0;
  transform: matrix(1, 0, 0, 1, 0, 250); /* scX, skY, skX, scY, tX, tY */
  width: 80%;
}

Try it on StackBlitz

Let's also represent the matrix's values as homogeneous coordinates on ℝℙ²:

| 1 0 0   | ← x-axis
| 0 1 250 | ← y-axis
| 0 0 1   | ← constants

Below is a third example.

How to convert translateX() and scale() to matrix() function:

img {
  transform-origin: 0 0;
  transform: translateX(100px) scale(2);
  width: 80%;
}

Try it on StackBlitz

Here is the syntax for converting the above transform property's value to matrix():

matrix = (translateX's homogeneous coordinates) x (scale's homogeneous coordinates)

Let's begin the conversion by defining translateX(100px)'s homogeneous coordinates:

| 1 0 100 | ← x-axis
| 0 1 0   | ← y-axis
| 0 0 1   | ← constants

Let's also define scale(2)'s homogeneous coordinates:

| 2 0 0 | ← x-axis
| 0 2 0 | ← y-axis
| 0 0 1 | ← constants

It's now time to multiply the two homogeneous coordinates by using the following syntax:

| a d g |   | j m p |   | aj + dk + gl   am + dn + go   ap +dq  + gr |
| b e h | x | k n q | = | bj + ek + hl   bm + en + ho   bp + eq + hr |
| c f i |   | l o r |   | cj + fk + il   cm + fn + io   cp + fq + ir |

Let's implement the above syntax like so:

| 1 0 100 |   | 2 0 0 |   | 2 + 0 + 0   0 + 0 + 0   0 + 0 + 100 |
| 0 1  0  | x | 0 2 0 | = | 0 + 0 + 0   0 + 2 + 0   0 + 0 +  0  |
| 0 0  1  |   | 0 0 1 |   | 0 + 0 + 0   0 + 0 + 0   0 + 0 +  1  |

The next step is to resolve the addition. So, let's do that now.

| 1 0 100 |   | 2 0 0 |   | 2 0 100 |
| 0 1  0  | x | 0 2 0 | = | 0 2  0  |
| 0 0  1  |   | 0 0 1 |   | 0 0  1  |

The addition's result above gives us the homogeneous coordinates of the transform: translateX(100px) scale(2) property.

In other words, the product of (translateX's homogeneous coordinates) and (scale's homogeneous coordinates) equal:

| 2 0 100 | ← x-axis
| 0 2  0  | ← y-axis
| 0 0  1  | ← constants

Therefore, the matrix equivalence of transform: translateX(100px) scale(2) is transform: matrix(2, 0, 0, 2, 100, 0).

img {
  transform-origin: 0 0;
  transform: matrix(2, 0, 0, 2, 100, 0);
  width: 80%;
}

Try it on StackBlitz

Please note that transform: translateX(100px) scale(2) and transform: scale(2) translateX(100px) return different matrixes. Let's see an example of the second arrangement below.

How to convert scale() and translateX() to matrix() function:

Consider the following transform property:

img {
  transform-origin: 0 0;
  transform: scale(2) translateX(100px);
  width: 80%;
}

Try it on StackBlitz

Here is the syntax for converting the above transform property's value to matrix():

matrix = (scale's homogeneous coordinates) x (translateX's homogeneous coordinates)

Let's begin the conversion by defining scale(2)'s homogeneous coordinates:

| 2 0 0 | ← x-axis
| 0 2 0 | ← y-axis
| 0 0 1 | ← constants

Let's also define translateX(100px)'s homogeneous coordinates:

| 1 0 100 | ← x-axis
| 0 1  0  | ← y-axis
| 0 0  1  | ← constants

It's now time to multiply the two homogeneous coordinates by using the following syntax:

| a d g |   | j m p |   | aj + dk + gl   am + dn + go   ap +dq  + gr |
| b e h | x | k n q | = | bj + ek + hl   bm + en + ho   bp + eq + hr |
| c f i |   | l o r |   | cj + fk + il   cm + fn + io   cp + fq + ir |

Let's implement the above syntax like so:

| 2 0 0 |   | 1 0 100 |   | 2 + 0 + 0   0 + 0 + 0   200 + 0 + 0 |
| 0 2 0 | x | 0 1  0  | = | 0 + 0 + 0   0 + 2 + 0    0 + 0 + 0  |
| 0 0 1 |   | 0 0  1  |   | 0 + 0 + 0   0 + 0 + 0    0 + 0 + 1  |

The next step is to resolve the addition. So, let's do that now.

| 2 0 0 |   | 1 0 100 |   | 2 0 200 |
| 0 2 0 | x | 0 1  0  | = | 0 2  0  |
| 0 0 1 |   | 0 0  1  |   | 0 0  1  |

The addition's result above gives us the homogeneous coordinates of the transform: scale(2) translateX(100px) property.

In other words, the product of (scale's homogeneous coordinates) and (translateX's homogeneous coordinates) equal:

| 2 0 200 | ← x-axis
| 0 2  0  | ← y-axis
| 0 0  1  | ← constants

Therefore, the matrix equivalence of transform: scale(2) translateX(100px) is transform: matrix(2, 0, 0, 2, 200, 0).

img {
  transform-origin: 0 0;
  transform: matrix(2, 0, 0, 2, 200, 0);
  width: 80%;
}

Try it on StackBlitz

Notice that transform: scale(2) translateX(100px) equals transform: matrix(2, 0, 0, 2, 200, 0). And transform: translateX(100px) scale(2) is equivalent to transform: matrix(2, 0, 0, 2, 100, 0).

In other words, the order in which you write the transform functions matters. Let's discuss more on this below.

Why Does the CSS Transform Functions' Order Matter?

The order in which you write CSS transform functions matters because of the way browsers calculate the matrix's values.

For instance, consider the following snippet:

div {
  position: absolute;
  width: 100px;
  height: 100px;
  transform-origin: 0 0;
}

.red {
  border: 3px solid red;
  background-color: rgba(255, 0, 0, 0.5);
}

.green {
  border: 3px solid green;
  background-color: rgba(0, 128, 0, 0.5);
  transform: translateX(100px) scale(2);
}

.blue {
  border: 3px solid blue;
  background-color: rgba(0, 0, 255, 0.5);
  transform: scale(2) translateX(100px);
}

Try it on StackBlitz

The only difference between the green and the blue divs is the order in which we wrote their transform functions.

However, the computer translated the two containers using different values (100px for the green div and 200px for the blue one).

So, why did the transform functions' order affect the divs' translation values? Here's the reason:

• Browsers multiply each transform function's homogeneous coordinates in order—from left to right.

In other words, the computer used the following syntax to compute the green div's matrix:

• Green div's matrix = (translateX's homogeneous coordinates) x (scale's homogeneous coordinates)

And it used the following syntax to calculate the blue div's matrix:

• Blue div's matrix = (scale's homogeneous coordinates) x (translateX's homogeneous coordinates)

Therefore, the position of the transform functions determined the matrix's arguments because browsers began the calculation in order from the leftmost function to the right.

Knowing how to convert transform functions to matrix() is beneficial. And having some conversion tools can come in handy. So, let's discuss some helpful tools you can use.

Tools for Converting Transform Functions to matrix()

The two tools you can use to do a quick conversion of transform functions to matrix() are:

• JavaScript's window.getComputedStyle() method

• Eric Meyer and Aaron Gustafson's matrix resolution tool

How to use window.getComputedStyle() to convert transform functions to matrix()

Suppose you want to convert the following transform functions to matrix:

img {
  transform-origin: 0 0;
  transform: scale(2) translateX(100px);
  width: 80%;
}

You will add an id attribute to the image element:

<img
  src="https://cdn.pixabay.com/photo/2022/09/26/23/26/african-american-7481724_960_720.jpg"
  alt=""
  id="image"
/>

Then, in JavaScript, you will:

1. Use the id attribute to get the image element.

2. Use the window.getComputedStyle() method to get the image's transform property's value.

Here's the code:

// Get the image element by its id name:
const image = document.getElementById("image");

// Get the image element's transform property's value:
const matrix = window.getComputedStyle(image).getPropertyValue("transform");

// Log the matrix variable's value to the console:
console.log(matrix);

Try it on StackBlitz

Browsers, by default, convert a CSS transform property's value to its matrix equivalent. So, the snippet above returned the image's computed value.

Let's now discuss the second conversion tool.

How to use the matrix resolutions tool to convert transform functions to matrix()

Suppose you want to convert the following transform functions to a matrix():

img {
  transform-origin: 0 0;
  transform: scale(2) translateX(100px);
  width: 80%;
}

You will do the following:

1. Go to The Matrix Resolutions website: https://meyerweb.com/eric/tools/matrix/.

2. Paste your transform functions (scale(2) translateX(100px)) into the first text field.

3. Click "The Red Pill" button to generate the transform functions' matrix equivalence.

Click the red pill button to convert CSS transform functions to a matrix() function

Tip: Use matrix3d() to create a 3D transformation matrix.

Important Stuff to Know about Transforming Elements in CSS

Here are three essential facts to remember when you transform elements in CSS.

1. Transform creates a stacking context

Suppose you set the transform property to any value other than none. In that case, the browser will create a stacking context. And the transformed element will serve as a containing block to any absolute or fixed positioned elements it contains.

2. Scaling and zooming animations cause accessibility issues

Whenever you include scaling or zooming animations in your app, provide users an option to turn off animations. This option is necessary because scaling and zooming animations cause accessibility issues.

3. Not all elements are transformable

You cannot transform the following box models:

• Non-replaced inline elements

• table-column boxes

• table-column-group

Wrapping Up

In this article, we discussed all the CSS transform tools you need to translate, rotate, skew, scale, or add perspective effects to HTML elements.

I hope you've found this article helpful.

Thanks for reading!

If you like this tutorial, you will enjoy my CSS Flexbox book. It is a handy quick reference guide that uses images and live examples to explain Flexbox.

• [The many layers of development](#The many layers of development)
• But we’re not all full stack
• So what is the difference between Front End Development and Back End Development?
• What is Front End Development?
• What is Back End Development?
• Where things get fuzzy
• Resources to learn

The many layers of development

Whether you’re working on a website or a native iOS app, all development environments share a common theme — there’s a front end to an application and a back end.

This line can get blurry, especially given the rise of javascript and the serverless world. With the tooling somewhat merging together, we might sometimes wonder if we’re a full stack developer.

But we’re not all full stack

As much as we might all want to be, we’re not all full stack developers. Personally, I find myself able to be productive in the back end of an application, but it’s not my strength and I much prefer to be heads down building UIs.

And some people are the opposite, where they are strongest dealing with building APIs in the back end of an application and while they can build out a UI, it might be more of a prototype-like experience than a fleshed out application.

So what is the difference between Front End Development and Back End Development?

Even if you are a full stack developer, that doesn’t mean there’s not a division of responsibilities.

Front End Engineer vs Back End Engineer

So what do those look like?

What is Front End Development?

The front end of an application typically refers to the layer that represents the UI (user interface). This can include anything from a static site with HTML and CSS to a full React app that powers the UI.

What did Front End Development traditionally look like?

Javascript currently rules the front end web, but that wasn’t always the case. While it could have been used to add little bits of interaction to a site, typically front ends were rendered using server-side templating languages like framework-driven PHP and Template Toolkit (Perl).

This grew to be super popular in practice with home grown frameworks or tools like Wordpress that used PHP to drive a massive community of developers who built their websites with those tools.

The way it worked was the templating language was able to get its data straight from the server as it was rendered. When a browser requested the page directly from the origin (the server itself), whatever data the template would need, the application logic would provide at that time.

Some of the more traditional front end tools include:

• Libraries like jQuery or MooTools
• Website frameworks like Wordpress
• Plain CSS
• Abundant use of Table elements

But as time went on, javascript kept getting more mature as a language and browsers kept getting more powerful, which led to the idea that we could move more of that work to the browser to build faster and more interactive experiences.

What does Front End Development look like now?

Now it’s common to see javascript-heavy websites and apps built using UI frameworks like React, Vue, and Angular. These tools provide abstractions that allow developers to build complex UIs with reusable patterns like components.

When the browser loads the page, the page receives an initial HTML document that also includes the script tag to the javascript (same as always). But once that javascript loads, it reaches out to APIs using browser requests that when completed, update the page to fill in any kind of dynamic data that you’d typically get along with that first HTML document.

It's like building a website... with more steps

While it sounds like more steps, it commonly provides a faster initial page load and render, not to mention it has a great developer experience. By delivering less on that first request and prioritizing what loads after that, it usually ends up as a better user experience.

Some of the front end tools that are more common and growing in popularity include:

• UI frameworks like React or Vue
• Web frameworks like Gatsby
• Compilers like Babel
• Bundlers like Webpack
• CSS tools like Sass

But those APIs, whether ones we pay for or create ourselves, need to be built somewhere. That’s where the back end comes in.

What is Back End Development?

The back end layer is usually where the business logic occurs. This can be super complex like the rules that determine revenue for an e-commerce company or something more common like a user profile.

What did Back End Development traditionally look like?

The back ends of applications were historically built using server-side languages like PHP or Ruby. The idea is that you have a server that you need to perform complex operations on, so the way to do that is with a language that server would understand.

On each request to the server, the backend would perform the full stack of the operations, including rendering out the front end. By using frameworks or DIY architectures, the back end would accept the request, figure out what it should do with that request, run any business logic needed with the request, and provide the front end any data that it would need to display a response to that request.

Back end giving the front end a 500 Internal Server Error

Some of the more traditional back end tools include:

• On-premise or remotely managed servers like Rackspace
• HTTP servers using Apache
• Databases like MySQL
• Server side languages like PHP or Perl
• Application frameworks like Ruby on Rails

What does Back End Development look like now?

Back end stacks look somewhat similar to the way they did before, aside from newer code patterns, except more often you’ll see the back ends provide data through APIs via HTTP requests instead of directly to the templates the front end team are working on.

While the foundation isn’t super different, it actually be comes increasingly complex as you have to deal with different security implications that could compromise your system if not properly configured such as leaving an API open to the public that returns sensitive user data.

But also how the server operates can be completely different. While previously, we might run our python on our own managed server (we still can), we can now make use of serverless functions with tools like AWS Lambda that simplify how we manage code.

While “serverless” doesn’t necessarily mean there are literally no servers, it means that as a service, the developer doesn’t have to worry about maintaining that server and can instead just focus on the code they need to run.

Some of the back end tools that are more common and growing in popularity include:

• Cloud servers like AWS EC2
• Serverless services like AWS Lambda
• NoSQL databases like MongoDB
• Languages like Python or javascript via NodeJS
• Web application frameworks like Serverless Framework

Where things get fuzzy

Part of the twist with back ends is now you can write your back end with javascript. With the inception of Node.js, developers were given the ability to use their favorite browser language to do most of the same things they were used to and familiar with but now on a server.

Never stopped to think if we should write JS on a server

While not everyone is fond of running javascript as a server side language, it became a little easier to use the same language to write the full stack of an application. This changed the game a bit as far as front ends and back ends were concerned.

But it’s also started to come full circle where you now see systems that build APIs right next to the front end similar to what you might see in a traditional stack.

Front End vs Back End

Regardless of the stack, there will always be the separation of concerns. The UI and all of the interaction, whether rendered on the server or in the browser, is what makes the front end the front end and the data and business logic, whether coming from the server in your company’s closet or a managed function, is what makes the back end the back end.

Whether you prefer to work on the user facing features or build the logic that lets them do things, there are plenty of resources to get started.

Resources to learn

Front End

• freecodecamp.org Responsive Web Design Certification (freecodecamp.org)
• Beginner Javascript (beginnerjavascript.com - Wes Bos)
• React Tutorial for Beginners (youtube.com - Programming with Mosh)
• Front End Masters (frontendmasters.com)

Back End

• freecodecamp.org APIs and Microservices Certification (freecodecamp.org)
• Super simple start to serverless (kentcdodds.com)
• AWS Certified Cloud Practitioner Training 2019 - A Free 4-hour Video Course (freecodecamp.org)
• CS50's Introduction to Computer Science (edx.org)

All the above

• How to Become a Full Stack Web Developer in 2020 (colbyfayock.com)
• Egghead.io (egghead.io)
• 100 Days of Code (100daysofcode.com)
• The Web Developer Bootcamp (udemy.com - Colt Steele)

• What is VS Code?
• What will we use?
• How does it work?
• Step 1: Install Settings Sync
• Step 2: Authorize access to Github
• Step 3: Upload your current settings
• Step 4: Syncing your configuration to another environment
• Step 5: Updating your configuration

What is VS Code?

Visual Studio Code, or VS Code, is an all-inclusive code editor that takes all of the features you want out of working with code and puts them in one editor to make you ultra productive.

VS Code editor

It’s been the “cool kid on the block” for a little while now and has been increasingly growing in popularity at least in the JavaScript community. Microsoft has put a lot of effort into making it something people want to use (and they’re doing a great job at that).

What will we use?

We’re going to use a VS Code extension called Settings Sync that makes use of Github’s Gist feature to store a private JSON configuration file in the cloud.

How does it work?

The extension uses Github’s OAuth to log in to your Github account. Once approved, VS Code obtains an access token and reaches out to both store and download your settings file to a private Github Gist.

Once it’s set up, you can then configure the extension on any other instance of VS Code and immediately download your configuration to sync up your editor.

Step 0: VS Code

We’ll assume for this walkthrough you have VS Code already installed. While you don’t need to have any special configuration, having something different than the default (like a color theme) will help you see it work.

Let’s get started!

Step 1: Install Settings Sync

The first thing we need to do is install the extension. You can do this a few ways — you can visit the webpage and hit Install which will open up VS Code or you can search for the extension in the Extensions panel.

VS Code Settings Sync extension

Once installed, it will open up a new tab with the Settings Sync dashboard.

Settings Sync dashboard after installation

Step 2: Authorize access to Github

To get started with Github, click the Login with Github button in the Settings Sync dashboard.

Log in to Settings Sync with Github

This will open up Github in your default web browser and ask you to log in. While you can use any Github account you want, it would probably make most sense to use your personal account.

Successful Github login to Settings Sync

Once you’re logged in, you should now see Success! in your browser.

Step 3: Upload your current settings

Now that you’re connected to Github, you’re ready to upload your settings.

Open up your Command Palette with CMD+Shift+P (on Mac) or navigate to View and Command Palette. Type “Sync Upload” which will filter the commands and hit enter once the Sync: Update/Upload Settings option is selected.

Update/Upload Settings command in Settings Sync

When doing this, you might be prompted with screen that asks if you want to force upload — press Yes.

Force upload new settings in Settings Sync

At this point, Settings Sync will create a new Gist in your Github account with your configuration settings. Once it’s done you should see a success message.

Successful settings upload in Settings Sync

You should now be able to visit gist.github.com and find a new private cloudSettings Gist that includes all of your VS Code settings!

Step 4: Syncing your configuration to another environment

To sync your VS Code configuration to another computer or VS Code environment, you want to first follow steps 1 and 2 above — installing the extension and logging in to Github.

The difference is this time, you’ll want to configure VS Code to download your settings instead of upload them.

To get started, first open back up your Sync Settings dashboard. If this is a new installation like we’re assuming here, you can open up the Command Palette and type “sync download” and hit enter which will open up that dashboard. Here, click Edit Configuration this time.

Edit Settings Sync configuration

On this screen, you should see your Github Access Token, but you should also see an empty field for Gist ID. Here, we want to first grab the ID from our cloudSettings Gist URL:

VS Code cloudSettings Gist ID

And then paste that value inside of our Gist ID input in VS Code.

Adding Gist ID to Settings Sync configuration

Once it’s there, you can open the Command Palette again, type “sync download”, and hit enter, and Sync Settings will fetch your VS Code configuration from the Gist and update your local settings with that configuration!

Step 5: Updating your configuration

From here on, any time you want to make a new change to your stored configuration, you’ll want to use both the Update/Upload and Download features like we used above.

To update a new tweak to your configuration, type “sync update” and hit enter:

Update command for Settings Sync

And to download your configuration to sync up another editor, type “sync download” and hit enter:

Download settings command for Settings Sync

These commands will both update your cloudSettings Gist and download from it to sync up your VS Code instances

What’s your favorite VS Code trick?

Share it with me on Twitter!

Join the conversation

I am a JavaScript/Node developer who secretly likes (actually, loves and adores) Deno. I have been a huge fan of Deno ever since it was announced and I've been wanting to play with it.

This tutorial focuses on creating a set of REST APIs for a Todo application. Keep in mind that I did not touch on the database here – I will cover that in another article.

At any point if you feel lost or want to check a reference, here is the entire source code of this tutorial: Chapter 1: Oak.

_Photo by [Unsplash](https://unsplash.com/@bernardtheclerk?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Bernard de Clerk / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Things we will cover

• Create a basic server
• Create 5 APIs (routes/controller)
• Create a middleware to log API requests as they are made in the console
• Create a not found (404) middleware when the user tries to access an unknown API

What will we need

• An installed version of Deno (don't worry I'll walk you through it)
• A tiny bit of knowledge of Typescript
• Would be awesome if you have worked with Node/Express before (don't worry if you haven't — this tutorial is very basic)

Let's get started

First things first let's install Deno. I am on a Mac computer so I am using brew. Simply open your terminal and type:

$ brew install deno

But if you are using a different operating system, just head over to deno.land installation. They have a lot of ways you can easily install it on your machine.

Once you have it installed, close the terminal, open a new one, and type:

$ deno --version

It should output something like this:

running command "deno --version" to see which version of deno is installed

Awesome! With this we are almost done with 10% of this tutorial.

Let's move ahead and create the backend API for our Todo app.

Setting up the project

Before you move on, here is the entire source code of this tutorial: Chapter 1: Oak.

Let's get started:

• Create a new folder and call it chapter_1:oak (but you can call it anything you want)
• Once you create a folder simply cd into your new project. Create a file called server.ts and write the following code in it:

import { Application } from "https://deno.land/x/oak/mod.ts";

const app = new Application();
const port: number = 8080;

console.log('running on port ', port);
await app.listen({ port });

Let's run this file. Open your terminal and in your project root folder type:

$ deno run --allow-net server.ts

I will talk about what the --allow-net flag does, but for now just bear with me ?.

You should get something like this:

What we have done so far is create a server which listens on port 8080. It doesn't do much right now besides being able to run on port 8080.

If you have used JavaScript before, one thing you might have noticed is we are importing packages in a different way. We have to do something like:

import { Application } from "https://deno.land/x/oak/mod.ts";

When you run deno run ---allow-net <file_name> in your terminal, Deno will look at all your imports and install them locally in your machine if they are not there.

The first time you run this it will go to this URL https://deno.land/x/oak/mod.ts and install the oak package. Oak is basically a Deno framework for writing API's. It will put it somewhere locally in your cache.

In the next line we do this:

const app = new Application();

This creates a new instance of our application, and it will be the basis of everything as you progress further in this tutorial. You can add routes to the application instance, attach middleware like API logging, write a 404 not found, and so on.

Then we write:

const port: number = 8080;
// const port = 8080; // => can also be written like this

Both are the same and do the same thing. The only difference is writing const port: number = 8080 tells Typescript that port variable is of type number.

If you were to write const port: number = "8080", this would throw an error in your terminal, as port is of type number. But we are trying to assign it a string of value "8080".

If you want to learn more about different types of types (pun intended) check out this very easy and basic guide on Basic types by Typescript. Just give it a quick glance for 2-3 minutes and head back here.

And in the end we have:

console.log('running on port ', port);
await app.listen({ port });

We simply console here the port number and tell Deno to listen to the port, which is 8080.

It isn't doing much right now. Let's make it do something basic like show a JSON message in your browser when you go to http:localhost:8080.

Add the following to your server.ts file:

import { Application, Router } from "https://deno.land/x/oak/mod.ts";

const app = new Application();
const port: number = 8080;

const router = new Router();
router.get("/", ({ response }: { response: any }) => {
  response.body = {
    message: "hello world",
  };
});
app.use(router.routes());
app.use(router.allowedMethods());

console.log('running on port ', port);
await app.listen({ port });

The new thing added here is that we are now also importing Router along with Application from oak in line 1.

Next what we do is:

const router = new Router();
router.get("/", ({ response }: { response: any }) => {
  response.body = {
    message: "hello world",
  };
});
app.use(router.routes());
app.use(router.allowedMethods());

We create a new router instance by doing const router = new Router() and then we create a new route called / which is of type get.

Let's break this down:

router.get("/", ({ response }: { response: any }) => {
  response.body = {
    message: "hello world",
  };
});

router.get takes 2 parameters. The first is route which we have set to / and the second is function. The function itself takes an argument which is an object. What I am doing here is destructuring the object and getting only response.

Next I am type checking response similar to how I did const port: number = 8080;. All I am doing is { response }: { response: any } which is telling TypeScript here that the response which I have destructed can be of type any.

any helps you avoid type checking in TypeScript. You can read more about it here.

Then all I am doing is taking that response object and setting response.body.message = "hello world";.

response.body = {
  message: "hello world",
};

Last but not least, we just add these two lines:

app.use(router.routes());
app.use(router.allowedMethods());

This tells Deno to include all routes by our router (currently we only have one) and the next line tells Deno to allow all methods for this route(s) like GET, POST, PUT, DELETE.

And now we are done. ✅ Let's run this and see what we have:

$ deno run --allow-net server.ts

The ---allow-net property tells Deno that this app gives the user the permission to access its content via the port opened up.

Now open your favorite browser and go to http://localhost:8080. You will see something like this:

Result of running localhost:8080 on your browser

Honestly the hardest part is done. Conceptually we are 60% there.

Master Yoda approves

Awesome.

Just one last thing before we start with our Todo API. Let's replace:

console.log('running on port ', port);
await app.listen({ port });

with:

app.addEventListener("listen", ({ secure, hostname, port }) => {
  const protocol = secure ? "https://" : "http://";
  const url = `${protocol}${hostname ?? "localhost"}:${port}`;
  console.log(`Listening on: ${port}`);
});

await app.listen({ port });

The code we had before was not very accurate, because we were simply console logging a message and then waiting for the app to start listening on a port.

With the later version we wait for the app to start listening on port and we can listen by adding an event listener to our app instance with the following: app_.addEventListener_("listen", ({ secure, hostname, port }) => {}.

The first param is the event we want to listen for (which is listen ?) and then the second param is an object which we destruct to { secure, hostname, port }. Secure is a boolean, hostname is a string, and port is a number.

Now when we start our app, it will only console the message once the app actually starts listening on port.

We can just go one step ahead and make it more colorful. Let's add a new module to the top of the file in server.ts:

import { green, yellow } from "https://deno.land/std@0.53.0/fmt/colors.ts";

And then inside our event listener method we can replace:

console.log(`Listening on: ${port}`);

with:

console.log(`${yellow("Listening on:")} ${green(url)}`);

Now when we do:

$ deno run --allow-net server.ts

it will show this in our console:

Cool, now we have a colourful console.

If you get stuck anywhere you can simply go to the source code of this tutorial here.

Let's create our Todo API's routes next.

• Create a new folder in your root folder called routes and inside that folder create a file called todo.ts
• At the same time in your root folder create a new folder called controllers and inside that folder create a file called todo.ts

Let's first touch the controllers/todo.ts file:

export default {
  getAllTodos: () => {},
  createTodo: async () => {},
  getTodoById: () => {},
  updateTodoById: async () => {},
  deleteTodoById: () => {},
};

We are simply exporting an object here with some named functions which are empty (for now).

Next go inside your file routes/todo.ts and type this:

import { Router } from "https://deno.land/x/oak/mod.ts";

const router = new Router();
// controller
import todoController from "../controllers/todo.ts";

router
  .get("/todos", todoController.getAllTodos)
  .post("/todos", todoController.createTodo)
  .get("/todos/:id", todoController.getTodoById)
  .put("/todos/:id", todoController.updateTodoById)
  .delete("/todos/:id", todoController.deleteTodoById);

export default router;

This might look familiar to people who have worked with Node and Express.

All we are doing here is importing Route from oak and then setting up a new instance of Router by doing const router = new Router();.

Next we import our controllers by doing:

import todoController from "../controllers/todo.ts";

One thing to notice here in Deno is every time we import a local file in our Deno project we have to provide the file extension. This is because Deno doesn't know whether the file being imported is a .js or .ts file.

Moving forward we simply set all of our routes according to REST conventions:

router
  .get("/todos", todoController.getAllTodos)
  .post("/todos", todoController.createTodo)
  .get("/todos/:id", todoController.getTodoById)
  .put("/todos/:id", todoController.updateTodoById)
  .delete("/todos/:id", todoController.deleteTodoById);

The code above will translate to our API definition like this:

and at the end we simply export our router by doing _export_ _default_ router;.

We are done with creating our routes structure. (Now, each route doesn't do anything because our controllers are empty, we will add functionality to them in a bit.)

Here's the last piece of the puzzle before we start adding functionality to each route controller. We need to attach this router to our app instance.

So head over to server.ts file and do the following:

• Add this to the very top:

// routes
import todoRouter from "./routes/todo.ts";

• Remove this piece of code:

const router = new Router();
router.get("/", ({ response }: { response: any }) => {
  response.body = {
    message: "hello world",
  };
});
app.use(router.routes());
app.use(router.allowedMethods());

• Replace it with:

app.use(todoRouter.routes());
app.use(todoRouter.allowedMethods());

This is it – we are done. Your server.ts file should look like this now:

import { Application } from "https://deno.land/x/oak/mod.ts";
import { green, yellow } from "https://deno.land/std@0.53.0/fmt/colors.ts";

// routes
import todoRouter from "./routes/todo.ts";

const app = new Application();
const port: number = 8080;

app.use(todoRouter.routes());
app.use(todoRouter.allowedMethods());

app.addEventListener("listen", ({ secure, hostname, port }) => {
  const protocol = secure ? "https://" : "http://";
  const url = `${protocol}${hostname ?? "localhost"}:${port}`;
  console.log(
    `${yellow("Listening on:")} ${green(url)}`,
  );
});

await app.listen({ port });

If you got stuck anywhere while following this, simple head over to the source code of this tutorial here.

Awesome, now we have our routes with no functionality at the moment. So let's add that functionality in our controllers.

But before we do that we have to create 2 more (tiny) files.

• In your root folder create a new folder called interfaces and inside that folder create a file called Todo.ts (make sure Todo is capitalized, as it won't give any syntax error here if you don't – these are just conventions.)
• Also in your root folder create a new folder called stubs and inside that folder create a file called todos.ts

Let's create an interface in our interfaces/Todo.ts file. Simply add the following code:

export default interface Todo {
  id: string,
  todo: string,
  isCompleted: boolean,
}

What is an interface?

One of the core things in TypeScript is checking the shape that value has. Similar to const port: number = 8080 or { response }: { response : any }, we can also type check an object.

In TypeScript, interfaces fill the role of naming these types, and are a powerful way of defining contracts within your code as well as contracts with code outside of your project.

Here is an another example of an interface:

// We have an interface
interface LabeledValue {
  label: string;
}

// the arg passed to this function labeledObj is 
// of type LabeledValue (interface)
function printLabel(labeledObj: LabeledValue) {
  console.log(labeledObj.label);
}

let myObj = {label: "Size 10 Object"};
printLabel(myObj);

Hopefully this example gives you a bit more insight into interfaces. If you want more detailed information check out the docs on interfaces here.

Now that our interface is ready, let's mock some data (since we don't have an actual database for this tutorial).

Let's create a mock list of todos first in our stubs/todos.ts file. Simply add the following:

import { v4 } from "https://deno.land/std/uuid/mod.ts";
// interface
import Todo from '../interfaces/Todo.ts';

let todos: Todo[] = [
  {
    id: v4.generate(),
    todo: 'walk dog',
    isCompleted: true,
  },
  {
    id: v4.generate(),
    todo: 'eat food',
    isCompleted: false,
  },
];

export default todos;

• Two things to notice here: we add a new package and use its method v4 by doing _import_ { v4 } _from_ "https://deno.land/std/uuid/mod.ts";. Then every time we use v4.generate() it will create a new random string of id.

The id can not be a number, only a string because in our Todo interface we have defined id as a string.

• The other thing to focus on here is let _todos_: _Todo_[] = []. This basically tells Deno that our todos array is of type Todo (which is awesome, our compiler now automagically knows that each item in our array can only have {**id**: _string_, **todo**: _string_ & **isCompleted**: _boolean_} it will not accept any other key).

If you want to learn more about interfaces in TypeScript check out this amazing detailed documentation on interfaces here.

Awesome. If you have come this far, give yourself a pat on the back. Good job everyone.

The Rock appreciates all the effort you are doing

Let's work on our controllers

In your file controllers/todo.ts:

export default {
  getAllTodos: () => {},
  createTodo: async () => {},
  getTodoById: () => {},
  updateTodoById: async () => {},
  deleteTodoById: () => {},
};

Let's write the controller for getAllTodos:

// stubs
import todos from "../stubs/todos.ts";

export default {
  /**
   * @description Get all todos
   * @route GET /todos
   */
  getAllTodos: ({ response }: { response: any }) => {
    response.status = 200;
    response.body = {
      success: true,
      data: todos,
    };
  },
  createTodo: async () => {},
  getTodoById: () => {},
  updateTodoById: async () => {},
  deleteTodoById: () => {},
};

Before I begin on this block of code, let me explain that every controller has an argument – let's call it context.

So we can deconstruct _getAllTodos_: (context) => {} to:

getAllTodos: ({ request, response, params }) => {}

And since we are using typescript we have to add type checking to all of these variables:

getAllTodos: (
  { request, response, params }: { 
    request: any, 
    response: any, 
    params: { id: string },
  },
) => {}

So we have added type checks to all 3 { request, response, params }

• request is what the user sends us (information like headers and JSON data)
• response is what we send the user back in the API response
• params is what we define in our router routes, that is:

.get("/todos/:id", ({ params}: { params: { id: string } }) => {})

So the :id in /todos/:id is the param. Params are a way to get information from the URL. In this example we know that we have an /:id . So when the user tries to access this API (that is, /todos/756) 756 is basically the :id param. Since it is in the URL we know it is of type string.

Now that we have our basic definitions defined let's get back to our todos controller:

// stubs
import todos from "../stubs/todos.ts";

export default {
  /**
   * @description Get all todos
   * @route GET /todos
   */
  getAllTodos: ({ response }: { response: any }) => {
    response.status = 200;
    response.body = {
      success: true,
      data: todos,
    };
  },
  createTodo: async () => {},
  getTodoById: () => {},
  updateTodoById: async () => {},
  deleteTodoById: () => {},
};

For getAllTodos we only need response . If you remember, response is what is needed to send data back to the user.

For people coming from a Node and Express background, one big thing that is different here is that we don't need to return the response object. Deno does this for us automatically.

All we have to do is set response.status which in this case is 200.

More on response statuses here.

The other thing we set is the response.body which in this case is an object:

{
  success: true,
  data: todos
}

I will go ahead and run my server:

$ deno run --allow-net server.ts

Revision: The ---allow-net property tells Deno that this app gives the user permission to access its content via the port opened up.

Once your server is running, you can access the GET /todos API. I am using postman which is a Google Chrome extension and can be downloaded here.

You can use whatever rest client you like. I like using postman because I think it is very easy.

In Postman, open up a new tab. Set the request to type GET and in the URL bar type http://localhost:8080/todos. Hit Send and this is what you see:

GET /todos API response

Cool! 1 API done, 4 more to go. ??

If you feel stuck anywhere just have sneak peak at the source code directly here.

Let's move on to our next controller:

import { v4 } from "https://deno.land/std/uuid/mod.ts";
// interfaces
import Todo from "../interfaces/Todo.ts";
// stubs
import todos from "../stubs/todos.ts";

export default {
  getAllTodos: () => {},
  /**
   * @description Add a new todo
   * @route POST /todos
   */
  createTodo: async (
    { request, response }: { request: any; response: any },
  ) => {
    const body = await request.body();
    if (!request.hasBody) {
      response.status = 400;
      response.body = {
        success: false,
        message: "No data provided",
      };
      return;
    }

    // if everything is fine then perform
    // operation and return todos with the
    // new data added.
    let newTodo: Todo = {
      id: v4.generate(),
      todo: body.value.todo,
      isCompleted: false,
    };
    let data = [...todos, newTodo];
    response.body = {
      success: true,
      data,
    };
  },
  getTodoById: () => {},
  updateTodoById: async () => {},
  deleteTodoById: () => {},
};

Since we are going to be adding a new Todo to our list, I have imported 2 modules in the controller file.

• import { v4 } fromhttps://deno.land/std/uuid/mod.ts; this will be used to create a new unique one for the todo being created
• import Todo from "../interfaces/Todo.ts"; this will be used to ensure that the new todo that is being created follows the same structure.

Our createTodo controller is async meaning there are some promises used inside the controller.

Let's break it into smaller parts:

const body = await request.body();
if (!request.hasBody) {
      response.status = 400;
      response.body = {
        success: false,
        message: "No data provided",
      };
      return;
}

First we get the content of the JSON body that the user has sent us. Then we use oak's built-in method called request.hasBody to check if the user has even sent any content. If not then we can do if (!request_._hasBody) {} inside this if block.

We set the status to 400 (400 means that the user did something they were not suppose to do) and the body is set to {success: false, message: "no data provided }. Then we simple add return; to ensure that no further code below is executed.

Next we do this:

// if everything is fine then perform
// operation and return todos with the
// new data added.
let newTodo: Todo = {
  id: v4.generate(),
  todo: body.value.todo,
  isCompleted: false,
};
let data = [...todos, newTodo];
response.body = {
  success: true,
  data,
};

We create a new todo by doing this:

let newTodo: Todo = {
  id: v4.generate(),
  todo: body.value.todo,
  isCompleted: false,
};

let newTodo: Todo = {} ensures that newTodo follows the same structure as the rest of the todos. We then assign a random id by using v4.generate(), set todo to body.value.todo and isCompleted to false.

The thing to notice here is all the data the user sends us we can access from body.value in oak.

Next we do the following:

let data = [...todos, newTodo];
response.body = {
  success: true,
  data,
};

Append the newTodo to our current list of todos and simply set the body to {success: true & data: data.

And we are done ✅ with this controller as well.

Let's restart our server:

$ deno run --allow-net server.ts

In my postman, I open up a new tab. Set the request to POST type and in the URL bar type http://localhost:8080/todos. Then hit Send and this is what you see:

I send an empty request and get a 400 status error code along with an error message

Then I send some content in the body of the request payload and try again:

Awesome, POST /todos with body content { todo: "eat a lamma" } is success & we can see content appended to our current todo list

Cool, we can see that our API is working as expected.

Two APIs down, three more to go.

We are almost there. Most of the hard work is done. ☺️ ? ? ?

Let's move on to our third API:

import { v4 } from "https://deno.land/std/uuid/mod.ts";
// interfaces
import Todo from "../interfaces/Todo.ts";
// stubs
import todos from "../stubs/todos.ts";

export default {
  getAllTodos: () => {},
  createTodo: async () => {},
  /**
   * @description Get todo by id
   * @route GET todos/:id
   */
  getTodoById: (
    { params, response }: { params: { id: string }; response: any },
  ) => {
    const todo: Todo | undefined = todos.find((t) => {
      return t.id === params.id;
    });
    if (!todo) {
      response.status = 404;
      response.body = {
        success: false,
        message: "No todo found",
      };
      return;
    }

    // If todo is found
    response.status = 200;
    response.body = {
      success: true,
      data: todo,
    };
  },
  updateTodoById: async () => {},
  deleteTodoById: () => {},
};

Let's talk about our controller for GET todos/:id. This will get us a todo by ID.

Let's break this down into smaller parts and discuss it:

const todo: Todo | undefined = todos.find((t) => t.id === params.id);
if (!todo) {
  response.status = 404;
  response.body = {
    success: false,
    message: "No todo found",
  };
  return;
}

In the first part we set a new const todo and set its type to either Todo or undefined. So todo will either be an object with the Todo interface shape or it will be undefined – it can not be anything else.

We then _todos.find_((_t_) => t.id === params.id); use Array.find() to find the todo with the id provided in params.id. If it matches we get a Todo with shape todo, otherwise undefined.

If todo is undefined, it means that this if block will run:

if (!todo) {
  response.status = 404;
  response.body = {
    success: false,
    message: "No todo found",
  };
  return;
}

Here we simply set the status to 404 which means not found along with our standard failure response or { status, message }

Cool, right? ?

Next we simply do this:

// If todo is found
response.status = 200;
response.body = {
  success: true,
  data: todo,
};

Set a 200 success response and in our response body we set success: true & data: todo.

Let's run this in our postman.

Let's restart our server:

$ deno run --allow-net server.ts

In my postman, I open up a new tab. Set the request to GET type and in the URL bar type http://localhost:8080/todos/:id, then hit Send.

Since we are generating ID's randomly, first get all todos by hitting theget all todos API. Then from any todo get one of its ID to test this newly created API.
Every time you restart this Deno application, new ID's will be generated.

Let's go:

404 status, no record found case

Provided it a known ID and it returned the todo associated with that ID along with status 200

If you need to reference the original source code of this tutorial go here.

Great, 3 APIs done, 2 more to go.

import { v4 } from "https://deno.land/std/uuid/mod.ts";
// interfaces
import Todo from "../interfaces/Todo.ts";
// stubs
import todos from "../stubs/todos.ts";

export default {
  getAllTodos: () => {},
  createTodo: async () => {},
  getTodoById: () => {},
  /**
   * @description Update todo by id
   * @route PUT todos/:id
   */
  updateTodoById: async (
    { params, request, response }: {
      params: { id: string },
      request: any,
      response: any,
    },
  ) => {
    const todo: Todo | undefined = todos.find((t) => t.id === params.id);
    if (!todo) {
      response.status = 404;
      response.body = {
        success: false,
        message: "No todo found",
      };
      return;
    }

    // if todo found then update todo
    const body = await request.body();
    const updatedData: { todo?: string; isCompleted?: boolean } = body.value;
    let newTodos = todos.map((t) => {
      return t.id === params.id ? { ...t, ...updatedData } : t;
    });
    response.status = 200;
    response.body = {
      success: true,
      data: newTodos,
    };
  },
  deleteTodoById: () => {},
};

Let's talk about our controller for PUT todos/:id. This will update a todo by ID.

Let's break this down into smaller bits:

const todo: Todo | undefined = todos.find((t) => t.id === params.id);
if (!todo) {
  response.status = 404;
  response.body = {
    success: false,
    message: "No todo found",
  };
  return;
}

This is something we did exactly the same with the previous controller as well, so I won't go into much detail here.

Pro tip here: You can if you want make this piece of code a generic code block and then use it in both controllers.

Next we do this:

// if todo found then update todo
const body = await request.body();
const updatedData: { todo?: string; isCompleted?: boolean } = body.value;
let newTodos = todos.map((t) => {
  return t.id === params.id ? { ...t, ...updatedData } : t;
});
response.status = 200;
response.body = {
  success: true,
  data: newTodos,
};

The piece of code I want to talk about here is the following:

const updatedData: { todo?: string; isCompleted?: boolean } = body.value;
let newTodos = todos.map((t) => {
  return t.id === params.id ? { ...t, ...updatedData } : t;
});

First we do const updatedData = body.value and then add type checking to updatedData like the following:

updatedData: { todo?: string; isCompleted?: boolean }

This piece of code is telling TS that updatedData is an object which can have/not have todo: string and also can have/not have isCompleted: boolean.

Then we simply map over all todos like this:

let newTodos = todos.map((t) => {
  return t.id === params.id ? { ...t, ...updatedData } : t;
});

And where params.id match with t.id we simply append everything to that object we get from the user.

We are done with this API as well.

Let's restart our server:

$ deno run --allow-net server.ts

Open up a new tab in Postman. Set the request to PUT and in the URL bar type in http://localhost:8080/todos/:id, then hit Send:

Since we are generating ID's randomly, first get all todos by hitting get all todos API. Then from any todo get one of its ID to test this newly created API.
Every time you restart this Deno application, new ID's will be generated.

404 status returned and no todo found error message given

Provided a known ID, updated todo content in body. It returned the updated todo along with all the other todos

This is amazing – four APIs done and just one more to go.

import { v4 } from "https://deno.land/std/uuid/mod.ts";
// interfaces
import Todo from "../interfaces/Todo.ts";
// stubs
import todos from "../stubs/todos.ts";

export default {
  getAllTodos: () => {},
  createTodo: async () => {},
  getTodoById: () => {},
  updateTodoById: async () => {},
  /**
   * @description Delete todo by id
   * @route DELETE todos/:id
   */
  deleteTodoById: (
    { params, response }: { params: { id: string }; response: any },
  ) => {
    const allTodos = todos.filter((t) => t.id !== params.id);

    // remove the todo w.r.t id and return
    // remaining todos
    response.status = 200;
    response.body = {
      success: true,
      data: allTodos,
    };
  },
};

Let's talk about our controller for Delete todos/:id this will delete a todo by ID.

We simply run a filter on all todos:

const allTodos = todos.filter((t) => t.id !== params.id);

Remove the todo.id that matches with params.id and return the rest.

Then we do this:

// remove the todo w.r.t id and return
// remaining todos
response.status = 200;
response.body = {
  success: true,
  data: allTodos,
};

Simply return all the todos left which do not have the same todo.id.

Let's restart our server:

$ deno run --allow-net server.ts

Open up a new tab in Postman. This time set the request to DELETE and in the URL bar type http://localhost:8080/todos/:id and hit Send.

Since we are generating ID's randomly, first get all todos by hitting get all todos API. Then from any todo get one of its ID to test this newly created API.
Every time you restart this Deno application, new ID's will be generated.

With this we are all done with all five APIs.

Now we only have two things remaining:

• Add a not found route middleware so that when the user tries to access an unknown route it gives an error.
• Add a logger API that consoles the response time it took to return data from one API endpoint.

Creating a route middleware for routes that aren't found

In your root folder create a new folder called middlewares. Inside that folder create a file called notFound.ts and inside this file add this code:

export default ({ response }: { response: any }) => {
  response.status = 404;
  response.body = {
    success: false,
    message: "404 - Not found.",
  };
};

Here we aren't doing anything new – it is very similar to our controllers structure. Just returning a status 404 (which means not found) along with a JSON object for { success, message }.

Next go in your server.ts file and add the following content:

• Add this import somewhere at the top:

// not found
import notFound from './middlewares/notFound.ts';

• And then just below your app.use(todoRouter.allowedMethods()) add this line like this:

app.use(todoRouter.routes());
app.use(todoRouter.allowedMethods());

// 404 page
app.use(notFound);

The order of execution is important here: every time we try to access an API end point it will first match/check routes from our todoRouter. If none are found, it will then execute app_.use_(notFound);.

Let's see if this works.

Restart the server:

$ deno run --allow-net server.ts

Open up a new tab in Postman. Set the request to GET and in the URL bar type http://localhost:8080/something-unknown, then hit Send.

So we now have a route middleware that we put at the end of our routes in server.ts as app_.use_(notFound);. If no route matches this middleware it will execute and return a 404 status code (which means not found). Then we simply send a response message like always which is {success, message}.

Pro tip: We have decided that {success, message} is what we return in failed scenarios and {success, data} is what we return to user in success scenarios. So we can even make these to object/shapes as interfaces and add them to our project to ensure consistency and safe type checking.

Cool, now we are done with one of our middlewares – let's add the other middleware for logging our APIs in the console.

Reminder: If you get stuck anywhere you can use the source code here.

Logging APIs in console

In your middlewares folder create a new file called logger.ts and enter the following code:

import {
  green,
  cyan,
  white,
  bgRed,
} from "https://deno.land/std@0.53.0/fmt/colors.ts";

const X_RESPONSE_TIME: string = "X-Response-Time";

export default {
  logger: async (
    { response, request }: { response: any, request: any },
    next: Function,
  ) => {
    await next();
    const responseTime = response.headers.get(X_RESPONSE_TIME);
    console.log(`${green(request.method)} ${cyan(request.url.pathname)}`);
    console.log(`${bgRed(white(String(responseTime)))}`);
  },
  responseTime: async (
    { response }: { response: any },
    next: Function,
  ) => {
    const start = Date.now();
    await next();
    const ms: number = Date.now() - start;
    response.headers.set(X_RESPONSE_TIME, `${ms}ms`)
  },
};

In your server.ts file add this code:

• Import this somewhere at the top:

// logger
import logger from './middlewares/logger.ts';

• Just above your todoRouter code add these middlewares like this:

// order of execution is important;
app.use(logger.logger);
app.use(logger.responseTime);

app.use(todoRouter.routes());
app.use(todoRouter.allowedMethods());

Now let's discuss what we just did.

Let's talk about the logger.ts file and break it down into bits:

import {
  green,
  cyan,
  white,
  bgRed,
} from "https://deno.land/std@0.53.0/fmt/colors.ts";

I am importing some console colors and console background colors that I want to use in API logging.

This is similar to what we did in our eventListener in our server.ts file. We will use colors in our console to log API requests.

Next I set const X_RESPONSE_TIME: string = "X-Response-Time";. This is the header we will inject in our API requests as they come into our server. I am calling this X_RESPONSE_TIME and its value is X-Response-Time. I will demonstrate its usage in a bit.

Next we simply export an object like this:

export default {
    logger: async ({ response, request }, next) {}
    responseTime: async ({ response }, next) {}
};

And then we simply use it inside our server.ts file like this:

// order of execution is important;
app.use(logger.logger);
app.use(logger.responseTime);

Let's now discuss what is happening in our logger middleware code and discuss it execution style using next():

Execution of order of logging middleware when GET /todos API is called.

The only difference here and in the controllers we had before is the use of the next() function. This functions helps us jump from one controller to the other as shown in the image below.

So in:

export default {
  logger: async (
    { response, request }: { response: any, request: any },
    next: Function,
  ) => {
    await next();
    const responseTime = response.headers.get(X_RESPONSE_TIME);
    console.log(`${green(request.method)} ${cyan(request.url.pathname)}`);
    console.log(`${bgRed(white(String(responseTime)))}`);
  },
  responseTime: async (
    { response }: { response: any },
    next: Function,
  ) => {
    const start = Date.now();
    await next();
    const ms: number = Date.now() - start;
    response.headers.set(X_RESPONSE_TIME, `${ms}ms`)
  },
};

Keep in mind that this is what we have in our server.ts file:

// order of execution is important;
app.use(logger.logger);
app.use(logger.responseTime);

app.use(todoRouter.routes());
app.use(todoRouter.allowedMethods());

The order of execution is as follows:

• logger.logger middleware
• logger.responseTime middleware
• todoRouter controller (whatever path is called by the user, for the purpose of explanation I am assuming that the user called GET /todos API to get all todos.)

So it will first execute logger.logger middleware which is this:

logger: async (
    { response, request }: { response: any, request: any },
    next: Function,
  ) => {
    await next();
    const responseTime = response.headers.get(X_RESPONSE_TIME);
    console.log(`${green(request.method)} ${cyan(request.url.pathname)}`);
    console.log(`${bgRed(white(String(responseTime)))}`);
  },

It will come inside this function and immediately as it reads await next() it quickly jumps to the next middleware which is responseTime:

Sharing the image above again for revision.

Inside responseTime, it only executes two lines which are (look at execution order 2 in image above):

const start = Date.now();
await next();

before jumping to the getAllTodos controller. Once it goes inside getAllTodos it will run the entire code inside that controller.

Since in that controller we are not using next() it will simply return the flow of logic back to responseTime controller. There it will run the following:

const ms: number = Date.now() - start;
response.headers.set(X_RESPONSE_TIME, `${ms}ms`)

Now keeping in perspective of the order of execution which is 2, 3, 4 (look at the image above).

This is what happens:

• We capture the data in ms by doing const start = Date.now();. Then we immediately call next() which goes to getAllTodos controller and runs the entire code. Then it comes back in the responseTime controller.
• We then subtract that start date with whatever the date is at that moment by doing const _ms_: _number_ = _Date.now_() - start; ms. Here it will return a number which is basically the difference in milliseconds that will tell us all the time it took Deno to execute our getAllTodos controller.

Sharing the image once again for review:

• Next we simply set headers in our response like this:

response.headers.set(X_RESPONSE_TIME, `${ms}ms`)

Which just sets the header value X-Response-Time to the milliseconds it took Deno to execute our API.

• Then from execution order 4 we move back to execution order 5 (have a look at the image above for reference).

Here we simply do:

const responseTime = response.headers.get(X_RESPONSE_TIME);
console.log(`${green(request.method)} ${cyan(request.url.pathname)}`);
console.log(`${bgRed(white(String(responseTime)))}`);

• We get the time we passed in the X-Response-Time
• Then we take that time and simply console it colourfully in the console.

request.method tells us the method used to call our API, that is GET, PUT etc while request.url.pathname will tell the API which path the user used i.e, /todos

Let's see if this works.

Restart the server:

$ deno run --allow-net server.ts

Open up a new tab in Postman. Set the request to GET, type in http://localhost:8080/todos, and hit Send.

Hit the API a couple of times in Postman. Then when you go back to the console, you should see something like this:

API being logged in our console

This is it – we are done.

If you still feel stuck, take a look at the entire source code for this tutorial here: github.com/adeelibr/deno-playground/tree/master/chapter_1:oak

I hope that you found this article useful and that it was able to help you learn something today.

If you liked it, please do share it on social media. If you want to have a discussion about it, reach out to me on Twitter.

Why should we write in the first place?

Maybe you've never thought about writing before or maybe you're looking for a little more motivation. Whatever the case, there are a lot of good reasons why writing can help us grow.

Helping others to learn

Coding can be tough. And we all started somewhere at the beginning.

It's a long journey that each of us go through and it's even harder to go at it alone. Luckily, we've had websites like freecodecamp.org and css-tricks.com along the way that have made that journey more manageable, but there's always going to be a challenge that just doesn't make sense.

CSS-Tricks around 2011 when I got my first official coding job via Way Back Machine

This is where we have an opportunity to share our experiences to help others grow. While our favorite coding sites have tons of amazing tutorials, maybe they're missing a key point someone needed to fully grasp the solution.

Whether you're at the beginning or middle of your journey, every experience, big or small, can help another developer on their own journey.

And this is where it can be rewarding. One of my favorite parts of writing has been getting a Twitter DM from someone about how one of my tutorials helped them learn. It's a great feeling knowing you helped someone else on their journey.

Take this as a way for you to give back to the community that helped you learn and grow.

Reinforcing your learning

Thinking back to your grade school Spanish class, one of the tricks to helping the students learn was to reinforce learning. Teachers use different methods like reading, writing, speaking, flashcards, or even that Cinco de Mayo fiesta where you learned about and celebrated Mexico's heritage to help make the language stick.

This applies to development concepts as well. While your solution is still fresh in your head, write it down! Being able to teach what you've learned by writing about it will help those concepts stick in your head.

And just because you write it, it doesn't mean you have to share it. If you're not comfortable sharing it with the world, just keep a copy in a private notebook. You'll always be able to reference it yourself and still reinforce what you know by writing it down.

Documenting our experiences

Doubling up on reinforcing your learning, by writing about your experiences, you're kind of creating your own personal StackOverflow with a list of problems you've already solved.

As much as we had hoped we would remember how to speak Spanish from the classes we took, 10 years goes by pretty quickly and you suddenly realize you can only correctly say "hola" in Spanish.

_Hola sign from Jon Tyson on Unsplash_

If you were the ambitious type, maybe you saved all of your notes. If not, maybe you remember a good website that has flashcards.

Either way, having resources to go back to, whether it's your own notes or that website you still have bookmarked, helps us to quickly reference challenges we've already come across. By writing down your experiences, you're adding to that digital notebook that you know you can always use to remember that quirk you fixed.

Growing your personal network

Everyone has their own reasons for wanting to write and share content – and that's okay! While some of us might be doing this to help others learn, others might be simply trying to get a job or grow their Twitter following.

One of the benefits of sharing your experiences is that you're immediately growing the network of developers that have a little more insight into who you are and the work you've done.

This doesn't guarantee a job, but it certainly can help. All teams are a little different in how they recruit. Smaller teams tend to include other developers more in the beginning of the process who are probably more likely to open your blog and not only read a little bit, but actually understand it.

But even if you don't immediately get hired, you're playing the long game. Opportunities will start to come in small ways that lead to bigger opportunities down the road.

Why you might be hesitating and how we can look at it another way

Sometimes motivation isn't enough. We all have our personal challenges that might prevent us from doing something we want to do. But sometimes it's a matter of finding a different perspective to give you that bit of inspiration to finally dive in.

Imposter syndrome – who am I to write about this?

This is something I've personally struggled with for the majority of my career. Whether I was confident in my ability to do my job or not, I never felt like it was enough to be one of the people writing guides for others.

My website and blog

It wasn't until another team member brought another perspective to this argument (thanks Marquet) – everyone learns differently and maybe my way of telling a story can help someone learn.

If someone doesn't read my work, what are the consequences beyond a little bit of wasted time? On the other hand, maybe my blog post resonated with someone in a way that other blog posts didn't and they were finally able to solve their problem.

And this goes for any level of experience. As Swyx says, the fastest way to learn is in public. If you're not helping someone else, you're at least helping yourself grow.

Finding time – it takes a while to write a post

Time is a funny thing – it becomes an excuse that we use when we don't want to admit the real reason we're holding back.

Of course that's not always the case. Realistically a lot of us have a ton on our plates already whether we work, take care of a family, or are volunteering to help others. It can be a struggle to not want to just sit on the couch after a hard day's work.

But consider the free time you do have. Can you spare 10 minutes jotting down a few notes or even starting an outline of some things you want to say?

While 10 minutes won't write a whole post, if you start the habit and write another paragraph or two every day, you'll slowly end up with a blog post that you can feel good about sharing.

Just don't set the bar too high. If you start off with an unrealistic goal, you're likely to burn out fast and end up back in the same position you're at now.

No topic – not knowing what to write about

From speaking with other developers, I've noticed this seems to be tied a little bit to imposter syndrome. Maybe you're getting confident enough that you're more willing to write, but you're struggling to find what to write about. Is it because you can't think of a topic or is it because every topic you think about, you don't think you're enough of an expert to write about it?

Not having a topic can be a legitimate problem, but there's inspiration all around us. If you're working every day as a developer, you're working on problems that you ultimately need to solve. Why not write about those problems? And if you can't write about the problems due to contract concerns, what about writing about them in an abstract way without any sensitive information?

Inspiration for me comes from my experience talking with others. I'm lucky to be on a team that encourages growth of junior developers and during my time helping them out, their questions lead me to think about topics that I took for granted.

Whenever a topic like that comes up, I immediately note it down for later. This topic was on that list! Over time, my list of topics has grown to a point where I don't think I'll even finish it by the end of the year.

My personal list of topic ideas

While that could feel overwhelming, it's also motivates me to have a bigger selection of what I'm in the mood to write about rather than forcing myself to both think of a new topic and write about something I don't want to write about each week.

Whatever the case, find your source of inspiration. You don't need to be an expert on it. It doesn't matter if someone more experienced already wrote about it. Write what you know. Share your experiences. Maybe you'll help someone see the problem from a different perspective.

Finding what motivates you

At the end of the day, writing is something that each of us will need to find our own motivation to do.

Try to evaluate your goals. What are you looking to achieve? If writing is something you truly want to do, you'll need to find your own source of inspiration.

While some reasons might be more valid than others, it's easier to find reasons not to do something than it is to do it.

You got this! ?

In this article we'll explore what kinds of things you can do to make it a little easier on your future self.

Revisiting "prior art"

We've all been there. Six months into a project, you're trying to squash a bug, and what you find is shocking. You might be asking yourself, "who would write this kind of code?"

So you dig through your git commit history using git log -p filename.js showing changes for a specific file, trying to see who would come up with something like that. And then your heart drops – you're the one who wrote it!

Tituss Burgess shocked

This is a common scenario for any developer, experienced or new. If you haven't hit that scenario, I promise if you stick with coding long enough, you will.

Becoming more conscious about our coding habits

That six month reflection point is inevitable. That's a lot of time which you've most likely been using to work on other parts of the project or another project completely. Chances are, you've leveled up which has changed the way you write code.

On the other hand, sometimes it takes stepping outside of the code to see the bigger picture and get a better look at how all the pieces fit together. We can naturally dig ourselves too deep into a solution and can become a little narrowly focused as we work to solve those challenges.

But either way, while part of the code journey will simply be gaining more experience and learning more about your craft, there are other small habits you can get used to early on that will help you down the road.

So let's jump in.

Improving the readability of your code

What is the challenge?

Part of the fun about our craft is there are a ton of ways you can do the same thing. Think an if statement is too many lines? Well we can write it ternary style!

// Example ternary statement
const isFreezing = temperature <= 32 ? true : false;

But sometimes this takes a toll on the readability of your code. While it might seem like it looks nice and super clean on one line, imagine that as that ternary gets more complex, someone will have to spend more time understanding what it means.

const minutes = 30;
const cookie = {
  color: 'black'
};

const cookieStatus = minutes > 20 ? cookie.color === 'black' ? 'burned' : 'done' : 'not done';

What can we do better?

Now I would imagine most of us can figure out what cookieStatus is in this example (spoilers: burned). But think about the time you spent figuring it out. Whether an extra 1s or 2s, it forces you to spend additional cognitive energy to read through the code.

On the other hand:

const minutes = 30;
const cookie = {
  color: 'black'
};
let cookieStatus;

if ( minutes <= 20 ) {
  cookieStatus = 'not done';
} else if ( cookie.color === 'black' ) {
  cookieStatus = 'burned';
} else {
  cookieStatus = 'done';
}

No, it may not be as clean or clever as the 1-line ternary statement, but the next time you visit it, the less you'll have to think about what the answer is.

It's also going to make it that much easier for bugs to creep up and get past your code reviewers when all of your code changes are in a 1-line git diff.

And yes, this is a simple example. But imagine this in a real world scenario with important business logic where you could run into these situations frequently.

Say you need to add another condition – that ternary is just going to keep getting more complex! You're just making it more difficult to debug or extend, where the if statements can continue on in an easily readable way.

For what it's worth, ternaries and other shortcuts can be simple and effective in code, but don't abuse that effectiveness and end up making things more difficult.

Keeping things consistent

What is the challenge?

We all have our favorite way to code. Though I'd argue not including a semicolon at the end of your JavaScript is just completely wrong, you might prefer to write your code the wrong way without them.

// Jim's code style

function MyComponent() {
  function handleOnClick() {
    alert('Click!')
  }
  return (
    <button onClick={handleOnClick}>My Button</button>
  )
}

// Creed's code style

const MyComponent = () => <button onClick={() => alert('Click!')}>My Button</button>;

But it's not always about what you prefer. When working with a team, chances are, everyone's opinion on how code should look is slightly different. You might agree about the semi-colon, but disagree about whitespace.

And no one is wrong (except for the non-semi-coloners)! There are valid arguments to most code styles, whether for or against, but the solution isn't for everyone to write their code their own way.

What can we do better?

Keeping code consistent is important to maintain code health. A typical goal is to "make the codebase look like one person wrote it."

The point isn't that one person gets their way, it's that the team came to a conclusion about a set of rules they would use that everyone would follow. Having this consistency provides less cognitive overhead as people work through the code. It gives everyone the ability to know what to expect when reading the code.

Errors from linting code

And achieving this doesn't need to be hard. There are tools that can simply check for these inconsistencies like Eslint for Javascript. And even better, there is another level of tools like Prettier that will fix it for you!

Commenting your code

What is the challenge?

Keeping up with commenting your code is an important way to put context to complex logic. As much as we all want our code to be self-documenting, that's rarely the case.

Too often we find ourselves dealing with a block of code that just doesn't make sense. And even if it makes sense on its own, we might not be able to figure out how it fits in to the rest of the application.

What can we do better?

By providing a good set of comments, you're setting up the next person who touches that code to have a better understanding of what the code is doing before they make a change.

// DONT CHANGE - WILL STOP MAKING MONEY

const shouldMakeMoney = true;

function makeMoney() {
  if ( shouldMakeMoney ) {
    return noMoney;
  }
  return moreMoney;
}

While this is a silly example, it brings up a real world case. Businesses are increasingly dependent on being able to maintain a reliable website to make money. Whether this is as an ecommerce business or an ad giant, these websites rely on business logic that determine things like cost, taxes, discounts, and other math related things we tend to not want to think about, but could make or break a business on the internet.

But it's not all about the company you work for. Touching old code can be scary. It's even scarier when no one on your team was around when it was written, so no one knows what it does!

Patton Oswalt hands over mouth

While you might not be the next person who touches that code, try to help out your future friend who's tackling the next ticket involving that code. Because there's also a good chance you will be that person and you'll wish you remembered how it worked.

Documenting your solutions

What is the challenge?

Documentation is similar to commenting your code, but from a different perspective. Documentation and commenting are both about finding ways to describe a solution in a human-readable way that will ultimately give more context. But documentation is more about the overall solution rather than the implementation details.

Having a high performing application is everyone's goal. But how did we get there? There's a realistic chance that someone will have to be working on the same project you are like onboarding a new team member. How will they be able to maintain that high performance if they don't know how it works?

What can we do better?

Whether it's introducing that new team member to the project or trying to share knowledge with another project team, documentation is an important part of maintaining a project. It helps keep everyone on the same page so we all confidently know what we're working towards.

For example, if we're still working with our ecommerce project with our business logic, there will be rules that the code needs to implement. While commenting might give details inline about how the rules were implemented, the documentation would define those rules.

/**
 * DOCUMENTATION
 * Order Total >= 25: Discount %10
 * Order Total >= 50: Discount %15
 * Order Total >= 100: Discount %20
 * Order Total >= 75: Free Shipping
 */

const orderSubTotal = 84.00;
let orderTotal = orderSubTotal;

// If the order total is under 75, apply shipping discount

if ( orderTotal < 75 ) {
  orderTotal = addShipping(orderTotal);
}

// If the order total reaches a threshold, apply given discount

if ( orderTotal >= 100) {
  orderTotal = applyDiscount(orderTotal, .2);
} else if ( orderTotal >= 50 ) {
  orderTotal = applyDiscount(orderTotal, .15);
} else if ( orderTotal >= 25 ) {
  orderTotal = applyDiscount(orderTotal, .1);
}

This is a minimal example, but we can see the difference between the rules at the top and how we apply them. The documentation should clearly explain what the rules are, but it shouldn't care about how those rules were implemented.

On the other hand, the comments might not care about what the rules are, but need to implement them in an efficient and logical way. We should be able to update the code with the business rules, such as changing the top level discount tier from $100 to $80, without having to rework the code.

But documentation is much more than business rules – it's providing a way for anyone to understand your work from a higher level. This could include anything from architectural diagrams to the theory behind your core algorithm.

While maybe code isn't the best place for details like this to live, it's really important information that can help instill confidence in your project and give others an opportunity to understand more about the work.

Creating effective Pull Requests

What is the challenge?

Pull requests (or merge requests) are a core part of any development team's project lifecycle. It provides a way to package and present your code in a consumable way for your peers to review and understand your work.

There's a lot that can go into a pull request from a single commit to the entirety of the next version of your website. That's a lot of context to expect someone to understand by reading through the commits alone.

What can we do better?

Pull requests don't need to be an art. There should be one primary goal of the preparation you put into it – providing context into your changes. At a minimum, it should answer the questions of "what" and "why".

We can even use tools like pull request templates to push us in the right direction. Define an outline of what you want explained and chances are, people will follow that outline. This helps avoid the 1-line "closes [ticket]" description or even worse, an empty description.

With my projects, I hope to have a few questions answered before I dive into a code review:

• What is the change?
• What does it impact?
• How do I reproduce or test the change?

Just a few details around the change set can provide much needed context for those reviewing your code. It's easy to look at code, but it's harder to understand it without knowing how it fits into the bigger picture.

Hardening your code with tests

What is the challenge?

Tests are a way to ensure your code runs the same way each time. Being able to prove that the same input will always have the same output will help provide you and your team with a higher level of confidence that your application won't come crashing down with the next small change.

Without them, we're left with human error, where no matter how good your QA Engineer is (shoutout to my testers out there), something will always slip through. And that's not to say your tests will always catch every problem, but we can use the tools available to help prevent it.

What can we do better?

Where comments are a way of providing the context of how something works, test are a way to ensure they work. Providing test cases that are repeatable helps enforce that.

function applyDiscount(value, discount) {
  const discountAmount = value * discount;
  return value - discountAmount;
}

expect(applyDiscount(10, .1)).toEqual(.9);
expect(applyDiscount(532151235, .1054)).toEqual(476062494.831);

If I fudge the math on our applyDiscount function above, there's a high probability that the test would fail (never say never).

But testing doesn't need to be hard. There are many tools out there that help from different perspectives. For example, you might use Jest to run your unit tests or add Enzyme on top to test your React components. But you can also bring in Cypress as an integration test solution that will work like a robot clicking through your application to make sure all the components actually work together.

There's also different methodologies of testing. While you probably see most teams write their tests after they have a working solution, some people swear by test-driven development. They might write their tests first where the code has to pass the tests rather than the other way around. This is a great way to define the requirements of the code before diving right in.

Whatever the method, capture the points that are most likely to break or the functions that add the most business value. You'll be helping to prevent a potential business loss or even simpler, a headache.

What can we learn from this?

That might be a lot to digest, but they're important points to consider as you grow as a developer. Starting these habits early in your career will help you naturally build these skills and work that way by default.

And if you're late in your career, it's never too late to start. We should all want to strive to be the best developer we can be and do our best to help make our teammate's lives easier, as we're all in this together.

Looking for more to learn?

• Put Down the Javascript - Learn HTML & CSS
• How to Become a Full Stack Web Developer in 2020
• What is the JAMstack and how do I get started?
• What is linting and how can it save you time?
• Why you should write merge requests like you’re posting to Instagram

What’s your advice for growing as a developer?

Share with me on Twitter!

Twaikura, haikus but funnier

As easy as ABC: some stranger on the Internet starts a 120 characters story, some stranger on the Internet finishes it. And that makes a Twaiku (tweet + haiku). Twaikus can be funny, serious, artistic, it’s up to you.

So, as a developer, implementing something like that shouldn't be hard, right? Yes, but no. Here is the story of how it took me multiple years to create Twaikura and how you could do the same in a matter of hours.

Back to TwentyParts and why it never came to existence

TwentyParts was my first “entrepreneurial concept” back in 2015. As you may guess, the idea is to write a story in 20 parts, with each part written by a different author.

I was a CS student at the time and it took me 2 months to release a first draft. The result was disastrous. I didn’t even know about the concept of a “framework”, picture the code. The concept was too complex, the interface unusable.

I did not give up. A few months later, in 2016, I came up with a simplified version of TwentyParts, HiKoo. I limited the length of a story to 3 tweets. And instead of rushing to development, I created mocks using a marvelous tool named MarvelApp.

Now I had a great UI and all, but no working code. One more app that never came to existence.

Looks good, doesn't work

Fast forward to now. I’ve graduated. I’ve built my consulting company, LBKE. I’ve developed complex SaaS platforms for multiple clients. And I've kept this question running in my head:

What prevents me from recreating TwentyParts, now I am fast and skilled and over-confident?

After all, it would only take a full work week nowadays. Yet there’s a problem: I am not a student anymore. With one spare hour here and there, a “full work week“ can span over a few months. Too slow.

How to code fast: don’t.

I’ve explored thoroughly the realms of fast web development. You may have read my previous articles on freeCodeCamp about Vulcan, a framework based on Meteor that makes me very productive.

Those researches all lead me to the same conclusion: the best code is the code you don’t write.

There are a lot of ways NOT to write code, even for a developer. Scaffolding, declarative programming, using snippets, or using an ORM are all methods to circumvent writing code. Using open source is another great example. Some may even think that developers are a bit lazy – but aren't they?

Yet minimal skills in web development are still necessary. That means careful thinking, lots of doc reading, debugging and so on. In the end, the time needed to create a fully functional app can only be reduced this much.

You know what? Using a massive framework to speed up developments feels like cheating sometimes. What if I did not have those skills? What if I was not a developer? I would have no other choice than embracing the “no-code way”. And that’s what I’ve done.

Relax, Code will be on vacation for the remainder of this article

Sparkling innovations for web non-developers

No-code solutions have been pretty bad in the past. Limited, difficult to extend, proprietary, expensive, the list is long. But some recent tools are starting to be worthy enough.

I will focus specifically on Bubble. Its plugin system coupled with its data management features makes it the most complete solution on the market currently. Here are a few key features and how I used them to build Twaikura.

The UI editor

Bubble proposes a WYSIWYG editor (What You See Is What You Get) to create the app user interface. You put your blocks of content wherever you want, and configure their content.

It’s grid-based so you can have pixel perfect alignment. It handles responsiveness. So you should be able to create designs as complex as you wish.

Building Twaikura's interface using the WYSIWYG editor.

But I’ll be honest, I am not the hugest fan. More precisely, I am not very good with it. It’s very different both from writing HTML/CSS and from using web-based design tools like Figma, so there is a learning curve.

I ended up sticking myself to an old school Windows 98-ish style. With a little bit of imagination you could even believe it has some “V a p o r w a v e” aesthetic.

Thinking in workflows

The most impressive feature of Bubble to me is its “Workflows”. It lets you describe complex process in a visual language. It can mix data management (validating and storing a Twaiku, sending an email) and user experience (resetting a form, refreshing the page) transparently. You don’t need to mentally split the workflow between frontend and backend as you would do in a traditional web app.

Twaiku creation workflow

This example workflow is triggered when the user wants to submit the second part of a Twaiku. It will create a "Twaiku End" in the database, link it with a "Twaiku Begin", and reset the form. I could also display a success message, send a mail to a moderator and so on. Visualizing the full workflow in a single timeline is very intuitive.

Complete data management

Bubbles comes with a relational database and complete filtering features. That means you can easily create both forms and list of data. For example, the “Read latest Twaikus” block will load all valid Twaikus.

Plugins can help secure your content. For example, there is a ReCaptcha plugin to add CAPTCHAs to your form in a matter of minutes. This is important as security is usually left behind in the prototyping steps. Malevolent bots and hackers don't care that you are a "lean startup-er", and they won't miss an opportunity to spam or hack your website.

A few hours of work for an app that works

I won’t describe all features of Bubble, because it has a lot more. The conclusion is that it's been powerful enough to write an app like Twaikura. Instead of writing tons of crappy code that will end up in a dumpster, instead of creating a visual prototype as lively as Frankenstein’s Creature, I just created something that works.

Is my website great? Honestly, not yet. Does it do the job? Hell yes. I had fun creating it, it cost me no more than a few hours, and I am able to test the concept in the most direct possible way. The longest part was writing this article.

I especially recommend no-code tools for people who want to learn web development. Taking a lot of time to produce simple features can feel frustrating at first. Using a no-code tool alongside traditional programming is a way to keep having fun. It's instructive too, because, even if you don't write code, you still have to think like a developer: designing conditional workflows, structuring a database, validating forms... That's a win-win.

I won't become a no-code evangelist, but Bubble is a great addition to my tool belt. And it could be great addition to yours too!

Thanks for the read. If you liked this article, come try a Bubble app by creating your first Twaiku on twaikura.com!

People tend to use the terms “problems” and “exercises” interchangeably. But there’s a difference—and it matters.

Professor Paul Zeitz makes the distinction.

Take 5 × 5. That’s easy, and that’s an exercise. So is 5,490,900 × 496. It’s a bit harder and will take you more time to solve, but you know what to do. That’s the key point.

“An exercise is a mathematical question that you immediately know how to answer,” explains Zeitz in a lecture series on problem-solving. “You may not answer it correctly, in fact you may never answer it correctly...but there’s no doubt about how to proceed.”

Not so with problems. A problem, according to Zeitz, “is a mathematical question that you do not know how to answer, at least initially.”

He defines problems and exercises through the lens of mathematical problem-solving, but they’re applicable to programming as well.

Each day we put our problem-solving skills to work as programmers: debugging code, learning a new topic, or even solving a problem. Exercises have their place, but as a programmer there’s no replacement for solving problems.

Exercise with Exercises

There are two ways you can benefit from exercises. First, they’re helpful when learning a new topic.

I’m learning JavaScript right now and using a mix of exercises and problems to do so. The exercises help me see patterns and get comfortable with concepts and syntax.

Here’s an example of an exercise from a project that asked me to write a function, which took an array of cars.

const cars = [
  { id: 1, car_make: "Lincoln", car_model: "Navigator", car_year: 2009 },
  { id: 2, car_make: "Mazda", car_model: "Miata MX-5", car_year: 2001 },
  { id: 3, car_make: "Land Rover", car_model: "Defender Ice Edition", car_year: 2010 },
  ...
 ]

I had to sort the array of objects by the car_model key, in ascending order.

It’s not to say this exercise was a breeze—it wasn’t. It took me time and I got my fair share of error messages.

However, it qualifies as an exercise because I knew what I needed to do from the start.

I’d recently learned about arrays in JavaScript. I was familiar with sorting data from my experience with Python, though I had to research how to do this in JavaScript. The explicit directions helped, too.

But the concepts were still new. I needed practice putting them together, which is why this exercise was valuable. Repetition breeds familiarity, and the concepts began to solidify in my mind.

Maintain What You’ve Gained

Exercises also help keep learned information fresh.

As I learn JavaScript, I don’t want to forget everything I’ve learned about the first language I learned, Python. So I use Anki, a flashcard program, multiple times per day.

In this context, exercises help you keep a mountain of material straight, remind you of important concepts, and get more comfortable using a particular data structure or approach. It’s maintenance work on the body of knowledge you’ve gained so far.

I have over 1,000 cards that are filled with material I’ve seen many times before. Some cards have questions about syntax. Others ask me to write SQL queries or command-line or Git commands. Many others are filled with exercises, like “rotate a list of numbers to the right by one place value.”

It’s important to note that this exercise was once a problem for me. If you do a problem enough, it can become an exercise. At the same time, you can make an exercise a problem by adding a constraint.

Exercises are a slippery slope. On the one hand, they’re useful for learning purposes. On the other, it’s easy to get comfortable by sticking with exercises exclusively.

That’s the downside: staying in your comfort zone.

Dealing with Ambiguity

Programming is about problem-solving. And solving problems will take you outside of your comfort zone. This is a good thing.

For me, problems have two distinctive qualities. The first is ambiguity. Problem-solving is largely about how to effectively deal with ambiguity.

• An error message appears each time your program runs. Why? What’s going on? Where’s the bug? How can you fix it?
• You pull up a new problem statement. You read it and re-read it. At first glance, you’ve got no idea what’s going on, let alone what you need to do to solve it. You may even get the “deer in headlights” sensation that’s accompanied by a pit in the bottom of your stomach. (You picked a good problem!)
• You need to learn about relational databases. That’s pretty broad. How are you going to go about it? What to focus on first? What matters most? What do you really need to know right now?

These examples all involve ambiguity. And all of them require solving problems, whether that’s finding and trouble-shooting a bug, solving an actual problem, or learning a new topic.

To make progress, you research, experiment, pull out the facts, create a plan, and apply a variety of problem-solving tactics. In short, you learn to figure it out. The more time you spend with a problem and the different perspectives you gain, the more layers it reveals and the closer you get to the “aha” moment.

Embrace the Struggle

The other difference with problems is the struggle. It’s real.

Problem-solving will test your mental stamina and patience. Progress can be slow, and the process tedious. I’ve toiled away at problems for hours, days, and even weeks.

It’s not to say that exercises won’t challenge you. They can. It’s one thing when you know that you need to use a particular method; you just need to get it to work properly. That’s a challenge, which can sometimes be downright frustrating.

But it’s something else entirely when you have no idea what to do from the start, which may happen multiple times when solving a problem. To me, problems are a struggle.

The best solution is to endure it and get yourself unstuck. In my experience, the struggle means I’m learning a lot and the breakthrough is usually around the corner.

As you push through the mental discomfort, you’ll find yourself thinking creatively and devising solutions you never thought of before. (You surprise and impress yourself—you know more than you think!) You’re becoming a stronger programmer.

You’ll even find yourself having fun. Problem-solving is challenging, to be sure, and even frustrating at times. But it’s also incredibly rewarding.

It’s like crossing the finish line of a half-marathon. No doubt the past 13.1 miles were grueling, but crossing the finish line was worth it and I’d do it again. Solving a problem feels the same way.

Which Is It: Problems or Exercises?

When you crack open your laptop, are you going to solve problems or complete exercises?

Exercises have benefits, and it’s fine to incorporate them into your programming sessions. I use exercises as a warm-up prior to a programming session. I’ll flip through an Anki flashcard deck for ten or fifteen minutes and work through some exercises. If I’m learning something new, like JavaScript, I may have an entire programming session devoted to exercises.

However, I devote time each day to solving problems—no matter what else I’m learning or building. Even on the days when I allocate a large chunk of time to exercises, I allocate plenty of time to solving problems, too.

So when you’re about to start a programming session, be aware what you’re setting out to do: exercises or problems. And no matter what, make time for solving problems.

Problem-solving is a skill that takes a lot of practice and time to develop. The only way to get better is to work at it each day. It’s that important, and for good reason.

We solve problems each day as programmers, and in a variety of ways. Making time to problem-solve is a no-brainer; our work as programmers depends on it.

I write about learning to program, and the best ways to go about it (amymhaddad.com).

As many of you know, I have been applying for a job in web development for a few weeks and I thought it would be a good idea to share some of the coding challenges I've encountered.

Not only that but I'll share the ways I went about solving these challenges. Granted, there are many ways to solve these challenges but these are the ways I went about it. If you have different ways that's awesome and I'd love for you to share them with me!

I will not share any identifiable information about the companies or specifics on the interview process of said company to preserve process integrity.

Alright, let's get to it then.

The Challenge

This is a challenge I was given recently that I felt good about solving:

Task: Return a basic styled list of posts from an endpoint in reverse chronological order

To protect the company and their information, I will not share the URL from which I returned the information but instead will have a generic link from JSONPlaceholder (a great, free, open source API for developers when you need to get some generic outside data) in the code below.

Here's the HTML I started with so we have something to display our results in:

Basic HTML boilerplate

The

Fetching Data From the Endpoint

Alright, let's dig into the JavaScript portion of this challenge. First, I like to set my output and display variables:

Our variables used when displaying the returned code

I use let for the output variable and set it to null because we will change it's value later in the code. The list variable is declared with const because it's value will not be changing.

Fetching data from the endpoint

In the above example, we’re declaring an arrow function named getData wrapped in a try…catch block (This is a cleaner/easier to use/read syntax that uses tries some code and catches errors if they happen — you’ll also see the catch portion below). Because we're getting data asynchronously we also need to make use of async/await to fetch data. This is the method I'm most comfortable with but I know there are many other ways to get data from an endpoint so feel free to share yours :D

Once we've declared our data variable, the next thing is to set a variable to turn the returned data to a JSON object so we can get it in a usable form. We do that with the .json() method. We're awaiting the data as well because if we were to omit the await keyword, JavaScript would try to turn the data variable into JSON but the data would not be there yet because it's coming from an asynchronous API.

Our glorious data!

As the very last line in the section, we console.log our data that we get back from the API endpoint just to make sure we're getting everything we wanted. We have an array full of objects. You'll also notice that the key _publishedat holds our dates and they are not in any type of order. Their format is also not a simple four digit number representing the year which would make it easy to filter them into reverse chronological order. We'll need to take care of that.

Manipulating Our Data

Making a copy of our data variable

Here we declare the variable dataCopy which points to the dataJSON variable mutated into an array via the _spread operator(...)_. Essentially, we are copying our returned JSON data so we aren't manipulating the original (bad practice) while making it into an array so that we can iterate over it.

After, we _sort_ the array. Sort is an extremely useful array method that will put our array indices into the order of our choosing based on the function we pass into sort.

Typically, we might want to sort the data based on value (largest to smallest) so we subtract the parameter a from parameter b. But because we need to display our results in reverse chronological order I decided to produce a new date (accomplished with the new operator and the JavaScript built in method _Date that creates a new platform independent formatted instance of a date. Now, because a and b_ represent our objects sitting inside our array indices, we can access the key/value pairs held within said objects. So, we subtract _b.publishedat from _a.publishedat and this should give us our dates in reverse chronological order.

Displaying the Fruits of Our Labor

Remember that output variable we set to null at the very top of our program? Well now is it's time to shine!

That output variable is earning it's keep now!

So, there's a few things going on here. First, we're setting our output variable to a new value by mapping over our dataCopy variable using the _map_ method. This method returns a new array with the results of calling the provided function once for each index. The item parameter represents our objects inside of our array that was returned from the endpoint and thus has access to all of their properties such as title and _publishedat.

We return two list elements with a inside each one (for styling purposes), as well as a string for the Title and Date Published headings. Inside of those, we have our variables that use template literals to set the title and the date for each post.

Then, we set our list variable's innerHTML equal to that of our output variable.

Finally, we have the closing bracket and error handling of our try...catch block as well as our function call:

This code will handle any errors and display them in the console

Final Code

Here is what our full code body looks like now:

The entirety of our code base

And here is our basic CSS styling:

Did I say basic styling? I meant basic :D

And here is the result of our work with it's very basic styling:

Isn't it beautiful?

As you can see, we accomplished what we set out to do and in fact the list is in reverse chronological order. Yay!

I hope you've enjoyed this walk through of my thought process and of how I solved this challenge. Granted, there are many ways of completing this so feel free to share yours with me! I'm excited to keep this series going and will post another after I've gone through another challenge!

Also, I cross post most of my articles on great platforms like Dev.to and Medium so you can find my work there as well. This article was originally posted on my blog on May 27, 2019.

While you’re here why not sign up for my Newsletter. I promise I’ll never spam your inbox and your information will not be shared with anyone/site. I like to occasionally send out interesting resources I find, articles about web development, and a list of my newest posts.

Have an awesome day filled with love, joy, and coding!

Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another’s code; too little and expressiveness is endangered. - Guido van Rossum

This freedom that Guido talks about is part of what makes Python so popular. That popularity, among other, is what attracts more and more developers to use the language - eventually leading to some really amazing open source projects.

I usually find myself project hunting on GitHub once a day. Throughout this article, I will try to cover 10 wonderful packages that you may or may not be familiar with. I will start from the less trendy and end up with… well, Flask.

Let’s begin!

Loguru — Logging made easy

This is a really awesome package I regularly use in my projects. It describes itself as “a library which aims to bring enjoyable logging in Python”. This package just lets you easily configure your logs out of the box.

All you have to do after installing is to import the module:

from loguru import logger

And you’re free to use it out of the box:

logger.debug("Hello, cool debugger")

The documentation is good and there are many customization options.

more-itertools

A variety of interesting methods that could sometimes come very useful, such as peekable:

>>> p = peekable(['a', 'b'])>>> p.peek()'a'>>> next(p)'a'

or chunked:

>>> list(chunked([1, 2, 3, 4, 5, 6], 3))[[1, 2, 3], [4, 5, 6]]

MonkeyType — Static type annotations generator

monkeytype run myscript.py

This package automatically generates type annotations for you, either in a stub file or in the source code itself, by collecting runtime types. Right, Python doesn’t enforce you to use annotations — but I believe they are very important for readability of the code (and sometimes for avoiding errors), which is also why there are 2 more packages in this list that are handling type annotations :)

Pyright — Static type checker

Exciting new package coming from Microsoft. The inital commit was just 17 days ago! This package is the competitor of Mypy (also on this list). To be honest, I haven’t yet had the chance to use it, but I definitely plan to. I currently use mypy as a type checker, but I’ll give this one a try!

requests-async — support for async/await syntax for requests

This is a new package I discovered the other day on GitHub, and it seems pretty promising. We all know the requests package, that lets us easily handle HTTP requests in our code. Well, this package implements async and await words for these requests:

import requests_async as requests​response = await requests.get('https://example.org')print(response.status_code)print(response.text)

Pretty cool right?

HTTPie — Modern command line cURL

Those of you who have used cURL before, must know it’s not that fun. Having to remember the parameters names, making sure your data is encapsulated… Well, HTTPie aims to make this much easier. Here’s one of their examples, of submitting form data:

http -f POST example.org hello=World

pipenv — Better packaging for Python

When I start a new project, I always create a new virtualenv and install some basic packages with pip. I then need to save these packages names in a file, be it setup.py or requirements.txt. Those of you who have worked with npm, know it's much simpler there. All you need to do is write npm —save and the package name is saved in your package.json. That's why I first created pypkgfreeze, a simple package to "freeze" the versions of your currently used pip packages into setup.py.

Anyway, pipenv is an interesting solution that aims to merge the two worlds - They describe it best in their repo page:

It automatically creates and manages a virtualenv for your projects, as well as adds/removes packages from your Pipfile as you install/uninstall packages. It also generates the ever-important Pipfile.lock, which is used to produce deterministic builds.

You can try it out here.

mypy — Static type checker

As I said before, this is the package I currently use as my standard static type checker. It helps me keep my code readable and elegant (I think).

black

I have tried many Python formatters, and black is clearly my favourite. The syntax looks neat, and the command line runs quick and can either check the files or actually edit them - very useful for CI/CD. You can even try it here!

flask

Not sure if I have anything to write here that hasn’t been written before. You are probably familiar with this astonishing micro framework, and if you’re not.. you definitely should check it out.

Before you go…

Thanks for reading! You can follow my GitHub account for more cool repos. I tend to star every cool thing that I see :)

If you enjoyed this article, please hold down the clap button ? to help others find it. The longer you hold it, the more claps you give!

And do not hesitate to share your thoughts in the comments below.

Python is a beautiful language, and it contains many built-in modules that aim to help us write better, prettier code.

Objective

Throughout this article, we will use some lesser-known modules and methods that I think can improve the way we code - both in visibility and in efficiency.

NamedTuple

I believe that some of you already know the more popular namedtuple from the collections module (if you don't - check it out), but since Python 3.6, a new class is available in the typing module: NamedTuple. Both are designed to help you quickly create readable immutable objects.

NamedTuple is actually a typed version of namedtuple, and in my opinion, is much more readable:

Here’s the namedtuple alternative:

array.array

Efficient arrays of numeric values. Arrays are sequence types and behave very much like lists, except that the type of objects stored in them is constrained. — Python docs

When using the array module, we need to instantiate it with a typecode, which is the type all of its elements will use. Let's compare time efficiency with a normal list, writing many integers to a file (using [pickle](https://docs.python.org/3.7/library/pickle.html) module for a regular list):

_[https://gist.github.com/AdamGold/961758c66cdfe92642eabb61d9ce9866](https://gist.github.com/AdamGold/961758c66cdfe92642eabb61d9ce9866" rel="noopener" target="blank" title=")

14 times faster. That’s a lot. Of course it also depends on the pickle module, but still - the array is way more compact than the list. So if you are using simple numeric values, you should consider using the array module.

itertools.combinations

itertools is an impressive module. It has so many different time-saving methods, all of them are listed here. There's even a GitHub repository containing more itertools!

I got to use the combinations method this week and I thought I'd share it. This method takes an iterable and an integer as arguments, and creates a generator consisting of all possible combinations of the iterable with a maximum length of the integer given, without duplication:

dict.fromkeys

A quick and beautiful way of creating a dict with default values:

Last but not least - the dis module

The [dis](https://docs.python.org/3/library/dis.html#module-dis) module supports the analysis of CPython bytecode by disassembling it.

As you may or may not know, Python compiles source code to a set of instructions called “bytecode”. The dis module helps us handle these instructions, and it's a great debugging tool.

Here’s an example from the Fluent Python book:

We got an error — but the operation still succeeded. How come? Well, if we look at the bytecode (I added comments near the important parts):

Before you go…

Thanks for reading! For more Python related articles and other cool stuff, you can follow me on Medium or GitHub (I star some awesome repos!).

If you enjoyed this article, please hold down the clap button ? to help others find it. The longer you hold it, the more claps you give!

And do not hesitate to share more Python hidden gems in the comments below.

Creating pull requests and reviewing them are two of the most common tasks in a developer’s daily schedule. Most projects have common guidelines which developers need to follow while creating and reviewing the pull requests.

Now, it is hard for developers to remember every guideline while making a pull request. It is even more difficult for reviewers to ensure that every line of code is compliant to the set guidelines.

We faced the same problem with our projects and solved it by automating the major part of the manual rote work. This made the lives of our developers and reviewers a lot easier. They spent more time improving code quality and less on common chores.

In this article, I will describe exactly how we did it, what all aspects of the process we automated and the tools we used for this.

200 million plus pull requests created on Github. Source: Octoverse

Automate styling issues

We don’t want our reviewers asking the contributors to add the corresponding Jira issue number and description whenever they make a pull request. Instead, we have deployed a bot that does all the regular checks. This helps contributors to follow project guidelines.

Yes, a bot can verify if the description is present or not by checking the body of the pull request. It can comment on a pull request if the description is missing.

Applozic Bot commenting on pull requests.

We can also add a pull request template to get some of the information related to the pull request. But this approach increases the friction required to create a pull request. When we add rules, we need to make sure that the experience of a new developer will be as frictionless as possible. At the same time, we need to maintain the code quality.

Now let’s look at the steps required in creating such a bot.

‘Danger’ to the rescue

Danger runs during your CI process, and gives teams the chance to automate common code review chores. This provides another logical step in your build, through this Danger can help lint your rote tasks in daily code review.

You can use Danger to codify your team’s norms. Leaving humans to think about harder problems. She does this by leaving messages inside your PRs based on rules that you create with the Ruby scripting language. Over time, as rules are adhered to, the message is amended to reflect the current state of the code review.

Danger is used in all sorts of projects: ruby gems, python apps, Xcode projects, blogs, npm websites and modules.

It will give you an abstraction on top of Github’s API to get details related to a pull request and perform the necessary checks. It is created and maintained by Orta and many other awesome contributors. After installation, you need to create a file named Dangerfile which will contain all the rules. This file should be present in the root of your project.

After adding this file you are all set with the rules. Now you need to run Danger every time someone creates a pull request.

Adding it to your CI workflow

We use Bitrise in our mobile SDK projects. It’s a Continuous Integration and Continuous Delivery service for mobile Apps. If you are using a different CI service then, you can check this guide on how you can integrate Danger with that service. There is a detailed blog post on integrating Danger with Bitrise. I will summarise it in five points:

• Install bundler, create a Gemfile and add the Danger gem to the Gemfile.
• Create a Dangerfile for your project.
• Create a bot user on Github and a Personal Access Token for the bot.
• Then add the generated token on Bitrise.
• Add a script step in the project’s workflow. That’s it! ?

Rules which we can Automate

One of the ways to identify what rules we can automate is by looking at Github’s pull request API response. By comparing the API response with our pull request checklist or guideline, we can get an idea of the possibilities that are there. This is how the response looks like:

Response from Github’s pull request API

• It returns almost all the information you see on GitHub’s pull request webpage like title, description, assignee, reviewers, labels etc.
• There’s one more API to fetch a list of changed files. For each file, it will return the name of the file, the number of additions to the file, the number of deletions to the file.
• We don’t have to use this APIs as we will be using Danger which gives us an easy way to interact with this data.

Response from Github’s list pull requests files API

List of Rules we Automated

When we were adding Danger to our repository we looked at our requirements and some of the other projects which were using Danger. Below are some of the checks that we have in our projects.

• Warn if it’s a big PR: We tend to make this mistake of pushing a lot of changes in one PR. Reviewing such PRs is a difficult task. We added a warning which shows up when the number of lines updated in a PR is more than 500.
• Encourage pull request descriptions: Sometimes developers think that description is not necessary or we forget to add. Even though you mentioned the issue number, a brief description always helps and gives a context to the pull request. To see if the description is empty or not we can check the body length:

• Check if the tests are missing: We all know tests are important and yet we tend to skip this step. Whenever we do any modification in the source code, we should add tests if possible. So, now it warns if there are any changes in the source code and the tests folder is not modified, which means new tests are missing.
• Update Changelog: Added a new feature or fixed a bug — update the Changelog with the details. We made it mandatory to add a Changelog entry if the change is nontrivial. If the Changelog is not updated and pull request is not marked as trivial, then our CI fails the build. Now, we don’t have to keep track whether the Changelog was updated.
• Encourage rebase not merge commits: As the project grows it’s always recommended that we should avoid ‘merge’ commits so that the project has a clean history. We prefer using rebase instead of merging different branches. We can add a check for messages of this format: “Merge branch ‘master’” to avoid the merge commits.

Where to go next

For reference, you can check ApplozicSwift’s Dangerfile or in some of the other popular open source projects like React Native or CocoaPods. I discovered while writing this blog post that projects like React Native and React were also using danger. This shows us how this process of automating these checks has become part of the common pull requests workflow.

Liked the story? Hit that clap button and follow me on Medium. Thanks for reading! This article was originally published on Kommunicate blog.

Before getting started, let’s talk about what the Tower of Hanoi problem is. Well, this is a fun puzzle game where the objective is to move an entire stack of disks from the source position to another position. Three simple rules are followed:

1. Only one disk can be moved at a time.
2. Each move consists of taking the upper disk from one of the stacks and placing it on top of another stack. In other words, a disk can only be moved if it is the uppermost disk on a stack.
3. No larger disk may be placed on top of a smaller disk.

Now, let’s try to imagine a scenario. Suppose we have a stack of three disks. Our job is to move this stack from source A to destination C. How do we do this?

Before we can get there, let’s imagine there is an intermediate point B.

_[Three disks](http://www.texample.net/tikz/examples/towers-of-hanoi/" rel="noopener" target="blank" title=").

We can use B as a helper to finish this job. We are now ready to move on. Let’s go through each of the steps:

1. Move the first disk from A to C
2. Move the first disk from A to B
3. Move the first disk from C to B
4. Move the first disk from A to C
5. Move the first disk from B to A
6. Move the first disk from B to C
7. Move the first disk from A to C

Boom! We have solved our problem.

_Tower of Hanoi for 3 disks. [Wikipedia](https://en.wikipedia.org/wiki/Tower_of_Hanoi" rel="noopener" target="blank" title=")

You can see the animated image above for a better understanding.

Now, let’s try to build the algorithm to solve the problem. Wait, we have a new word here: “Algorithm”. What is that? Any idea? No problem, let’s see.

_Photo by [Unsplash](https://unsplash.com/@brucemars?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">bruce mars on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=")

What is an algorithm?

An algorithm is one of the most important concepts for a software developer. In fact, I think it’s not only important for software development or programming, but for everyone. Algorithms affect us in our everyday life. Let’s see how.

Suppose you work in an office. So every morning you do a series of tasks in a sequence: first you wake up, then you go to the washroom, eat breakfast, get prepared for the office, leave home, then you may take a taxi or bus or start walking towards the office and, after a certain time, you reach your office. You can say all those steps form an algorithm.

In simple terms, an algorithm is a set of tasks. I hope you haven’t forgotten those steps we did to move three disk stack from A to C. You can also say that those steps are the algorithm to solve the Tower of Hanoi problem.

In mathematics and computer science, an algorithm is an unambiguous specification of how to solve a class of problems. Algorithms can perform calculation, data processing and automated reasoning tasks. — Wikipedia

If you take a look at those steps you can see that we were doing the same task multiple times — moving disks from one stack to another. We can call these steps inside steps recursion.

Recursion

_Recursion — [giphy](https://giphy.com/gifs/homer-simpson-the-simpsons-3ov9jQX2Ow4bM5xxuM" rel="noopener" target="blank" title=")

Recursion is calling the same action from that action. Just like the above picture.

So there is one rule for doing any recursive work: there must be a condition to stop that action executing. I hope you understand the basics about recursion.

Now, let’s try to build a procedure which helps us to solve the Tower of Hanoi problem. We are trying to build the solution using pseudocode. Pseudocode is a method of writing out computer code using the English language.

tower(disk, source, intermediate, destination)
{

}

This is the skeleton of our solution. We take the total disks number as an argument. Then we need to pass source, intermediate place, and the destination so that we can understand the map which we will use to complete the job.

Now we need to find a terminal state. The terminal state is the state where we are not going to call this function anymore.

IF disk is equal 1

In our case, this would be our terminal state. Because when there will be one disk in our stack then it is easy to just do that final step and after that our task will be done. Don’t worry if it’s not clear to you. When we reach the end, this concept will be clearer.

Alright, we have found our terminal state point where we move our disk to the destination like this:

move disk from source to destination

Now we call our function again by passing these arguments. In that case, we divide the stack of disks in two parts. The largest disk (nth disk) is in one part and all other (n-1) disks are in the second part. There we call the method two times for -(n-1).

tower(disk - 1, source, destination, intermediate)

As we said we pass total_disks_on_stack — 1 as an argument. And then again we move our disk like this:

move disk from source to destination

After that we again call our method like this:

tower(disk - 1, intermediate, source, destination)

Let’s see our full pseudocode:

tower(disk, source, inter, dest)

IF disk is equal 1, THEN
      move disk from source to destination
   ELSE
      tower(disk - 1, source, destination, intermediate)   // Step 1
      move disk from source to destination                 // Step 2
      tower(disk - 1, intermediate, source, destination)   // Step 3
   END IF

END

This is the tree for three disks:

Tree of tower of hanoi (3 disks)

This is the full code in Ruby:

def tower(disk_numbers, source, auxilary, destination)
  if disk_numbers == 1
    puts "#{source} -> #{destination}"
    return
  end
  tower(disk_numbers - 1, source, destination, auxilary)
  puts "#{source} -> #{destination}"
  tower(disk_numbers - 1, auxilary, source, destination)
  nil
end

Call tower(3, 'source','aux','dest')

Output:

source -> dest
source -> aux
dest -> aux
source -> dest
aux -> source
aux -> dest
source -> dest

It took seven steps for three disks to reach the destination. We call this a recursive method.

_Photo by [Unsplash](https://unsplash.com/@aronvisuals?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">Aron Visuals on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=")

Time complexity and space complexity calculations

Time complexity

When we run code or an application in our machine it takes time — CPU cycles. But it’s not the same for every computer. For example, the processing time for a core i7 and a dual core are not the same. To solve this problem there is a concept used in computer science called time complexity.

Time complexity is a concept in computer science that deals with the quantification of the amount of time taken by a set of code or algorithm to process or run as a function of the amount of input.

In other words, time complexity is essentially efficiency, or how long a program function takes to process a given input. — techopedia

The time complexity of algorithms is most commonly expressed using big O notation. It’s an asymptotic notation to represent the time complexity.

Now, the time required to move n disks is T(n). There are two recursive calls for (n-1). There is one constant time operation to move a disk from source to the destination, let this be m1. Therefore:

T(n) = 2T(n-1) + m1    ..... eq(1)

And

T(0) = m2, a constant   ...... eq(2)
From eq (1)
T(1) = 2T(1-1) + m1
     = 2T(0)+m1
     = 2m2 + m1 ..... eq(3) [From eq 2]
T(2) = 2T(2-1) + m1
     = 2T(1) + m1
     = 4m2 + 2m1 + m1 .... eq(4) [From eq(3)]
T(3) = 2T(3-1) + m1
     = 2T(2) + m1
     = 8m2 + 4m1 + 2m1 + m1  [From eq(4)]

From these patterns — eq(2) to the last one — we can say that the time complexity of this algorithm is O(2^n) or O(a^n) where a is a constant greater than 1. So it has exponential time complexity. For the single increase in problem size, the time required is double the previous one. This is computationally very expensive. Most of the recursive programs take exponential time, and that is why it is very hard to write them iteratively.

Space complexity

After the explanation of time complexity analysis, I think you can guess now what this is…This is the calculation of space required in ram for running a code or application.

In our case, the space for the parameter for each call is independent of n, meaning it is constant. Let it be J. When we do the second recursive call, the first one is over. That means that we can reuse the space after finishing the first one. Hence:

T(n) = T(n-1) + k .... eq(1)
T(0) = k, [constant] .... eq(2)
T(1) = T(1-1) + k
     = T(0) + k
     = 2K
T(2) = 3k
T(3) = 4k

So the space complexity is O(n).

After these analyses, we can see that time complexity of this algorithm is exponential but space complexity is linear.

Conclusion

From this article, I hope you can now understand the Tower of Hanoi puzzle and how to solve it. Also, I tried to give you some basic understanding about algorithms, their importance, recursion, pseudocode, time complexity, and space complexity. If you want to learn these topics in detail, here are some well-known online courses links:

1. Algorithms, Part I
2. Algorithms, Part II
3. The Google course on Udacity
4. Javascript Algorithms And Data Structures Certification (300 hours)

You can visit my data structures and algorithms repo to see my other problems solutions.

I am on GitHub | Twitter | LinkedIn