Lunatech's engineer blog

Change Detection Strategies in Angular: Zones and Signals

Jake Ortega — 2025-11-05T00:00:00.000Z

Understand Angular’s change detection mechanism and how to optimize performance using the OnPush strategy. Learn how to use Signals for more granular reactivity. This article provides a practical mental model and shows how to apply it with Zone.js, OnPush, and Signals, along with a clear path toward building zoneless applications when you’re ready.

The mental model: how Angular knows to update

At a high level, Angular renders your component tree into a graph of views. A change detection pass checks template bindings and updates the DOM where something changed. Something has to tell Angular when to do that pass:

With Zone.js (the default), Angular patches async APIs (Promises, setTimeout, DOM events, etc.) and schedules checks automatically after those tasks.
With signals, writes to a signal schedule the right components to re-render even without Zone.js.
With OnPush, Angular narrows when a component is checked: on input reference changes, events in that component, async pipe emissions, and signal writes.

Once you see what triggers checks, you can guide Angular to do less work and update only when it matters.

Working with Zone.js (default)

Zone.js intercepts most async boundaries and calls into Angular to run change detection. It’s a safe default and reduces boilerplate, especially for teams migrating legacy code.

You can configure Zone.js coalescing to reduce redundant checks:

// app.config.ts
import { ApplicationConfig, provideZoneChangeDetection } from '@angular/core';
import { provideHttpClient } from '@angular/common/http';

export const appConfig: ApplicationConfig = {
  providers: [
    // Collapses multiple events/microtasks into fewer change detection cycles.
    provideZoneChangeDetection({
      eventCoalescing: true,
      runCoalescing: true,
    }),
    provideHttpClient(),
  ],
};

For performance-sensitive work (e.g., animations or polling), run it outside Angular to avoid thrashing, and re-enter only when UI state actually changes.

import {
  Component,
  NgZone,
  ChangeDetectionStrategy,
  signal,
  inject,
  OnInit,
  OnDestroy
} from '@angular/core';

@Component({
  selector: 'cpu-heavy',
  standalone: true,
  template: `
    Frames: {{ frames() }}
  `,
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class CpuHeavyComponent implements OnInit, OnDestroy {
  private zone = inject(NgZone);

  // Signal handles reactivity; no CDR needed
  private _frames = signal(0);
  frames = this._frames.asReadonly();

  private intervalId?: ReturnType;

  ngOnInit() {
    this.zone.runOutsideAngular(() => {
      let n = 0;
      this.intervalId = setInterval(() => {
        // Update signal outside Angular zone
        // Signals batch updates automatically
        this._frames.set(++n);

        if (n > 3000) {
          clearInterval(this.intervalId);
        }
      }, 16);
    });
  }

  ngOnDestroy() {
    if (this.intervalId) {
      clearInterval(this.intervalId);
    }
  }
}

Embracing OnPush for predictable performance

OnPush reduces unnecessary checks and nudges you toward immutable data and explicit updates. Angular will check an OnPush component when:

An Input reference changes (immutability shines here).
The component fires an event or an async pipe emits.
A bound signal writes (signals integrate with the scheduler).
You explicitly call markForCheck or detectChanges.

Use immutable updates for inputs and track nodes for stable lists.

import { Component, ChangeDetectionStrategy, input } from '@angular/core';

type User = { id: number; name: string };

@Component({
  selector: 'user-list',
  standalone: true,
  template: `
    
      @for (u of users(); track u.id) {
        {{ u.name }}
      }
    
  `,
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class UserListComponent {
  // Signal-based input (works great with OnPush)
  users = input>([]);
}

// parent.component.ts
import { Component, ChangeDetectionStrategy, signal } from '@angular/core';
import { UserListComponent } from './user-list.component';

type User = { id: number; name: string };

@Component({
  selector: 'parent',
  standalone: true,
  imports: [UserListComponent],
  template: `
    
    

    
  `,
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class ParentComponent {
  private _users = signal>([
    { id: 1, name: 'Maya' },
    { id: 2, name: 'Dee' },
  ]);
  users = this._users.asReadonly();

  // Correct: immutable update changes the reference and triggers OnPush
  add() {
    const currentIds = this.users().map(u => u.id);
    const nextId = currentIds.length > 0 ? Math.max(...currentIds) + 1 : 1;
    this._users.update(arr => [...arr, { id: nextId, name: 'New User' }]);
  }

  // Bad: mutates in place; OnPush children won't see a different reference
  mutate() {
    // as any to showcase the pitfall (avoid in real code)
    (this.users() as any)[0].name = 'Mutated';
    // The UI may not update; prefer immutable patterns.
  }
}

If you’re not using signals and you must update UI from a callback that Angular doesn’t know about, call markForCheck.

import { Component, ChangeDetectionStrategy, ChangeDetectorRef, OnInit } from '@angular/core';

@Component({
  selector: 'ws-status',
  standalone: true,
  template: `Status: {{ status }}`,
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class WebSocketStatusComponent implements OnInit {
  status = 'disconnected';
  constructor(private cdr: ChangeDetectorRef) {}

  ngOnInit() {
    const ws = new WebSocket('wss://example.org');
    ws.onopen = () => { this.status = 'connected'; this.cdr.markForCheck(); };
    ws.onclose = () => { this.status = 'disconnected'; this.cdr.markForCheck(); };
  }
}

import { Component, ChangeDetectionStrategy, ChangeDetectorRef } from '@angular/core';

@Component({
  selector: 'ws-status',
  standalone: true,
  template: `Status: {{ status }}`,
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class WebSocketStatusComponent {
  status = 'disconnected';
  constructor(private cdr: ChangeDetectorRef) {}

  ngOnInit() {
    const ws = new WebSocket('wss://example.org');
    ws.onopen = () => { this.status = 'connected'; this.cdr.markForCheck(); };
    ws.onclose = () => { this.status = 'disconnected'; this.cdr.markForCheck(); };
  }
}

Signals (intro): fine‑grained reactivity without heavy lifting

Signals give you a declarative, dependency-tracked model for state. Reading a signal in a template links it to the view; writing to that signal schedules the right view to update. This makes change detection more targeted and pairs naturally with OnPush or even zoneless.

import { Component, ChangeDetectionStrategy, signal, computed, effect } from '@angular/core';

type Todo = { id: number; title: string; done: boolean };

@Component({
  selector: 'todo-panel',
  standalone: true,
  template: `
    

    Completed: {{ completedCount() }} / {{ todos().length }}

    
      @for (t of filteredTodos(); track t.id) {
        
          
            
            {{ t.title }}
          
        
      }
    
  `,
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class TodoPanelComponent {
  private _todos = signal([
    { id: 1, title: 'Ship dashboard', done: false },
    { id: 2, title: 'Write docs', done: true },
  ]);
  todos = this._todos.asReadonly();

  filter = signal('');
  filteredTodos = computed(() => {
    const q = this.filter().toLowerCase();
    return this.todos().filter(t => t.title.toLowerCase().includes(q));
  });
  completedCount = computed(() => this.todos().filter(t => t.done).length);

  toggle(id: number) {
    this._todos.update(ts => ts.map(t => (t.id === id ? { ...t, done: !t.done } : t)));
  }

  // Optional: side effects
  log = effect(() => {
    console.debug('Todos changed:', this.todos());
  });
}

Interop with RxJS is straightforward; toSignal turns an Observable into a signal that drives OnPush views.

import { toSignal } from '@angular/core/rxjs-interop';
import { Observable } from 'rxjs';

@Component({ /* ... */ })
export class ClockComponent {
  now = toSignal(
    // Emits a new Date every second
    new Observable(sub => {
      const id = setInterval(() => sub.next(new Date()), 1000);
      return () => clearInterval(id);
    }),
    { initialValue: new Date() }
  );
}

Because writing to signals schedules view updates, you often don’t need ChangeDetectorRef calls. The result is simpler, more predictable change detection.

Zoneless change detection: when you’re ready to drop Zone.js

Zoneless mode lets Angular skip patching browser APIs (no Zone.js) and rely purely on explicit reactive triggers (signals, template events, async pipe, router). By Angular 20, zoneless is mature enough for production in well-structured, signal‑driven apps.

Use the stable provider if it exists; otherwise keep using the experimental one until your project confirms the upgrade path.

// app.config.ts
import { ApplicationConfig, provideHttpClient } from '@angular/common/http';
import {
  // Verify which one exists in your installed version:
  // If Angular 20 exposes `provideZonelessChangeDetection`, prefer it.
  provideZonelessChangeDetection,               // <-- Confirm availability
  provideExperimentalZonelessChangeDetection,   // <-- Fallback if stable not present
} from '@angular/core';

export const appConfig: ApplicationConfig = {
  providers: [
    // Use ONE of the following:
    // provideZonelessChangeDetection(),
    provideExperimentalZonelessChangeDetection(), // ← Remove when stable provider confirmed
    provideHttpClient(),
  ],
};

With zoneless, Angular still updates views when:

Template events fire (click, input, etc.).
A signal is written (set/update).
AsyncPipe emits (it marks its view manually).
Router navigation completes.

Other async sources (WebSocket, timers, SDK callbacks): funnel them through signals (or Observables bound via async pipe / toSignal). Avoid manual ChangeDetectorRef unless integrating with legacy patterns.

import { Component, ChangeDetectionStrategy, signal } from '@angular/core';
import { toSignal } from '@angular/core/rxjs-interop';
import { interval, map, startWith } from 'rxjs';

@Component({
  selector: 'zoneless-demo',
  standalone: true,
  template: `
    Server time: {{ time() }}
    Clicks: {{ clicks() }}
    
  `,
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class ZonelessDemoComponent {
  time = toSignal(
    interval(1000).pipe(
      map(() => new Date().toLocaleTimeString()),
      startWith(new Date().toLocaleTimeString()),
    ),
    { initialValue: new Date().toLocaleTimeString() },
  );

  private _clicks = signal(0);
  clicks = this._clicks.asReadonly();

  inc() {
    this._clicks.update(n => n + 1);
  }
}

If you interact with non-Angular callbacks (e.g., third‑party SDKs), prefer to set signals inside the callback. That write will schedule the needed view updates.

Practical checklist

Prefer OnPush for all app components; combine with immutable data.
Use signal-based inputs (input()) in leaf components for ergonomic, fine-grained updates.
Store local UI state as signals; use computed for derivations and effect for side effects.
In Zone.js apps, isolate heavy loops with runOutsideAngular and re-enter only on state writes.
In zoneless apps, ensure all UI-affecting async work flows through signals or async pipe.
Track list items by a stable key to avoid re-render churn.
Use provideZoneChangeDetection with coalescing in legacy/mixed environments; move toward provideExperimentalZonelessChangeDetection when your reactive pathways are solid.

Troubleshooting gotchas

“My OnPush child didn’t update.” Ensure the Input reference changes (immutable update) or the child reads a signal that you wrote to.
“Zoneless didn’t repaint after a callback.” Convert that callback’s data to a signal or trigger an async pipe emission; avoid manual detectChanges unless you know the implications.
“Perf regressions after refactor.” Check for unintended synchronous effects that write many signals in a loop; batch updates if needed, or compose a single state write.

Conclusion

Change detection in Angular is powerful because you can choose the right tool for the job. Zone.js gives you simplicity, OnPush gives you predictability and performance, and signals give you precise, maintainable reactivity. Together, they help you ship fast UIs without guesswork, and you can progressively adopt a zoneless model when your state is signal-driven.

Next Steps

Audit your components: enable OnPush and fix any mutable input flows.
Introduce signals for local state and derived values; replace ad‑hoc ChangeDetectorRef calls.
Wrap recurring async sources (timers, sockets) with toSignal or async pipe.
Experiment with provideExperimentalZonelessChangeDetection in a feature slice to validate your reactive pathways.
Read the Angular guides on signals and zoneless change detection to deepen your understanding.

Getting Started with Angular 20 CLI and Standalone Components

Jake Ortega — 2025-10-27T00:00:00.000Z

Learn how to initialize and structure a new Angular 20 project using the Angular CLI. Understand standalone components and the simplified bootstrapping process. This guide focuses on a clean project setup, modern routing, and practical patterns you can reuse in real projects.

Prerequisites

Node.js 24+ (LTS recommended) and npm or pnpm
Angular CLI 20 installed globally: npm i -g @angular/cli@20
Familiarity with TypeScript and Angular fundamentals

Create a new project with the Angular CLI

The Angular CLI scaffolds a production-grade baseline with sensible defaults. Standalone components are the default in Angular 20, which means no NgModules are required for most apps.

// Terminal
// Create a new app with routing and SCSS. Use --ssr to scaffold server-side rendering.
ng new lt-dashboard --routing --style=scss
cd lt-dashboard
ng serve

Open http://localhost:4200 and confirm the app runs. The CLI gives you fast dev server reloads, TypeScript checks, and a ready-to-extend project.

Project structure that scales

A small, predictable layout keeps cognitive load low as features grow.

// Suggested structure (simplified)
src/
  main.ts
  index.html
  styles.scss
  environments/
    environment.ts
    environment.prod.ts
  app/
    app.component.ts
    app.routes.ts
    features/
      home/
        home.component.ts
      projects/
        projects.component.ts

app.routes.ts holds your route config.
Each feature gets its own folder with a standalone component.
environments holds build-time configuration.

Simplified bootstrapping with bootstrapApplication

Standalone components and functional providers eliminate boilerplate. The entry point is lean and explicit.

// src/main.ts
import { bootstrapApplication } from '@angular/platform-browser';
import { provideRouter, withComponentInputBinding } from '@angular/router';
import { provideHttpClient, HttpInterceptorFn, withInterceptors } from '@angular/common/http';
import { provideAnimations } from '@angular/platform-browser/animations';
import { AppComponent } from './app/app.component';
import { routes } from './app/app.routes';

// Example functional interceptor (adds a version header)
const versionHeaderInterceptor: HttpInterceptorFn = (req, next) =>
  next(req.clone({ setHeaders: { 'X-App-Version': '1.0.0' } }));

bootstrapApplication(AppComponent, {
  providers: [
    provideRouter(routes, withComponentInputBinding()),
    provideHttpClient(withInterceptors([versionHeaderInterceptor])),
    provideAnimations(),
    // If you generated the project with --ssr, enable hydration:
    // provideClientHydration(),
  ],
}).catch(err => console.error(err));

provideRouter wires your routing without a root NgModule.
provideHttpClient configures HttpClient with tree-shakable features like withInterceptors.
provideAnimations enables Angular animations globally.
withComponentInputBinding lets you bind route params/data directly to component inputs.

Routing with lazy standalone components

Define routes in a single place and lazy-load components with loadComponent.

// src/app/app.routes.ts
import { Routes } from '@angular/router';

export const routes: Routes = [
  {
    path: '',
    loadComponent: () =>
      import('./features/home/home.component').then(m => m.HomeComponent),
    title: 'Home',
  },
  {
    path: 'projects',
    loadComponent: () =>
      import('./features/projects/projects.component').then(m => m.ProjectsComponent),
    title: 'Projects',
  },
  { path: '**', redirectTo: '' },
];

This setup is fast to read and easy to evolve. Each path points directly at a standalone component without an intermediate NgModule.

A minimal root component

Keep your root component focused on layout and navigation.

// src/app/app.component.ts
import { Component } from '@angular/core';
import { RouterLink, RouterLinkActive, RouterOutlet } from '@angular/router';

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [RouterOutlet, RouterLink, RouterLinkActive],
  styles: [`
    nav { display: flex; gap: 1rem; padding: 1rem; border-bottom: 1px solid #eee; }
    a.active { font-weight: 600; text-decoration: underline; }
    main { padding: 1rem; }
  `],
  template: `
    
      Home
      Projects
    
    
      
    
  `,
})
export class AppComponent {}

Build a real feature: Home with forms and new control flow

Use reactive forms and the modern control flow syntax (@if, @for) to keep templates expressive and predictable.

// src/app/features/home/home.component.ts
import { Component, signal } from '@angular/core';
import { FormBuilder, ReactiveFormsModule } from '@angular/forms';

type Project = { id: number; name: string };

@Component({
  imports: [ReactiveFormsModule],
  styles: [`
    form { display: flex; gap: 0.5rem; margin: 1rem 0; }
    input { min-width: 240px; }
    ul { padding-left: 1.25rem; }
  `],
  template: `
    Welcome

    
      
      
      
    

    @if (results().length === 0) {
      No results found.
    } @else {
      
        @for (p of results(); track p.id) {
          {{ p.name }}
        }
      
    }
  `,
})
export class HomeComponent {
  private readonly allProjects: Project[] = [
    { id: 1, name: 'Roadmap' },
    { id: 2, name: 'UI Kit' },
    { id: 3, name: 'Infra' },
  ];

  results = signal(this.allProjects);

  constructor(private fb: FormBuilder) {}

  searchForm = this.fb.nonNullable.group({ q: '' });

  onSearch(): void {
    const q = this.searchForm.value.q?.toLowerCase() ?? '';
    this.results.set(
      this.allProjects.filter(p => p.name.toLowerCase().includes(q))
    );
  }

  reset(): void {
    this.searchForm.reset({ q: '' });
    this.results.set(this.allProjects);
  }
}

signal gives you ergonomic local state without services when you don’t need them.
The new control flow removes structural directive noise while remaining explicit.

A lazy projects page

Keep feature components focused and stateless by default.

// src/app/features/projects/projects.component.ts
import { Component } from '@angular/core';

@Component({
  template: `
    Projects
    This is a lazy-loaded page. Add tables, filters, or charts here.
  `,
})
export class ProjectsComponent {}

The route configuration we defined earlier will load this component on demand.

HTTP setup with functional interceptors

You already provided HttpClient in main.ts. Add domain-specific concerns via functional interceptors as your app grows (auth tokens, correlation IDs, error normalization). They compose with withInterceptors and stay tree-shakable.

// Example: src/app/core/auth.interceptor.ts (optional)
import { HttpInterceptorFn } from '@angular/common/http';

export const authInterceptor: HttpInterceptorFn = (req, next) => {
  const token = localStorage.getItem('token');
  return next(token ? req.clone({ setHeaders: { Authorization: `Bearer ${token}` } }) : req);
};

// Then in main.ts:
// provideHttpClient(withInterceptors([authInterceptor, versionHeaderInterceptor]))

Keep cross-cutting code small, testable, and colocated in core/.

Environment-driven configuration

Use build-time environments for API base URLs and toggles. The CLI swaps files based on configuration.

// src/environments/environment.ts
export const environment = {
  production: false,
  apiUrl: 'http://localhost:3000/api',
};

// src/environments/environment.prod.ts
export const environment = {
  production: true,
  apiUrl: 'https://api.example.com',
};

Access where needed:

// Anywhere in app code
import { environment } from '../environments/environment';
// http.get(`${environment.apiUrl}/projects`)

CLI commands you’ll use daily

Generate features: ng g component app/features/activity
Add utilities: ng g interceptor core/logging
Run locally: ng serve
Build for production: ng build --configuration production
Run unit tests: ng test

The Angular CLI keeps project setup consistent while remaining flexible.

Optional: Server-side rendering (SSR)

If you create your project with --ssr, the CLI scaffolds an SSR server and hydration for you. In main.ts, include provideClientHydration() so the browser picks up the server-rendered DOM without re-rendering. SSR improves Time to First Byte (TTFB), SEO, and perceived performance for content-heavy routes.

Why this structure works

Standalone components reduce indirection and speed up onboarding.
A single routes file gives you a map of the app at a glance.
Providers in main.ts make cross-cutting behavior explicit.
Feature-first folders keep implementation details close to their templates and styles.

Troubleshooting and tips

Type errors on control flow (@if/@for): ensure your component template uses the new Angular control flow (Angular 17+). No extra imports are needed.
RouterLinkActive not working on root: pass [routerLinkActiveOptions]="{ exact: true }" for the root link.
Interceptor order: interceptors run in the order provided for requests, and in reverse for responses. Put auth/correlation early; place global error handling last to see the final response state.

Conclusion

Angular 20 cuts the ceremony: standalone components by default, functional providers, and minimal bootstrapping. Organize by feature, keep routes clear, and scale without the bloat. The CLI does the grunt work, you build features.

Next Steps

Add a core/ directory for cross-cutting concerns (interceptors, guards, tokens).
Introduce a shared/ library for reusable UI primitives.
Wire HttpClient to a real backend and centralize API calls behind a data-access service.
Enable SSR (--ssr) and hydration for content-rich pages.
Adopt signals in more places thoughtfully: state local to a component is a good fit; shared, cross-route state still belongs in services.

Routing in Angular 20: Basics to Navigation Guards

Jake Ortega — 2025-10-22T00:00:00.000Z

Master client-side routing with Angular’s Router. Learn route configuration, navigation, guards, and Angular 20’s asynchronous redirect improvements.

Why the Router still matters

Routing is the backbone of user flow. It defines how screens load, what data they need, and how access is enforced. A reliable setup pays off when your app scales and your team grows. In Angular 20, the Angular Router keeps moving in the right direction: clearer configuration, better async flows, and ergonomics that prioritize maintainability.

This guide walks through a practical baseline: route configuration, links, programmatic navigation, route guards, and async redirects, all with standalone components and functional APIs.

A minimal, modern router setup

Use standalone APIs and provideRouter for a clean bootstrap.

// main.ts
import { bootstrapApplication } from '@angular/platform-browser';
import { provideRouter, withPreloading, PreloadAllModules } from '@angular/router';
import { AppComponent } from './app/app.component';
import { routes } from './app/app.routes';

bootstrapApplication(AppComponent, {
  providers: [
    provideRouter(
      routes,
      withPreloading(PreloadAllModules),
    ),
  ],
});

Define your routes in a dedicated file. Prefer lazy-loading to keep initial bundles lean.

// app/app.routes.ts
import { Routes } from '@angular/router';
import { authCanActivate, authCanMatch, unsavedCanDeactivate } from './auth/guards';

export const routes: Routes = [
  { path: '', redirectTo: 'home', pathMatch: 'full' },

  {
    path: 'home',
    title: 'Home',
    loadComponent: () => import('./features/home/home.component').then(m => m.HomeComponent),
  },
  {
    path: 'dashboard',
    title: 'Dashboard',
    canActivate: [authCanActivate],
    loadComponent: () => import('./features/dashboard/dashboard.component').then(m => m.DashboardComponent),
  },
  {
    path: 'projects',
    canMatch: [authCanMatch],
    loadChildren: () => import('./features/projects/projects.routes').then(m => m.PROJECTS_ROUTES),
  },
  {
    path: 'settings',
    title: 'Settings',
    canDeactivate: [unsavedCanDeactivate],
    loadComponent: () => import('./features/settings/settings.component').then(m => m.SettingsComponent),
  },
  {
    path: 'login',
    title: 'Sign in',
    loadComponent: () => import('./features/auth/login.component').then(m => m.LoginComponent),
  },
  {
    path: '**',
    title: 'Not Found',
    loadComponent: () => import('./shared/not-found/not-found.component').then(m => m.NotFoundComponent),
  },
];

The application shell: links and outlet

Make navigation obvious and accessible. Use RouterLink and RouterLinkActive for feedback.



  
    Home
    Dashboard
    Projects
    Settings

RouterLink keeps your templates declarative; RouterOutlet hosts the matched view. For accessibility and UX, the active class communicates where the user is during navigation.

A realistic feature route with params and lazy-loading

For features like Projects, lazy load the route definition and child screens.

// features/projects/projects.routes.ts
import { Routes } from '@angular/router';

export const PROJECTS_ROUTES: Routes = [
  {
    path: '',
    title: 'Projects',
    loadComponent: () => import('./list/projects-list.component').then(m => m.ProjectsListComponent),
  },
  {
    path: ':id',
    title: 'Project Details',
    loadComponent: () => import('./details/project-details.component').then(m => m.ProjectDetailsComponent),
  },
];

In a details component, read route params. Use clean, testable patterns.

// features/projects/details/project-details.component.ts
import { Component, computed, inject } from '@angular/core';
import { ActivatedRoute, Router } from '@angular/router';
import { toSignal } from '@angular/core/rxjs-interop';
import { ProjectService } from '../data/project.service';

@Component({
  standalone: true,
  selector: 'app-project-details',
  template: `
    @if (project(); as data) {
      {{ data.name }}
      
    } @else {
      Project not found.
    }
  `,
})
export class ProjectDetailsComponent {
  private route = inject(ActivatedRoute);
  private router = inject(Router);
  private service = inject(ProjectService);

  private paramMap = toSignal(this.route.paramMap, { initialValue: this.route.snapshot.paramMap });
  id = computed(() => this.paramMap()?.get('id') ?? null);

  project = toSignal(this.service.getProjectStream(this.route.paramMap), { initialValue: null });

  goBack() {
    this.router.navigate(['../'], { relativeTo: this.route });
  }
}

Notes:

Use toSignal when a component benefits from reactive values in the template.
Keep navigation relative to avoid hardcoding URLs.

Programmatic navigation that reads well

When you need to route from code, favor clarity and explicitness.

// features/auth/login.component.ts (snippet)
import { Component, inject } from '@angular/core';
import { ActivatedRoute, Router } from '@angular/router';
import { AuthService } from './auth.service';

@Component({
  standalone: true,
  template: `
    
      
      
    
  `,
})
export class LoginComponent {
  private router = inject(Router);
  private route = inject(ActivatedRoute);
  private auth = inject(AuthService);

  async login() {
    await this.auth.signIn();
    const redirect = this.route.snapshot.queryParamMap.get('redirect') || '/dashboard';
    this.router.navigateByUrl(redirect, { replaceUrl: true, state: { from: 'login' } });
  }
}

navigate and navigateByUrl are both fine; navigate works with command arrays and relative routes.
replaceUrl avoids filling history with transient steps like login.

Route guards: protect, match, and confirm

Functional guards are terse, testable, and DI-friendly. Use canActivate for already-loaded routes and canMatch to gate access before lazy-loading. Use canDeactivate to protect against losing changes.

// app/auth/guards.ts
import { inject } from '@angular/core';
import { CanActivateFn, CanDeactivateFn, CanMatchFn, Router, UrlSegment, Route } from '@angular/router';
import { AuthService } from './auth.service';

export const authCanActivate: CanActivateFn = (_route, state) => {
  const auth = inject(AuthService);
  const router = inject(Router);
  if (auth.isLoggedIn()) return true;
  // Return a UrlTree to redirect without throwing
  return router.createUrlTree(['/login'], { queryParams: { redirect: state.url } });
};

export const authCanMatch: CanMatchFn = (route: Route, segments: UrlSegment[]) => {
  const auth = inject(AuthService);
  const router = inject(Router);
  if (auth.isLoggedIn()) return true;

  const attempted = '/' + segments.map(s => s.path).join('/');
  return router.createUrlTree(['/login'], { queryParams: { redirect: attempted } });
};

export const unsavedCanDeactivate: CanDeactivateFn<{ hasUnsavedChanges(): boolean }> = (component) => {
  return component.hasUnsavedChanges()
    ? confirm('You have unsaved changes. Leave this page?')
    : true;
};

Notes:

Returning a UrlTree is the most ergonomic way to redirect from guards.
Prefer canMatch for lazy-loaded feature entries. It prevents loading code the user can’t access.

Async redirects in Angular 20

Redirects are often conditional and data-driven. Angular 20 refines ergonomics for async redirects by allowing redirect functions to return a Promise or Observable of a UrlTree, keeping logic declarative in the route table. When you need Dependency Injection, the function executes in a proper injection context.

// app/app.routes.ts (excerpt showing async redirect)
import { Router, Routes } from '@angular/router';
import { inject } from '@angular/core';
import { AuthService } from './auth/auth.service';

export const routes: Routes = [
  // ...
  {
    path: 'start',
    // Async redirect based on login status
    redirectTo: async () => {
      const auth = inject(AuthService);
      const router = inject(Router);
      const isLoggedIn = await auth.isLoggedInOnce(); // e.g., resolves after token refresh
      return isLoggedIn
        ? router.createUrlTree(['/dashboard'])
        : router.createUrlTree(['/login'], { queryParams: { redirect: '/start' } });
    },
    pathMatch: 'full',
  },
  // ...
];

If your team prefers explicit control (or for compatibility), use canMatch to perform the same async decision and return a UrlTree. Both approaches keep “redirect intent” within the routing layer, preserving a clear separation from UI.

Handling 404s and fallbacks

Keep a final catch-all route at the end. Make the not-found component tiny and isolated.

// shared/not-found/not-found.component.ts
import { Component } from '@angular/core';

@Component({
  standalone: true,
  template: `
    Page not found
    The page you’re looking for doesn’t exist.
    Go to Home
  `,
})
export class NotFoundComponent {}

Developer experience tips that scale

Title and data: Use the route title for sensible defaults. Keep route data small and serializable.
Preloading: withPreloading(PreloadAllModules) improves perceived speed after the first screen.
Guard reuse: Share a single predicate behind multiple guard types (e.g., canActivate and canMatch) to avoid drift.
UrlTree over side effects: Prefer returning UrlTree over imperative router.navigate inside guards.
Relative navigation: Favor relativeTo where possible to avoid brittle absolute paths.
Observability: Listen to router.events for tracing NavigationStart, NavigationEnd, NavigationCancel when debugging.

// Simple router event logging helper (dev only)
import { filter } from 'rxjs';
import { Router, NavigationStart, NavigationEnd, NavigationCancel } from '@angular/router';

export function logNavigation(router: Router) {
  router.events
    .pipe(filter(e => e instanceof NavigationStart || e instanceof NavigationEnd || e instanceof NavigationCancel))
    .subscribe(e => console.debug('[router]', e));
}

Common pitfalls and guardrails

Infinite redirect loops: Always check target vs current URL when redirecting conditionally. Returning the same UrlTree repeatedly will stall navigation.
Missing pathMatch: For empty-path redirects, pathMatch: 'full' prevents partial matches from hijacking nested routes.
Eager vs lazy: Use canMatch for feature entries to avoid loading code for unauthorized users.
Query params and state: Preserve user intent via redirect query params. Clear them after successful navigation if they’re transient.

Putting it together: a cohesive flow

Users hitting /start are asynchronously redirected based on auth state using async redirects.
Unauthenticated users attempting /projects are intercepted by canMatch and sent to /login with a redirect back.
Settings protects against accidental loss via canDeactivate.
Dashboard and Projects load lazily, preloaded after the first screen.

This balances UX and performance while keeping the routing layer the single source of truth for navigation logic.

Conclusion

A well-structured router is more than a URL switchboard, it’s an agreement about flow, access, and intent. Angular’s modern APIs make routing readable and testable: standalone routes, functional route guards, lazy-loading, and async redirects that keep decisions close to configuration. When your code communicates clearly, your team moves faster and makes fewer mistakes.

Next Steps

Extract guard predicates into pure functions and unit test them with dependency mocks.
Add a data resolver where you need the route to wait for critical data before rendering.
Introduce a prefetch strategy for specific features, or preload on hover using quicklink-style heuristics.
Explore view transitions with router integration to smooth screen changes.
Audit routes for consistent titles, data contracts, and error handling paths.

Data Binding in Angular: Templates, Interpolation, and Property/Event Binding

Jake Ortega — 2025-10-15T00:00:00.000Z

Data binding is the heartbeat of Angular templates. Learn how data flows between components and templates using interpolation, property binding, event binding, and two-way binding. This topic also introduces new Angular 20 template features like template literals. We’ll keep the focus practical: clear patterns, minimal surprises, and maintainable code that scales.

The mental model: unidirectional data flow, well-timed feedback

From component to view: interpolation and property binding render state.
From view to component: event binding captures user intent.
Two-way binding is a convenience that composes the two, not a separate mechanism.

Favor predictable one-way flows; reach for two-way when it improves clarity without hiding complexity.

Interpolation: simple, readable, one-way display

Interpolation renders values into text nodes using template syntax like {{ … }}. It’s ideal for human-readable content.

{{ title }}
Welcome, {{ user?.name ?? 'Guest' }}.
Subtotal: {{ price | currency: 'USD' }}

Guidelines:

Keep expressions simple. Avoid calling methods that do non-trivial work.
Use pipes for presentation logic (formatting, slicing, etc.).
Use the safe-navigation operator (?.) to avoid null/undefined errors at render time.

Angular 20 template literals in expressions

Angular 20 enables JavaScript-style template literals inside template expressions for more expressive string composition.

{{ `${greeting}, ${user?.firstName || 'friend'}!` }}

Use them for readable, localized strings or ARIA attributes. Keep them concise. If you’re building complex messages, consider a dedicated formatter or i18n.

Property binding: write to DOM and component inputs

Property binding uses square brackets to set DOM properties, ARIA attributes, styles, classes, and child component inputs.

Under the hood, Angular binds to the actual property when available (safer and more correct than raw attributes). Use [attr.*] only when there is no matching property.

Signals play nicely with bindings

Signals provide push-based reactivity. Call them in templates to read their current value.

import { ChangeDetectionStrategy, Component, computed, signal } from '@angular/core';

@Component({
  selector: 'app-search',
  standalone: true,
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    
      Query:
      
    

    @if (filtered().length === 0) {
      No results
    } @else {
      
        @for (item of filtered(); track item) {
          {{ item }}
        }
      
    }
  `
})
export class SearchComponent {
  readonly items = signal(['apple', 'banana', 'citrus', 'date', 'elderberry']);
  readonly query = signal('');
  readonly filtered = computed(() =>
    this.items().filter(v => v.toLowerCase().includes(this.query().toLowerCase()))
  );

  onInput(event: Event) {
    const input = event.target as HTMLInputElement;
    this.query.set(input.value);
  }
}

Note:

Property binding [value]="query()" reads the signal.
Event binding (input)="…" updates the signal.
Built-in control flow (@if and @for) keeps the template declarative and fast.

Event binding: user intent back to the component

Event binding uses parentheses to listen to DOM or component events.

Type your handlers for safety and clarity.

toggle(): void {
  this.isOpen = !this.isOpen;
}

submit(): void {
  if (!this.formValid) return;
  this.save();
}

onInput(event: Event): void {
  const target = event.target as HTMLInputElement;
  this.value = target.value;
}

Prefer specific event names like keydown.enter for intent-revealing handlers.
Avoid expensive work inside template expressions; do it in component methods or computed signals.

Two-way binding: when it helps, use it intentionally

Two-way binding composes property binding and event binding into a single banana-in-a-box syntax.

With forms (ngModel)

This is convenient in simple forms. Import FormsModule in standalone components.

import { Component } from '@angular/core';
import { FormsModule } from '@angular/forms';

@Component({
  selector: 'app-preferences',
  standalone: true,
  imports: [FormsModule],
  template: `
    Nickname: 
    
      
      Email me updates
    
    Preview: {{ nickname }} (opt-in: {{ emailOptIn }})
  `
})
export class PreferencesComponent {
  nickname = '';
  emailOptIn = true;
}

With signals, bridge two-way binding by pairing [ngModel] and (ngModelChange):

Custom two-way binding for child components

Define a pair of Input and Output with the Change suffix. Angular will recognize [(value)].

import { Component, EventEmitter, Input, Output } from '@angular/core';
import { CommonModule } from '@angular/common';

@Component({
  selector: 'app-rating',
  standalone: true,
  imports: [CommonModule],
  template: `
    
      
    
  `,
  styles: [`.filled { color: #f59e0b; } button { background:none; border:none; font-size:1.25rem; cursor:pointer; }`]
})
export class RatingComponent {
  @Input() value = 0;
  @Output() valueChange = new EventEmitter();

  setValue(v: number) {
    this.value = v;
    this.valueChange.emit(v);
  }
}

Parent usage:


Current rating: {{ product.rating }}

Tip: If your project uses the signal-based inputs API, the model() helper can reduce boilerplate. The classic pair above remains broadly compatible and explicit.

Template syntax patterns that scale

Keep expressions pure and cheap. Avoid calling functions that allocate arrays or perform filtering on each change detection; use computed signals or memoized selectors.
Bind to properties, not attributes. Prefer [value], [disabled], [checked] over [attr.value], except when no property exists.
Use track with @for to avoid re-rendering stable items: @for (item of items; track item.id) { … }
For [innerHTML], sanitize or trust only safe content. Angular’s DomSanitizer exists for exceptional cases—prefer plain text whenever possible.

Angular 20 template literal examples in context

Use template literals where they improve clarity, especially for ARIA and labeling.





{{ `Hello, ${user?.name || 'Guest'}` | titlecase }}


{{ link.title }}

Keep logic minimal; push complex decisions into the component or computed signals for testability.

A cohesive example: binding the pieces

import { ChangeDetectionStrategy, Component, signal } from '@angular/core';
import { CommonModule } from '@angular/common';
import { FormsModule } from '@angular/forms';
import { RatingComponent } from './rating.component';

@Component({
  selector: 'app-product-card',
  standalone: true,
  imports: [CommonModule, FormsModule, RatingComponent],
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    
      
        {{ product().name }}
        {{ product().price | currency:'USD' }}
      

      
        Qty:
        
      

      

      {{ description }}

      
    
  `,
  styles: [`.card{border:1px solid #e5e7eb;border-radius:.5rem;padding:1rem}.price{color:#374151}.add{margin-top:.75rem}`]
})
export class ProductCardComponent {
  readonly product = signal({ id: 1, name: 'Noise-canceling Headphones', price: 199.99 });
  readonly qty = signal(1);
  rating = 4; // two-way bound to child
  readonly isSubmitting = signal(false);

  get description(): string {
    return `${this.product().name} — rated ${this.rating}/5 by our customers.`;
  }

  async addToCart() {
    this.isSubmitting.set(true);
    try {
      await fakeHttpPost({
        id: this.product().id,
        qty: this.qty(),
        rating: this.rating
      });
    } finally {
      this.isSubmitting.set(false);
    }
  }
}

function fakeHttpPost(payload: unknown) {
  return new Promise(r => setTimeout(r, 500));
}

What you see:

Interpolation renders human-readable fields.
Property binding controls input state and disabled state.
Event binding processes clicks and model changes.
Two-way binding streamlines rating updates.
Template literals keep labels clear and accessible.

Conclusion

Data binding is how intent flows through your Angular app. Interpolation and property binding project state. Event binding captures change. Two-way binding composes both when it reduces friction. With Angular 20’s template literal support, you can craft clearer strings and ARIA labels without sacrificing readability. Keep expressions simple, push complexity into components or computed signals, and lean on built-in control flow for performance.

Next Steps

Audit a component for heavy template expressions. Move logic into computed signals or pure methods.
Add ARIA attributes with property binding and template literals to improve accessibility.
Refactor a custom control to support [(value)] using the input/output pair.
Explore Angular’s built-in control flow (@if, @for, @switch) to reduce directive boilerplate.
If your team uses signals broadly, standardize patterns for bridging with forms: [ngModel] + (ngModelChange) for crisp two-way behavior.

Getting Started with Angular 19: Your First Signals-Powered App

Jake Ortega — 2025-10-12T00:00:00.000Z

Angular 19 makes signals a first-class, ergonomic way to manage reactive state—without the ceremony many of us associate with using RxJS for every problem. In this guide, you’ll build a small, production-quality feature using signals, computed values, and effects, sticking to Angular basics while practicing patterns you’ll reuse in real apps. Think of it as your “hello world” for signals, with enough structure to scale.

Why signals for your first Angular 19 app

Signals shine when:

You want local or feature-level state that’s easy to understand and test.
You prefer declarative data flow with minimal boilerplate.
You care about performance and predictable change detection.

Signals give you:

signal(): a mutable value you set and read like a variable.
computed(): a derived value that automatically recalculates when dependencies change.
effect(): a side effect that runs when its dependent signals change (think persistence, logging, analytics).

With the built-in control flow (@if, @for, @switch), Angular templates read signals naturally and concisely—no async pipe or manual subscriptions required.

What we’re building

A tiny yet complete “Tasks” feature:

Add tasks, toggle done, filter by status.
Persist to localStorage.
Derive stats via computed signals.

We’ll use:

Standalone components.
inject() for dependency injection.
Signals for reactive state.
New template control flow.

If you’re comfortable with Angular basics (components, templates, DI), you’re good to go.

App structure

TaskStore: a signals-powered service for state and business logic.
AppComponent: a standalone component that renders the UI and interacts with the store.
main.ts: bootstraps the app.

TaskStore: reactive state with signals

We’ll keep domain logic, mutations, and persistence here—a clean separation from the component.

import { Injectable, computed, effect, signal } from '@angular/core';

export type TaskFilter = 'all' | 'open' | 'done';

export interface Task {
  id: string;
  title: string;
  done: boolean;
}

function loadTasks(): Task[] {
  try {
    const raw = localStorage.getItem('tasks.v1');
    return raw ? JSON.parse(raw) as Task[] : [];
  } catch {
    return [];
  }
}

@Injectable({ providedIn: 'root' })
export class TaskStore {
  // Source signals
  private readonly tasks = signal(loadTasks());
  readonly filter = signal('all');

  // Derived reactive state
  readonly stats = computed(() => {
    const list = this.tasks();
    const done = list.filter(t => t.done).length;
    const open = list.length - done;
    return { total: list.length, open, done };
  });

  readonly filtered = computed(() => {
    const f = this.filter();
    const list = this.tasks();
    if (f === 'open') return list.filter(t => !t.done);
    if (f === 'done') return list.filter(t => t.done);
    return list;
  });

  // Persist tasks whenever they change
  private readonly persist = effect(() => {
    const current = this.tasks();
    localStorage.setItem('tasks.v1', JSON.stringify(current));
  });

  add(title: string) {
    const clean = title.trim();
    if (!clean) return;
    const newTask: Task = { id: crypto.randomUUID(), title: clean, done: false };
    this.tasks.update(list => [newTask, ...list]);
  }

  toggle(id: string) {
    this.tasks.update(list =>
      list.map(t => (t.id === id ? { ...t, done: !t.done } : t))
    );
  }

  remove(id: string) {
    this.tasks.update(list => list.filter(t => t.id !== id));
  }

  clearDone() {
    this.tasks.update(list => list.filter(t => !t.done));
  }

  // Expose readonly getters where helpful
  get all() { return this.tasks.asReadonly(); }
}

Notes:

Keep tasks private, expose asReadonly() if needed, and route all mutations through methods. That protects invariants and makes tests straightforward.
computed() caches until dependencies change, so stats and filtered are cheap to read in templates.
effect() is for side effects only. Don’t derive data there.

AppComponent: template-first with control flow

The component stays lean: read signals, call store methods, and keep the markup honest. No subscriptions and no manual change detection.

import { Component, inject } from '@angular/core';
import { TaskStore, TaskFilter } from './task.store';

@Component({
  selector: 'app-root',
  standalone: true,
  templateUrl: './app.component.html',
})
export class AppComponent {
  readonly store = inject(TaskStore);

  setFilter(f: TaskFilter) {
    this.store.filter.set(f);
  }

  add(input: HTMLInputElement) {
    this.store.add(input.value);
    input.value = '';
    input.focus();
  }
}


  Tasks (Signals)
  
    Total: {{ store.stats().total }}
    • Open: {{ store.stats().open }}
    • Done: {{ store.stats().done }}
  



  
  



  
  
  



  @if (store.filtered().length === 0) {
    No tasks to show.
  } @else {
    
      @for (task of store.filtered(); track task.id) {
        
          
            
            {{ task.title }}
          
          
        
      }
    
  }

A few things to notice:

Reading a signal in a template uses function-call syntax: store.stats().
The new @if and @for syntax is concise and fast; track by a stable id to minimize DOM churn.
We avoid ngModel here to keep the example lean; use reactive forms if you need validation and composition.

Bootstrap

With standalone components, the bootstrap is pleasantly thin.

import { bootstrapApplication } from '@angular/platform-browser';
import { AppComponent } from './app.component';

bootstrapApplication(AppComponent).catch(err => console.error(err));

That’s it. No NgModule, no extra ceremony. In a larger app, you’d layer in provideRouter, HTTP, and other providers here.

Developer experience and design notes

From real projects migrating to signals and the new control flow, a few principles keep teams productive:

Keep mutations small and intention-revealing.
add, toggle, remove, clearDone communicate behavior explicitly.
Encapsulate shape and invariants in your store; keep the component mostly declarative.
Use computed for any value you want to “feel like” state in the template.
stats and filtered are cheap to read and always consistent.
Avoid doing ad-hoc filtering in templates; it’s harder to optimize and test.
Reserve effect for I/O and cross-cutting behavior.
Persistence, analytics, message bus publishing—great uses of effect.
Don’t compute UI data inside effect; that’s what computed is for.
Prefer signals for local/feature reactive state, embrace RxJS where it fits.
Signals are excellent for UI state and domain mutations.
Streams still shine for event composition, websockets, and complex async flows.
Interop utilities exist if you need to bridge; start simple.
Track by stable ids in @for.
You’ll avoid unnecessary re-renders and improve perceived performance.
Keep templates dumb.
Let the store manage logic; your templates will stay readable, and testing gets easier.

Testing the store

Signals play nicely with unit tests because there’s no hidden subscription machinery to manage.

Instantiate TaskStore directly, call methods, and assert on taskStore.filtered(), taskStore.stats(), etc.
If an effect writes to localStorage, consider injecting a light persistence adapter so you can stub it in tests. For this article’s simplicity, we wrote to localStorage directly; in production, prefer an injected storage port.

Where this scales

This pattern scales surprisingly far:

Add tags or due dates? Extend Task and update computed accordingly.
Need a multi-page app? Provide routes and lazy-load feature components while keeping a small, focused store per feature.
Want undo/redo? Wrap mutations to capture patches and provide intent-level commands.

Signals help you move faster because the mental model is simple: read values, change values, derive values. It’s the right default for many UI flows.

Common pitfalls to avoid

Overusing effect for data derivation. If you find yourself setting signals inside an effect just to compute something, reach for computed instead.
Mixing many mutable signals in components. Prefer a single cohesive store per feature or sub-feature.
Forgetting to track by id in @for. It’s a small habit with big performance wins.

Conclusion

Getting started with Angular 19 and signals doesn’t require a framework rewrite. By leaning on a simple TaskStore and a lean component using the new control flow, we built a small but complete feature with clear reactive state and minimal boilerplate. This is the kind of foundation that keeps teams sane as apps grow—explicit mutations, derived state where it belongs, and templates that read like a story.

Next Steps

Add a search signal and a computed that combines filter + search.
Extract persistence into an injected storage service and mock it in unit tests.
Introduce provideRouter and split the UI into feature routes.
Integrate reactive forms for validation on create/edit flows.
Explore interop with RxJS for server events or HTTP polling, using signals at the edges.
Measure with Angular DevTools and keep track-by rules tight as lists grow.

Terminal-first Mouseless Development Or How To Be A Hipster Engineer

2025-07-11T00:00:00.000Z

In this article, I’m going to give you a slightly different view on something you do on a daily basis. A philosophy that encourages you to only use what you really need, keeps you away from being distracted, lets you think about what your problem really involves, and trust what your fingers have learned instead of relying on visual representation. That is what I call terminal-first mouseless development. I’ll try to sell it to you by giving an overview of how you can benefit from it in real life. Apart from the theory, we are also going to see real applications of these approaches. In particular, we will talk about tmux and neovim — industry standards for becoming a real hipster developer.

Hipster development?

We are all familiar with our IDEs, coupled with other tools for tasks like database management (DBeaver), testing APIs (Postman), and container management (Docker Desktop). Even though they provide an extensive GUI, they are also quite rich in distracting elements. Additionally, using multiple tools and navigating between them means a lot of context switching as well as having quite a loaded environment. If you say that your favorite IDE has everything built-in, then it violates the philosophy of Unix, which says that it is more idiomatic to use small tools that do one thing well rather than the opposite. Sort of a single responsibility principle.

And here comes what I call “Terminal-first development”, but it can be called by any other similar terms. Its core principle is that your terminal should be your central hub for development tasks. Instead of installing a new GUI application to solve a problem, the terminal-first approach challenges you to:

Decompose the problem into smaller, distinct steps.
Assign a small, dedicated CLI tool to each step.
Combine these tools, piping their outputs together, to solve the initial challenge.

As a practical example, you want to select an arbitrary table from your database, get all of the data within it, and pretty-print it as JSON. You have two options:

Install and use a couple hundred megabytes of “pgAdmin” that will create another distractive window in your workflow and eat your memory, blasting your brain with all the buttons and menus around its GUI.
Create a simple script that uses “psql” to get a list of all tables in your database, pass them to “fzf” so you could interactively select them, pass the table name again to “psql” to output data from it in JSON, and finally pass it to “jq” to pretty-print the result.

Even though I have already intentionally hated on option 1, there could be a point like: “Why would I do everything said in point 2 if I can just go to pgAdmin and press a single button or two?”. And that is valid. And here we come to one of the most important points: the approach described in option 2 is just an example of a philosophy that you can follow or not. And that is your choice. And it would not be incorrect or make you a bad developer. It is all about what you prefer (and how lazy you are :P). But if you selected option 2, then you probably prioritize:

Modularity & Portability
Better resource usage
Minimalistic & distraction-free workflow
Scriptability & Automation
Customisation

Another interesting thing to think about the second approach is that if you look closely, it is all about piping, or basically passing data from one function to another. And with this approach, it gives you a grounded look at something fundamental regarding software engineering in general — it is quite a lot, if not completely, about viewing, manipulating, and creating data. Actually, pretty much what our brains do.

Last but not least — such an approach really encourages learning, deeper understanding, and mastering of general software engineering skills, which eventually raises the level of craftsmanship. Personally, this philosophy is what sparks joy in my everyday work.

Another philosophy that usually goes hand in hand with the terminal-first one is mouseless or keyboard-centric development, which literally means what it says — it encourages you to prioritize the usage of a keyboard over a mouse or trackpad for writing or navigating through your code. It is important to say here that it doesn’t mean that you should never use those. Sometimes it is quite inefficient to avoid using your trackpad, but for the most part, the theory is that mostly using your keyboard makes your development faster, more efficient, and less tiring.

Why? Well, you keep your hands on the keyboard and avoid switching between it and a mouse. Additionally, you rely on muscle memory in the form of keybindings and not on visual navigation to perform actions. This way you reduce mental overhead, stay in the flow state, and perform basic actions much faster. For example, the research by SuperHuman showed that some basic operations that we perform every day can be done from 2 to 5 seconds faster if performed with a keyboard rather than a mouse. And we perform those actions a lot, so think about the amount of time you could save in a day.

But let’s not idealize things and talk about the downsides. The primary one is a steep learning curve. From my experience, following those philosophies really makes you rethink the way you approach software development. I struggle to point out the exact points, but it just feels quite different, and you really need time to get used to that new reality, and that basically means a long learning curve. The basic parts of it are memorizing all the keybinds or switching your mindset to use CLIs over graphical applications. But hey, learning all the buttons in your IDE also took time, so it is more about whether you are ready to commit to that.

Core In Practice

So now, let’s finally go from something totally metaphorical to something more practical. There isn’t a single right way to implement the philosophy that I described above. But, while finding my own way there, I could distinguish two core elements or, in fact, pieces of software, that will help you to build up a foundation.

tmux

I mentioned that with terminal-first development, your terminal becomes the “central hub” for solving software engineering tasks. When you think about a hub, you probably expect it to provide an infrastructure that you can utilize to effectively achieve your goals. The industry standard for that is called “tmux”, which is a terminal multiplexer by its definition.

It allows you to conveniently create terminal windows, splits, or even sessions for grouping. That makes it easy to organize your work between multiple projects, for example, and allows you to navigate more smoothly.

You can say, “Yeah, but my terminal emulator can do the same.” Sure, but what if the keybinds change? What if you switch to another emulator? What if you now have to use a different system? You basically need to adapt and configure this new tool for yourself. So how does using “tmux” help you? It is completely platform and terminal-emulator agnostic. Everything you have to do is to put your configuration file in the root folder and run “tmux”. This way you are completely independent of the platform that you run “tmux” on top of.

Another thing is that, at its core, “tmux” is a server, having all your terminal sessions working in the background. So this can at least save you from accidentally pressing Command + Q in your terminal and crashing out again, but what you can also do is to basically have your whole terminal session setup running, that you can SSH from any other machine and have it all there, as “tmux” itself is just a command-line tool. Combining a configuration basis and server nature, you basically become independent of a machine and/or terminal emulation tools, if you have your “tmux” server hosted somewhere.

Regarding the config, you can do quite a lot, starting from setting basic keybinds, finishing with writing custom scripts for your workflow or modifying the UI. There is even a whole ecosystem of plugins!

And if we talk about downsides, there are not that many, except for the steep learning curve, but trust me, the outcome is worth it.

neovim

I think most of you know “vi” — the editor that’s impossible to exit. One of the first text editors in existence, it relies on the keyboard only. This is because there was no mouse in the early computer days. Theoretically, you can use it to perform any tasks related to text editing and code writing. But the problem with the original “vi” is that it is as plain as possible, and when it comes to modern development, not really efficient. For example, not having the ability to autocomplete code or quickly navigate to a class definition doesn’t sound like a lot of productivity.

To solve this issue, “vim” was created — a feature-rich version of the original “vi” with things like syntax highlighting, the ability to split windows, etc. And most importantly — it provides the ability for extensive configuration, even featuring its own language — “vimscript”. That basically created the possibility to write plugins that allow you to customize your experience in “vim” however you want. As a result, the “vim” plugin ecosystem is probably one of the biggest plugin ecosystems in the world.

But this was not enough for people who considered themselves to be ultra-hipsters. This led to the creation of “Neovim” - a fork, partly rewritten in Lua. This way, significant gains were achieved in terms of extensibility and architecture. Nowadays, “Neovim” is known for its great documentation and is supported by a quite big and active community of contributors.

Ultimately, you can think of “*vim” as a constructor. Its ecosystem provides you with the bricks you can use to build a development tool to satisfy any of your needs. From the most plain text editor to an ultra-feature-rich IDE. Basically, you can completely replace whatever you are using now. Just watch out so as not to violate the Unix philosophy.

So how does switching to “*vim” feel, and what does it bring to your life? First of all, text editing starts to feel so much smoother, and the whole navigation process around the code feels really fluent. Using “*vim” really proves the benefits of trusting your muscle memory via keybinds instead of visual navigating. The overall overhead goes down, and you can also feel it when you have to work with several projects/directories. Opening a project, quickly looking for something, and editing it feels so light and easy. Using “*vim” is like dropping a huge backpack when going uphill and changing it for something small, compact, accessible, but extendable at the same time. And last but not least, making the editor behave literally however you want it to in a programmatic way is another amazing part.

But let’s not forget about the struggles you may face: “*vim” really makes you rethink the way you write your code (and using keybinds is not the only part), which will take quite some time. Another thing is configuring the thing to meet your needs. Yeah, that takes time. Initially, it took me maybe like 20+ hours, and it is also a non-stop process, but that is a fair trade-off for the extensibility you get. There is a joke in the “*vim” community about people spending more time on customizing their config than on actually using it. And another thing is that as it is community-driven, you may face things that don’t work properly. For example, in order to have all the IDE features for Java, you need to run Eclipse’s “jdtls”, a language server, which doesn’t usually perform well on a large Java codebase. But your mileage may vary.

Conclusions

My main point in this article was to provide you with a new perspective. An approach that you can incorporate in your day-to-day tasks. A philosophy that embraces you to:

Think more about what your task involves and what you really need to solve it
Maintain your workspace clean and distraction-free
Build a unique environment that you love working in
Introduce joy and creativity into your routine

And while it might feel like a step back, this philosophy is surprisingly forward-thinking. Many of today’s brand-new AI tools are designed specifically for the command line. In the end, there is no single way to do things. Technical benefits like efficiency are important, but so is finding joy and pride in your craft. Hipster engineering is something that makes me a better professional and makes me love what I do. My sincere hope is that you find your own way to do the same. Thanks for reading.

Ctrl+Alt+Defeat: Noob vs. Neural Net

2025-07-04T00:00:00.000Z

For decades, competitive games have served as milestones in artificial intelligence research. From IBM’s Deep Blue beating Garry Kasparov at chess in 1997, to AlphaGo’s victory over Lee Sedol in 2016, games have offered a clear stage for AI to measure itself against the best human minds.

But as games have grown more complex, so too has the challenge. Turn-based board games like chess and Go, while difficult, offer complete information and relatively limited options per move. Real-time strategy games like StarCraft II and Dota 2, however, introduce chaos: thousands of actions per minute, imperfect information, shifting alliances, and the need for long-term planning — all in real time.

So the question arises: Can AI beat humans in these games, fairly, without relying on superhuman speed or godlike awareness? Let’s take a deeper look into how two landmark systems, OpenAI Five and AlphaStar, set out to do just that.

The Complexity of Real-Time Strategy Games

To appreciate the achievements of AI in games like Dota 2 and StarCraft II, it’s essential to understand what makes these games hard:

Partial information: Players don’t see the whole map due to fog of war.
High action complexity: At any moment, there are thousands of possible moves.
Real-time dynamics: No turns, decisions must be made continuously.
Coordination: Especially in team games, success hinges on synergy and communication.
Long-term planning: Decisions made in the early game can determine the late-game outcome.

Unlike games with set openings and established endgames, these environments are closer to the messiness of the real world and that’s exactly why they interest AI researchers.

OpenAI Five: Dota 2 Without Superpowers

In 2019, OpenAI introduced OpenAI Five, a team of five neural networks trained to play Dota 2, a popular and highly complex team-based multiplayer game. Unlike previous AIs, OpenAI Five didn’t rely on hardcoded rules. Instead, it learned by playing itself millions of times in a massive distributed training setup.

What made OpenAI Five especially impressive was the effort to simulate human-like constraints:

Reaction time was capped at 200 milliseconds, close to average human reflexes.
Actions per minute (APM) were restricted to human levels, avoiding the inhuman speed advantage.
It had no access to information unavailable to humans, like opponent positions under fog of war.

Despite these constraints, OpenAI Five steadily improved and eventually beat top human teams culminating in a 2–0 victory over the reigning world champion team OG at The International in 2019.

Yet, Five was not without flaws. It was:

Weaker in novel situations it hadn’t seen during training.
Sometimes inflexible, making odd decisions when opponents deviated from expected tactics.
Emotionally agnostic, meaning while it would never play emotionally, it also doesn’t have the ability to read human psychology or use momentum the way humans do.

Still, the fact that an AI could beat the world’s best without using non-human like reactions speeds speaks for itself.

AlphaStar: Outmaneuvering Pros in StarCraft II

DeepMind’s AlphaStar tackled StarCraft II, another legendary RTS known for its brutal learning curve and mechanical demands. It used a combination of imitation learning (watching human games) and self-play reinforcement learning to master the game.

Like OpenAI Five, AlphaStar imposed human-like limitations:

Capped APM and reaction delays (averaging around 350 milliseconds).
Camera view limitations, meaning it had to "look" around the map like a human player.
Trained against a diversity of opponents and strategies.

AlphaStar climbed the European ladder to Grandmaster, ranking in the top 0.2% of players. It beat professional players like TLO and MaNa convincingly, sometimes using unexpected and creative strategies.

However, it too had its shortcomings:

Predictability: Once players had time to study it, some human pros found exploitable patterns.
Lack of intuitive game sense: Humans often make intuitive calls based on experience, psychology, or a “feel” for the flow of the game — AlphaStar relied solely on data and outcomes.
Difficulty adapting to “meta shifts”, since it lacked the kind of quick generalization humans can make from limited examples.

Even so, AlphaStar showed that AI could compete — and win — not by outclicking, but by outthinking.

Summary of the restrictions imposed on the AI’s

Metric	Pro Human Player	OpenAI Five	AlphaStar
Average Reaction Time	~200 ms	200 ms	350 ms
Max APM	~300	~180	~150
Map Vision	Partial	Partial	Limited camera view
Strategy Adaptation	High	Medium	Medium-High

Metric

Pro Human Player

OpenAI Five

AlphaStar

Average Reaction Time

~200 ms

200 ms

350 ms

Max APM

~300

~180

~150

Map Vision

Partial

Limited camera view

Strategy Adaptation

High

Medium

Medium-High

Where AI Still Falls Short

Even with these victories, AI is not yet a complete replacement for human intelligence in games. Some weaknesses include:

Lack of common sense or intuition: AIs still struggle with decisions that require real-world reasoning or emotional awareness.
Context blindness: Without extensive training, AIs can’t generalize well to new game versions or unexpected strategies.
Communication and deception: While some advanced AIs, like Meta’s "CICERO", have made progress in games that involve negotiation and persuasion — such as the board game Diplomacy — most game-playing AIs still struggle to understand or influence human opponents the way skilled players can. They can’t read body language, sense bluffing, or adapt their strategy based on trust or psychology — key elements of human gameplay.
Creativity with purpose: AIs can discover new tactics, but they don’t “understand” them in a human sense, nor can they justify them conceptually.

In essence, AI can win — but it doesn’t always know why it wins.

Conclusion: A New Era of Competitive Play

So, can AI truly outplay humans at complex games? The answer, remarkably, is yes — even under constraints that mimic human limitations. OpenAI Five and AlphaStar both demonstrated that intelligent agents can excel in games long thought too complex for machines.

But while the victories are real, the limitations are too. These AIs don’t think or feel like us. They win through scale, training, and narrow focus — not general intelligence or intuition.

Still, each success in these arenas nudges us closer to AI that can not only perform, but reason, adapt, and collaborate — skills that matter far beyond the game board.

GPU Programming For The Brave

Boyuan Xiao — 2025-06-27T00:00:00.000Z

Introduction

GPUs, some might call them graphic cards, have never been a stranger for video gamers. The evolution of GPUs significantly changed not just the video game industry, but also the field of parallel programming.

I was lucky enough to participate some courses that briefly introduced GPU programming during my master study. As my first humble attempt, I hereby write down my knowledge and understanding about GPU programming in this blog post. Hopefully, after reading this write-up, you can have a basic idea about: how GPUs work, how to do some simple GPU programming and why it is so important to the field of AI.

What is GPU

GPU is the abbreviation of "graphics processing unit". It is a specialized electronic circuit designed for digital image processing and to accelerate computer graphics, being present either as a discrete video card or embedded on motherboards, mobile phones, personal computers, workstations, and game consoles.

If you have tried to build your own PC, you will probably call the big gas-stove-look-a-like thing in Figure 1 a GPU. However, this is not entirely correct. Graphics card is a more suitable name for it. And if you have ever had a chance to disassemble a graphics card like me, then I am sure you will notice there are much more than just a GPU on a graphics card. The GPU itself is only a small part on it and there’s memory, power supply and cooling unit. The composition resembles any normal PC you can see. Figure 2 is taken when I had an GPU memory overheating issue. As you can see in the picture, the GPU is surrounded by the red box and blue boxes for the GPU memory. The part on the right is the cooling unit.

Figure 1. My Nvidia RTX 3080.

Figure 2. My Nvidia RTX 3080 (disassemble).

The small exercise

There is no way we can actually know how to do GPU programming by just looking at the composition picture. To help with the understanding, let’s consider a small code exercise where you have to implement a simple fill_matrix function in C to fill a rectangle shape within a two-dimensional matrix with some certain value:

#include 
#include 

void fill_matrix(int **s, int x_len, int y_len, int draw_start, int draw_end, int value_to_fill) {
  // IMPLEMENT ME
}

void print_matrix(int **s, int x_len, int y_len) {
  // doesn't matter...
}

int64_t initialize_matrix(int rows, int cols) {
  // doesn't matter...
}

int main() {
  int **s = (int **)initialize_matrix(10, 10);
  printf("before: \n");
  print_matrix(s, 10, 10);

  fill_matrix(s, 10, 10, 2, 8 9);

  printf("after: \n");
  print_matrix(s, 10, 10);
  return 0;
}

C version

Easy, isn’t it? All we need to do is to use two nested for-loops to fill the value when the loop arrives the expected range:

void fill_matrix(int **s, int x_len, int y_len, int draw_start, int draw_end, int value_to_fill) {
  for (int i = 0; i < y_len; i++) {
    for (int j = 0; j < x_len; j++) {
      if (i > draw_start && i < draw_end && j > draw_start && j < draw_end) {
        s[i][j] = value_to_fill;
      }
    }
  }
}

If you would like to speed up your implementation, you can even use OpenMp to turn your it into a multi-threaded implementation by simply adding #pragma omp parallel for collapse(2) on top of the outer for-loop. After re-compiling and running export OMP_NUM_THREADS=4, your program should automatically delegate the execution of the for-loop to at most 4 threads.

Now it seems like we really pushed to the boundary, and couldn’t get any more speedup unless increasing the number of threads. However, what we have seen so far is still in the realm of CPU programming, where your code gets executed by the CPU. Besides that, the time complexity of the implementation is O(n*m), which is not a very pleasant number. So let’s try to make use of the power of GPUs, with which we could achieve O(1) complexity.

CUDA version

Tip	You might find it helpful to temporarily forget what you have learnt about `thread` and `kernel` when reading this section.

__global__ void fill_matrix_kernel(int* matrix, int rows, int cols, int draw_start, int draw_end, int value) {
    int row = blockIdx.y * blockDim.y + threadIdx.y;
    int col = blockIdx.x * blockDim.x + threadIdx.x;

    if (row > draw_start && row < draw_end && col < draw_end && col > draw_start) {
        int idx = row * cols + col;
        matrix[idx] = value;
    }
}

int main() {
  const int rows = 10;
  const int cols = 10;
  const size_t size = rows * cols * sizeof(int);

  // Host memory
  int* h_matrix = (int *)malloc(size);

  // Device memory
  int* d_matrix;
  cudaMalloc((void **)&d_matrix, size);

  // Define grid and block dimensions
  dim3 block(32, 32);  // 256 threads per block
  dim3 grid(
      (cols + block.x - 1) / block.x,  // ceil(cols/block.x)
      (rows + block.y - 1) / block.y   // ceil(rows/block.y)
  );

  // Launch kernel
  fill_matrix_kernel<<>>(d_matrix, rows, cols, 2, 8 9);

  // Copy result back to host
  cudaMemcpy(h_matrix, d_matrix, size, cudaMemcpyDeviceToHost);

  // Verify values
  print_matrix(h_matrix, rows, cols);

  // Cleanup
  free(h_matrix);
  cudaFree(d_matrix);

  return 0;
}

Above is the CUDA implementation. CUDA is a C-like programming language provided by Nvidia. Naturally, it only runs on Nvidia cards. To compile the code above, we can simply run nvcc -o code_example code_example.cu just like when compiling C code using gcc. Then, the code_example it produces also isn’t any different from other native executable, which could be run by the command ./code_example.

So what happens when we run it? Besides allocating memory on the device, which is our graphics card, the computation kernel (the fill_matrix_kernel function) is executed by all the GPU threads that we requested simultaneously. In the example, we define a grid of one block ((10 + 32 - 1) / 32 = 1) with 256 threads on it. GPU threads are fundamentally different from the CPU threads we know. By design, the number of GPU threads on a GPU is much larger than the number of CPU threads on a CPU. On top of that, what is executed by CPU threads is completely dependent on how you program it. On contrast, GPU threads provides high-throughput due to the nature of simultaneous execution for a kernel. Therefore, we need a way to control the behavior of each GPU thread. Luckily, an unique threadId is assigned to each GPU thread within the same block and each block has a unique blockId. What we can do is to see if the the current thread is within the drawing range and fill the value accordingly based on the location of the thread (blockId * number of blocks + threadId) , which is exactly what the if clause is doing.

Figure 3. The Grid, The Block and The Thread.

Figure 4. Nvidia’s interpretation.

If we leave out the main() function, the actual implementation is only 6 lines and there is no loop being used at all. But how much faster it really is? When running with the matrix shape of 32768 * 32768, our CUDA implementation can finish it within 0.3 seconds while the C implementation needs 1.9 seconds.

Figure 5. Speed showcase.

Impressive, isn’t it? But trust me, everything seems reasonable when you actually see the difference of thread numbers:

Intel® Xeon® 6966P-C Processor	AMD Ryzen Threadripper PRO 9995WX	Nvidia RTX 5090
192 threads in total	192 threads in total	21760 CUDA threads

Intel® Xeon® 6966P-C Processor

AMD Ryzen Threadripper PRO 9995WX

Nvidia RTX 5090

192 threads in total

21760 CUDA threads

Tip	This code example might be too simple and too boring for you. But if you think of the matrix that we are filling as a screen, and the value as RGB value — We are actually rendering a screen!

Okay, but why AI?

As you might have heard, GPUs are widely used in the field of AI. Given the high-throughput trait of GPU, the process of AI model training can be significantly facilitated. But why is that?

Look into the AI

Thankfully, Wikipedia made it a lot easier for me to explain AI:

"The largest and most capable LLMs are generative pretrained transformers (GPTs), which are largely used in generative chatbots such as ChatGPT or Gemini."

"A GPT is a type of LLM and a prominent framework for generative artificial intelligence. It is an artificial neural network that is used in natural language processing by machines.".

To put it simply: most of the popular AIs are made of neural networks. A neural network is composite of multiple layers of nodes. The first layer takes input from the outside world, normally as the format of a vector of numbers. The output of a layer consists of the output number from each node, which is calculated by summing the input times the weight of the node (sum(input * weight)). And all the subsequent layers take input from the previous one. The process of training the neural network aims to find the weights for each nodes so that the output is most acceptable. And it requires to feed the input → calculate the output → compare with the expected output → adjust the weights repetitively.

Figure 6. A neural network.

We can let GPU run this

If we try to write a simple implementation, or even pseudo code, of how things are done in each layer of a neural network, we could arrive at what is shown in Figure 7. Once again we see a pattern we have seen just before: a linear algebra calculation wrapped by two for-loops. Therefore, we can easily rewrite to a CUDA implementation shown in Figure 8.

Figure 7. C implementation of a neural network layer.

Figure 8. CUDA implementation of a neural network layer.

Both Figure 7 and Figure 8 are taken from a research article by Ricardo Brito et al[[1]]. The authors managed to utilize the high-throughput of GPU to accelerate the training process of a neural network in the year of 2016. Except for the countless open-source repositories that implement CUDA-based neural networks, Nvidia offers cuDNN as a GPU-accelerated library of primitives for deep neural networks. Popular neural network frameworks like PyTorch and TenhsorFlow can operate on GPU devices without any extra effort.

To sum up

GPUs, which are originally made for graphics processing, has shown a huge potential in the field of parallel programming and AI training due to their high-throughput nature. This is achieved by piling significant amount of GPU threads and impose simultaneous execution of the compute kernel. Even though it’s not quite possible to assign GPU threads for different execution routine like CPU threads, we can still do minimum control-flow manipulation based on their threadId. Several examples of CUDA, which is a C-like GPU programming language offered by Nvidia, are also shown to demonstrate its syntax.

Finally, you can checkout the code examples I used in this GitHub repo.

References

[[[1]]] Brito R., Fong S., Cho K., Song W., Wong R., Mohammed S., Fiaidhi J. "GPU-enabled back-propagation artificial neural network for digit recognition in parallel". The Journal of Supercomputing. 72, (2016). https://doi.org/10.1007/s11227-016-1633-y

Graveyard of technologies

Pere Tarrida — 2025-06-20T00:00:00.000Z

Software: When Technical Excellence Isn’t Enough

ALGOL, Japronto, and Apache Ant represent fascinating case studies of software that, despite their technical merits, faced significant challenges in achieving lasting market success. Each offers valuable lessons about the complex relationship between technical excellence and commercial viability. ALGOL, Japronto, and Apache Ant: Lessons in Technology Adoption

Represent fascinating case studies of technologies that, despite their technical merits, faced significant challenges in achieving lasting market success. Each offers valuable lessons about the complex relationship between technical excellence and commercial viability.

ALGOL: Revolutionary Syntax That Shaped Programming

ALGOL introduced groundbreaking programming concepts that influenced virtually every modern programming language. The language featured elegant recursive procedures and call-by-name parameters, as demonstrated in this classic example:

real procedure GPS (I, N, Z, V); integer I; real N, Z, V;
begin
   for I := 1 step 1 until N do
      Z := V;
   GPS := 1;
end;

This GPS (General Problem Solver) procedure showcased ALGOL’s sophisticated parameter passing mechanisms and recursive capabilities. The language’s clean syntax and mathematical precision made it ideal for academic research and algorithm description. ALGOL’s influence can be seen in modern languages through its introduction of block structure, lexical scoping, and formal syntax definition using Backus-Naur Form.

However, ALGOL’s academic origins became its commercial weakness. The language prioritized theoretical elegance over practical business applications, creating a barrier for commercial adoption. Unlike FORTRAN, which had IBM’s backing and clear scientific computing applications, ALGOL remained primarily an academic exercise without strong industry support.

Japronto: The Performance Paradox

Japronto emerged as a high-performance Python HTTP framework, promising extraordinary speed through aggressive optimization. A typical Japronto application demonstrated its streamlined approach:

from japronto import Application

def hello(request):
    return request.Response(text='Hello world!')

app = Application()
app.router.add_route('/', hello)
app.run(debug=True)

The framework achieved remarkable performance by optimizing HTTP pipelining and utilizing the picohttpparser C library with SSE4.2 CPU instructions. Japronto could handle over 1 million requests per second in benchmarks, dramatically outperforming traditional Python frameworks and even some Go alternatives.

However, this performance came at a significant cost. Japronto’s speed optimizations discouraged the use of Python-level objects and complex application logic. The framework relied heavily on HTTP pipelining, which modern browsers don’t support reliably. Most critically, real-world applications requiring database connections, business logic, and data processing couldn’t maintain Japronto’s benchmark performance levels.

Apache Ant: The XML Build Tool Era

Apache Ant dominated Java build automation for years with its XML-based configuration system. A typical Ant build file demonstrated its declarative approach:

Ant succeeded in providing platform-independent build automation and flexible task execution. Its XML-based configuration allowed detailed control over build processes, and its extensible architecture supported custom tasks and complex build workflows.

However, Ant’s imperative approach became increasingly cumbersome as projects grew in complexity. The lack of dependency management, standardized project layouts, and convention-over-configuration principles made Ant builds verbose and difficult to maintain. Maven’s introduction of automatic dependency resolution and Gradle’s programmatic build scripts eventually displaced Ant in most modern Java projects.

Netscape Navigator: The Pioneer That Lost the War

Netscape Navigator pioneered web browsing and helped create the modern internet, but ultimately fell victim to Microsoft’s aggressive competitive tactics and strategic missteps. Despite its early dominance, Netscape’s market share collapsed in the late 1990s.

Netscape Navigator introduced fundamental web technologies including JavaScript, SSL encryption, and dynamic HTML capabilities. The browser’s plugin architecture and standards-based approach laid the foundation for modern web development and demonstrated the potential for rich, interactive web applications.

However, Netscape’s downfall illustrates how market leadership can quickly evaporate in fast-moving technology sectors. Microsoft leveraged its Windows monopoly to bundle Internet Explorer with every PC, making it the default browser for millions of users. Netscape also made strategic errors, including focusing too heavily on enterprise solutions while neglecting the consumer market, allowing Microsoft to catch up and eventually surpass Netscape’s technical capabilities.

Adobe Flash + ActionScript: A Multimedia Giant’s Swift Decline

For over a decade, Adobe Flash was the dominant platform for rich multimedia content on the web. Powered by ActionScript, a scripting language similar to JavaScript, Flash enabled highly interactive websites, games, and animations. A classic snippet of ActionScript might look like:

var myText:TextField = new TextField();
myText.text = "Hello, World!";
myText.x = 100;
myText.y = 100;
addChild(myText);

This interactivity revolutionized early web experiences, making Flash a staple in web development and advertising. ActionScript 3.0 introduced object-oriented features, bringing more structure and power to web applications.

Despite its popularity, Flash faced mounting criticism for its performance, security vulnerabilities, and closed ecosystem. The death knell came when Apple declined to support Flash on iOS, signaling the industry’s shift toward open standards like HTML5, CSS3, and JavaScript. Adobe officially ended Flash support in 2020.

Visual Basic: Accessibility Meets Obsolescence

Microsoft’s Visual Basic (VB) democratized Windows software development in the 1990s. Its simple syntax and drag-and-drop interface allowed non-programmers and beginners to create full-fledged Windows applications rapidly:

Module Module1
   Sub Main()
     Console.WriteLine("Hello World!")
   End Sub
End Module

VB’s tight integration with the Windows API and rapid application development tools made it a hit for business applications. However, as .NET and more modern languages like C# emerged, Visual Basic was gradually phased out. VB.NET, its successor, attempted modernization but lacked traction among new developers.

The rise of more versatile, cross-platform, and open-source development frameworks ultimately made Visual Basic an outdated choice for contemporary software needs.

Fortran: The Long-Reigning King of Scientific Computing

Developed in the 1950s, Fortran (FORmula TRANslation) was one of the first high-level programming languages. Its strength in numerical computation made it the go-to choice for scientists and engineers for decades. A basic Fortran program might look like:

PROGRAM Hello
   PRINT *, 'Hello, world!'
END PROGRAM Hello

Fortran introduced critical concepts like structured programming and efficient array handling, which made it ideal for high-performance computing tasks such as climate modeling and computational fluid dynamics.

Though still used in legacy scientific codebases, Fortran’s relevance has dwindled. Modern languages like Python, with libraries like NumPy and SciPy, offer more flexible and accessible alternatives, leading to Fortran’s slow fade from the mainstream.

Smalltalk: Object-Oriented Pioneer with Limited Reach

Smalltalk was a trailblazer in object-oriented programming. It introduced core concepts such as message passing, live coding environments, and a uniform object model that inspired languages like Java, Python, and Ruby. A Smalltalk code example:

Transcript show: 'Hello, world!'; cr.

The entire environment was built from objects, offering unprecedented dynamism and introspection. Smalltalk’s interactive IDE and immediate feedback loop remain unmatched in some respects.

Yet, Smalltalk struggled with adoption due to performance issues, steep learning curves, and limited tooling outside its own ecosystem. While it remains influential in academic and niche circles, it was overshadowed by more pragmatic object-oriented languages that better integrated with mainstream operating systems and development workflows.

Hardware Nightmares: When Innovation Meets Market Reality

Windows Phone, Google Glass, Microsoft Zune, and Netscape Navigator represent fascinating case studies of hardware and platforms that, despite their technical innovations, faced significant challenges in achieving lasting market success. Each offers valuable lessons about the complex relationship between technological capability and commercial viability.

Windows Phone: Microsoft’s $7.6 Billion Lesson

Microsoft’s Windows Phone stands as one of tech’s most expensive failures, with the company writing off $7.6 billion related to the Nokia acquisition. Despite having superior hardware and a polished user interface, Windows Phone never gained meaningful market share.

The platform featured a unique tile-based interface that demonstrated Microsoft’s innovative approach to mobile design. This Live Tile system showcased Windows Phone’s dynamic interface capabilities and integration with the broader Windows ecosystem. The platform’s Metro design language influenced modern UI design principles and demonstrated Microsoft’s vision for unified experiences across devices.

However, Windows Phone’s failure stemmed from entering the market too late and creating a vicious ecosystem cycle. Microsoft launched Windows Phone 7 in 2010, three years after the iPhone had already transformed the industry. By then, iOS and Android had established dominant positions with hundreds of thousands of apps, while Windows Phone launched with only 2,000. The platform suffered from a destructive cycle where low user adoption meant developers ignored the platform, which in turn meant fewer apps, leading to even lower adoption.

Google Glass: The Wearable That Wasn’t Ready for Society

Google Glass generated enormous hype as the future of wearable computing but crashed spectacularly due to privacy concerns and social acceptance issues. Despite Google’s technological prowess, the product was discontinued just two years after its 2013 launch.

The Glass platform introduced revolutionary concepts in augmented reality and hands-free computing. Its voice recognition capabilities and heads-up display technology influenced modern AR development and demonstrated the potential for seamless human-computer interaction through voice commands and gesture controls.

However, Google Glass faced a perfect storm of problems that made it unsuitable for mainstream adoption. The $1,500 price tag made it inaccessible to most consumers, while the device’s bulky design and visible camera created immediate privacy concerns. People worried about being recorded without consent, leading to bans in restaurants, bars, and other public spaces. Most critically, Google failed to clearly define the target market and value proposition for everyday users.

Microsoft Zune: The iPod Killer That Never Was

Microsoft’s Zune music player launched in 2006 as a direct competitor to Apple’s iPod but failed to make a significant dent in Apple’s market dominance. Despite some innovative features, the Zune became synonymous with Microsoft’s inability to compete in consumer electronics.

Zune introduced innovative wireless sharing capabilities and social music discovery features that predated modern streaming services. Its larger screen and improved navigation demonstrated Microsoft’s understanding of user interface design, while the Zune software provided a more integrated media management experience than many competitors.

However, the Zune suffered from classic late-mover disadvantages. By 2006, the iPod had already established itself as the dominant music player, with a mature ecosystem including iTunes and strong brand loyalty. Microsoft’s device offered improvements like wireless sharing and a larger screen, but these incremental benefits weren’t enough to overcome Apple’s head start. Microsoft also struggled with marketing and brand positioning, lacking the sleek design aesthetic that made Apple products desirable.

Conclusion: Lessons in Technology Adoption

The histories of these varied technologies illustrate a critical lesson: technical merit alone is insufficient to guarantee market success. Whether it’s a programming language like ALGOL that lacked commercial focus, a framework like Japronto whose benchmark performance was impractical for real-world use, or hardware like the Zune and Windows Phone that couldn’t overcome established ecosystems, the pattern is consistent.

Sustainable adoption requires a delicate balance of innovation with practical usability, strong industry support, and the ability to evolve alongside changing user needs and market dynamics. The failure to address real-world problems, build a supportive ecosystem, or adapt to new industry standards ultimately led to the decline of these once-promising technologies.

A brief introduction to HyperLogLog++

Alberto — 2025-06-13T00:00:00.000Z

Table of Contents

The Problem
The Algorithm
Example
Implementation
Relative Percentage Error
Conclusion

This document demonstrates a fascinating technique that tackles a complex computational problem using an elegant probabilistic strategy.

The Problem

The count-distinct problem (also known as the cardinality estimation problem) involves finding the number of distinct elements in a data stream containing repeated elements.

Traditionally, solving this problem requires Θ(D) space complexity, where D represents the number of unique elements. This is because we need to store each unique element to determine whether a new element has been previously encountered.

Unfortunately, this approach doesn’t scale for massive cardinalities found in real-world applications such as:

Unique Query Counting: Tracking the number of unique searches in a search engine
Network Monitoring: Counting unique source IP addresses
Unique Visitor Tracking: Monitoring distinct users across web platforms

Note	In the original paper and related literature, "cardinality" refers to the number of distinct elements.

The Algorithm

When you only need an estimation, or when the number of unique elements makes it impractical to store them all in memory, HyperLogLog++ provides an excellent solution.

This technique estimates the number of unique elements with a relative percentage error between -4% and 6%, using only 16 KB of memory (though this depends on the number of registers configured).

Example

Let me illustrate the core concept with a simple analogy.

Imagine someone spends an entire day rolling a die and tells you the maximum number of consecutive 1s they rolled was 3. While you can’t determine the exact number of rolls, you can estimate it by calculating the probability of this event occurring.

The probability of rolling three consecutive 1s is:

1/6 * 1/6 * 1/6 = 1/(6^3)

Therefore, the expected number of trials needed to observe this event is:

1 / (1/6^3) = 6^3 = 216

Translating this concept into an algorithm:

The Dice game becomes a Hash function that hashes the element in input and yields bits. These bits represent the outcome of the game run, like if the dice had only two faces, 1 and 0.
The event taken into account was that the longest sequence of 1’s (that the die returns 1) at the start of the game, but in this case, since hashing returns a binary output, the algorithm will calculate the event of longest run of leading bits set to 0. Technically, it’s also possible to count leading ones, but counting leading zeros is a common convention.
Probability of rolling a 1 (1/6) → Probability of a bit being 0 (1/2)
Number of plays → Cardinality

This represents the fundamental idea behind the Flajolet–Martin algorithm, which HyperLogLog improves upon through three key enhancements. *Correction Factor* is applied to mitigate the overestimation bias inherent in the standard HLL algorithm. *Grouped Averaging* specifically the harmonic mean across multiple registers (or buckets), to significantly improve the accuracy of its cardinality estimates. HLL for small cardinalities suffers from the Overestimation Bias, for that reason Linear Counting is used, which is another probabilistic counting algorithm simple and highly accurate for that scale.

Implementation

Data Structure

class HyperLogLog {
    //Number of registers. Must be a power of 2. `buckets = 2^p`
    private final int buckets = 16384;

    // Correction factor
    private final double alpha = 0.7213 / (1 + 1.079 / buckets); //0.72125250052

    //Initialize the array of 16 383 (2^14-1) elements
    private final byte[] registers = new byte[buckets];

The hash function outputs 64 bits, the first 14 are used to address the registers while the last 50 are used for calculating the ranking. That’s why the size of the register array is 16384 and the type is byte sufficient to count up to 50 leading zeros.

Add Operation

The add operation is how you feed individual elements into the HyperLogLog structure. The goal is to update the internal state of the HLL to reflect the presence of this new element.

    public void add(String element) {
        // Calculate hash
        long hash = hashElement(element);
        // Take the first 14 bits to address the register
        short registerIndex = getIndex(hash);
        // Take the last 50 bits
        long value = getValue(hash);
        // Calculate the rank value for the target register
        byte rank = (byte) (leadingZeros(value) + 1);
        // Keep the biggest rank between rank and registers[registerIndex]
        if (rank > registers[registerIndex]) {
            registers[registerIndex] = rank;
        }
    }

Calculate a 64-bit hash of the input
Extract the first 14 bits of the hash to index the register
Use the remaining 50 bits to calculate the number of leading zeros
Compare with the existing register value and store the biggest rank

Count Operation

The count operation provides an approximation of the number of distinct elements that have been added to the HyperLogLog.

    public long count() {
        double sum = 0;
        int zeroRegisters = 0;
        // Calculate the harmonic mean of the register values
        for (byte register: registers) {
            sum += Math.pow(2, -register);
            if (register == 0) {
                zeroRegisters++;
            }
        }
        // Raw estimate
        double estimate = alpha * buckets * buckets / sum;
        // Apply corrections for small cardinalities
        if (estimate <= 2.5 * m && zeroRegisters > 0) {
            // Linear counting
            estimate = buckets * Math.log((double) buckets / zeroRegisters);
        }
        return Math.round(estimate);
    }

Calculate the harmonic mean of all register values
Apply a correction factor
Count the number of empty registers
Fall back to linear counting for small cardinalities

Merge Operation

The merge operation allows you to combine two or more HyperLogLog structures into a new HLL structure (or update one with another). This is a powerful feature for distributed systems where distinct counts might be computed on subsets of data in parallel and then combined.

    public void merge(HyperLogLog that) {
        for (int i = 0; i < buckets; i++) {
            if (this.registers[i] < that.registers[i])
                this.registers[i] = that.registers[i];
        }
    }

Compare each register pair at the same index
Retain the register with the larger value

Relative Percentage Error

In this graph x-axis represents the expected cardinality, and it goes from 0 to 100k elements. While the y-axis represents the relative error in percentage. We can observe that in the first part that linear counting is used for cardinalities up to approximately 40,000, after which HyperLogLog++ takes over, the error is quite high, but it starts to converge around 0 the more elements come in. The next graph shows what would happen without linear counting, the Overestimation Bias.

Conclusion

HyperLogLog++ is a good solution for counting unique elements in those use case where storing them in memory is not practical. It provides O(1) complexity both in terms of time and space, and the relative error is in the range of -4% to 6%.

Philippe Flajolet - First author of "HyperLogLog: the analysis of a near-optimal cardinality estimation algorithm"

A Quest to Tame Large Language Models

Luke Woodcock — 2025-05-26T00:00:00.000Z

Introduction

Large Language Models represent one of the most significant advances in artificial intelligence, fundamentally transforming how we interact with natural language processing systems. Understanding their architecture and mechanisms is essential for anyone working with modern AI systems.

This guide examines the core concepts underlying LLMs, from foundational statistical models to sophisticated attention mechanisms, providing practical insights for implementation and deployment. We’ll explore how these systems generate coherent text, the role of context in language understanding, and the architectural innovations that enable modern capabilities.

If new to the language of LLMs, this guide aims to demystify some of the "magic" surrounding them. If already versed in the language of LLMs, this guide hopes to be a refresher.

1. The Foundation: Probabilistic Text Generation

Large Language Models operate as sophisticated probability machines. At their core, they analyze patterns in text data to predict the most likely next token given a specific context. While they incorporate stochastic elements through temperature controls, pedantically, their underlying mechanisms are fundamentally deterministic—the same prompt with identical parameters will consistently produce the same output. In pratice, however, they are far from determinisitic—the stochastic elements and numerous other caveats render that statement for "illustration purposes only".

Statistical Language Models

Statistical language models form the conceptual foundation for understanding modern LLMs. These models process a corpus of text and use statistical patterns to predict subsequent words or tokens. While contemporary LLMs have evolved far beyond these simple approaches, understanding statistical models illuminates the core challenges that advanced architectures address.

Bi-gram Models

A bigram model represents the simplest form of statistical language modeling. It analyzes pairs of consecutive words to build frequency tables that inform predictions.

Consider this example corpus: "The cat sat on the mat. The mat was soft and warm."

The resulting bi-gram frequency table would contain:

Bigram	Count
The cat	1
cat sat	1
sat on	1
on the	1
the mat	2
mat The	1
was soft	1
soft and	1
and warm	1

When processing the input "The," the model examines all bi-grams beginning with "The":

"The cat" (1 occurrence)
"The mat" (2 occurrences)

The model predicts "mat" as the most probable next word based on frequency.

While effective for demonstration, bigram models suffer from severe contextual limitations, because the consider only one preceding word for their predictions.

N-gram Models

The n-gram model extends the bi-gram concept by incorporating longer contextual windows. A trigram model, for example, considers two preceding words, while an n-gram model employs n-1 words of context.

Let’s look at the sentence: "Thank you very much for your cooperation. I very much appreciated it. We very much made progress."

A trigram model encountering "you very" would leverage both "you" and "very" to predict "much," using conditional probability P("much" | "you", "very").

The relationship between context length and model performance involves critical trade-offs:

Longer Context (Higher n):

Captures richer contextual dependencies
Enables more coherent text generation
Increases model complexity and parameter space
Higher risk of data sparsity

Shorter Context (Lower n):

Simpler models with fewer parameters
More robust probability estimates
Limited contextual understanding
Reduced coherence in generated text

Data sparsity becomes increasingly problematic as n increases—many n-grams may not appear frequently enough in training data to provide reliable probability estimates.

2. The Transformer Revolution: "Attention is All You Need"

The transformer architecture, introduced by Google researchers, revolutionized natural language processing by solving the contextual limitations of n-gram models through sophisticated attention mechanisms.

Vector Representations

Transformers convert words and tokens into high-dimensional vectors (embeddings) that capture semantic and syntactic relationships. Unlike sequential models that process text word-by-word, transformers can analyze relationships between all words in a passage simultaneously.

Vector Dimensionality:

2D vectors contain 2 numbers (analogous to map coordinates)
3D vectors contain 3 numbers (spatial coordinates)
LLM vectors are high-dimensional with hundreds or thousands of dimensions

Each dimension in an vector space captures different aspects of meaning, enabling the model to represent complex relationships between words and concepts. Vectors occupying similar positions in this space represent semantically related concepts.

Attention Mechanisms

An attention mechanism functions as a dynamic spotlight, highlighting relevant information during text processing. For each token, the model calculates attention weights determining how much focus to allocate to every other token in the context.

Key Advantages:

Long-range Dependencies: Links related information across distant text portions
Context-Aware Processing: Resolves ambiguous words based on surrounding context
Parallel Processing: Analyzes all relationships simultaneously rather than sequentially

Attention Architecture

Attention mechanisms operate through three primary components for each token:

Query Vector: Represents what the current token is "looking for"
Key Vector: Represents what each token "offers" as context
Value Vector: Contains the actual information to be combined

Processing Steps:

Generate query, key, and value vectors for each token
Compare the current token’s query with all tokens' keys
Calculate attention scores indicating relevance strength
Use scores to weight value vectors
Combine weighted values to produce final token representation

Attention Weight Properties:

Higher weights indicate stronger relevance
Weights are normalized to form probability distributions (sum to 1)
Enable the model to focus on the most contextually relevant information

Self-Attention:

Every token in a sequence attends to all others, including itself, capturing comprehensive contextual relationships across the entire sequence.

Technical Glossary

attention mechanism

Mechanisms that enable models to weigh the importance of different input portions relative to each other, focusing on the most relevant information for accurate and coherent output generation.

bigram model

Statistical models that predict the next word based on the immediately preceding word, analyzing word pair frequencies to determine probability distributions.

byte-pair encoding

An algorithm for creating efficient tokenization by:

Counting character frequencies in the corpus
Identifying the most common character pairs
Adding common pairs to the vocabulary
Iteratively building tokens from frequent patterns

context

The surrounding words or sequences that inform next-word prediction. Context length varies by model type—bigram models use 1 word, trigram models use 2 words, and ngram models use n-1 words of context.

corpus

The comprehensive dataset of texts used for model training, typically including diverse sources such as books, articles, websites, and other written materials. Corpus quality and diversity directly impact model performance.

data sparsity

Insufficient coverage of possible inputs or features in training data, where certain patterns may not appear frequently enough to provide reliable probability estimates.

embedding

Embeddings transform symbolic language into mathematical forms (the vector) that neural networks can process, with similar concepts positioned closer together in the vector space.

The terms "embedding" and "vector" are often used interchangeably in machine learning contexts, though "embedding" specifically speaks to the process of transforming data into the vector form, whereas "an embedding" likely speaks to a vector—unless a new model is invented that doesn’t use vectors.

epoch

One complete pass through the entire training dataset, during which the model processes all examples and updates parameters based on prediction errors.

hyperparameter

A configuration setting that influences model behavior but is not learned during training. Examples include learning rate, batch size, and temperature. Hyperparameters are typically set before training begins and can significantly impact model performance.

long range dependencies

Relationships between words or phrases separated by significant distances in text, such as pronouns referring to entities in different paragraphs.

loss

A metric measuring prediction accuracy by quantifying the difference between model outputs and correct answers. Training progressively reduces loss through parameter optimization.

n-gram model

Describes the general version of a bigram model. It is a statistical language modeling approach that predicts words based on n-1 previous words in sequence. Common variants include bigrams (n=2), trigrams (n=3).

over-fitting

A condition where models perform exceptionally on training data but fail to generalize to new, unseen inputs—analogous to memorizing without understanding.

parameter

The individual weights and biases within a model that are adjusted during training to minimize prediction error. Parameters are learned from the training data and define the model’s behavior.

parameter space

The multidimensional mathematical domain that encompasses all the weights and biases that the model can learn, which can number in the millions or billions for modern language models.

preprocessing

Data preparation steps including cleaning, transformation, and structuring to optimize datasets for machine learning, such as lowercasing text or removing stop words.

temperature

A hyperparameter controlling output randomness:

Lower Temperature: More deterministic, focused responses with higher probability words
Higher Temperature: Increased randomness and creativity, selecting less probable words

Not to be confused with the parameter space.

token

The fundamental unit of text processed by language models, representing a piece of text produced through tokenization. Tokens can be words, subwords, characters, or other linguistic units depending on the tokenization method used.

tokenization

The process of segmenting text into smaller units (tokens) such as words, subwords, or characters. Effective tokenization increases training examples and enables models to learn morphological patterns.

training

The process of optimizing the model’s parameter space to maximize prediction accuracy, expressed as f(x|params) where x represents input and params represents learned weights.

transformer

A neural network architecture that consists of encoders (for understanding input) and decoders (for generating output), or decoder-only (for generative tasks). Transformers process all tokens in parallel rather than sequentially and better capture long range context.

vector

High-dimensional numerical representations of text or data, capturing semantic and syntactic relationships in mathematical space suitable for computational processing.

Part 4: Angular 19 Deep Dive – Smarter Forms with Signals and Control Flow

Jake Ortega — 2025-05-20T00:00:00.000Z

Welcome back to the Full-Stack Authentication Boilerplate (Angular
NestJS + PostgreSQL) series. So far, we’ve wired up the backend and built a working Angular frontend. Now it’s time to modernize our forms using the latest Angular 19 features—specifically Signals, control flow syntax, and defer blocks.

Angular 19 isn’t a total rewrite—it’s a refinement. It tightens up template logic, improves reactivity, and lets us write cleaner, more performant UI code. In this part, we’ll refactor the login and register forms to take full advantage of these improvements.

Angular 19 Recap (and What Actually Matters for Devs)

Here’s what we’ll use in this part:

✅ Signals: Angular’s native reactive primitive, lets you track state like useState() in React—but fully integrated into Angular’s change detection.
✅ Control Flow Syntax (@if, @for, @switch): Cleaner alternatives to structural directives like *ngIf and *ngFor.
✅ Defer Blocks: Lazy-load parts of the UI, just like backend routes or feature modules.
✅ @let Directive: Declare local variables directly in templates.
✅ Smarter Change Detection: Updates only the DOM parts that actually changed, for faster UIs.

For backend devs: Think of signal() like a reactive field or an in-memory tracked variable; @if/@for in your templates is like having expressive, inline logic with instant UI updates—no more verbose boilerplate.

Signals or Reactive Forms?

When to Use Each (for Backend Devs):

Signals are perfect for local/component UI state and simple forms.

Reactive Forms (FormBuilder, etc.) are the gold standard for complex, validation-heavy, or dynamic forms—especially if you need granular error handling or will scale up forms later.

Pro Tip: You can use both! Track form state with Reactive Forms, then reflect with signals using Angular’s toSignal() utility for the best DX.
// Example: Bridge form values to signals
formValue = toSignal(form.valueChanges, { initialValue: form.value });

Migration: NgModules → Standalone Components

Old way:
@NgModule({
  declarations: [LoginComponent],
  imports: [ReactiveFormsModule],
})
export class AuthModule {}
New way (Angular 15+):
@Component({
  standalone: true,
  selector: 'app-login',
  templateUrl: './login.component.html',
  imports: [ReactiveFormsModule],
})
export class LoginComponent {}
No more @NgModule needed.

Use standalone: true and import dependencies directly in the component.

Both patterns can coexist during migration.

Refactoring the Login Form

Here’s how to use Reactive Forms as the foundation, enhanced with signals and modern control flow blocks.

`login.component.ts`

import {
  Component,
  computed,
  signal,
  inject,
  ChangeDetectionStrategy,
} from '@angular/core';
import { Router } from '@angular/router';
import { FormBuilder, Validators, ReactiveFormsModule } from '@angular/forms';
import { AuthService } from '../../services/auth.service';
import { toSignal } from '@angular/core/rxjs-interop';
import { take } from 'rxjs/operators';

@Component({
  selector: 'app-login',
  templateUrl: './login.component.html',
  styleUrls: ['./login.component.scss'],
  standalone: true,
  imports: [ReactiveFormsModule],
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class LoginComponent {
  private readonly fb = inject(FormBuilder);
  readonly form = this.fb.group({
    email: ['', [Validators.required, Validators.email]],
    password: ['', [Validators.required, Validators.minLength(6)]],
  });

  readonly isLoading = signal(false);
  readonly errorMessage = signal(null);

  readonly formValue = toSignal(this.form.valueChanges, {
    initialValue: this.form.value,
  });
  readonly formStatus = toSignal(this.form.statusChanges, {
    initialValue: this.form.status,
  });
  readonly isFormValid = computed(() => this.formStatus() === 'VALID');

  constructor(
    private readonly auth: AuthService,
    private readonly router: Router
  ) {}

  onSubmit() {
    if (!this.isFormValid()) return;

    const { email, password } = this.form.getRawValue();
    if (!email || !password) return;

    this.isLoading.set(true);
    this.errorMessage.set(null);

    this.auth
      .login({ email, password })
      .pipe(take(1))
      .subscribe({
        next: () => {
          this.isLoading.set(false);
          this.router.navigate(['/welcome']);
        },
        error: (err) => {
          this.isLoading.set(false);
          const message =
            err?.error?.message ||
            err?.message ||
            'Login failed. Please try again.';
          this.errorMessage.set(message);
        },
      });
  }
}

Migration: Control Flow Syntax

Before (classic Angular):
Loading...

  {{ user.name }}
After (Angular 17+):
@if (loading) {
  Loading...
}

  @for (user of users) {
    {{ user.name }}
  }
The new syntax is cleaner and more readable.

You can use both during your migration to Angular 17+.

`login.component.html`


  Login

  
    @let isInvalidEmail = form.get('email')?.invalid && form.get('email')?.touched;
    
    @if (isInvalidEmail) {
      Please enter a valid email.
    }
  

  
    @let isInvalidPassword = form.get('password')?.invalid && form.get('password')?.touched;
    
    @if (isInvalidPassword) {
      
        Password must be at least 6 characters long.
      
    }
  

  @if (errorMessage()) {
    {{ errorMessage() }}
  }

Refactoring the Register Form

`register.component.ts`

import {
  Component,
  computed,
  signal,
  inject,
  ChangeDetectionStrategy,
} from '@angular/core';
import { Router } from '@angular/router';
import { FormBuilder, Validators, ReactiveFormsModule } from '@angular/forms';
import { AuthService } from '../../services/auth.service';
import { toSignal } from '@angular/core/rxjs-interop';
import { take } from 'rxjs/operators';

@Component({
  selector: 'app-register',
  templateUrl: './register.component.html',
  styleUrls: ['./register.component.scss'],
  standalone: true,
  imports: [ReactiveFormsModule],
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class RegisterComponent {
  private readonly fb = inject(FormBuilder);
  readonly form = this.fb.group({
    name: ['', [Validators.required]],
    email: ['', [Validators.required, Validators.email]],
    password: ['', [Validators.required, Validators.minLength(6)]],
    role: ['user', [Validators.required]],
  });

  readonly isLoading = signal(false);
  readonly errorMessage = signal(null);

  readonly formValue = toSignal(this.form.valueChanges, {
    initialValue: this.form.value,
  });
  readonly formStatus = toSignal(this.form.statusChanges, {
    initialValue: this.form.status,
  });
  readonly isFormValid = computed(() => this.formStatus() === 'VALID');

  constructor(
    private readonly auth: AuthService,
    private readonly router: Router
  ) {}

  onSubmit() {
    if (!this.isFormValid()) return;

    const { name, email, password, role } = this.form.getRawValue();
    if (!name || !email || !password || !role) return;

    this.isLoading.set(true);
    this.errorMessage.set(null);

    this.auth
      .register({ name, email, password, role })
      .pipe(take(1))
      .subscribe({
        next: () => {
          this.isLoading.set(false);
          this.router.navigate(['/login']);
        },
        error: (err) => {
          this.isLoading.set(false);
          const message =
            err?.error?.message ||
            err?.message ||
            'Registration failed. Please try again.';
          this.errorMessage.set(message);
        },
      });
  }
}

`register.component.html`


  Register

  
    @let isInvalidName = form.get('name')?.invalid && form.get('name')?.touched;
    
    @if (isInvalidName) {
      Name is required.
    }
  

  
    @let isInvalidEmail = form.get('email')?.invalid && form.get('email')?.touched;
    
    @if (isInvalidEmail) {
      Please enter a valid email.
    }
  

  
    @let isInvalidPassword = form.get('password')?.invalid && form.get('password')?.touched;
    
    @if (isInvalidPassword) {
      
        Password must be at least 6 characters long.
      
    }
  

  @if (errorMessage()) {
    {{ errorMessage() }}
  }

Real-World Patterns for Backend Devs

✅ Signals vs Observables

Rule of Thumb: Use signals for local, component-level UI state. Use observables for async or backend-driven data.

Signals (local state):

isModalOpen = signal(false);

openModal() { this.isModalOpen.set(true); }
closeModal() { this.isModalOpen.set(false); }

@if (isModalOpen()) {
  
}

Observables (async state):

private modalSubject = new BehaviorSubject(false);
isModalOpen$ = this.modalSubject.asObservable();

openModal() { this.modalSubject.next(true); }
closeModal() { this.modalSubject.next(false); }

@let isOpen = (isModalOpen$ | async);
@if (isOpen) {
  
}

✅ Control Flow in Action

Using @for instead of *ngFor:


  @for (user of users; track user.id) {
    {{ user.name }}
  }

Using @switch vs *ngSwitch:

@switch (status) {
  @case ('loading') {
    Loading...
  } @case ('error') {
    Error!
  } @default {
    All good.
  }
}

Backend parallel: @if, @for, and @switch are like inline logic in your backend template engines (e.g., EJS, Razor, Thymeleaf)—but here they’re fully reactive and type-safe.

✅ Lazy Loading and UX Patterns with @defer

Angular’s @defer block is great for loading UI only when needed.

Basic Usage:

@defer (when isHeavyComponentVisible) {
  
} @placeholder {
  Loading widget...
}

Loading feedback:

@defer (when dataReady; loading minimum 300ms) {
  
} @loading {
  Loading dashboard...
} @placeholder {
  Initializing view...
}

Viewport entry:

@defer (on viewport) {
  
} @placeholder {
  Loading news feed when visible...
}

Idle trigger:

@defer (on idle) {
  
}

⏳ Why care? Optimizes TTI (time to interactive) on heavy or mobile pages.

✅ Smart Change Detection in a Dashboard

userCount = signal(0);
orderTotal = signal(0);

ngOnInit() {
  this.api.getUsers().subscribe(users => this.userCount.set(users.length));
  this.api.getOrders().subscribe(orders => this.orderTotal.set(orders.length));
}

Users: {{ userCount() }}
Orders: {{ orderTotal() }}

Signals update just what changed—no wasted DOM re-renders.

SSR & Hydration (Bonus Note)

💡 SSR & Hydration: Angular 19’s hydration improvements are especially useful if you’re rendering Angular on the server (Angular Universal). Most projects won’t need this—but it’s a great step for future-proofing.

Final Thoughts

Angular 19 brings a more approachable and modern developer experience: signals simplify state, @if and @for make templates more readable, and @defer gives you fine control over performance.

You just:

Replaced legacy form logic with clean Signals-based state.
Simplified templates using Angular’s new control flow.
Learned how to delay rendering and optimize performance with @defer.

Next: We’ll bring everything together in Part 5 with route guards, token parsing, and role-based access control.

Part 3: Frontend Setup with Angular

Jake Ortega — 2025-05-06T00:00:00.000Z

Now that we’ve built our NestJS backend with secure JWT auth, it’s time to wire up the frontend. In this part, we’ll scaffold an Angular app, integrate it with our backend, and secure it with JWT-based route protection.

By the end of this part, you’ll have:

A basic Angular app styled with Bootstrap
Auth service for login/register with JWT handling
Login and Register components using reactive forms
A protected Welcome page
Route guard to lock down private views

Step 1: Initialize the Angular Frontend

Let’s get your frontend up and running. Open your terminal and run:

ng new frontend
cd frontend

Pick SCSS (or your favorite style option) when prompted.
This gives you a fresh Angular workspace to play with.

What is `ng` in Angular CLI?

The ng command is the core of the Angular CLI (Command Line Interface) — a powerful toolkit that streamlines Angular development from start to finish. It acts as a shortcut to perform a wide range of tasks without manually setting up files or configurations.

With ng, you can quickly scaffold new projects, generate application features, and manage your build and development workflow with ease. Here are some common ng commands and what they do:

ng new: Creates a new Angular project with a complete directory structure, TypeScript configuration, and ready-to-run setup.
ng generate (or ng g): Automatically creates Angular building blocks such as components, services, directives, pipes, and more — following Angular’s style guide and best practices.
ng serve: Launches a local development server with live reload. As you make changes, the app updates instantly in the browser.
ng build: Compiles your application into optimized static files for production deployment.

The real power of ng lies in automation. It eliminates repetitive boilerplate and helps you stick to Angular conventions, leading to cleaner, more maintainable codebases.

💡 Tip: With Angular v19, components and services are created as standalone by default. This means they no longer need to be declared in NgModules, which promotes better modularity and reduces coupling in your app architecture.

By mastering the ng CLI, you’re not just saving time — you’re building apps the Angular way, with a foundation rooted in scalability and consistency.

Step 2: Install Dependencies

We’ll need a few extras to make our app functional and visually appealing:

Bootstrap: For responsive and professional styling.
jwt-decode: To decode JWTs and extract user information.

Install them with:

npm install bootstrap jwt-decode

Step 3: Set Up Bootstrap

Let’s make things look good with minimal effort.

Open angular.json

Find the "styles" array and add Bootstrap’s CSS:

"styles": [
  "node_modules/bootstrap/dist/css/bootstrap.min.css",
  "src/styles.scss"
]

Start your development server if it’s not already running:
```
ng serve
```

Test it by adding a Bootstrap class (like btn btn-primary) to a button in app.component.html. If it’s blue, you’re golden.

Step 4: Setting Up Environments

Angular provides a built-in way to manage environment-specific configurations, such as API URLs for development and production. Let’s configure them.

Run the following command to generate the environment files for development and production:

ng generate environments

This will create two files in the src/environments/ folder:

src/
├── environments/
│   ├── environment.development.ts # Development environment
│   └── environment.ts             # Production environment

Open both environment.ts and environment.development.ts and add the apiUrl property. environment.development.ts

export const environment = {
  production: false,
  apiUrl: "http://localhost:3000", // Replace with your backend's dev URL
};

environment.ts

export const environment = {
  production: true,
  apiUrl: "https://your-production-api.com", // Replace with your backend's prod URL
};

The environment files are automatically selected based on the build configuration:
- Development: When running ng serve, Angular replaces environment.ts with environment.development.ts.
- Production: when running ng build --prod, Angular uses environment.ts.
  
  You can now use environment.apiUrl in your services to dynamically switch between development and production APIs.

Step 5: Generate Guards, Services, and Components

Let Angular CLI do the heavy lifting for you. Run the following commands to generate the necessary files:

ng generate service services/auth
ng generate guard auth/auth
ng generate component pages/login
ng generate component pages/register
ng generate component pages/welcome

What These Commands Do:

Auth Service: Handles API calls for login, registration, and token management.
Auth Guard: Protects routes by checking if the user is authenticated.
Login Component: Provides a form for users to log in.
Register Component: Provides a form for users to register.
Welcome Component: Displays a personalized welcome message for logged-in users.

This sets up your folders and boilerplate files, keeping things organized and modular.

Project Structure Overview

Here’s how your Angular app should look after generating the files:

src/
├── app/
│   ├── auth/                     # Guards, interceptors, maybe a module
│   │   └── auth.guard.ts
│   ├── pages/                    # Feature components
│   │   ├── login/
│   │   │   ├── login.component.html
│   │   │   ├── login.component.scss
│   │   │   └── login.component.ts
│   │   ├── register/
│   │   │   ├── register.component.html
│   │   │   ├── register.component.scss
│   │   │   └── register.component.ts
│   │   └── welcome/
│   │       ├── welcome.component.html
│   │       ├── welcome.component.scss
│   │       └── welcome.component.ts
│   ├── services/                 # API communication
│   │   └── auth.service.ts
│   ├── shared/                   # Models, utilities, etc. (optional)
│   ├── app.component.html
│   ├── app.component.scss
│   ├── app.component.ts
│   ├── app.config.ts
│   └── app.routes.ts
├── environments/
│   ├── environment.development.ts # Development environment
│   └── environment.ts             # Production environment
├── index.html
├── main.ts
└── style.scss

Step 6: The Auth Service – Your API Bridge

The AuthService is the backbone of your authentication flow. It communicates with your backend’s /auth/login and /auth/register endpoints, manages the JWT in localStorage, and provides utility methods for token handling.

Here’s the complete implementation:

// src/app/services/auth.service.ts
import { Injectable } from "@angular/core";
import { HttpClient } from "@angular/common/http";
import { catchError, Observable, tap, throwError } from "rxjs";
import { environment } from "../../environments/environment";

@Injectable({
  providedIn: "root",
})
export class AuthService {
  constructor(private http: HttpClient) {}

  /**
   * Logs in the user by sending their credentials to the backend.
   * Stores the access token in localStorage upon success.
   * @param data - The user's email and password.
   * @returns An observable containing the access token.
   */
  login(data: {
    email: string;
    password: string;
  }): Observable<{ access_token: string }> {
    return this.http
      .post<{ access_token: string }>(`${environment.apiUrl}/auth/login`, data)
      .pipe(
        tap((res) => localStorage.setItem("access_token", res.access_token)),
        catchError((error) => {
          const errorMessage =
            error.status === 401
              ? "Invalid email or password. Please try again."
              : "An unexpected error occurred. Please try again later.";
          return throwError(() => new Error(errorMessage));
        })
      );
  }

  /**
   * Registers a new user by sending their details to the backend.
   * @param data - The user's name, email, password, and role.
   * @returns An observable for the registration process.
   */
  register(data: {
    email: string;
    password: string;
    name: string;
    role: string;
  }): Observable {
    return this.http.post(`${environment.apiUrl}/auth/register`, data).pipe(
      catchError((error) => {
        const errorMessage =
          error.status === 400
            ? "Registration failed. Please check your input."
            : "An unexpected error occurred. Please try again later.";
        return throwError(() => new Error(errorMessage));
      })
    );
  }

  /**
   * Logs out the user by removing the access token from localStorage.
   */
  logout(): void {
    localStorage.removeItem("access_token");
  }

  /**
   * Retrieves the stored access token from localStorage.
   * @returns The access token or null if not found.
   */
  getToken(): string | null {
    return localStorage.getItem("access_token");
  }

  /**
   * Checks if the user is authenticated by verifying the presence of a token.
   * @returns A boolean indicating whether the user is authenticated.
   */
  isAuthenticated(): boolean {
    const token = this.getToken();
    return !!token;
  }
}

Step 7: Protecting Routes with a Guard

Angular’s CanActivate guard is like a backend middleware for your routes. Here’s how we check for a valid JWT:

// src/app/auth/auth.guard.ts
import { Injectable } from "@angular/core";
import { CanActivate, Router } from "@angular/router";
import { AuthService } from "../services/auth.service";
import { jwtDecode } from "jwt-decode";

@Injectable({ providedIn: "root" })
export class AuthGuard implements CanActivate {
  constructor(private authService: AuthService, private router: Router) {}

  canActivate(): boolean {
    const token = this.authService.getToken();
    if (!token) {
      this.redirectToLogin();
      return false;
    }

    if (this.isTokenExpired(token)) {
      this.authService.logout();
      this.redirectToLogin();
      return false;
    }

    return true;
  }

  /**
   * Checks if the token is expired.
   * @param token - The JWT token to validate.
   * @returns A boolean indicating whether the token is expired.
   */
  private isTokenExpired(token: string): boolean {
    try {
      const decoded: any = jwtDecode(token);
      return Date.now() > decoded.exp * 1000;
    } catch {
      return true; // Treat invalid tokens as expired
    }
  }

  /**
   * Redirects the user to the login page.
   */
  private redirectToLogin(): void {
    this.router.navigate(["/login"]);
  }
}

Step 8: Login & Register Components

The LoginComponent and RegisterComponent are the core components for user authentication in the application. Both components use Angular’s reactive forms to manage user input and validations. They interact with the AuthService to send requests to the backend for login and registration functionality. Upon successful operations, they navigate the user to the appropriate page (/welcome for login and /login for registration).

Key Features

Reactive Forms: Both components use Angular’s reactive forms to handle user input and validations.
Validation Rules: Fields like email, password, and name (for registration) have validation rules to ensure proper input.
Error Handling: User-friendly error messages are displayed when login or registration fails.
Loading State: Prevents duplicate submissions by disabling the submit button while the request is in progress.
Navigation: Redirects users to the appropriate page upon successful login or registration.

Login Component

// src/app/pages/login/login.component.ts
import { Component } from "@angular/core";
import { Router } from "@angular/router";
import {
  FormBuilder,
  FormGroup,
  ReactiveFormsModule,
  Validators,
} from "@angular/forms";
import { AuthService } from "../../services/auth.service";
import { CommonModule } from "@angular/common";

@Component({
  selector: "app-login",
  templateUrl: "./login.component.html",
  styleUrls: ["./login.component.scss"],
  imports: [ReactiveFormsModule, CommonModule],
})
export class LoginComponent {
  form: FormGroup;
  isLoading = false;
  errorMessage: string | null = null;

  constructor(
    private fb: FormBuilder,
    private auth: AuthService,
    private router: Router
  ) {
    this.form = this.fb.group({
      email: ["", [Validators.required, Validators.email]],
      password: ["", [Validators.required, Validators.minLength(6)]],
    });
  }

  onSubmit() {
    if (this.form.invalid) return;

    this.isLoading = true;
    this.errorMessage = null;

    this.auth.login(this.form.value).subscribe({
      next: () => {
        this.isLoading = false;
        this.router.navigate(["/welcome"]);
      },
      error: (err) => {
        this.isLoading = false;
        this.errorMessage =
          err.error?.message || "Login failed. Please try again.";
      },
    });
  }
}

Login HTML



  Login

  
    
    
      Please enter a valid email.
    
  

  
    
    
      Password must be at least 6 characters long.
    
  

  
    {{ errorMessage }}

Register Component

// src/app/pages/register/register.component.ts
import { Component } from "@angular/core";
import { Router } from "@angular/router";
import {
  FormBuilder,
  FormGroup,
  ReactiveFormsModule,
  Validators,
} from "@angular/forms";
import { AuthService } from "../../services/auth.service";
import { CommonModule } from "@angular/common";

@Component({
  selector: "app-register",
  templateUrl: "./register.component.html",
  styleUrls: ["./register.component.scss"],
  imports: [ReactiveFormsModule, CommonModule],
})
export class RegisterComponent {
  form: FormGroup;
  isLoading = false;
  errorMessage: string | null = null;

  constructor(
    private fb: FormBuilder,
    private auth: AuthService,
    private router: Router
  ) {
    this.form = this.fb.group({
      name: ["", [Validators.required]],
      email: ["", [Validators.required, Validators.email]],
      password: ["", [Validators.required, Validators.minLength(6)]],
      role: ["user", [Validators.required]],
    });
  }

  onSubmit() {
    if (this.form.invalid) return;

    this.isLoading = true;
    this.errorMessage = null;

    this.auth.register(this.form.value).subscribe({
      next: () => {
        this.isLoading = false;
        this.router.navigate(["/login"]);
      },
      error: (err) => {
        this.isLoading = false;
        this.errorMessage =
          err.error?.message || "Registration failed. Please try again.";
      },
    });
  }
}

Register HTML


  Register

  
    
    
      Name is required.
    
  

  
    
    
      Please enter a valid email.
    
  

  
    
    
      Password must be at least 6 characters long.
    
  

  
    {{ errorMessage }}

Step 9: Welcome Page – Static Greeting and Logout

The WelcomeComponent provides a user-friendly page that welcomes the user after a successful login. It integrates with the existing AuthService to manage logout functionality but does not attempt to decode or extract any user-specific data from the access token.

Key Features

Static Greeting: Display a generic welcome message for all users.
Logout Functionality: Allow users to log out and clear their session.

Welcome Component

// src/app/pages/welcome/welcome.component.ts
import { Component } from "@angular/core";
import { AuthService } from "../../services/auth.service";
import { Router } from "@angular/router";

@Component({
  selector: "app-welcome",
  templateUrl: "./welcome.component.html",
  styleUrls: ["./welcome.component.scss"],
})
export class WelcomeComponent {
  constructor(private authService: AuthService, private router: Router) {}

  logout(): void {
    this.authService.logout();
    this.router.navigate(["/login"]);
  }
}

Welcome HTML



  Welcome!
  We're glad to have you here.

Welcome Component SCSS

/* /src/app/pages/welcome/welcome.component.scss */
.welcome-container {
  max-width: 600px;
  margin: auto;
  padding: 20px;
  background-color: #f8f9fa;
  border-radius: 8px;
  box-shadow: 0 4px 6px rgba(0, 0, 0, 0.1);
}

h1 {
  color: #343a40;
}

p {
  color: #6c757d;
}

Step 10: Routing: Lock Down Protected Pages

Alright, now that we’ve got our login, registration, and welcome pages ready, it’s time to lock things down. We don’t want just anyone accessing the protected parts of our app, right? That’s where Angular’s routing and guards come into play. Let’s set up our routes and ensure only authenticated users can access the welcome page.

Setting Up Routes

In Angular, routes define how users navigate through your app. Here’s how we’ll structure our routes:

/login: For users to log in.
/register: For new users to sign up.
/welcome: A protected page that greets logged-in users.
/: Redirects to /welcome by default.

Here’s the code:

// src/app/app.routes.ts
import { Routes } from "@angular/router";
import { LoginComponent } from "./pages/login/login.component";
import { RegisterComponent } from "./pages/register/register.component";
import { WelcomeComponent } from "./pages/welcome/welcome.component";
import { AuthGuard } from "./auth/auth.guard";

export const routes: Routes = [
  { path: "", redirectTo: "welcome", pathMatch: "full" },
  { path: "login", component: LoginComponent },
  { path: "register", component: RegisterComponent },
  { path: "welcome", component: WelcomeComponent, canActivate: [AuthGuard] },
];

This is a simple and clean way to define your app’s navigation. Notice how we’ve added canActivate: [AuthGuard] to the /welcome route? That’s the magic that protects it.

Protecting Routes with a Guard

The AuthGuard is like a bouncer for your routes. It checks if the user is authenticated before letting them in. If they’re not, it redirects them to the login page.

Wiring It All Together

Now that we’ve defined our routes and guard, let’s hook everything up in main.ts. Angular v19 makes this super simple with the provideRouter function:

// src/main.ts
import { bootstrapApplication } from "@angular/platform-browser";
import { AppComponent } from "./app/app.component";
import { provideRouter } from "@angular/router";
import { routes } from "./app/app.routes";
import { provideHttpClient } from "@angular/common/http";

bootstrapApplication(AppComponent, {
  providers: [
    provideRouter(routes), // Provide the routes
    provideHttpClient(), // Provide the HTTP client
  ],
}).catch((err) => console.error(err));

No need for a separate AppRoutingModule. Just provide the routes directly in main.ts, and you’re good to go.

Testing It Out

Try Accessing /welcome Without Logging In:
- You should be redirected to /login.
Log In and Access /welcome:
- After logging in, navigate to /welcome. You should see the personalized greeting.
Log Out and Try Again:
- After logging out, try accessing /welcome again. You should be redirected to /login.

Why This Matters

For backend developers, this should feel familiar. Think of the AuthGuard as middleware for your routes. It ensures that only authenticated users can access certain parts of your app, just like how you’d protect API endpoints on the server side.

By combining Angular’s routing with guards, you’ve got a solid foundation for building secure, user-friendly apps. And the best part? It’s modular and easy to extend. Want to add role-based access? Just tweak the guard. Need to protect more routes? Add canActivate to them.

What’s Next?

You’ve got a working Angular app wired to your backend, protected with route guards and powered by JWT auth. Next up, we’ll level things up with some Angular 19 enhancements and best practices.

👉 Part 4: Angular 19 Deep Dive

We’ll cover:

🧠 Signals vs Observables — When to use which and why
🔁 @if, @for, and defer blocks — Smarter templates with better control
⚡ Change detection and performance tuning

This part’s optional, but worth it if you want your Angular app to be leaner, faster, and future-ready.

For now, pat yourself on the back—you’ve just implemented a secure, modern routing system in Angular. 🚀

AI plugins for code development

Rajendra Maniyal — 2025-05-02T00:00:00.000Z

Introduction

Recently, I experimented with integrating AI into my IntelliJ IDEA setup for JVM development, and I wanted to share the steps I followed. It turned out to be really helpful, so maybe this guide can assist someone else in getting started too!

IntelliJ is one of the preferred IDE for Java, Scala and Kotlin development. I have been using the IntelliJ IDEA with plugins for AI, which allows me to use Local LLMs to generate code suggestions, refactor my code and even write tests for me.

What I did

Step 1: Install Ollama

First, visit Ollama and download the version for your operating system. Follow the simple installation steps.

Open your terminal and run ollama pull llama3 to download the model. Start the model by running ollama serve llama3.

Tip	Choosing the right model is very important .

Step 2: IntelliJ Plugins

I tested a few plugins and found Continue.dev really useful:

Note	A list of plugins at the bottom of this article with links

Continue.dev Helps with code completion, converting comments into code, and debugging tips. Works locally (privacy-friendly), quick. Needs decent hardware resources.

Step 3: Setting Up Continue.dev with IntelliJ

Install the Plugin: Open IntelliJ IDEA, navigate to Settings → Plugins, search for "Continue.dev", and install it.

Connect to Ollama: Open the Continue.dev settings and add the local Ollama server URL (http://localhost:11434).

Step 4: Exploring AI Features

Code Suggestions: The plugin provided accurate code completions immediately, significantly speeding up my workflow.

Generating Code from Comments: I tried writing simple English comments, and Continue.dev translated them into functioning code snippets effortlessly.

Debugging: Even when intentionally making small errors, the plugin quickly suggested effective fixes.

Step 5: AI-Assisted Refactoring

I highlighted some messy code. Using the AI suggestions via right-click helped clean up and optimize the code efficiently.

Tips for Best Results:

Regularly update plugins and AI models for optimal performance.

If hardware resources are limited, experiment with smaller models initially.

IntelliJ IDEA Plugins Supporting Local LLM Integration

Plugin	Features	Pros	Cons
Continue.dev	Code completion Natural language to code generation Inline code explanations Supports multiple local LLM providers	- Open-source - Highly customizable - Supports various local LLMs like Ollama, LM Studio, GPT4All	- May require manual configuration for optimal performance
DevoxxGenie	Code review and explanation Unit test generation Retrieval-Augmented Generation (RAG) Integration with various local LLMs	- Fully Java-based - Rich feature set including RAG and Git Diff viewer - Supports multiple local LLMs	- Interface may be overwhelming for beginners
Proxy AI	Connects IntelliJ IDEA with locally running LLMs Provides AI assistance features	- Open-source - Simple setup for local LLM integration	- Limited feature set compared to other plugins
CodeGPT	AI-powered code suggestions Chat interface within IntelliJ IDEA Supports local LLMs via LM Studio	- User-friendly interface - Supports multiple programming languages	- May require additional setup for local LLM integration
JetBrains AI Assistant	AI-driven code suggestions Code explanations and documentation generation Integration with local LLMs	- Official JetBrains plugin - Seamless integration with IntelliJ IDEA	- May have limited customization compared to open-source alternatives

Plugin

Features

Pros

Cons

Continue.dev

Code completion
Natural language to code generation
Inline code explanations
Supports multiple local LLM providers

- Open-source - Highly customizable - Supports various local LLMs like Ollama, LM Studio, GPT4All

- May require manual configuration for optimal performance

DevoxxGenie

Code review and explanation
Unit test generation
Retrieval-Augmented Generation (RAG)
Integration with various local LLMs

- Fully Java-based - Rich feature set including RAG and Git Diff viewer - Supports multiple local LLMs

- Interface may be overwhelming for beginners

Proxy AI

Connects IntelliJ IDEA with locally running LLMs
Provides AI assistance features

- Open-source - Simple setup for local LLM integration

- Limited feature set compared to other plugins

CodeGPT

AI-powered code suggestions
Chat interface within IntelliJ IDEA
Supports local LLMs via LM Studio

- User-friendly interface - Supports multiple programming languages

- May require additional setup for local LLM integration

JetBrains AI Assistant

AI-driven code suggestions
Code explanations and documentation generation
Integration with local LLMs

- Official JetBrains plugin - Seamless integration with IntelliJ IDEA

- May have limited customization compared to open-source alternatives

Part 2: Backend Setup with NestJS

Jake Ortega — 2025-04-22T00:00:00.000Z

With our project vision and stack laid out in Part 1, it’s time to build the backend. In this part, we’ll scaffold a NestJS project, connect it to PostgreSQL via TypeORM, and implement secure JWT-based authentication.

By the end of this part, you’ll have:

A working NestJS app connected to PostgreSQL
A User entity with hashed passwords
Endpoints for registration and login
JWT authentication using guards and strategies
CORS enabled to allow Angular frontend communication

Project Structure Overview

Once set up, your backend folder will look like this:

src/
├── app.module.ts
├── main.ts
├── auth/
│   ├── auth.controller.ts
│   ├── auth.module.ts
│   ├── auth.service.ts
│   ├── dto/
│   │   ├── login.dto.ts
│   │   └── register.dto.ts
│   └── jwt/
│       └── jwt.strategy.ts
├── users/
│   ├── user.entity.ts
│   ├── users.controller.ts
│   ├── users.module.ts
│   └── users.service.ts
.env

Goals for Part 2

Scaffold a NestJS project with PostgreSQL and TypeORM
Create a User entity, DTOs with validation, and an Auth module
Implement registration and login with password hashing
Add JWT authentication with guards and strategy
Enable CORS for frontend connectivity

Step 1: Run PostgreSQL and Set Environment Variables

You can use either Docker or Podman. Run one of the following commands in your terminal:

Docker:

docker run --name pg-nest \
  -e POSTGRES_USER=nestuser \
  -e POSTGRES_PASSWORD=nestpass \
  -e POSTGRES_DB=nestdb \
  -p 5432:5432 \
  -d postgres

Podman:

podman run --name pg-nest \
  -e POSTGRES_USER=nestuser \
  -e POSTGRES_PASSWORD=nestpass \
  -e POSTGRES_DB=nestdb \
  -p 5432:5432 \
  -d postgres

Once the project is created in Step 2, add a .env file to your root:

DB_HOST=localhost DB_PORT=5432 DB_USERNAME=nestuser DB_PASSWORD=nestpass
DB_NAME=nestdb JWT_SECRET=dev_secret BCRYPT_SALT_ROUNDS=10

Step 2: Scaffold the Project and Install Dependencies

nest new backend
cd backend

Install project dependencies:

npm install @nestjs/typeorm typeorm pg @nestjs/jwt passport-jwt @nestjs/passport bcrypt class-validator class-transformer dotenv

At the top of main.ts, import environment variables:

import "dotenv/config";

Enable CORS:

app.enableCors({
  origin: "http://localhost:4200",
  credentials: true,
});

✅ Tip: For production, consider using @nestjs/config for cleaner environment management.

Step 3: Configure TypeORM

In app.module.ts:

import { Module } from "@nestjs/common";
import { TypeOrmModule } from "@nestjs/typeorm";
import { UsersModule } from "./users/users.module";
import { AuthModule } from "./auth/auth.module";

@Module({
  imports: [
    TypeOrmModule.forRoot({
      type: "postgres",
      host: process.env.DB_HOST,
      port: parseInt(process.env.DB_PORT, 10),
      username: process.env.DB_USERNAME,
      password: process.env.DB_PASSWORD,
      database: process.env.DB_NAME,
      entities: [__dirname + "/**/*.entity{.ts,.js}"],
      synchronize: true, // ⚠️ Don't use this in production — it'll drop/recreate tables
    }),
    UsersModule,
    AuthModule,
  ],
})
export class AppModule {}

Step 4: Create the User Module and Entity

Generate boilerplate:

nest g module users
nest g service users
nest g controller users

In users/user.entity.ts:

import { Exclude } from "class-transformer";
import { Column, Entity, PrimaryGeneratedColumn } from "typeorm";

@Entity()
export class User {
  @PrimaryGeneratedColumn()
  id: number;

  @Column({ unique: true })
  email: string;

  @Column()
  name: string;

  @Column()
  @Exclude()
  password: string;

  @Column()
  role: string;
}

Step 5: Set Up the Auth Module

Generate files:

nest g module auth
nest g service auth
nest g controller auth

Step 5a: Create DTOs with Validation

In auth/dto/register.dto.ts:

import { IsEmail, IsNotEmpty, MinLength } from "class-validator";

export class RegisterDto {
  @IsEmail()
  email: string;

  @MinLength(6)
  password: string;

  @IsNotEmpty()
  name: string;

  @IsNotEmpty()
  role: string;
}

These are like your request payload models with annotations. Think @NotEmpty, @Email, etc. The validation logic is handled globally (we’ll wire that up in main.ts using ValidationPipe).

In auth/dto/login.dto.ts:

import { IsEmail, MinLength } from "class-validator";

export class LoginDto {
  @IsEmail()
  email: string;

  @MinLength(6)
  password: string;
}

Enable validation globally in main.ts:

import { ValidationPipe } from "@nestjs/common";

app.useGlobalPipes(new ValidationPipe({ whitelist: true }));

Step 6: Implement UsersService

This service handles persistence logic using TypeORM’s repository pattern. In users.service.ts:

import { Injectable } from "@nestjs/common";
import { InjectRepository } from "@nestjs/typeorm";
import { Repository } from "typeorm";
import { User } from "./user.entity";

@Injectable()
export class UsersService {
  constructor(
    @InjectRepository(User)
    private repo: Repository
  ) {}

  create(data: Partial) {
    const user = this.repo.create(data);
    return this.repo.save(user);
  }

  findByEmail(email: string) {
    return this.repo.findOne({ where: { email } });
  }
}

Again, if you’re used to JPA, this is just standard repository stuff.

In users.module.ts:

import { Module } from "@nestjs/common";
import { TypeOrmModule } from "@nestjs/typeorm";
import { User } from "./user.entity";
import { UsersService } from "./users.service";
import { UsersController } from "./users.controller";

@Module({
  imports: [TypeOrmModule.forFeature([User])],
  providers: [UsersService],
  controllers: [UsersController],
  exports: [UsersService],
})
export class UsersModule {}

Step 7: Build AuthService

This is where registration and login happens. We hash passwords with bcrypt, and return a JWT if login succeeds.

You’ll notice:

delete user.password;

It manually removes the password before returning the user — feels a bit hacky, but we’ve also used @Exclude() in the entity, so this is just being extra cautious.

⚠️ We’re using both @Exclude() (to hide the password when transforming entities) and delete user.password as a backup. Depending on how Nest returns the object — directly vs. through a serialization step — the password field might still leak through without this extra guard.

In auth.service.ts:

import { Injectable, UnauthorizedException } from "@nestjs/common";
import * as bcrypt from "bcrypt";
import { JwtService } from "@nestjs/jwt";
import { UsersService } from "../users/users.service";
import { RegisterDto } from "./dto/register.dto";
import { LoginDto } from "./dto/login.dto";

@Injectable()
export class AuthService {
  constructor(
    private usersService: UsersService,
    private jwtService: JwtService
  ) {}

  async register(dto: RegisterDto) {
    const existing = await this.usersService.findByEmail(dto.email);
    if (existing) throw new UnauthorizedException("Email already in use");

    const hashed = await bcrypt.hash(dto.password, 10);
    const user = await this.usersService.create({
      ...dto,
      password: hashed,
    });
    delete user.password;
    return user;
  }

  async login(dto: LoginDto) {
    const user = await this.usersService.findByEmail(dto.email);
    const valid = user && (await bcrypt.compare(dto.password, user.password));
    if (!valid) throw new UnauthorizedException("Invalid credentials");

    const payload = { sub: user.id, role: user.role };
    return { access_token: this.jwtService.sign(payload) };
  }
}

In auth.module.ts:

import { Module } from "@nestjs/common";
import { JwtModule } from "@nestjs/jwt";
import { AuthService } from "./auth.service";
import { AuthController } from "./auth.controller";
import { UsersModule } from "../users/users.module";
import { JwtStrategy } from "./jwt/jwt.strategy";

@Module({
  imports: [
    UsersModule,
    JwtModule.register({
      secret: process.env.JWT_SECRET,
      signOptions: { expiresIn: "1d" },
    }),
  ],
  providers: [AuthService, JwtStrategy],
  controllers: [AuthController],
})
export class AuthModule {}

Step 8: JWT Strategy and Guards

Here we set up Passport’s JWT strategy. If you’re new to Passport: it’s just NestJS’s way of plugging in different auth strategies.

Create the strategy file:

touch src/auth/jwt/jwt.strategy.ts

In jwt.strategy.ts:

import { Injectable } from "@nestjs/common";
import { PassportStrategy } from "@nestjs/passport";
import { ExtractJwt, Strategy } from "passport-jwt";

@Injectable()
export class JwtStrategy extends PassportStrategy(Strategy) {
  constructor() {
    super({
      jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
      secretOrKey: process.env.JWT_SECRET,
    });
  }

  validate(payload: any) {
    return { id: payload.sub, role: payload.role };
  }
}

This function runs once the JWT is verified. It attaches the returned object to req.user.

So if you hit a route with a valid JWT, this is what gets injected.

Step 9: Connect Auth Routes

In auth.controller.ts:

import { Controller, Post, Body } from "@nestjs/common";
import { AuthService } from "./auth.service";
import { RegisterDto } from "./dto/register.dto";
import { LoginDto } from "./dto/login.dto";

@Controller("auth")
export class AuthController {
  constructor(private authService: AuthService) {}

  @Post("register")
  register(@Body() dto: RegisterDto) {
    return this.authService.register(dto);
  }

  @Post("login")
  login(@Body() dto: LoginDto) {
    return this.authService.login(dto);
  }
}

Two routes here:

POST /auth/register → Creates a user
POST /auth/login → Validates user and returns a token

Nice and clean.

Step 10: Test It

Start your server:

npm run start:dev

Use Postman or Insomnia:

Register

POST /auth/register
Content-Type: application/json

{
  "email": "test@example.com",
  "password": "123456",
  "name": "Test User",
  "role": "user"
}

Login

POST /auth/login
Content-Type: application/json

{
  "email": "test@example.com",
  "password": "123456"
}

Response:

{
  "access_token": ""
}

Use this token to access protected routes with:

Authorization: Bearer

Recap

You now have:

A functional NestJS backend with PostgreSQL
User registration and login with secure hashed passwords
JWT-based authentication strategy and guards
DTO validation and global pipes
Environment config and CORS enabled for the frontend

👉 Next up (Part 3): We’ll switch gears and start building the Angular frontend — hooking it up to this backend, wiring in JWT auth, and securing client-side routes.

GenAI: Optimizing Local Large Language Models Performance

Radek Kargul — 2025-04-17T00:00:00.000Z

Local large language models (LLMs) are becoming more capable and accessible than ever — but to truly unlock their power, you need to know how to optimize them. Whether you’re running AI on an M-series MacBook or a 2019 Intel machine, there are tricks to get better speed, quality, and control.

In the final session of our GenAI series (after covering Local Dev, RAG, and Agents), we explored the real-world performance tuning of local LLMs. Here’s what we covered 👇

1. Running LLMs on Your Laptop

Apple Silicon vs Intel Macs

Feature	Apple Silicon (M1/M2/M3/M4)	Intel Mac (e.g. 2019 MBP)
CPU & GPU	Unified on one chip (SoC)	Separate chips for CPU and GPU
Memory	Shared Unified Memory Architecture	RAM for CPU, VRAM for GPU
Model performance	Fast, efficient, great for LLMs	Slower, GPU mostly unused

Feature

Apple Silicon (M1/M2/M3/M4)

Intel Mac (e.g. 2019 MBP)

CPU & GPU

Unified on one chip (SoC)

Separate chips for CPU and GPU

Memory

Shared Unified Memory Architecture

RAM for CPU, VRAM for GPU

Model performance

Fast, efficient, great for LLMs

Slower, GPU mostly unused

Note	M-series chips shine for local AI workloads thanks to unified memory. Intel Macs can still work well but rely entirely on CPUs and may struggle with larger models.

What Can You Run?

Models are measured by parameters, typically in billions (e.g., 3B, 7B, 13B). More parameters = more "intelligence" — but also more memory use.

Use quantization (more below!) to fit larger models, even on machines with 8–16 GB RAM.

2. Quantization: Making LLMs Lighter

What is Quantization?

Quantization reduces the precision of the numbers in a model — trading a little accuracy for huge gains in size and speed.

Format	Description	Typical Use
FP32	Full precision	Training
FP16	Half precision	Deployment
INT8	Quantized	Light inference (some loss)
INT4	Heavily quantized	Fast local inference
INT2–3	Experimental	Ultra-lightweight, niche

Format

Description

Typical Use

FP32

Full precision

Training

FP16

Half precision

Deployment

INT8

Quantized

Light inference (some loss)

INT4

Heavily quantized

Fast local inference

INT2–3

Experimental

Ultra-lightweight, niche

LLaMA2-70B goes from 138GB (FP16) to 42GB (INT4) — a huge saving!

What is GGUF?

GGUF stands for GPT-Generated Unified Format. It’s a modern, standardized file format designed for running quantized large language models (LLMs) locally.

Why GGUF?

GGUF makes loading and using models in tools like llama.cpp, Ollama, or LM Studio.

Feature Benefit

Feature	Benefit
🧳 Compact	Stores quantized models in a smaller, efficient format
🧠 Self-contained	Includes weights, tokenizer, metadata, and vocab in one file
⚡ Fast	Optimized for quick loading and inference
🔧 Flexible	Supports various quantization formats like `Q4_K_M`, `Q5_K_S`, etc.

🧳 Compact

Stores quantized models in a smaller, efficient format

🧠 Self-contained

Includes weights, tokenizer, metadata, and vocab in one file

⚡ Fast

Optimized for quick loading and inference

🔧 Flexible

Supports various quantization formats like Q4_K_M, Q5_K_S, etc.

Tools that Support GGUF

llama.cpp – Core backend for CPU/GPU inference
Ollama – CLI + API for local models
LM Studio – Desktop GUI for Mac/Windows/Linux
text-generation-webui – Powerful browser-based frontend

Example GGUF Model Filename

mistral-7b-instruct-v0.1.Q4_K_M.gguf

Part Description

Part	Description
`mistral-7b-instruct`	Model type and size
`v0.1`	Model version
`Q4_K_M`	Quantization type (4-bit, medium group)
`.gguf`	File format extension

mistral-7b-instruct

Model type and size

v0.1

Model version

Q4_K_M

Quantization type (4-bit, medium group)

.gguf

File format extension

Think of a .gguf file as an AI-in-a-box — it includes everything the model needs to run locally, compressed and ready to go.

K-Quant Types (for GGUF Models)

When downloading quantized models (especially in GGUF format), you’ll often see suffixes like Q4_K_S, Q5_K_M, or Q6_K_L. These aren’t just random labels — they define how the quantization is applied, and they directly affect model quality vs. performance.

The K in these names refers to the quantization group size and method, which influences:

how much precision is preserved;
how fast the model can run;
how much RAM is required.

Suffix Description

Suffix	Description
`K_S`	Small group quantization Fastest and most memory-efficient. It compresses more aggressively, which means it’s ideal when you’re on a tight memory budget or running on weaker hardware — but output quality might noticeably degrade on complex tasks.
`K_M`	Medium group quantization A great balance of speed, memory use, and output quality. It’s the "safe middle ground" for most users running 4–7B models locally. If you’re unsure where to start, this is a solid default.
`K_L`	Large group quantization More conservative compression — keeps more precision, giving higher-quality outputs. Slower and uses more RAM, but closer to non-quantized behavior. Ideal for tasks requiring accurate and nuanced responses.

K_S

Small group quantization Fastest and most memory-efficient. It compresses more aggressively, which means it’s ideal when you’re on a tight memory budget or running on weaker hardware — but output quality might noticeably degrade on complex tasks.

K_M

Medium group quantization A great balance of speed, memory use, and output quality. It’s the "safe middle ground" for most users running 4–7B models locally. If you’re unsure where to start, this is a solid default.

K_L

Large group quantization More conservative compression — keeps more precision, giving higher-quality outputs. Slower and uses more RAM, but closer to non-quantized behavior. Ideal for tasks requiring accurate and nuanced responses.

The difference isn’t just in speed — it’s also in how much subtle detail the model retains in its responses.

“Think of K_S, K_M, and K_L as image compression presets: Small is low-res JPEG, Medium is standard HD, Large is almost RAW quality.”

What is Quantization used for?

Quantization is a trade-off between size, speed, and accuracy. For some perspective, here’s a rough guide on how quantization is used in the LLM world:

Task	Quantization
Model training	FP32 (that’s why it is so expensive to train models, to get that knowledge accurate)
For deployment	Usually FP16 (for speed)
Local models	Unused INT4 (for speed and accuracy)

Task

Quantization

Model training

FP32 (that’s why it is so expensive to train models, to get that knowledge accurate)

For deployment

Usually FP16 (for speed)

Local models

Unused INT4 (for speed and accuracy)

Why Not Just Use a Smaller Model?

Models under 3B can run easily — but often lack reasoning or language nuance.
Quantization gives you the best of both worlds: keep a 7B+ model’s brain but shrink the size.

“It’s like watching a 4K movie compressed to 1080p — smaller, still looks good.”

Quantized Models In Action (Example)

In this example, we consider qwen2.5, a 14B model with quantized versions available in Ollama. We will focus on different quantization levels of the 14B model.

Let’s have a look at how different models deal with the following prompt:

Explain recursion to a 10-year-old in one paragraph.

To run the models, execute one of the following prompts, starting with Q4_0:

ollama run qwen2.5:14b-instruct-q4_0
ollama run qwen2.5:14b-instruct-q8_0
ollama run qwen2.5:14b-instruct-q2_K
ollama run qwen2.5:14b-instruct-fp16

For example, let’s start with Q4_0:

ollama run qwen2.5:14b-instruct-q4_0

Now that the model is loaded, we can run the prompt:

"Explain recursion to a 10-year-old in one paragraph."

Pay attention to the response time and the memory usage. Compare it with the other models.

You may have noticed there is not much difference in quality between the Q4_0 and Q8_0 models, but the Q2_K model is much faster and smaller. Perfect for showing the quality/speed trade-off in action, and how to adjust for your needs. This does not necessarily mean that the behavior is the same for other prompts or tasks. You have to try this for yourself and see what works best for you on your machine.

3. Tuning Parameters in Ollama

Using Ollama? You can change some parameter settings of the local models based on your preference, for example, a more deterministic response, or a more creative one.

Let us consider the llama3 model, we can run it with the following command:

ollama run llama3

You can set these parameters after the model is loaded:

/set parameter

So, for example, to set temperature to 1.0:

/set parameter temperature 1.0

And then we set top_p to 0.9:

/set parameter top_p 0.9

In the example above, we set the temperature to 1.0, a more creative response, and top_p to 0.9, a more deterministic response. Parameter temperature adds randomness. The lower the value, the more focused and deterministic the model response. The higher the value, the more creative and varied the response. Parameter top_p picks from the smallest possible set of words whose cumulative probability adds up to p. It controls diversity — higher values mean more diverse and creative responses, and lower values make responses more focused.

Here are some more common parameters you can tune:

Param	What it Does	Typical Values
num_ctx	Context size (how much it remembers)	2048–4096
top_k	Limits top options for output	40–100
top_p	Controls diversity	0.8–0.95
temperature	Controls creativity	0.6–0.8 (chat), 0.3–0.6 (code)
repeat_penalty	Avoids repeating phrases	1.1–1.3
threads	Number of CPU threads (config only)	Match to physical cores

Param

What it Does

Typical Values

num_ctx

Context size (how much it remembers)

2048–4096

top_k

Limits top options for output

40–100

top_p

Controls diversity

0.8–0.95

temperature

Controls creativity

0.6–0.8 (chat), 0.3–0.6 (code)

repeat_penalty

Avoids repeating phrases

1.1–1.3

threads

Number of CPU threads (config only)

Match to physical cores

If you want to learn more about the parameters, you can find some extra information here.

Resources

Final Thoughts

Running LLMs locally is no longer science fiction — it’s practical, efficient, and private. With just a bit of tuning and the right model format, your laptop becomes an AI powerhouse.

Part 1: Introduction and Stack Breakdown for the Angular + NestJS Auth Boilerplate

Jake Ortega — 2025-04-04T00:00:00.000Z

Welcome to the first part in this series on building a full-stack authentication boilerplate with Angular, NestJS, and PostgreSQL.

If you’re a backend developer comfortable with APIs, databases, and business logic—but frontend frameworks feel like foreign territory—this series is for you. We’ll walk through the full stack, showing you how to build real authentication flows while picking up modern Angular features along the way.

By the end, you’ll have a production-ready authentication boilerplate you can reuse in your own projects—or hand off confidently to frontend collaborators.

Why Angular + NestJS?

We’re using Angular on the frontend and NestJS on the backend. Both are built in TypeScript, so you get a unified development experience without switching mental models.

Here’s why this stack works well together:

Angular is opinionated, scalable, and modular—perfect for building real apps, not just prototypes. Angular 19 introduces useful features like Signals and new control flow syntax that cut boilerplate and improve performance.
NestJS is a structured backend framework with decorators, guards, and strong support for things like JWTs and PostgreSQL—ideal for secure authentication systems.
PostgreSQL is a reliable, battle-tested relational database with great tooling and support for user/session management.

Together, this stack gives you a clean, testable, and scalable foundation—without gluing together a bunch of libraries yourself.

What You’ll Build

Over this series, you’ll create a modular, full-stack authentication boilerplate with:

A NestJS backend featuring JWT login and registration
A styled Angular frontend with auth forms and route guards
Token management, global error handling, and frontend state control
CI/CD pipelines, testing setup, and a containerized dev environment

This isn’t a toy app—it’s a starting point for real projects.

What’s New in Angular 19

Angular 19 introduces major improvements that simplify frontend development and reduce complexity:

Signals – A new reactive state primitive. Think of it like useState, but built into Angular. Great for managing form state and authentication status.
Control Flow Syntax – @if, @for, and @switch clean up your templates and reduce the need for verbose structural directives.
Defer Blocks – Lazily load components based on app state, perfect for gating authenticated vs. public views.
Improved Change Detection – Smarter re-rendering out of the box for better performance.

We’ll use these features where they make sense—especially in the login and registration flows—so you learn by doing.

Who This Is For

This series is for backend developers who want to:

Understand modern Angular concepts without getting lost in frontend jargon
Build secure, token-based authentication flows using best practices
Deploy real full-stack apps with confidence

You don’t need Angular experience. If you know TypeScript, you’ll feel at home.

Tools You’ll Need

Required

Node.js – Backend + Angular CLI
NestJS CLI – Backend scaffolding
Angular CLI – Frontend scaffolding
PostgreSQL – Local dev database
Git – Version control

Optional (but helpful)

Postman – For testing APIs
pgAdmin – For inspecting the database
VS Code – With TypeScript extensions

Getting Set Up

Install Node.js
https://nodejs.org
```
node -v
npm -v
```
Install Angular and NestJS CLIs
```
npm install -g @angular/cli @nestjs/cli
```
Install PostgreSQL
https://www.postgresql.org/download
```
CREATE DATABASE auth_boilerplate;
```
Initialize Git Repo
```
git init
```

Coming Up Next (Part 2)

In Part 2, we’ll scaffold the NestJS backend, hook it up to PostgreSQL with TypeORM, and implement JWT-based login and registration logic you can actually ship.

Final Thoughts

This series is about building something real—not another tutorial app you toss out after reading. Whether it’s for a SaaS product, side project, or production tool, having a solid authentication foundation makes every other feature easier to build.

Full-Stack Authentication Boilerplate: Angular + NestJS + PostgreSQL

Jake Ortega — 2025-04-04T00:00:00.000Z

A practical series for backend developers building secure full-stack apps

For backend developers who want to ship full-stack projects—without wrestling with frontend complexity.

We’re building a full-stack authentication boilerplate—a reusable, modular codebase that gives you login, registration, route protection, token handling, and database integration out of the box. Clone it, customize it, and start building faster.

Why This Stack?

We chose Angular 19 and NestJS for a reason:

TypeScript end-to-end: Write frontend and backend in the same language with consistent tooling.
Angular 19 introduces Signals and control flow syntax (@if, @for), simplifying state and UI logic.
NestJS is structured, modular, and test-friendly—ideal for developers coming from Spring or .NET.
PostgreSQL + TypeORM provide a robust relational layer with strong typing and migrations.

You could build this with React, Express, or MongoDB. But we picked this stack for its structure and scalability—great for teams or solo developers who want a solid foundation, not just flexibility.

What’s in the Series?

Here’s the roadmap 👇

Each post builds on the last, walking you through:

✅ JWT login & registration
✅ Angular route guards & auth state
✅ NestJS modules, guards, and services
✅ PostgreSQL setup with TypeORM
✅ CI/CD, E2E tests with Playwright, and Docker deployment

You don’t need prior Angular or NestJS experience—just TypeScript and backend fundamentals.

Why This Series Exists

You don’t need another to-do app.

You need a working authentication foundation—something you can reuse, extend, and deploy. That’s what this series delivers, while helping you build real frontend + backend skills along the way.

Let’s build something you can actually ship.

Mastering Typeclass Derivation with Scala 3

Gustavo De Micheli — 2025-03-07T00:00:00.000Z

Polymorphism

When learning about programming we stumble upon the concept of Polymorphism, and when learning something new I always wonder, why should we care? Besides getting a new tool on our tool belt I think it’s important to understand what are we getting from this new programming trick.

Polymorphism, from the Greek "having multiple forms", allows us to define and implement a set of different algorithms using the same interface. This has the benefit of lowering the complexity of our system from our client’s point of view. By switching to another implementation, they don’t need to understand what changed underneath, they just need to know that the interface is honored by another implementation. And by lowering this complexity we lower the cognitive-load developers need to have while using our API, making their code easier to maintain.

As far as I’m aware, there are at least 3 types of polymorphism:

Ad-Hoc
Parametric, and
Sub-type

If you come from a Object Oriented programming background you’ll recognize the last one. Sub-type polymorphism is implemented by defining a parent class that defines an API, and child classes implementing it. Then using a mechanism like double-dispatch, a implementation is chosen based on the actual subclass being instantiated:

trait Shape:
    def area: Double

class Square(width: Double) extends Shape:
    override def area: Double = width * width

class Rectangle(width: Double, height: Double) extends Shape:
    override def area: Double = width * height

class Circle(radius: Double) extends Shape:
    override def area: Double = Math.pow(radius, 2) * Math.PI

val s1: Shape = new Circle(4)
val s2: Shape = new Rectangle(4, 2)

s1.area
s2.area

Another type of polymorphism we can find in both Functional and Object Oriented programming languages is Parametric polymorphism where we don’t necessarily provide different implementations based on different types, but rather abstract over some types:

def identity[A](a: A): A = a

enum List[+A]:
    case Cons(head: A, tail: List[A]) extends List[A]
    case Nil extends List[Nothing]

    def map[B](fn: A => B): List[B] = this match
        case Cons(head, tail) => Cons(fn(head), tail.map(fn))
        case Nil => Nil

The List doesn’t care what’s containing, but its map method can easily work for `Int`s, `String`s, and so on.

The last type of polymorphism we mentioned was Ad-Hoc polymorphism, which can be defined as a "A system where functions or expressions are defined for specific types". Let’s see how this gets implemented using Typeclasses.

Typeclasses

Typeclasses are a way to implement Ad-Hoc polymorphism with 2 significant properties:

Separate Definitions: For each relevant class, we define a separate instance of a function or method (like Show, Eq, etc.) This similar to defining a separate function for specific types.
Context-Dependent Selection: An implementation will be selected based on where the typeclass is used.

In Scala, a Typeclass is implemented by defining 3 parts:

Interface: What functionality is the Typeclass offering.
Instances: How is that functionality implemented.
Usage: Where and how is that functionality used.

Let’s see a simple implementation of the Show Typeclass:

// Interface
trait Show[A]:
    def show(a: A): String

// Instances
object Show:
    given Show[Int]     = (i: Int) => i.toString
    given Show[String]  = (s: String) => "'" + s + "'"
    given Show[Boolean] = (b: Boolean) => i.toString

// Usage
def log[A](a: A)(using s: Show[A]): Unit =
    println(s.show(a))

An important detail of the Typeclass definition is that we use a Type Parameter on it’s interface, instances, and usage.

Typeclass Derivation

An interesting feature of Scala is that we can automatically generate the instances of a Typeclass by implementing Typeclass Derivation code. This will make the compiler generate instances at compile-time, making our Typeclass more usable as we’ll shift the burden of implementation to our code instead of our client’s code.

To derive instances for a Typeclass we need:

Tools to decompose complex types, such as case classes.
Tools to compose complex types from more simpler types.

And one way we can approach implementing Derivation code is:

Think Recursively (Base vs. Iterative Case)
Implementing one Typeclass by implementing a simpler version first.

On Scala 2 we’d use a library like Shapeless or Magnolia to compose and decompose complex types. In Scala 3 these features are backed in the language.

Mirrors provide typelevel information about types being derived, with similar features as HList and Coproduct in a single abstraction.

import scala.collection.AbstractIterable
import scala.compiletime.{erasedValue, error, summonInline}
import scala.deriving.*

// Interface
trait Show[A]:
    def show(a: A): String

// Instances
object Show:
    given Show[Int]     = (i: Int) => i.toString
    given Show[String]  = (s: String) => "'" + s + "'"
    given Show[Boolean] = (b: Boolean) => i.toString

    def iterable[T](p: T): Iterable[Any] = new AbstractIterable[Any]:
        def iterator: Iterator[Any] = p.asInstanceOf[Product].productIterator

    def showProduct[T](p: Mirror.ProductOf[T], elems: => List[Show[?]]): Show[T] =
        new Show[T]:
            def show(a: A): String =
                iterable(x).lazyZip(elems).map { case (i, s) => s.show(i) }.mkString(",")

    inline def derived[A](using m: Mirror.ProductOf[A]): Show[A] =
        lazy val elemInstances = summonInstances[T, m.MirroredElemTypes]
        showProduct(m, elemInstances)

    inline def summonInstances[T, Elems <: Tuple]: List[Show[?]] =
        inline erasedValue[Elems] match
            case _: (elem *: elems) => deriveOrSummon[T, elem] :: summonInstances[T, elems]
            case _: EmptyTuple => Nil

    inline def deriveOrSummon[T, Elem]: Show[Elem] =
        inline erasedValue[Elem] match
            case _: T => deriveRec[T, Elem]
            case _    => summonInline[Show[Elem]]

    inline def deriveRec[T, Elem]: Show[Elem] =
        inline erasedValue[T] match
            case _: Elem => error("infinite recursive derivation")
            case _       => Show.derived[Elem](using summonInline[Mirror.Of[Elem]]) // recursive derivation

This is a simplified example of a Typeclass Derivation for the Show Typeclass. For a more thorough example with a more detailed explanation, I cannot recommend Type Class Derivation enough.

The Scala effect: Java’s Evolution Inspired by Scala

2025-03-04T00:00:00.000Z

Since its inception, Java has been one of the most widely used programming languages, known for its stability and enterprise adoption. However, as modern software development demands more expressive and concise code, Java has often looked to other languages for inspiration. One of its biggest influences has been Scala—a language that brought functional programming, immutability, and expressive syntax to the JVM.

Over the years, Java has steadily incorporated many features that were first introduced in Scala, from lambda expressions and pattern matching to records and data-oriented programming. In this article, we’ll explore how Java has evolved by adopting concepts from Scala, breaking down the changes version by version. We’ll also see some examples, to see each language’s unique approach, while pointing out some key differences.

Java 8

Stream API

I don’t think I need to introduce many of the readers to the Stream API, born in Java 8. It is also well known, how it basically changed the game on how you approach operations on collections. What might be a bit less known is the fact, that this feature is a big step towards functional programming, since the API promotes functional paradigms, such as immutability, pure functions, higher level functions. Exploring those paradigms could use a talk in itself, so the below example is rather to show, from a developer experience perspective how easy it is to do multiple, small operations on a collection, with the new API compered to the old way.

Scala Java (old) Java (new)

Scala	Java (old)	Java (new)
`def getNamesOfMammals(animals: List[Animal]): List[String] = animals .filter(_.classification == "mammal") .map(_.name)`	`private List getNamesOfMammals(List animals) { List names = new ArrayList<>(); for (Animal animal: animals) { if (animal.classification.equals("mammal")) { names.add(animal.name); } } return names; }`	`private List getNamesOfMammals(List animals) { return animals .stream() .filter(animal -> animal.classification.equals("mammal")) .map(animal -> animal.name) .toList(); }`

def getNamesOfMammals(animals: List[Animal]): List[String] =
  animals
    .filter(_.classification == "mammal")
    .map(_.name)

private List getNamesOfMammals(List animals) {
    List names = new ArrayList<>();

    for (Animal animal: animals) {
        if (animal.classification.equals("mammal")) {
            names.add(animal.name);
        }
    }

    return names;
}

private List getNamesOfMammals(List animals) {
    return animals
        .stream()
        .filter(animal -> animal.classification.equals("mammal"))
        .map(animal -> animal.name)
        .toList();
}

It is worth to note, that the above example is nice, and already a huge step in the right direction, when it comes to streaming data processing, java still lacks support for a lot of major operations (fold, sliding windows).

Optional

Safety first! Especially when it comes to nulls, and java. Option is a core part of the Scala language, making nullable data a breeze to work with, through great support for operations, and branchless behaviour definition. Java intends to implement some of that functionality with the Optional class. Just like in the streams' case, scala still offers more flexibility and more defined developer options, when it comes to potentially missing data (e.g.: exists, forall). The example illustrates the boilerplate needed to handle nested nullable structures, and the positive steps java already took in the right direction.

Scala Java (old) Java (new)

Scala	Java (old)	Java (new)
`case class Wing(length: Int, fact: Option[String]) case class Animal(name: String, wing: Option[Wing]) def printSafeInterestingWingFacts(animals: List[Animal]) = animals.foreach { animal => println(s"""${animal.name}: ${ animal.wing .flatMap(_.fact) .getOrElse("no interesting wing fact :(")}""")}`	`class Wing{public Integer length; public String fact;} class Animal{public String name; public Wing wing;} private void printInterestingWingFacts(List animals) { for (Animal animal: animals) { if (animal.wing != null) { if (animal.wing.fact != null) { System.out.printf("%s: %s%n", animal.name, animal.wing.fact); } else { System.out.printf("%s: no interesting wing fact :(%n", animal.name); } } else { System.out.printf("%s: no interesting wing fact :(%n", animal.name); } } }`	`class Wing{public Integer length; public Optional fact;} class Animal{public String name; public Optional wing;} private void printSafeInterestingWingFacts(List animals) { animals.forEach(animal -> { System.out.printf("%s: %s%n", animal.name, animal.wing .flatMap(wing -> wing.fact) .orElse("no interesting wing fact :(%n")); }); }`

case class Wing(length: Int, fact: Option[String])
case class Animal(name: String, wing: Option[Wing])

def printSafeInterestingWingFacts(animals: List[Animal]) =
  animals.foreach { animal => println(s"""${animal.name}: ${
    animal.wing
      .flatMap(_.fact)
      .getOrElse("no interesting wing fact :(")}""")}

class Wing{public Integer length; public String fact;}
class Animal{public String name; public Wing wing;}

private void printInterestingWingFacts(List animals) {
    for (Animal animal: animals) {
        if (animal.wing != null) {
            if (animal.wing.fact != null) {
                System.out.printf("%s: %s%n", animal.name, animal.wing.fact);
            } else {
                System.out.printf("%s: no interesting wing fact :(%n", animal.name);
            }
        } else {
            System.out.printf("%s: no interesting wing fact :(%n", animal.name);
        }
    }
}

class Wing{public Integer length; public Optional fact;}
class Animal{public String name; public Optional wing;}

private void printSafeInterestingWingFacts(List animals) {
    animals.forEach(animal -> {
        System.out.printf("%s: %s%n", animal.name, animal.wing
            .flatMap(wing -> wing.fact)
            .orElse("no interesting wing fact :(%n"));
    });
}

Functional interfaces (lambdas)

One of the key prerequisites of having support for all these functional paradigms, is to be able to pass functions as arguments. Java implements this concept via so-called functional interfaces. A functional interface, is an interface, with only one method declared. Java 8 also makes it easier to use these interfaces with the lambda syntax. With the lambda syntax you can pass lambda functions as arguments, and the compiler will be able to interpret it, as the needed interface.

Scala Java (old) Java (new)

Scala	Java (old)	Java (new)
`def chainEvenNumbers(numbers: List[Int]): String = numbers .filter(n => n % 2 == 0) .map(n => n.toString) .reduce{case (n1, n2) => n1 + n2}`	`String chainEvenNumbers(List numbers) { Predicate predicate = new Predicate<>() { @Override public boolean test(Integer integer) { return integer % 2 == 0; } }; Function mapper = new Function<>() { @Override public String apply(Integer integer) { return integer.toString(); } }; BinaryOperator accumulator = new BinaryOperator<>() { @Override public String apply(String s, String s2) { return s + s2; } }; return numbers .stream() .filter(predicate) .map(mapper) .reduce("", accumulator); }`	`String chainEvenNumbers(List numbers) { return numbers .stream() .filter(i -> i % 2 == 0) .map(Object::toString) .reduce("", (s, s2) -> s + s2); }`

def chainEvenNumbers(numbers: List[Int]): String =
  numbers
  .filter(n => n % 2 == 0)
  .map(n => n.toString)
  .reduce{case (n1, n2) => n1 + n2}

String chainEvenNumbers(List numbers) {
    Predicate predicate = new Predicate<>() {
        @Override
        public boolean test(Integer integer) {
            return integer % 2 == 0;
        }
    };

    Function mapper = new Function<>() {
        @Override
        public String apply(Integer integer) {
            return integer.toString();
        }
    };

    BinaryOperator accumulator = new BinaryOperator<>() {
        @Override
        public String apply(String s, String s2) {
            return s + s2;
        }
    };

    return numbers
        .stream()
        .filter(predicate)
        .map(mapper)
        .reduce("", accumulator);
}

String chainEvenNumbers(List numbers) {
    return numbers
        .stream()
        .filter(i -> i % 2 == 0)
        .map(Object::toString)
        .reduce("", (s, s2) -> s + s2);
}

Java 11

Java 11’s main features fall outside of this article’s scope, since they are not directly influenced by Scala, nor resemble existing Scala features. I would like to mention however a couple small additions, mainly in the area of scripting, and writing / running fast, without overhead. OVer the years a good argument for learning Scala (or against learning java, really) was that for a beginner, the learning curve might be steep, and writing small code snippets is not really possible. On top of that, while it scales up excellent, it is not really ideal for small projects. The following additions you can argue how much they were inspired by Scala actually (I wouldn’t argue against it either), but one thing is not arguable: Scala was always ahead in these topics, and with 11, Java is now one step closer.

`::of` factory method (Java 9)

No more dubious initialization, and element adding after, with Java 11 now most of the commonly used collections receive the ::of factory method, where you can quickly create a new immutable instance, with a number of initial elements.

Scala Java (old) Java (new)

Scala	Java (old)	Java (new)
`val l: List[Int] = List(1, 2, 3, 4, 5)`	`List l = new ArrayList<>(); l.add(1); l.add(2); l.add(3); l.add(4); l.add(5);`	`List l = List.of(1, 2, 3, 4, 5);`

val l: List[Int] = List(1, 2, 3, 4, 5)

List l = new ArrayList<>();

l.add(1);
l.add(2);
l.add(3);
l.add(4);
l.add(5);

List l = List.of(1, 2, 3, 4, 5);

Introduction of `jshell` (java REPL) (Java 9)

Huge step towards scripting, but also really important for bigger projects. The presence of the jshell is equally amazing for absolute beginners, as well as seasoned developers. It could be used in various ways, from writing quick "hello world" code to quickly test out more serious code in a bigger production environment. The java REPL is not yet that advanced as the Scala counterpart, but this long overdue feature is again making the language a bit more consumable.

Addition of var keyword (Java 11)

If it was not a 100% clear what does it mean, when we talk about steep learning curve for beginners, or challenges to test out code segment quickly in a bigger environment, having to quickly write a code like this (in both cases) hopefully explains it:

void testStateAndTranslator() {
    InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState state = nimbus.getState();
    assert state == expectedState;
    RefreshAuthorizationPolicyProtocolServerSideTranslatorPB translator = hadoop.getTranslator();
    assert translator == expectedTranslator;
}

Now this is a test, where you would most likely get some autocorrection, but imagine the nightmare typing these in the REPL! Luckily if you want to quicly test out something like this, sice java 11 it would only look like something like this:

jshell> var state = nimbus.getState()
state ==> InternalFrameInternalFrameTitlePaneInternalFrameT ... owNotFocusedState@1a86f2f1

jshell> state.testStuff()
Stuff works!

Launch single file (Java 11)

This is all great so far, but what if you want to write some code quickly to generate input, or want to process a file? You wouldn’t want to include that file in your project, and definitely don’t want to recompile every time you tweak that println statement. With Java 11, you get another benefit which points java in the scripting direction. You can run single java files, without associating it to a project, or even without precompiling it. In fact you can include a she-bang line, and run it as a shell script!

❯ javac HelloWorldJava8.java
❯ java HelloWorldJava8
Hello World!
❯ java HelloWorldJava11.java
Hello World!
❯ ./HelloWorldJava11Shell.java
Hello World!

Java 17

Switch expressions (Java 14)

Switch expressions' functionality is still limited to the same restrictions as before (we are going to talk about these restrictions later), but it got a nice facelift, where you can leave a lot of boilerplate code behind!

Scala Java (old) Java (new)

Scala	Java (old)	Java (new)
`def kindergartenToString(number: Int): String = number match { case 1 => "1" case 2 => "2" case _ => "cannot count until that" }`	`private String kindergartenToString(Integer number) { String result; switch (number) { case 1: result = "1"; break; case 2: result = "2"; break; default: result = "cannot count until that"; }; return result; }`	`private String kindergartenToString(Integer number) { return switch (number) { case 1 -> "1"; case 2 -> "2"; default -> "cannot count until that"; }; }`

def kindergartenToString(number: Int): String =
  number match {
  case 1 => "1"
  case 2 => "2"
  case _ => "cannot count until that"
}

private String kindergartenToString(Integer number) {
    String result;
    switch (number) {
        case 1:
            result = "1";
            break;
        case 2:
            result = "2";
            break;
        default:
            result = "cannot count until that";
    };

    return result;
}

private String kindergartenToString(Integer number) {
    return switch (number) {
        case 1 -> "1";
        case 2 -> "2";
        default -> "cannot count until that";
    };
}

Text blocks (Java 15)

Another long overdue feature, where you wonder, why exactly did we need to wait until Java 15 for that?

Scala Java (old) Java (new)

Scala	Java (old)	Java (new)
`var sql = """ \|SELECT \| name, \| salary, \| title \|FROM \| employees \|WHERE \| age < 25 \| AND title in ( \| SELECT \| summary \| FROM \| jobs \| ) \|""".stripMarging`	`String sql = "SELECT\n" + " name,\n" + " salary,\n" + " title\n" + "FROM\n" + " employees\n" + "WHERE\n" + " age < 25\n" + " AND title in (\n" + " SELECT\n" + " summary\n" + " FROM\n" + " jobs\n" + " )";`	`String sql = """ SELECT name, salary, title FROM employees WHERE age < 25 AND title in ( SELECT summary FROM jobs )""";`

var sql =
  """
    |SELECT
    |  name,
    |  salary,
    |  title
    |FROM
    |  employees
    |WHERE
    |  age < 25
    |  AND title in (
    |    SELECT
    |      summary
    |    FROM
    |      jobs
    |  )
    |""".stripMarging

String sql = "SELECT\n" +
            "  name,\n" +
            "  salary,\n" +
            "  title\n" +
            "FROM\n" +
            "  employees\n" +
            "WHERE\n" +
            "  age < 25\n" +
            "  AND title in (\n" +
            "    SELECT\n" +
            "      summary\n" +
            "    FROM\n" +
            "      jobs\n" +
            "  )";

String sql = """
            SELECT
              name,
              salary,
              title
            FROM
              employees
            WHERE
              age < 25
              AND title in (
                SELECT
                  summary
                FROM
                  jobs
              )""";

Pattern matching instanceof (Java 16)

You can argue if this in itself is a huge step or not, but this definitely set the table, for what’s to come with Java 21. And not having to cast (although it is 100% safe, already from context) by hand every time, and having to have either multiple casts, or nested branches is already a big step, but let the code speak for itself.

Scala Java (old) Java (new)

Scala	Java (old)	Java (new)
`def callIfPositiveInt(any: Any): Unit = any match { case i: Int => i.someMethodOnInt() }`	`void callIfPositiveIntImpl1(Object object) { if (object instanceof Integer) { Integer i = (Integer) object; if (i > 0) { i.someMethodOnInteger(); } } } void callIfPositiveIntImpl2(Object object) { if (object instanceof Integer && ((Integer) object) > 0) { Integer i = (Integer) object; i.someMethodOnInteger(); } }`	`void callIfPositiveInt(Object object) { if (object instanceof Integer i && i > 0) { i.someMethodOnInteger(); } }`

def callIfPositiveInt(any: Any): Unit =
  any match {
    case i: Int => i.someMethodOnInt()
  }

void callIfPositiveIntImpl1(Object object) {
    if (object instanceof Integer) {
        Integer i = (Integer) object;

        if (i > 0) {
            i.someMethodOnInteger();
        }
    }
}

void callIfPositiveIntImpl2(Object object) {
    if (object instanceof Integer && ((Integer) object) > 0) {
        Integer i = (Integer) object;
        i.someMethodOnInteger();
    }
}

void callIfPositiveInt(Object object) {
    if (object instanceof Integer i && i > 0) {
        i.someMethodOnInteger();
    }
}

Record classes (Java 16)

Record classes are a new type declaration, that allows you to compactly define immutable data classes. They are intended to be transparent carriers of their shallowly immutable data.

They resemble the well known case class in Scala. There’s no such thing as "same" between two languages, so it goes without saying that they have (on top of the many similarities) some differences. Exactly discovering all the similarities and differences is outside of the scope of this article, but from a developer experience perspective, being able to write compact code that speaks for itself is the same for both.

Records are going to be even more powerful in Java 21, paired with pattern matching concepts.

Scala Java (old) Java (new)

Scala	Java (old)	Java (new)
`case class Point(x: Int, y: Int) val point = Point(1, 2) val x = point.x val y = point.y val hashCode = point.hashCode val s = point.toString // "Point[x=1, y=2]" assert(point == Point(1, 2)) assert(!(point == Point(2, 2)))`	class Point { private final Integer x; private final Integer y; public Point(Integer x, Integer y) { this.x = x; this.y = y; } public Integer x() { return x; } public Integer y() { return y; } @Override public String toString() { return String.format("Point[x=%d, y=%d]", x, y); } @Override public boolean equals(Object object) { if (this == object) return true; if (!(object instanceof Point point)) return false; return Objects.equals(x, point.x) && Objects.equals(y, point.y); } @Override public int hashCode() { return Objects.hash(x, y); } } Point point = new Point(1, 2); Integer x = point.x(); Integer y = point.y(); int hashCode = point.hashCode(); String s = point.toString(); // "Point[x=1, y=2]" assert point.equals(new Point(1, 2)); assert !point.equals(new Point(2, 2));	`record Point(Integer x, Integer y) {} Point point = new Point(1, 2); Integer x = point.x(); Integer y = point.y(); int hashCode = point.hashCode(); String s = point.toString(); // "Point[x=1, y=2]" assert point.equals(new Point(1, 2)); assert !point.equals(new Point(2, 2));`

case class Point(x: Int, y: Int)


val point = Point(1, 2)
val x = point.x
val y = point.y
val hashCode = point.hashCode
val s = point.toString // "Point[x=1, y=2]"

assert(point == Point(1, 2))
assert(!(point == Point(2, 2)))

class Point {
    private final Integer x;
    private final Integer y;

    public Point(Integer x, Integer y) {
        this.x = x;
        this.y = y;
    }

    public Integer x() {
        return x;
    }

    public Integer y() {
        return y;
    }

    @Override
    public String toString() {
        return String.format("Point[x=%d, y=%d]", x, y);
    }

    @Override
    public boolean equals(Object object) {
        if (this == object) return true;
        if (!(object instanceof Point point)) return false;
        return Objects.equals(x, point.x) && Objects.equals(y, point.y);
    }

    @Override
    public int hashCode() {
        return Objects.hash(x, y);
    }
}


Point point = new Point(1, 2);
Integer x = point.x();
Integer y = point.y();
int hashCode = point.hashCode();
String s = point.toString(); // "Point[x=1, y=2]"
assert point.equals(new Point(1, 2));
assert !point.equals(new Point(2, 2));

record Point(Integer x, Integer y) {}


Point point = new Point(1, 2);
Integer x = point.x();
Integer y = point.y();
int hashCode = point.hashCode();
String s = point.toString(); // "Point[x=1, y=2]"
assert point.equals(new Point(1, 2));
assert !point.equals(new Point(2, 2));

Sealed interfaces/classes (Java 17)

With Scala’s language focus not just leverages, but was built on pattern matching, having an option to control your class hierarchy is essential. Hence sealed traits (interfaces) are essential part of scala. With it you can have fine grained control of the class hierarchy, and have guarantees for all possible subclasses, making pattern matching even more powerful. With the power of such features catching java’s attention, it had to adapt some of the concepts as well.

With sealed interfaces it is possible to have exact control over your class subclasses that can implement your class / interface. With having switch expression coming only in java 21, with java 17 most of the gains is having all the control over your class hierarchy, enabling you to enforce design principles, and prevent unauthorized extensions.

sealed interface Animal permits Dog, Cat {}
final class Dog implements Animal {}
final class Cat implements Animal {}
final class Bird implements Animal {}

"‘Bird' is not allowed in the sealed hierarchy"

Java 21

`SequencedCollection` interface

Before Java 21 accessing elements in order was not just not straight forward, but some brave people might call it chaos. With some of the types not having any method to access sequential elements (like getFirst, getLast, reversed), while others having the same, on top of some these' supertypes / subtypes having methods for that, while others did not. And even the ones having methods, had separate means of calling those. In short: chaos.

With Java 21, the collections implementing sequential elements have to implement the SequentialCollection interface, making the existence of these methods obvious, and unified.

Scala Java (old) Java (new)

Scala	Java (old)	Java (new)
`def doStuff( list: List[Int], deque: ArrayDeque[Int], sortedSet: SortedSet[Int], linkedHashSet: LinkedHashSet[Int] ) = { var i = 0 // get first i = list.head i = deque.head i = sortedSet.head i = linkedHashSet.head // get last i = list.last i = deque.last i = sortedSet.last i = linkedHashSet.last }`	`void doStuff( List list, Deque deque, SortedSet sortedSet, LinkedHashSet linkedHashSet ) { Integer i; // get first i = list.get(0); i = deque.getFirst(); i = sortedSet.first(); i = linkedHashSet.iterator().next(); // get last i = list.get(list.size() - 1); i = deque.getLast(); i = sortedSet.last(); // i = linkedHashSet.? missing }`	`void doStuff2( List list, Deque deque, SortedSet sortedSet, LinkedHashSet linkedHashSet ) { Integer i; // get first i = list.getFirst(); i = deque.getFirst(); i = sortedSet.getFirst(); i = linkedHashSet.getFirst(); // get last i = list.getLast(); i = deque.getLast(); i = sortedSet.getLast(); i = linkedHashSet.getLast(); }`

def doStuff(
  list: List[Int],
  deque: ArrayDeque[Int],
  sortedSet: SortedSet[Int],
  linkedHashSet: LinkedHashSet[Int]
) = {
  var i = 0
  // get first
  i = list.head
  i = deque.head
  i = sortedSet.head
  i = linkedHashSet.head
  // get last
  i = list.last
  i = deque.last
  i = sortedSet.last
  i = linkedHashSet.last
}

void doStuff(
    List list,
    Deque deque,
    SortedSet sortedSet,
    LinkedHashSet linkedHashSet
) {
    Integer i;
    // get first
    i = list.get(0);
    i = deque.getFirst();
    i = sortedSet.first();
    i = linkedHashSet.iterator().next();
    // get last
    i = list.get(list.size() - 1);
    i = deque.getLast();
    i = sortedSet.last();
    // i = linkedHashSet.? missing
}

void doStuff2(
    List list,
    Deque deque,
    SortedSet sortedSet,
    LinkedHashSet linkedHashSet
) {
    Integer i;
    // get first
    i = list.getFirst();
    i = deque.getFirst();
    i = sortedSet.getFirst();
    i = linkedHashSet.getFirst();
    // get last
    i = list.getLast();
    i = deque.getLast();
    i = sortedSet.getLast();
    i = linkedHashSet.getLast();
}

Pattern matching switch

Switch expressions were a nice syntactic sugar, but functionality wise they didn’t come with anything new. You could still only use primitive types, Strings, or enums, and were only able to match on the concrete value of the input. With java 21 all that changed, and you can use switch expressions with any types. In order to actually take advantage of this of course, a lot of new patterns were introduced on top of the value match.

null pattern
In previous versions if the value was null inside the switch, it would always throw NullPointerException. With the new null pattern these exceptions can be caught.
type pattern
You can now pattern match for the types. Just like with the pattern matching instanceof, you can use the new type without any casting necessary.
guarded patterns
You can define additional conditions for you patterns. This very well corresponds with the syntax, previously seen with instanceof, where the matched arguments can already be used as a concrete type in the guards.
record deconstruction
You can not only match on records similarly to the type pattern, but it is now possible to deconstruct nested structures, and match on nested types as well. You can also use the concrete types of these nested values. That is very powerful with deeply nested structures, where you don’t need to access a very deep value by hand.
Note, that this new record deconstruction also works with the instanceof operator.
sealed class exhaustion
Pattern matching switch is, where the most powerful feature of sealed classes / interfaces come to light. Because the compiler knows exactly which classes can implement a sealed class, if the input of the switch is a sealed class, you don’t need to define a default case, since the compiler is able to tell if the switch is exhaustive or not. That way, previously existing bugs, of not updating a switch, when e.g. the domain changes are a thing in the past, because with this new addition the compiler will force you to.

There is no point of bringing an old example for this, since it is so different from the core, you would simply look for another approach in previous java versions.

Scala Java (new)

Scala	Java (new)
case class Wing(length: Int, fact: Option[String]) sealed trait Animal case class Dog() extends Animal case class Cat() extends Animal case class Bird(birdType: String, wing: Wing) extends Animal def getWingStatus(animal: Animal): String = animal match { case null => "no animal provided" case Dog() => "dogs don't have wings" case Cat() => "cats don't have wings" case Bird(_, Wing(_, fact)) if fact.isDefined => s"interesting fact: ${fact.get}" case Bird(_, Wing(_, Some(fact))) => s"interesting fact: ${fact}" case Bird(birdType, Wing(length, _)) => s"$birdType has $length long wings" }	record Wing(Integer length, Optional fact) {} sealed interface Animal permits Dog, Cat, Bird {} final class Dog implements Animal {} final class Cat implements Animal {} record Bird(String birdType, Wing wing) implements Animal {} private String getWingStatus(Animal animal) { return switch (animal) { case null -> "no animal provided"; case Dog ignored -> "dogs don't have wings"; case Cat ignored -> "cats don't have wings"; case Bird(String birdType, Wing(Integer length, Optional fact)) when fact.isPresent() -> "interesting fact: " + fact.get(); case Bird(String birdType, Wing(Integer length, Optional fact)) -> String.format("%s has %d long wings", birdType, length); }; }

case class Wing(length: Int, fact: Option[String])

sealed trait Animal

case class Dog() extends Animal
case class Cat() extends Animal
case class Bird(birdType: String, wing: Wing) extends Animal

def getWingStatus(animal: Animal): String = animal match {
  case null => "no animal provided"
  case Dog() => "dogs don't have wings"
  case Cat() => "cats don't have wings"
  case Bird(_, Wing(_, fact)) if fact.isDefined => s"interesting fact: ${fact.get}"
  case Bird(_, Wing(_, Some(fact))) =>
    s"interesting fact: ${fact}"
  case Bird(birdType, Wing(length, _)) =>
    s"$birdType has $length long wings"
}

record Wing(Integer length, Optional fact) {}

sealed interface Animal permits Dog, Cat, Bird {}

final class Dog implements Animal {}
final class Cat implements Animal {}
record Bird(String birdType, Wing wing) implements Animal {}

private String getWingStatus(Animal animal) {
    return switch (animal) {
        case null -> "no animal provided";
        case Dog ignored -> "dogs don't have wings";
        case Cat ignored -> "cats don't have wings";
        case Bird(String birdType, Wing(Integer length, Optional fact))
            when fact.isPresent() -> "interesting fact: " + fact.get();
        case Bird(String birdType, Wing(Integer length, Optional fact)) ->
            String.format("%s has %d long wings", birdType, length);
    };
}

You can see, how it is pretty similar now in that exact case. However one must note, that while this is the new best thing in java, that is just the tip of the iceberg in Scala.

You can already see an example for that above, where (right before the guard pattern) the type pattern, and the literal value pattern is mixed. First the the type Bird is matched, then the record deconstructed, in a way that it will only match, if the wingfact is present.

Beyond

Unnamed variables (Java 22)

A minor improvement in developer experience is introducing unnamed variables. If you take a look at the previous example for pattern matching, you would notice, that although the example now looks pretty similar, in case of java you still had to give some name to the variables, even if you are not using them later on. With the introduction of unnamed variables you can use _ as the identifier, and you can reuse it as many times as you’d like, and not be able to reference it later. So it does not clutter up your scope, nor can it overshadow an outside variable by accident. In short it doesn’t just signals the implementor’s intention, but enforces it as well, making the code safer, and more obvious to read in the future.

private String getWingStatus(Animal animal) {
    return switch (animal) {
        case null -> "no animal provided";
        case Dog _ -> "dogs don't have wings";
        case Cat _ -> "cats don't have wings";
        case Bird(String _, Wing(Integer _, Optional fact))
            when fact.isPresent() -> "interesting fact: " + fact.get();
        case Bird(String birdType, Wing(Integer length, Optional _)) ->
            String.format("%s has %d long wings", birdType, length);
    };
}

Unnamed classes (Java 22)

With previous versions already enabling running java as a single file, or even as a script, the need for defining an exact main class is fading. This new feature leverages that thought, and lets the user create java files without extra boilerplate.

Java (old) Java (new)

Java (old)	Java (new)
`public class HelloWorldJava8 { public static void main(String[] args) { System.out.println("Hello World"); } }`	`void main() { System.out.println("Hello World"); }`

public class HelloWorldJava8 {
    public static void main(String[] args) {
	    System.out.println("Hello World");
    }
}

void main() {
    System.out.println("Hello World");
}

This makes the learning curve much easier for a newcomer, but also opens the door to even easier scripting in the future.

Closing thoughts

If now, you feel like Scala is bad, because Java adopted its best features I failed. If you feel like Java is bad, because it lacks a lot of features Scala has, I also failed. If you feel like Java is excellent, because it can adopt in an environment, it’s maybe not that familiar, and you feel like Scala is excellent, because it can leverage a familiar environment to the fullest, only then I have truly succeeded.

What we need to understand, is the goal of Scala, and Java are two very different things. Scala is a functional programming language, so the language and its whole ecosystem is designed around that fact, while java’s main focus lies rather elsewhere.

The fact, that Java recognizes the value in a lot of functional paradigms shows the modern thinking of its maintainers, and projects a bright future ahead.

The fact, that these paradigms are existing, and also well implemented (even well enough for the old bigbrother java) shows great design from the creators of Scala.

Java and Scala, while distinct in their philosophies, have carved out a shared space within the JVM ecosystem, proving that innovation and tradition can coexist, complement, and even elevate each other, hence elevate modern software development.

SBT: More than a Build Tool

George — 2025-02-21T00:00:00.000Z

Introduction

Scala Build Tool (SBT) is widely known for compiling, testing, and packaging Scala projects. However, its design as an extensible, programmable tool opens doors to uses beyond traditional build automation. Let’s explore SBT’s additional functionalities and practical applications.

SBT: A Brief Overview

What is SBT?

SBT (Scala Build Tool) is the de facto build tool for Scala projects. It’s an open-source build tool written in Scala that provides a Domain-Specific Language (DSL) for describing build configurations. SBT offers interactive capabilities, incremental compilation, and continuous compilation features. It uses Scala code for build definitions, allowing developers to leverage the full power of the Scala language in their build processes.

SBT vs Traditional Build Tools

SBT is specifically designed for Scala projects, with deep integration into the Scala ecosystem. While it can handle Java code within Scala projects, it’s not typically used for pure Java projects where tools like Maven and Gradle are more appropriate.

Practical Applications of SBT

Simple Configuration

SBT follows "convention over configuration" principles. For basic Scala projects, you might only need a few lines in your build.sbt file.

name := "my-project"
version := "1.0"
scalaVersion := "2.13.10"

Scala-Based Build Definition

Unlike XML-based build tools, SBT lets you write your build configuration in Scala. This means you can use variables, functions, and even complex logic in your build definitions, making them more maintainable and powerful.

val commonSettings = Seq(
  organization := "com.example",
  version := "1.0",
  scalaVersion := "2.13.10"
)

lazy val core = (project in file("core"))
  .settings(commonSettings)
  .settings(
    name := "my-core-project",
    libraryDependencies += "org.typelevel" %% "cats-core" % "2.9.0"
  )

Incremental Compilation

SBT tracks dependencies between your source files and only recompiles what’s necessary. When you change a file, SBT analyzes its dependencies and recompiles only affected files, significantly reducing build times.

Library Management

Using Coursier as its dependency resolver, SBT efficiently handles library dependencies, resolving and downloading them from repositories. It manages transitive dependencies and version conflicts automatically.

Continuous Compilation

With the ~ command prefix, SBT watches your source files and automatically recompiles when changes are detected. This creates a rapid development cycle, perfect for interactive development.

// Watch and recompile
$ sbt "~compile"

// Watch and run tests
$ sbt "~test"

// Watch specific test
$ sbt "~testOnly com.example.MySpec"

Mixed Scala/Java Support

SBT seamlessly handles projects containing both Scala and Java code, automatically detecting and compiling both languages while maintaining proper dependency ordering.

Testing Framework Integration

Built-in support for major Scala testing frameworks means you can run tests directly from SBT. It integrates with ScalaTest, specs2, and ScalaCheck out of the box, with plugin support for JUnit.

Interactive Scala REPL

Launch a Scala REPL session with your project’s classes and dependencies already loaded, perfect for exploring and testing code interactively.

// In your project
case class User(name: String, age: Int)
class UserService {
  def greet(user: User) = s"Hello, ${user.name}!"
}

// In the REPL (after running 'sbt console')
scala> val user = User("Alice", 25)
user: User = User(Alice,25)

scala> val service = new UserService
service: UserService = UserService@1234abcd

scala> service.greet(user)
res0: String = Hello, Alice!

Project Modularization

Break down complex projects into manageable sub-projects, each with its own dependencies and configurations, while maintaining build coordination across the entire project.

External Project Dependencies

Reference other Git repositories directly as dependencies, enabling seamless integration with external projects and custom forks of libraries.

Parallel Execution

Speed up builds and tests by running independent tasks in parallel, taking advantage of multiple CPU cores for faster build times. By default SBT runs tasks in parallel and tests in sequence. You can change this behavior by configuring the build.sbt file by either enablig test parallelism and adjusting the parallel execution settings, such as limiting the number of cores used for example.

Beyond Build Tool Features

Custom Task Creation

SBT allows you to define custom tasks for any purpose - from deploying applications to generating documentation. You can create tasks that integrate with external services, process data, or automate any development workflow.

// Define individual tasks
lazy val startDb = taskKey[Unit]("Starts the database")
startDb := {
  "docker-compose up -d postgres".!
}

lazy val runMigrations = taskKey[Unit]("Runs database migrations")
runMigrations := Def.sequential(
  startDb,                // Start database first
  flywayClean,           // Clean database schema
  flywayMigrate          // Run Flyway migrations
).value

Development Workflow Automation

Use SBT as a complete development environment orchestrator. Create custom commands to start databases, mock services, or set up entire development environments with a single command.

// Combine previously defined tasks into a workflow
lazy val startLocalEnv = taskKey[Unit]("Start local development environment")
startLocalEnv := Def.sequential(
  runMigrations,         // Run database migrations
  (Compile / run)        // Finally start the application
).value

// Use it with:
> sbt startLocalEnv  // Executes all tasks in sequence

Code Generation

Leverage SBT’s source generators to automatically create code, such as generating case classes from database schemas, creating TypeScript definitions from Scala classes, or producing API documentation.

Database Migration

Through plugins like Flyway or Slick-migration, SBT can manage database schemas and migrations, making it a powerful tool for database version control and deployment.

Using the SBT Flyway plugin:

// In plugins.sbt
addSbtPlugin("io.github.davidmweber" % "flyway-sbt" % "7.4.0")

// In build.sbt
flywayConfigFiles := Seq("flyway-e2e.conf")

> sbt flywayMigrate    // Using the SBT plugin

Documentation Generation

Beyond API docs, SBT can generate various types of documentation, from project websites to technical specifications, using plugins like sbt-site, ScalaDoc or mdoc.

A common example using ScalaDoc:

// In build.sbt
Compile / doc / scalacOptions ++= Seq(
  "-groups",
  "-doc-title", "My Project Documentation"
)

// Generate documentation with:
> sbt doc  // Creates ScalaDoc in target/scala-2.13/api/

Release Management

SBT can handle the entire release process, including version bumping, changelog generation, Git tagging, and publishing to various repositories or platforms.

Quality Analysis

Integrate with code quality tools to analyze source code, check coverage, enforce styling rules, and generate quality reports as part of your development workflow.

For example, to check code coverage in your project, first add the scoverage plugin to your project/plugins.sbt:

addSbtPlugin("org.scoverage" % "sbt-scoverage" % "2.0.9")

Then you can run coverage analysis:

> sbt coverage         // Enable code coverage tracking
> sbt test            // Run your tests - this collects coverage data
> sbt coverageReport  // Generate coverage report showing which code was tested

The report will be generated in target/scala-2.13/scoverage-report/ and includes:

HTML reports showing line-by-line coverage
Overall coverage statistics
Highlighted source code showing covered/uncovered lines

Conclusion

SBT is a powerful tool that transcends its role as a build tool, offering developers a versatile platform for managing, automating, and enhancing their development workflows. Whether you’re working on a small library or a large-scale application, SBT’s features and extensibility make it a valuable addition to the Scala ecosystem. SBT acts more as a development platform than a build tool and by understanding its capabilities and limitations, teams can leverage SBT to streamline their processes and focus on building great software.

Interop Summit. Why do we only import Java libraries?

Konstantin Kolmar — 2025-02-14T00:00:00.000Z

Short history of the Java platform

The Java platform, including the Java language and Java Virtual Machine (JVM), was first released around 1995. At that time, Java was the only language running on the JVM. Soon, however, other languages followed, which addressed some of Java’s shortcomings while still leveraging its runtime and the vast collection of standard and third-party libraries and allowing integration with a large amount of existing Java code.

Scala was one of the first such languages. Its development started in 2001, and the first release came out in 2004. Its main goal was to mix functional and object-oriented programming and to allow writing more concise code than Java.

Groovy was released in 2007 and introduced dynamic typing and improved scripting capabilities. Clojure also came out in 2007. As a Lisp dialect, its strengths lie in functional programming and metaprogramming.

Kotlin was one of the later major languages that entered the scene. Its implementation started in 2010, and the first stable release was in 2016. Kotlin was designed to be a nicer Java with seamless interoperability. Later, it became officially supported for Android development.

It is interesting to note that no new major languages have appeared in about 15 years now. This is probably because existing languages already cover the most important niches. Moreover, Java now includes quality-of-life features like lambdas, closures, lazy streams, records, and virtual threads, which had previously motivated the creation of new languages. Nowadays you would also need a large amount of tooling and libraries to support a new language, and probably some killer application or support and promotion from a large company.

Still, there is a large variety of less prominent languages on the JVM, including even some internal company languages. Many originally non-JVM languages have compilers that target JVM such as Jython for Python.

But given the large variety of available options, why do we only import libraries implemented in Java or in the language we are using? Well, it’s probably not a huge mystery. I bet you can name several important reasons yourself. But I think it’s still interesting to think about, so let’s review some of them.

1. Utility libraries are implemented in each language

Small or utility libraries are simply implemented natively in each language to provide idiomatic APIs. Such implementations might be a part of the standard library or provided by third parties. A good example is JSON processing. There are a lot of third-party JSON libraries in Scala, often using typeclasses and other special Scala features. In contrast, in Kotlin JSON is supported by an official library in kotlinx.serialization. There is a similar situation with idiomatic libraries for dependency injection, web frameworks, and so on.

2. Few large unique libraries

There is a lack of genuine need to import anything large from outside. What libraries unique to Kotlin, let alone other non-Java languages, would you want to use in your Scala code? Jetpack Compose is an example of a Kotlin library occupying a unique niche. It is the de facto default GUI framework on Android. However, since it’s a GUI framework you wouldn’t normally import it as a library, and you rarely see Scala code on Android anyway.

As for Scala, there are unique libraries that could be useful in Java or Kotlin code: Akka or Pekko, Spark, Gatling, or Flink. But they usually already provide bindings or APIs for Java, so you don’t need their Scala APIs. Many of them are even discontinuing their Scala API, or avoiding migration to Scala 3.

3. Focus on using Java code

Java is one of the most popular languages ever created, so over its long history a lot of libraries for all kinds of purposes have been produced. This means that language authors of every JVM language make a special effort to provide an easy way to interact with Java dependencies.

The end result is that using Java code from Scala or Kotlin is fairly simple. You can call methods normally and give them arguments, extend classes and interfaces, and so on. Scala standard library supplies a scala.jdk package, that contains many facilities to assist with interoperability.

Of course, this is still not always completely straightforward. One obvious point of contention is nullability. When using Java libraries from Scala you usually need to wrap nearly everything in an Option to avoid null pointer exceptions. You may say that using Java libraries is not idiomatic, but even in the standard library, there are packages you may want to use occasionally: java.nio.file, java.time, Unicode support, and so on.

Here is an example of a Scala 3 extension to wrap the result of one Java method:

extension (p: Path)
  def parent: Option[Path] = Option(p.getParent)

This approach is not ideal, because if you miss any wrappers, you’ll get a NullPointerException at runtime.

Scala 3 has added union types, so now you can declare nullable types directly: MyType | Null. It also has the explicit nulls feature enabled by the -Yexplicit-nulls flag. This means that all values that can have a null value, including all values coming from Java, must have a nullable type. This reduces the Option boilerplate when dealing with Java code, but introduces a different kind of boilerplate: null-checking the results of functions that can never return null.

To improve this the recently released Scala 3.5 has introduced flexible types inspired by Kotlin’s platform types. This feature is enabled by default but can be turned off with the -Yno-flexible-types flag. It means that values coming from Java can now be treated as either nullable or non-nullable. This offers the same safety guarantees as Java, so again it has reverted to the Option wrapper situation, and it’s possible to get null pointer exceptions again.

This development process demonstrates both how much effort forward interop receives and how hard it is to provide a good solution for some issues. Well, nulls wouldn’t have been a billion-dollar mistake otherwise.

4. Reverse interoperability is complicated

Reverse interoperability refers to tools and techniques that allow developers to write code accessible from Java and potentially other JVM languages. However, it can be difficult to transparently incorporate features that are unique to a particular language. For instance, when calling Scala code from Java, implicit values must be explicitly constructed, which undermines the usability of the API.

Even in simpler cases reverse interoperability requires carefully marking your code with annotations or using some non-idiomatic constructs. For example:

case class MountainRange(mountains: List[Mountain])
object MountainRange:
  @varargs
  @targetName("of3")
  @throws[IllegalArgumentException]
  def ^^^(mountains: Mountain*): MountainRange = {
    if (mountains.size != 3) throw IllegalArgumentException("Incorrect number of mountains")
    MountainRange(mountains.toList)
  }

The annotations in this method cause the Scala compiler to produce a signature that can better interact with Java. @varargs means that the argument will be a Java Array instead of a Scala Seq, targetName gives it a stable alphanumeric name instead of a technical name mangled by the compiler, and @throws adds the corresponding "throws" declaration to the method signature.

Another interesting example that demonstrates how much of an afterthought reverse interop can be is trying to define an enumeration that extends java.lang.Enum. In Scala 3 this is straightforward:

enum Mountain extends Enum[Mountain]:
  case Everest, Kilimanjaro, MontBlanc, Fujiyama

Scala 3 compiler automatically generates calls to the java.lang.Enum constructor to initialize the values. But I don’t know a way to create a Java-compatible enumeration from Scala 2. Maybe it’s not possible at all!

Other features reverse interoperability has to handle may include:

Static methods and constant values.
Class fields, getters, and setters, because many JVM languages try to improve their handling in some way.
Optional method arguments and default values. Java doesn’t allow those, but most other JVM languages do.
Different visibility modes, such as Scala’s sealed or Kotlin’s internal.
Concurrency primitives. Every language has something unique and barely compatible with each other. For example, Scala uses Futures or various IO libraries, Kotlin has coroutines in its standard library, and Java has recently added virtual threads.

Imagine having to support this menagerie for multiple languages, each with its own assumptions and idioms, changing and updating over time. If every language provided bindings or APIs for every other language, the complexity would explode.

5. Concerns about runtime dependencies

Using libraries from another language usually implies including that language’s standard library as a runtime dependency. This slows down the build and increases distribution sizes. The effect may not be large in absolute terms, but still provides enough incentive for library authors to design their libraries to avoid unnecessary dependencies on the entire standard library of a whole language.

As a consequence of those reasons Java naturally serves as the common denominator to mediate between JVM languages.

Case study

Situations where you need to interact between non-Java languages do happen but are fairly unusual. One interesting example from our team involved configuring access to intranet repositories (without internet access) in our Gradle builds.

Let’s adopt the following assumptions:

We are using Kotlin for our Gradle builds, because Kotlin is statically typed and its tooling and IDE support are better than Groovy’s.
Multiple teams publish their artifacts into their own repositories on the shared Artifactory. Different projects need different dependencies, so our goal is to give the project maintainers a simple way to add the repositories with the artifacts they need. We want to have an extension method on the RepositoryHandler, similar to the idiomatic Gradle methods such as mavenCentral() or gradlePluginPortal():
```
repositories { // this: RepositoryHandler =>
    mavenInternal("maven-releases")
    mavenInternal("gradle-plugins")
    mavenInternal("other-team-artifacts")
}
```

We have a local plugin to set the repository URL and configure a way to obtain a login token from the environment:

def extendRepositories(RepositoryHandler repositories) {
    if (repositories !instanceof ExtensionAware) return

    repositories.ext {
        mavenInternal = { repoName ->
            repositories.maven {
                name = repoName
                url = "https://artifactory.example.com/$repoName"
                credentials {
                    token = providers.environmentVariable("ARTIFACTORY_TOKEN")
                            .orElse(providers.systemProperty("gradle.wrapperPassword"))
                            .orNull
                }
            }
        }
    }
}

The problem here is that Gradle can automatically execute Groovy builds, but for Kotlin builds it needs to download a special plugin, and to download the plugin without internet access, it requires the internal repository to be already configured, creating a Catch-22 type of problem. This means the repository configuration plugin above has to be implemented in Groovy.

In the Groovy build flavor, you can directly use methods defined in an extra properties extension. But Kotlin doesn’t understand that approach. It can’t interact with standard Groovy extension methods either. Groovy implements them by modifying Groovy metaclasses, but in Kotlin extension methods are just syntax sugar, and at runtime are implemented as normal methods taking the receiver as the first argument.

In the end, the solution was to create an intermediate plugin in Kotlin, that provides a Kotlin-style extension method. It extracts Groovy Closure from the extra properties extension, casts it to the appropriate type, and calls it using Groovy API:

fun RepositoryHandler.mavenInternal(path: String) {
    ((this as ExtensionAware).extra["mavenInternal"] as Closure<*>).call(path)
}

This is still not ideal, because this helper method can’t be shared between the intermediate plugin build and implementation, so it has to be copy-pasted into several places. Nevertheless, this achieves the goal of having nice repository declarations in the user-level Kotlin build.

This is an example of how convoluted interoperability can look when assumptions and idioms from different languages and libraries come in conflict with each other.

Recap of the Joy of Coding Meetup at Lunatech

2025-02-13T00:00:00.000Z

Introduction

On February 12th, Lunatech had the privilege of hosting the Joy of Coding meetup at our office in Rotterdam.

We were excited to bring developers from across the city together to reconnect and share knowledge in an open and welcoming environment.

The evening began with a warm welcome, giving attendees the opportunity to mingle over delicious pizza. With the room buzzing with conversation, it was clear that everyone was eager to dive into the evening’s insightful sessions.

Figure 1. Introduction over pizza

Coding Your Documentation

The first session of the evening, "Coding Your Documentation" by Hubert Klein Ikkink, explored how developers can take a structured and automated approach to documentation.

Writing documentation is often seen as a tedious task, but Hubert demonstrated how code-driven techniques can make the process more efficient, maintainable, and even enjoyable.

Through practical examples, the session covered strategies such as using markup languages, automation tools, and integrating documentation directly into the development workflow. Hubert showcased how well-documented projects not only improve collaboration within teams but also enhance the onboarding process for new developers and contribute to overall software quality.

Attendees walked away with actionable insights on how to streamline documentation efforts, ensuring that code remains well-documented without slowing down development. The talk was a great reminder that good documentation is just as important as the code itself.

Figure 2. Coding Your Documentation

Reaching Operational Excellence Using OpenTelemetry

Riccardo Lippolis took the stage to talk about OpenTelemetry and its critical role in ensuring operational excellence. His session, "Reaching Operational Excellence Using OpenTelemetry," focused on how developers can easily implement standardized APIs for logging and metrics across distributed services.

Through practical demonstrations, attendees learned how OpenTelemetry allows for seamless service monitoring, making it easier to identify and solve issues in a production environment. This session provided valuable insights that our community can apply directly to their own work.

Figure 3. Reaching Operational Excellence Using OpenTelemetry

Networking and Drinks

As the talks concluded, the evening wrapped up with drinks and a networking session, giving everyone the opportunity to continue their conversations, exchange ideas, and make new connections.

The atmosphere was energizing, and it was clear that the local developer community is eager to keep pushing the boundaries of tech.

See you at the next meetup!

ZGC vs G1GC for Scala

Utku Aydın — 2025-02-07T00:00:00.000Z

Introduction

When it comes to high-performance Scala applications, memory management plays a crucial role in maintaining efficiency and stability. The JVM’s Garbage Collection (GC) mechanisms help developers avoid memory leaks and memory management while balancing latency and throughput. Two prominent GC strategies—Garbage First (G1GC) and Z Garbage Collector (ZGC)—offer different benefits depending on application needs. In this post, we’ll explore these two GC approaches, their configurations, benchmarks, and best-use scenarios for Scala applications.

Garbage First GC (G1GC)

What is G1GC?

G1GC was introduced in JDK 7 and became the default GC in JDK 9. It’s designed to optimize both latency and throughput by dividing the heap into regions and prioritizing the collection of those with the most garbage. Unlike traditional GC methods, G1GC performs concurrent marking to reduce stop-the-world pauses, enhancing application performance.

When to Use G1GC

G1GC should be used in applications that require predictable pause times.
It is suitable for systems where throughput is more critical than achieving ultra-low latency.

When Not to Use G1GC

G1GC is not ideal for applications with very large heaps that exceed a few hundred gigabytes.
It should be avoided in workloads with extreme garbage generation, as pause times may increase in edge cases.

Z Garbage Collector (ZGC)

What is ZGC?

ZGC, introduced in JDK 11, is a low-latency garbage collector designed to maintain sub-millisecond pause times regardless of heap size. It performs most of its work concurrently, including marking and compaction, ensuring minimal disruption to application performance. It ZGC can handle heap sizes up to 16 terabytes, making it an excellent choice for large-scale applications.

When to Use ZGC

ZGC is recommended for real-time systems that have strict latency requirements.
It is well-suited for applications that require efficient scalability with very large heaps.

When Not to Use ZGC

ZGC should not be used in applications that are constrained by CPU resources.
It is not ideal for workloads where high throughput is more critical than maintaining low latency.

Generational ZGC: The Cherry on Top

Generational ZGC introduces separate young and old generations, optimizing memory reclamation by focusing on short-lived objects more frequently. This approach reduces the overhead associated with managing short-lived objects, which are common in most workloads. Additionally, it further minimizes CPU and memory bandwidth usage compared to the non-generational ZGC. Despite these optimizations, Generational ZGC retains its ultra-low pause times, remaining in the sub-millisecond range. It continues to efficiently handle large heaps, with multi-terabyte support still intact. Like its predecessor, Generational ZGC performs marking, relocation, and compaction concurrently, making sure there are no disruptions in application performance.

Configuring Scala Applications for GC

To configure GC in Scala applications, appropriate Java options should be set in build.sbt.

javaOpts += "-XX:+UseZGC -XX:+ZGenerational"

In container environments, the configuration can be achieved by including the required flags in the java options environment variable (may vary between JDK distributions).

JAVA_OPTS = "-XX:+UseZGC -XX:+ZGenerational …"

Both garbage collectors also have additional flags that can be included to further fine tune their behavior depending on the use case. These are available in their respective documentation.

Benchmarking G1GC vs ZGC

Setup

The benchmarking tests were conducted in a Kubernetes cluster with 2 CPUs and 4GB of memory allocated.
Java options were pre-configured specifically for G1GC and Generational ZGC to ensure accurate comparisons.
The test workload consisted of a streaming application that processed messages at varying rates of 300, 600, and 900 messages per second.
Each test run included a warm-up phase lasting 10 minutes to allow the system to reach a stable state.
Following the warm-up, data recording was conducted for 20 minutes to capture performance metrics.

Observations

300 messages per second G1

300 messages per second ZGC

600 messages per second G1

600 messages per second ZGC

900 messages per second G1

900 messages per second ZGC

ZGC maintained ultra-low latency across all sample sizes.
G1GC delivered predictable pause times but showed increased latency under heavy load.
Generational ZGC improved short-lived object management, enhancing overall efficiency.

Conclusion

ZGC and G1GC both offer unique advantages for Scala applications:

ZGC is the best choice for ultra-low latency and massive heap scalability.
G1GC is ideal for general-purpose applications requiring predictable performance tuning.

Ultimately, selecting the right GC strategy depends on workload characteristics and performance requirements. Benchmarking under real-world conditions remains the key to making an informed decision.

SCALA-LUJAH! Happy coding!

JVM vs JVM

Nika Shamova — 2024-11-29T00:00:00.000Z

Introduction

You’ve probably heard people talk about different JVMs, each claiming to be the best. It made me wonder: why are there so many? What makes one JVM better than another? In this article, we’ll try to break down what the JVM is, how it works, and why there are so many different implementations.

Basic Concepts

Java Abbreviation Overload: JDK, JRE, JVM

If you’re working with Java, you’ve likely encountered terms like JVM, JRE, and JDK. But what do they mean, and how are they connected? Let’s break it down:

JDK (Java Development Kit)

This is a toolkit designed for Java developers. It includes everything you need to write and build Java applications: - A compiler (javac) to turn Java source code into bytecode. - Development libraries such as tools for debugging, monitoring, and packaging Java programs. - The JRE (our next guest, see below).

JRE (Java Runtime Environment)

This is the software environment required to run Java applications: - Runtime libraries: Core Java libraries (e.g., java.lang, java.util) and APIs for features like file I/O, networking, and concurrency. - The JVM (another guest, which is described below), which executes the bytecode.

JVM (Java Virtual Machine)

At the core of the Java runtime, it is responsible for: - Loading and executing Java bytecode, a platform-independent instruction set generated when Java code is compiled. - Optimizing performance with features like JIT (Just-In-Time) Compilation, which translates bytecode into machine-specific code during execution.

Java bytecode

Bytecode is an intermediate, low-level language into which Java source code is compiled. It allows Java applications to run on any platform with a JVM, enabling the "write once, run anywhere" promise.

JIT (Just-In-Time) Compilation

To improve speed, the JVM uses JIT to dynamically translate bytecode into native machine code at runtime. This reduces interpretation overhead, making applications faster.

AOT (Ahead-Of-Time) Compilation

While JIT improves performance during execution, some environments benefit from Ahead-Of-Time (AOT) Compilation, which compiles bytecode into native code before runtime. This approach is often used in resource-constrained environments, where startup speed and memory efficiency are critical.

How Do They Fit Together?

JDK: Developers use it to create Java applications.
JRE: Users rely on it to run Java applications.
JVM: This is the part of the JRE that runs Java bytecode.

During execution, the JVM can:

Use the JIT compiler to boost performance by translating bytecode to machine code on the fly.
Optionally benefit from AOT compilation to further improve startup times and efficiency in specific scenarios.

TLDR

The JDK includes the JRE, and the JRE contains the JVM. Together, they enable Java programs to be developed, executed, and optimized for a wide variety of platforms and use cases.

Write Once, Run Anywhere

The JVM is an abstract computing machine that enables Java applications to run on any hardware or operating system. It translates platform-independent bytecode into machine-specific instructions, ensuring seamless compatibility across environments.

In simpler terms, JVM developers handle the heavy lifting. Their job is to build a robust, cross-platform JVM that works on all environments. This allows Java developers to focus on writing code without worrying too much about the specifics of different platforms. (Though, let’s be real—sometimes they still have to consider it, but that’s a story for another day.)

JVM History

The Beginning of JVM

First Implementation of the JVM

The first implementation of the JVM was part of JDK 1.0, released in January 1996. Sun Microsystems developed this initial JVM in C. It was bundled with the early versions of the Java Development Kit (JDK), which included tools such as javac (the Java compiler) and runtime libraries.

Other Early Implementations

After the initial Sun JVM, several other JVM implementations were developed:

Kaffe: An independent, open-source implementation of the JVM. It aimed to provide a lightweight alternative to Sun’s JVM, which is well-suited for embedded systems.
IBM J9 (later OpenJ9): IBM’s implementation focused on enterprise environments, emphasizing performance and tuning capabilities.
Oracle JRockit: A JVM optimized for server-side performance, especially in low-latency environments. Oracle acquired it and later merged features with the HotSpot JVM.
HotSpot JVM: Originally developed by Longview Technologies, HotSpot was acquired by Sun Microsystems. It introduced Just-In-Time (JIT) compilation and adaptive optimization techniques. HotSpot eventually became the default JVM in the Java SE platform.

What is the Deal with OpenJDK and Oracle JDK?

OpenJDK and Oracle JDK are closely related, especially since Java 11. OpenJDK is the open-source implementation of the Java SE Platform, while Oracle JDK is a commercial build based on OpenJDK. Both share the same codebase, meaning their functionality is nearly identical from Java 11 onward.

Oracle JDK historically: included exclusive "commercial features" like Flight Recorder, Java Mission Control, and Application Class-Data Sharing. However, these features were added to OpenJDK starting with Java 11, eliminating most differences between the two.
The main distinction now lies in licensing and support. OpenJDK is free under the GNU General Public License (GPL), while Oracle JDK requires a commercial license for production use and comes with additional long-term support options for businesses. Essentially, OpenJDK is the foundation for Oracle JDK, and they are almost identical in technical terms for modern Java versions.

JVM vs JVM

So Many JVMs, What is the Difference?

There are so many JDKs and JVMs available these days. Let’s explore a few of them to see how they differ and what unique features they offer!

OpenJDK

The Open Java Development Kit (OpenJDK) is an open-source implementation of the Java Platform, Standard Edition (Java SE).

Reference Implementation: OpenJDK is the official reference implementation of Java SE, ensuring compliance with the Java SE specifications. Many other distributions use it as a core.
Regular Release Cycle: OpenJDK follows a six-month release cycle, with Long-Term Support (LTS) versions every three years.
Community-Driven: Features like improved garbage collectors, API updates, and performance optimizations are developed as an open-source.
Cross-Platform: OpenJDK supports major operating systems like Linux, macOS, and Windows, as well as architectures like x86, ARM, and RISC-V.
Licensing: OpenJDK is distributed under a GPL license, allowing it to be used freely for all purposes, including commercial applications.

Oracle JDK

The Oracle JDK is Oracle’s distribution of the Java Development Kit. It shares the same codebase as the open-source OpenJDK but comes with some proprietary features and licensing.

Oracle JDK is based on OpenJDK but includes additional optimizations and patches.
Oracle ensures backward compatibility and long-term support for enterprise users.
Access to critical bug fixes before they are included in publicly available releases.

GraalVM

GraalVM is a powerful version of the JDK that offers AOT native image compilation. It also enables integration between multiple programming languages using the Truffle framework. With Truffle, programs written in different supported languages can work together easily. For instance, a JavaScript program can call Ruby methods and share data without duplicating it.

Compiler: GraalVM introduces the Graal JIT Compiler, a replacement for the traditional HotSpot C2 compiler.
- Written in Java, the compiler is highly modular and easier to maintain and extend than older compilers written in C++.
- Implements advanced optimizations like speculative optimizations, partial escape analysis, and inlining across multiple languages.
Polyglot Support: GraalVM uses the Truffle language implementation framework, a platform for building interpreters for various languages. Each language runtime is implemented as a Truffle interpreter. Truffle is a framework for building language interpreters. When combined with the Graal compiler, these interpreters are automatically optimized with just-in-time (JIT) compilation, enabling programs running on them to achieve performance comparable to standard Java.
Native Image: Provides an AOT compilation feature called native image. Transforms JVM-based applications into standalone executables with reduced startup times and memory footprints.
Implementation Base: GraalVM builds on top of the OpenJDK HotSpot JVM. It replaces components like the compiler while retaining others, such as the garbage collector, class loader, and bytecode interpreter.

Azul JDK

Azul Systems provides two JDK distributions: Zulu and Zing.

Zulu:

A fully open-source JDK based on OpenJDK, claimed to be the world’s most secure and stable build of OpenJDK.
Delivers stabilized security builds.
Legacy Production Support for Java versions that are end of life by OpenJDK and Oracle including Java 6 & 7 (but it has to be paid).

Zing (Azul Platform Prime):

A commercial JDK designed for extreme performance and low-latency requirements.
The Falcon JIT compiler enhances performance through advanced speculative optimizations. Built on LLVM, it executes Java code 20–50% faster.
ReadyNow! Technology: It allows the JVM to be restored from a snapshot of another JVM, enabling faster startup times and optimized performance.
The C4 Garbage Collector: A pauseless, generational GC. It eliminates most stop-the-world pauses, allowing applications to run smoothly during garbage collection.

Use-Cases

Choosing a JVM doesn’t have to be a grand philosophical debate—it really depends on what you need and how much effort or money you’re willing to invest. Let’s break it down.

If you’re just building something straightforward with a handful of users and don’t see the point of adding unnecessary complexity, go with OpenJDK. It’s free, dependable, and perfectly capable of handling your needs. Let’s face it, your 100 users won’t notice the difference, so why overthink it?
For the big, established enterprises out there, where your codebase is a mix of old systems (possibly older than some of your interns) and shiny new features, Oracle JDK might be worth considering. Sure, it comes with a price tag, but you’ll have dedicated support and the peace of mind that your massive, mission-critical applications are in good hands.
If you’re a fan of Java but like to keep your options open, dabbling in other languages or running cutting-edge setups with serverless architectures and microservices, GraalVM could be your match. The free Community Edition is great if you’re on a budget, but the Enterprise Edition offers powerful features if you’re ready to splurge a little for performance.
Not an Oracle fan? Don’t need fancy bells and whistles? Enter Zulu, the practical, no-nonsense choice for developers who just want a solid, affordable JVM alternative. It’s reliable, efficient, and does the job without any drama—perfect for those who like to keep things simple.
And for those working with massive, memory-hungry applications that demand peak performance, Zing is the way to go. It’s designed for situations where every ounce of garbage collection optimization matters. Yes, it’s a premium option, but when your application has to run fast and smooth, the investment can make all the difference.

And here you can see the algorithm, but don’t take it too seriously!

Final Thoughts

The JVM you choose should align with your project’s size, complexity, and budget. For small projects, OpenJDK or Zulu are often more than enough. For larger enterprises or performance-focused teams, investing in solutions like Oracle JDK, GraalVM, or Zing can pay off. Explore your options, and pick what works best for your needs!

Conclusion

The JVM has evolved significantly since its debut with JDK 1.0, expanding from a single implementation to a diverse ecosystem of high-performance, specialized VMs. Building your own JVM or JDK requires deep knowledge of the Java specifications, low-level programming expertise, and a commitment to testing and optimization. If you’re genuinely considering this challenge, I must admit, I’m impressed! Best of luck! It’s a journey that will require immense dedication and effort!

AspectJ vs Spring AOP vs Quarkus: Aop Showdown

Natan Tesfaye — 2024-11-15T00:00:00.000Z

Overview

Imaging you’re developing a simple program, and you want to log every time a method is called. One option to do that is calling the logger in every method.

// Without AOP
public class UserService {
    public void createUser(String name) {
        System.out.println("Logging: createUser method called with name: " + name); // Logging logic
        System.out.println("User created: " + name);
    }
}

public class ProductService {
    public void addProduct(String product) {
        System.out.println("Logging: addProduct method called with product: " + product); // Logging logic
        System.out.println("Product added: " + product);
    }
}

But that is inefficient, and repetitive. Instead, We can use logging aspect to handle all the logging when methods are called.

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class LoggingAspect {

    // Pointcut: Matches all methods in UserService and ProductService classes
    @Pointcut("execution(* *Service.*(..))")
    public void userServiceMethods() {}

    // Logging logic before the method execution
    @Before("userServiceMethods()")
    public void logUserService() {
        System.out.println("Logging: createUser method called.");
    }

    @Before("productServiceMethods()")
    public void logProductService() {
        System.out.println("Logging: addProduct method called.");
    }
}

public class UserService {
    public void createUser(String name) {
        System.out.println("User created: " + name); // Core business logic
    }
}

public class ProductService {
    public void addProduct(String product) {
        System.out.println("Product added: " + product); // Core business logic
    }
}

When developing an application, you often encounter situations where certain functionality needs to be applied across various parts of the system—such as logging, error handling, or security. These are known as cross-cutting concerns, and traditionally, you’d end up repeating code across multiple classes or methods, leading to poor maintainability and scattered logic. This is where Aspect-Oriented Programming (AOP) comes in, allowing you to modularize these concerns separately from your business logic, making your code cleaner and easier to manage.

So, the purpose of Aspect-Oriented Programming (AOP) is to reduce code scattering and code tangling, improving the overall organization and maintainability of your code.

Code Scattering: This occurs when the same functionality (like logging or security) is implemented repeatedly in multiple places across the codebase. AOP reduces scattering by centralizing such functionalities into modular components (aspects), so they only need to be defined once and can be applied wherever necessary.

Code Tangling: This happens when multiple concerns (e.g., business logic, logging, error handling) are intertwined within the same code, making it difficult to understand or modify. AOP resolves this by separating concerns into distinct modules, allowing the business logic to remain clean and focused. By addressing these issues, AOP enhances code modularity, making the codebase easier to manage, extend, and test.

Key Concepts in AOP

Join Point: A point during the execution of a script.

Pointcut: A regular expression that matches join points.

Advice: Action Taken by an aspect at a join point.

Aspect: A modularization of concerns that cuts across multiple objects.

Weaving: process of integrating aspects (modularized cross-cutting concerns) into the main application code at Join Points.

AspectJ

AspectJ is an aspect-oriented extension to Java and one of the most robust implementations of AOP. It allows developers to modularize cross-cutting concerns and works seamlessly with any Java class. AspectJ supports compile-time, post-compile-time, and load-time weaving.

Example: Logging with AspectJ

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class LoggingAspect {

    // Pointcut: Matches methods in classes under the package 'service'
    @Pointcut("execution(* service..*(..))")
    public void serviceMethods() {}

    // Logging logic applied before method execution
    @Before("serviceMethods()")
    public void logMethodExecution() {
        System.out.println("Logging: A service method was called.");
    }
}

public class UserService {
    public void createUser(String name) {
        System.out.println("User created: " + name); // Core business logic
    }
}

AspectJ offers flexibility with annotations or an XML-based configuration for managing aspects, making it highly versatile in various Java projects. AspectJ is framework-independent. It works directly with raw Java classes, making it suitable for standalone applications or projects not tied to any ecosystem.

AspectJ provides an extensive and fine-grained join point model, allowing developers to intercept and manipulate almost any point in a program’s execution. This includes Method executions, Constructor calls, etc.

Spring AOP

Spring AOP is a lightweight implementation of AOP, designed specifically for use with Spring’s IoC (Inversion of Control) container. It supports runtime weaving and is particularly well-suited for managing cross-cutting concerns in Spring-based applications.

Example: Logging with Spring AOP

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.aspectj.lang.annotation.Pointcut;
import org.springframework.stereotype.Component;

@Aspect
@Component
public class LoggingAspect {

    // Pointcut to match all methods in the service package
    @Pointcut("execution(* com.example.service..*(..))")
    public void serviceMethods() {}

    // Before advice to log method execution
    @Before("serviceMethods()")
    public void logBeforeMethod() {
        System.out.println("Logging: Service method invoked.");
    }
}

@Component
public class UserService {
    public void createUser(String name) {
        System.out.println("User created: " + name);
    }
}

Spring AOP integrates easily into Spring projects and relies on proxies for weaving, offering developers a clean and Spring-friendly approach to AOP.

Quarkus

Quarkus, known for its Kubernetes-native Java stack, also supports AOP but in a simplified and efficient way compared to traditional implementations.

Example: Logging with Quarkus AOP

import io.quarkus.arc.Arc;
import javax.annotation.Priority;
import javax.interceptor.AroundInvoke;
import javax.interceptor.Interceptor;
import javax.interceptor.InvocationContext;

@Interceptor
@Priority(1)
@Logging
public class LoggingInterceptor {

    @AroundInvoke
    public Object logInvocation(InvocationContext context) throws Exception {
        System.out.println("Logging: Method called - " + context.getMethod().getName());
        return context.proceed();
    }
}

// Custom annotation to apply the interceptor
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
@InterceptorBinding
public @interface Logging {}

@Logging
public class UserService {
    public void createUser(String name) {
        System.out.println("User created: " + name);
    }
}

Quarkus brings AOP into the modern world of cloud-native, containerized Java applications. It uses build-time weaving to reduce the runtime overhead and optimize performance, which is crucial for microservices running in environments like Kubernetes. By leveraging CDI (Contexts and Dependency Injection), Quarkus simplifies the use of AOP, making it an excellent choice for developers building lightweight, fast, and highly performant Java applications in the cloud.

Final Note

AspectJ: Best suited for complex, large-scale enterprise applications where flexibility and deep integration into the application’s lifecycle are required. The learning curve is steeper, and performance may be a consideration, but its capabilities in fine-grained join points and weaving techniques make it ideal for scenarios where AOP is deeply integrated into the system’s architecture.
Spring AOP: Excellent for Spring-based applications where developers are looking for a lightweight, simple solution to apply cross-cutting concerns. It’s great for common needs such as logging and transaction management, but it’s limited to Spring-managed beans and doesn’t support all the advanced weaving options that AspectJ offers.
Quarkus AOP: A perfect choice for cloud-native, containerized applications. If you’re building microservices or applications with performance-critical requirements, Quarkus is optimized for minimal runtime overhead and integrates well with modern development workflows like Kubernetes.

Source

[What is AOP? ](https://www.spiceworks.com/tech/devops/articles/what-is-aop/)
[Spring AOP Documentation](https://docs.spring.io/spring-framework/reference/core/aop.html/)
[AspectJ in Action - Manning](https://www.baeldung.com/aspectj)

The Unit of a test

Erik Bakker — 2024-11-15T00:00:00.000Z

Have you ever heard someone about writing a test for a class or for a method? I bet you have. Yet this may be an indication of something being wrong. In this post, we’ll discuss a common misconception about unit testing, what the impact of that misconception can be, and what to do instead.

The misconception is that the term unit in unit testing refers to a structural unit, such as a class or a method. But this should not be the intention. Instead, the intention should be to test a unit of behaviour.

Let’s look at an almost trivial example. Suppose we have a UserService that can retrieve users from a repository, but which has to map between two different domains. It would use following two classes:

public class UserService {

	private final PeopleRepository peopleRepository;

	public UserService(PeopleRepository peopleRepository) {
		this.peopleRepository = peopleRepository;
	}

	public User getUserById(String id) {
		Person person = peopleRepository.getPersonById();
		return UserMapper.fromPerson(person);
	}

}

class UserMapper {
	static User fromPerson(Person person) {
		... map from person to user ...
	}
}

Now, a common mistake is that a proper unit test of the UserService requires to test it in isolation from other classes. In this case, that would mean to test the UserService without the real UserMapper, but instead with a test double for the UserMapper.

In this code, that’s hard, because there’s no way to make UserService use a test double. This may get people to modify the code to make replacement of the UserMapper possible:

public class UserService {

	private final PeopleRepository peopleRepository;
	private final UserMapper userMapper;

	public UserService(PeopleRepository peopleRepository, UserMapper userMapper) {
		this.peopleRepository = peopleRepository;
		this.userMapper = userMapper;
	}

	public User getUserById(String id) {
		Person person = peopleRepository.getPersonById();
		return userMapper.fromPerson(person);
	}

}

public class UserMapper {
	User fromPerson(Person person) {
		... map from person to user ...
	}
}

We’ve changed the static invocation of fromPerson to a method call on an instance of UserMapper, which we added as a field and to the constructor of PeopleService.

Some people would exclaim: "See, this is why static methods are bad! They make testing hard!". Now, a test can be written:

class UserServiceTest {

	@Mock
	UserMapper userMapper;

	@Mock
	PeopleRepository peopleRepository;

	@Test
	void testGetById() {
		UserService userService = new UserService(peopleRepository, userMapper);
		Person testPerson = new Person();
		when(peopleRepository.getPerson("123")).thenReturn(testPerson);
		User testUser = new User();
		when(userMapper.fromPerson(testPerson)).thenReturn(testUser);

		User user = userService.getUserById("123");

		assertEquals(testUser, user);
	}

}

Now we managed to test this class 'in isolation', and some would say all is well. But all is not well, this is not a good unit test.

This test is now tied to specific implementation details, which makes it hard to maintain, and prone to requiring changes when the implementation (but not behaviour!) of the UserService changes. The whole existence of the UserMapper is an implementation detail, as is the method fromPerson. We should be able to refactor this whole class away, and for example create a private mapPersonToUser method right within the UserService. Such a refactoring should not require a change of the test.

(Martin Fowler drew diagrams similar to the ones below, that illustrate (Jay Fields' concepts of Solitary and Sociable Unit tests:

In our example, we could draw it with the following classes

Note that we took the solitary unit test approach here. The disadvantage is that now we’ve tied the test to the interface between the UserService class and it’s collaborator UserMapper.

If we would have made a sociable unit test instead, that would not have happened. We could have used the original code with the static method invocation of UserMapper.fromPerson, and our test would look like this:

class UserServiceTest {

	@Mock
	PeopleRepository peopleRepository;

	@Test
	testGetById() {
		UserService userService = new UserService(peopleRepository);
		when(peopleRepository.getPerson("123")).thenReturn(testPerson);
		User user = userService.getUserById("123");
		assertEquals("123", user.id);
	}

}

Our test is now simpler and no longer tied to the interface of UserMapper. As a diagram, it would now look like the following:

Here, we drew the dashed green line around both the UserService and the UserMapper, which together provide the unit of behaviour we’re trying to test.

Some final considerations. Maybe you also want to have tests for UserMapper, because it may have complex behaviour. That’s fine. There’s nothing wrong with the tests for the UserService using the real UserMapper, and there also being additional tests that provide better coverage of UserMapper.

In our code, we did use mocks for UserRepository, because we considered that a different unit of behaviour. Or maybe because it’s slow to test or modifies shared state. Unfortunately there are no hard rules for what exactly is a unit of behaviour, certainly not one that’s as easy as the structural unit counterpart of 'one class' or 'one method'. Picking a suitable unit of behaviour requires some taste. One thing you could take into consideration is whether a class really exposes a public interface (not in the technical sense of public or interface, but in the conceptual sense), that includes a clear contract and is relatively stable. If it does, replacing it with a test double may make sense. But classes that merely exist as an implementation detail are best tested in a sociable way.

Java 22 vs Java 23 and the Evolution of String Templates

Francesco Scala — 2024-11-08T00:00:00.000Z

With Java 22 and Java 23, our favorite JVM language got elevated to a higher level. Many features were included in these two releases, some of which are Pattern Matching for primitive types, Unnamed variables, and Markdown language support. Let’s dive deeper into these features by looking at the bigger picture.

Pattern Matching

JEP 456: Unnamed Variables

With JEP 456 from Java 22, developers can now make use of unnamed variables in their Java code. Simply put, unnamed variables are the variables required syntactically by the language but whose values don’t add anything to the code logic.

String result = switch (expression) {
    case Integer _ -> "Integer";
    case String _ -> "String";
    default -> "Unknown";
};

Unnamed variables come in particularly handy when dealing with pattern matching in switch expressions, or inside try-catch blocks to define an exception that the developer won’t use.

JEP 455: Pattern Matching for Primitive Types

This preview feature of Java 23 enables pattern matching for primitive types. Thanks to it, developers can directly compare primitive types in pattern matching, without having to use their wrapper classes (Integer, Double, etc.).

int x = 55;
switch (x) {
    case 200 -> System.out.println("OK");
    case 404 -> System.out.println("Resource Not Found");
    case 500 -> System.out.println("Internal Server Error");
    case int k -> System.out.println("Unknown status: " + k);
}

Module Import Declarations and Simplified Main Method

JEP 476: Simplified Main Method

Reducing boilerplate code is one of the main focuses for Java 21, 22, and 23. Thanks to JEP 476, it’s now possible to import all of the packages exported by a module inside a Java file. The syntax resembles the one for importing packages:

import module java.base;

When multiple modules are imported, and a class is defined in more than one package, the developer can import the desired package to resolve the conflict:

import module java.base;
import module java.desktop;

import java.util.List;

JEP 463: Simplified Main Method Declaration

With this feature, Java enables developers to implicitly declare classes around a main method. Beginners will now struggle less to write an executable Java file, and the more experienced developers will benefit from the reduced boilerplate code.

void main() {
    System.out.println("Hello, World!");
}

JEP 477: Enhanced Main Method

JEP 477 also contributes to the simplification of the main method. Implicitly declared classes now implicitly import the java.base module and java.io.IO package. This new package includes the methods:

public static void print(Object obj);
public static void println(Object obj);
public static void readln(String prompt);

Therefore, a simple Java file with a main method will now look like:

void main() {
    String city = readln("Please enter a city: ");
    print("City: ");
    println(city);
}

Flexible Subclass Constructor

JEP 447: Flexible Superclass Constructors

As of before Java 22, subclass constructors should always include the call to the superclass constructor as the first statement. Any validation or initialization before the call to the superclass constructor would throw a compilation error.

JEP 447 is the first attempt of Java to change this constraint. Developers can now add logic in subclass constructors before the super() call. However, class fields cannot be initialized.

public class SubClass extends SuperClass {

    public SubClass(List data) {
        String element;
        if (data != null && !data.isEmpty()) {
            element = data.get(0).toLowerCase();
        } else {
            element = "";
        }

        super(element);
    }
}

Records can also benefit from this feature:

public record Email(String local, String domain) {

    public Email(String fqda) {
        Objects.requireNonNull(fqda);
        var parts = fqda.split("@");
        if (parts.length != 2) {
            throw new IllegalArgumentException("Invalid email format");
        }

        this(parts[0], parts[1]);
    }
}

JEP 482: Enhanced Subclass Constructors

JEP 482 extends the possibilities of JEP 447 by allowing developers to initialize class fields inside the subclass constructor before the superclass constructor call.

class Super {

    Super() {
        overriddenMethod();
    }

    void overriddenMethod() {
        System.out.println("hello");
    }
}

class Sub extends Super {
    final int x;

    Sub(int x) {
        this.x = x;
        super();
    }

    @Override
    void overriddenMethod() {
        System.out.println(x);
    }
}

String Templates… What happened?

String Templates were supposed to be included in Java 23. However, that didn’t happen, and the only way to use those in Java is by switching back to Java 22 with Preview Features enabled. Let’s have a look at what String Templates are, the issues that were raised by the community, and what’s going to happen next.

Introduction

String Templates are Java’s solution to string interpolation. They couple literal text with embedded expressions and template processors to produce specialized results.

String customerName = "Java Duke";
String phone = "555-123-4567";
String address = "1 Maple Drive, Anytown";
String json = STR."""
{
    "name": "\{customerName}",
    "phone": "\{phone}",
    "address": "\{address}"
}
""";

In order to define a template, the developers need to specify the abstract processor they want to use. Java provides three of them: STR, FMT, and RAW.

STR: Processes the template and returns a String.
FMT: Processes the template, together with the formatting rules specified, and returns a String.
RAW: Returns an instance of StringTemplate. Especially useful when creating a custom String Template Processor.

Design Issues

Several design issues were raised a few weeks before the Java 23 release:

Coupling: Template capture and processing are now tightly coupled when the two things should be separated and composable.
$ vs \{}: Some developers complained about the choice of the character for string interpolation. Some would have preferred the dollar sign, as it is used in other programming languages like JavaScript. However, this complaint felt more like syntactic sugar than an actual issue. Future versions of String Templates will most likely stick with \{}.
Explicit processor abstraction: Java already has a way of abstracting the implementation of a behavior given a desired input and output: methods. The whole setting of the abstract processors to process String Templates felt unnecessary. Eventually, String.format() could be extended to accept a parameter with type StringTemplate, and produce the desired output.

Future of String Templates

As of today, there is no clear news on when String Templates will be back again.

Other (cool) features

Java 22 and 23 bring several other exciting features to the table, enhancing the language’s capabilities and improving developer productivity. Some of them are listed below:

JEP 467: JavaDoc using Markdown language.
JEP 462: API for structured concurrency.
JEP 464: Scoped Values.

Maven vs Gradle Navigating the World of Java Build Tools

Giovanni Barbaro — 2024-11-01T00:00:00.000Z

This is the first of a series of articles for Lunatech’s Java over Java series. A seasonal occurrence where we pick a topic for a month and hold a series of presentations and articles about it. This season’s topic will be "Java vs the world", follow the link to see other articles from this series.

Introduction

Building tools have become part of our daily life as software engineers. There is almost no project that doesn’t make use of one, and there is no Java developer that hasn’t been exposed to Maven at least once. With it being such a commonly used tool one would assume that every Java developer knows their building tool of choice inside-out, but usually the exact opposite is true! (or at least it was for me!)

In today’s article we’ll take a look at the 2 most prominent building tools of recent years, Maven and Gradle, and try to understand how both of them works, their differences and how to customize your build in each system!

Disclaimer: We’ll be using Kotlin for our examples in Gradle

Tools overview

First of all, let’s take a quick look at both tools

	Maven	Gradle
Popularity	Most popular Java building tool by far	Popular in Android ecosystem and with Kotlin projects
Language	XML	Groovy/Kotlin
Philosophy	Convention over Configuration	Configuration over Convention
Build Definition	All in one file (pom.xml)	Defined in multiple files (settings, build, properties)

Maven

Gradle

Popularity

Build? Settings? Properties?

As discussed in the previous chapter, there are quite a few files that can be used to define a gradle build process. Here’s a quick overview for each one of them:

settings.gradle.kts: Script that takes place before any build script. It is required when working with multiple modules/projects, as it is responsible for setting up their hierarchy.
build.gradle.kts: Describes the build for a single gradle project. It holds its dependencies, plugins and available tasks
gradle.properties: It’s a normal .properties file, its values can be easily used in the build.gradle.kts script and, to a lesser extent, in the setting.gradle.kts. It is entirely optional.

To give a little example of the three files at work, we could have the current setup:

Our gradle.properties

whoToGreet=Lunatech

Bottom of build.gradle.kts

val whoToGreet: String by project // Will get the value from the gradle.properties
println("Hello $whoToGreet from Build")

Bottom of settings.gradle.kts

val whoToGreet: String by settings // Will get the value from the gradle.properties
println("Hello $whoToGreet from Settings")

When running gradle tasks you’ll see something like this:

Hello Lunatech from Settings

> Configure project :
Hello Lunatech from Build

> Task :tasks
...

This shows us that the value whoToGreet was fetched by the gradle.properties file, and that the settings.gradle.kts file was executed before the gradle.build.kts file.

Tools Lifecycle

Besides syntactical differences, the two tools have very different approaches to their lifecycles as well. Their documentation is very well-made, and as such we will make use of it in the following paragraphs where we try to point out their differences.

Maven

Maven has what I like to call a "fixed lifecycle". It has a predefined list of phases that have to be executed in order. Here are the most popular phases, but there are quite a few more:

validate
compile
test
package
verify
install
deploy

When running a maven build you can target a specific phase, for example mvn package will target the package phase. When a phase is targetted, all the phases before it will also be executed, so in our example validate, compile and test would also be executed before package.

What happens in a specific phase is defined by plugins. A plugin in Maven is a piece of configuration that allows to tie some script execution to a specific phase. Every time a phase is being processed maven will check which plugins have mapped their executions to that specific phase and will execute them.

To demonstrate this behaviour we can use an extremely simple plugin, echo-maven-plugin. This plugin allows us to print any message we want during the build process.

We can add the following block to our pom.xml


    
    
        
            com.github.ekryd.echo-maven-plugin
            echo-maven-plugin
            1.3.2
            
                
                    echo-test
                    test
                    
                        echo
                    
                    
                        Hello world at test
                    
                
                
                    echo-compile
                    compile
                    
                        echo
                    
                    
                        Hello world at compile
                    
                
                
                    echo-validate
                    validate
                    
                        echo
                    
                    
                        Hello world at validate

For this plugin, we’re defining 3 different executions that will occur at 3 different phases: validate, compile and test. Running mvn test should return something like this:

[INFO] --- echo:1.3.2:echo (echo-validate) @ maven_demo ---
[INFO] Hello world at validate
[INFO]
[INFO] --- resources:3.3.1:resources (default-resources) @ maven_demo ---
[INFO] Copying 0 resource from src/main/resources to target/classes
[INFO]
[INFO] --- compiler:3.13.0:compile (default-compile) @ maven_demo ---
[INFO] Recompiling the module because of changed source code.
[INFO] Compiling 2 source files with javac [debug target 17] to target/classes
[INFO]
[INFO] --- echo:1.3.2:echo (echo-compile) @ maven_demo ---
[INFO] Hello world at compile
[INFO]
[INFO] --- resources:3.3.1:testResources (default-testResources) @ maven_demo ---
[INFO] skip non existing resourceDirectory /Users/giovannibarbaro/Desktop/Personal/maven_gradle_demo/maven_demo/src/test/resources
[INFO]
[INFO] --- compiler:3.13.0:testCompile (default-testCompile) @ maven_demo ---
[INFO] Recompiling the module because of changed dependency.
[INFO]
[INFO] --- surefire:3.2.5:test (default-test) @ maven_demo ---
[INFO]
[INFO] --- echo:1.3.2:echo (echo-test) @ maven_demo ---
[INFO] Hello world at test

We can see how the three plugin executions were processed not in the order that they were defined, but in the lifecycle pre-determined order. It’s also possible to see how some default plugins will run even if not defined in our pom.xml, as they’re pre-configured by maven itself.

Gradle

In Gradle, there is no strict "fixed lifecycle" as in Maven. Instead, Gradle relies on a task-based model where tasks can be defined with custom actions and dependencies. Each task has a specific purpose, and you can control the order and execution of tasks through dependencies or by explicitly defining task relationships.

Gradle by default doesn’t come with any useful task, but thanks to the Java plugin a few key tasks are added to our arsenal:

assemble
build
check
clean
compileJava
test

When you run a Gradle build, you can specify a particular task, for example, gradle build. Gradle will run all necessary dependent tasks, so in this example, compileJava, test, and assemble would also execute as dependencies of build.

To experiment once again with this workflow, we can try to print some "Hellos". Let’s start by adding the following script at the bottom of our build.gradle.kts

val compileJava = tasks.named("compileJava")
val assemble = tasks.named("assemble")
val test = tasks.named("test")

val helloWorldCompile = tasks.register("helloCompile") {
    doFirst { println("Hello from compile") }
    dependsOn(compileJava)
}

tasks.register("helloAssemble") {
    doFirst { println("Hello from assemble") }
    dependsOn(assemble)
}

tasks.register("helloTest") {
    doFirst { println("Hello from test") }
    dependsOn(test)
}

Now we have registered 3 new tasks to our Gradle configuration: helloCompile, helloAssemble, helloTest When executing any of these tasks, Gradle will first resolve their dependencies and then execute them.

As an example, this should be the output of gradle helloAssemble --info

> Task :compileJava UP-TO-DATE
:pluginDescriptors (Thread[Execution worker Thread 4,5,main]) started.

> Task :pluginDescriptors
:processResources (Thread[Execution worker Thread 4,5,main]) started.

> Task :processResources NO-SOURCE
:classes (Thread[Execution worker Thread 4,5,main]) started.

> Task :classes UP-TO-DATE
:jar (Thread[Execution worker Thread 4,5,main]) started.

> Task :jar
:assemble (Thread[Execution worker Thread 4,5,main]) started.

> Task :assemble
:helloAssemble (Thread[Execution worker Thread 3,5,main]) started.

> Task :helloAssemble
Hello from assemble

We can see how :assemble and all of its dependencies had to be executed before :helloAssemble itself is processed.

One important thing to note is that by defining the tasks as we did, they will only ever be processed when called. If we want to define a task A that runs before/after another task B does, then we need change task B as in the following example

// :helloWorldCompile -> task A
// :compileJava -> task B
compileJava {
    // If you want for task A to run first
    dependsOn(helloWorldCompile)
    // If you want for task A to run last
    finalizedBy(helloWorldCompile)
}

Gradle plugin

Gradle also has the concept of plugin. We won’t be exploring it too much in this article, but it is important to know that it differs quite substantially from Maven’s plugin.

A Gradle plugin is highly flexible and allows dynamic changes in the build file. It adds tasks, configurations, or custom logic directly to the build.gradle file, which can modify the build’s behavior at different stages.

// Not functional code, only here to show general structure
abstract public class GradlePluginExample implements Plugin {

    @Override
    public void apply(Project project) {
        project.getPlugin().apply(JavaPlugin.class);
        project.getDependencies().add("implementation", "plugin:lunatech:1.9.93");

        var helloWorld = project.getTasks().register("helloWorld", (task) -> {
            System.out.println("Hello World!");
        });

        var compileJava = project.getTasks().getByName("compileJava");
        compileJava.finalizedBy(helloWorld);
    }
}

We can see how from the plugin’s apply method we can configure everything we could normally access from the build.gradle.kts. So, while we could limit ourselves to just define a set of tasks (which would make it similar to a Maven plugin), it has the full capabilities that are normally reserved to a build file.

Customizing the build cycle

As we’ve seen, customizing the build lifecycle can easily be done with both tools. But while Gradle tasks allow for custom code to be executed at any point of the build pipeline, maven relies on pre-packaged scripts in the form of plugins that will then be executed at specific phases.

Scenario

We have a very small Java application at app.Test that reads a file from its resources and prints it out. It looks something like this:

public class Test {
    public static void main(String[] args) {
        System.out.println("Hello world");

        var inputStream = Test.class.getResourceAsStream("/java_vs_java.txt");
        var bufferedReader = new BufferedReader(new InputStreamReader(inputStream));
        var result = bufferedReader.lines().collect(Collectors.joining("\n"));
        System.out.println(result);
    }
}

The kicker is, the file java_vs_java.txt does not exist, and we want to generate it during the build lifecycle.

Maven

Which options do we have if we’re working with Maven, and we can’t find the plugin that satisfies our needs?

There are 2 routes that we con follow in this scenario:

Create our own plugin
Leverage exec-maven-plugin, a plugin that allows to run custom code during the build lifecycle

Today we’ll explore the second option as it is the one that requires the least setup

The exec-maven-plugin plugin can run either Java classes or external programs. We’ll use it with a Java class defined in our project to further minimize the needed setup.

We can create a simple Java application at build.GenerateFile that will take care of generating the file that we need:

public class GenerateFile {

    public static void main(String[] args) throws IOException {
        String destFile = args[0];
        String content = args[1];

        System.out.println("Creating file " + destFile);
        System.out.println("Content is " + content);

        var file = new File(destFile);
        file.getParentFile().mkdirs();
        file.createNewFile();

        var fileWriter = new FileWriter(file);
        fileWriter.write(content);
        fileWriter.close();
        System.out.println("File created: " + file.getAbsolutePath());
    }
}

Since we want to make this application reusable, we parametrized the destination file and its content. Now that we’ve defined the application, we can call it as follows in our pom.xml


    
        
            org.codehaus.mojo
            exec-maven-plugin
            3.4.1
            
                
                    generate-custom-resource
                    compile
                    
                        java
                    
                    
                        build.GenerateFile
                        
                            
                                ${project.build.outputDirectory}/java_vs_java.txt
                            
                            Maven was able to create me!!

Let’s take a closer look at some of the configurations here:

phase=compile: This means that the code will run during the compile phase of the fixed lifecycle
goal=java: This will specify that we’re running a Java application - More info here
mainClass=build.GenerateFile: This points the plugin to the application that we want to run
arguments: Here we pass the destination file and its content

Lastly, to see if the application is working, let’s run java -cp ./target/maven_demo-1.0-SNAPSHOT.jar app.Test. We should see this:

Hello world
Maven was able to create me!!

One thing that is important to notice is that we ran the application after the compile phase. If we tried to use an earlier phase like validate we would have been met with a java.lang.ClassNotFoundException: build.GenerateFile.
This happens because the GenerateFile itself hasn’t been compiled yet, so the maven-exec-plugin won’t be able to execute it.

If you need to execute an application before the compile phase, consider moving the GenerateFile application to another module or, at that point, consider investing the time to create a custom plugin.

Gradle

Since gradle is intrinsically more configurable, creating custom executions is more straight forward. Given the same app.Test, we can achieve the file generation by adding this to our build.gradle.kts:

val generateFile = tasks.register("generateFile") {
    doFirst{
        val file = layout.buildDirectory.file("resources/main/java_vs_java.txt").get().asFile
        val content = "Gradle was able to create me!!"

        file.parentFile.mkdirs()
        file.createNewFile()
        file.writeText(content)
    }
}

assemble {
    dependsOn(generateFile)
}

Conclusion

Today we took a deep dive into Maven’s and Gradle’s build lifecycles, how they differ and how to leverage both to achieve your ideal build pipeline.
There is a lot of room to go even deeper into these topics, like understanding how to better use the multi-module/project capabilities of both tools or how to create custom plugins, but that will be the topic for another article!

Why the Women Automotive Network Summit Should Be on Your Radar: Diversity, Inclusion and Networking

2024-10-18T00:00:00.000Z

The Women Automotive Network (WAN) Summit Europe kicked off on October 8, 2024, in Stuttgart, Germany, focusing on the importance of diversity and inclusion in the automotive industry. Veronika Shamova and I, Kateryna Olenkovska, proudly represented Lunatech’s automotive expertise at the summit 😄 Veronika is a Site Reliability Engineer, and I am a Quality Assurance Specialist. Together, we are working with CARIAD to develop a Software Labeling Stack for creating and processing ground truth data. This summit was a great opportunity to connect business and software, reminding us that teamwork is just as important as coding.

Let’s take a closer look at the summit’s purpose

The summit aimed to unite leading women in the automotive sector from companies like Porsche, Volkswagen, Volvo, and Jaguar, and more. The big goal is to build a strong network and share experiences that helped these women succeed. The WAN community has grown to 40,000 members worldwide and is continuing to expand.

A key focus of the summit is mentorship, which is essential for career growth. Members can choose to be mentors or mentees, helping each other navigate their professional journeys.

So, what happened at the conference?

In the morning, we were welcomed at the Forum am Schlosspark in Ludwigsburg, a lovely venue that accommodated all 500 attendees. An additional 500 participants joined the summit online. After registering and enjoying some coffee, we were invited into a spacious conference hall filled with round tables.

The event began with a welcome speech from Micha Goebig, CEO and Founder of Go Big Coaching and Communication LLC. She shared insights about the community and stressed the importance of networking. "Don’t be shy to say hello to the woman next to you!" Micha encouraged us. With that, the summit officially began!

Let’s look at some highlights from the talks

From Linda Jackson, CEO of Peugeot, we gained firsthand insight into what it takes to climb the corporate ladder. With 45 years of experience in the automotive industry, Linda emphasized the importance of confidence, perseverance, learning from mistakes, and growing alongside a trusted team. She also reminded us that on this long journey to the top, it’s crucial to pause and appreciate the view.

Barbara Frenkel, Member of the Executive Board for Procurement at Porsche AG, delivered an inspiring talk titled “Follow Your Dream – My Path to the Porsche Executive Board.” The key takeaways from her presentation were to work hard, trust the process, and let your colleagues be your references. And who knows? One day, you might get a call from Porsche and be invited to become one of the nine board members!

FLEX panel group initiated a discussion on how we make our business decisions. It turns out that these choices are rarely based solely on facts; instead, they often involve a mix of intuition and facts. It’s essential to trust your gut feeling and be willing to take risks to explore uncharted territories.

After lunch, we were ready to dive into new topics. This time, it was a workshop led by Sara Gallian, a SDV Program Manager at the Eclipse Foundation, which Lunatech is part of. This foundation creates a business-friendly environment for open-source software collaboration and innovation.

The workshop, titled “Open Source for All: Democratising and Transforming the Automotive Software Industry in a Code-First Way,” highlighted the challenges open-source contributors face. These challenges include language barriers, cultural differences, years of experience and even unreliable internet connections.

We looked at charts showing cultural differences across countries, prompting us to think about our own experiences.

So, how can we enhance diversity in open source? We need to be more mindful and inclusive, making sure open source is a welcoming space for everyone, especially underrepresented groups. A typical open-source contributor can be anyone – it’s not just limited to a white, straight, cisgender man in his 40s! 😄

During the panel discussion, we learned that the industry is evolving, with women’s presence steadily growing and strong allies supporting diversity and inclusion at every turn. Looking ahead, there’s even more growth planned, with a goal to increase the representation of women in leadership positions from 20% to 25% by 2030. This goal is set to be achieved by enhancing mentorship and sponsorship networks within the industry, and WAN serves exactly that purpose.

Conclusion

After a day packed with insights, we wrapped it up with a fun after-party, where networking flowed just as smoothly as the Aperol Spritz! While networking can be tough and sometimes intimidating, it’s definitely rewarding when you find those genuine connections that help you grow personally and professionally. We left feeling energized, with several connections in LinkedIn and excited for what’s to come.

All in all, as for someone with a software engineering background, this summit was a unique experience, it was different from typical software conferences. Instead of focusing on technical skills, it emphasized sharing career stories, taking on new challenges, and never giving up. Seeing so many successful women in the automotive industry was inspiring. The focus on building a strong community made the event even better. I enjoyed the talks and gained valuable insights and I’m looking forward to coming back next year!

Links

If you’re interested in learning more and want to experience a bit of the conference atmosphere, check out the recorded talks through this link!

Also, you can learn more about Women Automotive Network and Eclipse Foundation here.