Technical Blog | Olivier Page

Angular for experts: modern architecture and the latest features

Wed, 02 Sep 2026 00:00:00 GMT

Angular has changed a lot in the last few versions. If you last wrote an app with NgModule, *ngIf, and @Injectable constructors, much of that is now optional. This guide covers what a modern, expert-level Angular codebase looks like today.

flowchart TD
    C[Component] --> S[Signals]
    C --> T[Template]
    T --> CF[Control flow]
    T --> DF[Defer]
    C --> I[inject services]
    I --> H[HttpClient / resource]
    C --> R[Router]
    R --> LZ[Lazy loading]
    R --> FG[Functional guards]

Standalone components

NgModule is now optional. Components, directives, and pipes declare their own dependencies with imports, and you wire the app with provide* functions.

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

@Component({
  selector: 'app-user-card',
  standalone: true,
  imports: [],
  template: `
    <div class="card">
      <h3>{{ name() }}</h3>
      <button (click)="select.emit(id())">Select</button>
    </div>
  `,
})
export class UserCardComponent {
  readonly id = input.required<number>()
  readonly name = input.required<string>()
  readonly select = output<number>()
}

Signals: the reactivity core

Signals replaced most of the old ChangeDetectionStrategy ceremony. They are the foundation for inputs, outputs, and derived state.

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

@Component({ /* ... */ })
export class CounterComponent {
  readonly count = signal(0)
  readonly double = computed(() => this.count() * 2)

  constructor() {
    effect(() => console.log('count is now', this.count()))
  }

  increment() {
    this.count.update((n) => n + 1)
  }
}

Modern two-way binding uses model(), and queries use viewChild / contentChild returning signals:

readonly value = model(0)
readonly list = viewChild.required(ElementRef)

For asynchronous data, resource() replaces the manual "loading state + fetch" dance:

import { resource, signal } from '@angular/core'

export class UserListComponent {
  readonly search = signal('')

  readonly users = resource({
    request: () => ({ q: this.search() }),
    loader: ({ request }) => fetchUsers(request.q),
  })
}

resource() exposes value(), status(), isLoading(), and error(), so the template can react to every loading phase.

Built-in control flow and deferred loading

The old *ngIf / *ngFor structural directives are now built-in blocks that read more like plain templates.

@if (user(); as u) {
  <p>Hello {{ u.name }}</p>
} @else {
  <p>Not signed in</p>
}

@for (item of items(); track item.id) {
  <li>{{ item.label }}</li>
} @empty {
  <li>Nothing here</li>
}

@switch (status()) {
  @case ('ok') { <span>OK</span> }
  @case ('error') { <span>Error</span> }
  @default { <span>Unknown</span> }
}

Load heavy pieces only when needed with @defer:

@defer (on viewport) {
  <app-heavy-chart />
} @placeholder {
  <p>Chart appears here…</p>
} @loading (minimum 200ms) {
  <p>Loading…</p>
}

Zoneless change detection

You can now drop Zone.js entirely. Provide zoneless detection at bootstrap and rely on signals to tell Angular what changed.

import { bootstrapApplication } from '@angular/platform-browser'
import { provideZonelessChangeDetection } from '@angular/core'

bootstrapApplication(AppComponent, {
  providers: [provideZonelessChangeDetection()],
})

Zoneless means less runtime overhead and fewer surprises — but it expects signal-based state and proper OnPush-friendly code.

Dependency injection with inject()

Constructor injection is replaced by the inject() function, which keeps code terse and plays nicely with functional APIs.

import { inject, Injectable } from '@angular/core'

@Injectable({ providedIn: 'root' })
export class UserService {
  readonly api = inject(ApiService)
  readonly users = this.api.getUsers()
}

Routing: functional guards and lazy loading

Guards, resolvers, and interceptors are now plain functions.

import { inject } from '@angular/core'
import type { CanActivateFn } from '@angular/router'
import type { HttpInterceptorFn } from '@angular/common/http'

// guard
export const authGuard: CanActivateFn = () => inject(AuthService).isLoggedIn()

// interceptor
export const authInterceptor: HttpInterceptorFn = (req, next) => {
  const token = inject(AuthService).token()
  return next(req.clone({ setHeaders: { Authorization: `Bearer ${token}` } }))
}

Lazy loading is per-route and per-component:

export const routes: Routes = [
  {
    path: 'admin',
    loadChildren: () =>
      import('./admin/admin.routes').then((m) => m.adminRoutes),
  },
  {
    path: 'profile',
    loadComponent: () =>
      import('./profile/profile.component').then((m) => m.ProfileComponent),
  },
]

HTTP with signals

HttpClient works directly with signals, so a GET can be a reactive value.

import { HttpClient, provideHttpClient } from '@angular/common/http'

@Injectable({ providedIn: 'root' })
export class UserService {
  private readonly http = inject(HttpClient)

  readonly users = this.http.get<User[]>('/api/users')
}

For request-scoped loading that already lives in an Observable, rxResource() wraps HttpClient directly:

import { inject, Injectable, signal } from '@angular/core'
import { HttpClient } from '@angular/common/http'
import { rxResource } from '@angular/core/rxjs-interop'

@Injectable({ providedIn: 'root' })
export class UserService {
  private readonly http = inject(HttpClient)
  readonly query = signal('')

  readonly users = rxResource({
    request: () => this.query(),
    loader: ({ request }) => this.http.get<User[]>(`/api/users?q=${request}`),
  })
}

rxResource() exposes the same value(), status(), isLoading(), and error() signals as resource().

State management with NgRx

For global state, NgRx offers a signals-based SignalStore that fits the modern zoneless, signal-driven model.

import { computed } from '@angular/core'
import { patchState, signalStore, withComputed, withMethods, withState } from '@ngrx/signals'

interface CartState {
  items: CartItem[]
}

export const CartStore = signalStore(
  withState<CartState>({ items: [] }),
  withComputed(({ items }) => ({
    count: computed(() => items().length),
    total: computed(() => items().reduce((sum, item) => sum + item.price, 0)),
  })),
  withMethods((store) => ({
    addItem(item: CartItem) {
      patchState(store, { items: [...store.items(), item] })
    },
    removeItem(id: string) {
      patchState(store, { items: store.items().filter((item) => item.id !== id) })
    },
  })),
)

Provide the store and inject it into the component:

@Component({
  selector: 'app-cart',
  standalone: true,
  providers: [CartStore],
  template: `
    <p>{{ cartStore.count() }} items — {{ cartStore.total() | currency }}</p>
    <button (click)="cartStore.addItem({ id: '1', price: 10 })">Add</button>
  `,
})
export class CartComponent {
  readonly cartStore = inject(CartStore)
}

For collections, withEntities gives a normalized, ready-to-use shape:

import { setAllEntities, withEntities } from '@ngrx/signals/entities'

export const UserStore = signalStore(
  withEntities<User>(),
  withMethods((store) => ({
    load(users: User[]) {
      patchState(store, setAllEntities(users))
    },
  })),
)

For complex asynchronous orchestration, the classic @ngrx/effects still excels; createEffect turns streams of actions into side effects.

@Injectable()
export class UserEffects {
  private readonly actions$ = inject(Actions)
  private readonly users = inject(UserService)

  loadUsers$ = createEffect(() =>
    this.actions$.pipe(
      ofType(loadUsers),
      switchMap(() => this.users.getAll().pipe(
        map((users) => loadUsersSuccess({ users })),
      )),
    ),
  )
}

SignalStore is the modern default for most state; reach for @ngrx/effects when you need advanced async flows.

A modern architecture

A clean, scalable Angular app today tends to look like this:

Standalone everything — no NgModule, explicit imports.
Signals for state — signal/computed/effect plus model/input.
inject() everywhere — composable, testable services.
Zoneless + OnPush — predictable change detection.
Functional guards/interceptors — thin, typed routing layer.
Lazy routes + @defer — fast initial load.
Feature-based folders — group by domain, not by layer.

src/app/
  auth/
    login.component.ts
    auth.service.ts
    auth.guard.ts
  orders/
    order-list.component.ts
    order.service.ts
  shared/
    ui/
      button.component.ts

Version history

A condensed timeline of the major releases and their headline changes.

Version	Release	Breaking changes / news
2.0	Sep 2016	Complete rewrite from AngularJS: TypeScript, components, DI
4.0	Mar 2017	Version jump (no 3.x); new `HttpClient`; animation package
5.0	Nov 2017	Build optimizer; `HttpClient` stable
6.0	May 2018	Angular CLI workspaces; RxJS 6; tree-shakable providers
7.0	Oct 2018	CLI prompts; CDK drag & drop and virtual scrolling
8.0	May 2019	Ivy (preview); differential loading; dynamic import for lazy routes
9.0	Feb 2020	Ivy enabled by default; TestBed improvements
10.0	Jun 2020	TypeScript 3.9; new date range picker
11.0	Nov 2020	Hot module replacement; stricter types
12.0	May 2021	View Engine removed; Sass modern API; strict mode default
13.0	Nov 2021	IE11 dropped; RxJS 7; no more `entryComponents`
14.0	Jun 2022	Standalone components (preview); typed reactive forms; `inject()`
15.0	Nov 2022	Standalone stable; `NgModule` optional; directive composition API
16.0	May 2023	Signals (preview); esbuild dev server; required inputs
17.0	Nov 2023	Built-in control flow; `@defer`; standalone default
18.0	May 2024	Zoneless (experimental); `@let` variables; signal inputs/outputs
19.0	Nov 2024	Signals stable; `resource()`/`rxResource()`; `linkedSignal`
20.0	May 2025	Zoneless change detection stable (default for new apps)
21.0	Nov 2025	Signal and zoneless refinements

Wrapping up

The move to signals, standalone components, and zoneless detection is the biggest shift in Angular's history. Adopting it — signals for state, inject() for dependencies, functional routing, and lazy loading — gives you smaller bundles, fewer change-detection bugs, and code that is far easier to reason about.

Design patterns for developers: a friendly guide

Wed, 02 Sep 2026 00:00:00 GMT

Design patterns are reusable solutions to common problems. They are not copy-paste templates — they are ideas you adapt to your own situation. This guide walks through ten of the most useful ones, grouped by what they do.

flowchart TD
    A[Design patterns] --> B[Creational]
    A --> C[Structural]
    A --> D[Behavioral]
    A --> E[Architectural]
    B --> B1[Singleton]
    B --> B2[Builder]
    C --> C1[Adapter]
    C --> C2[Decorator]
    C --> C3[Facade]
    D --> D1[Strategy]
    D --> D2[Observer]
    D --> D3[Chain of Responsibility]
    E --> E1[MVC]
    E --> E2[MVVM]
    E --> E3[CQRS]
    E --> E4[Event Sourcing]

Strategy

The idea: pick an algorithm at runtime without changing the code that calls it.

Think of a checkout page: the customer can pay by card, PayPal, or bank transfer. Each option is a different strategy behind the same button.

public interface IPaymentStrategy
{
    void Pay(decimal amount);
}

public class CreditCardPayment : IPaymentStrategy
{
    public void Pay(decimal amount) => Console.WriteLine($"Paid {amount} by card");
}

public class PayPalPayment : IPaymentStrategy
{
    public void Pay(decimal amount) => Console.WriteLine($"Paid {amount} via PayPal");
}

public class Checkout
{
    private readonly IPaymentStrategy _strategy;

    public Checkout(IPaymentStrategy strategy) => _strategy = strategy;

    public void Complete(decimal amount) => _strategy.Pay(amount);
}

Decorator

The idea: add behavior to an object by wrapping it, layer by layer.

Like adding toppings to a coffee: you start with an espresso and keep piling on milk, sugar, or caramel without changing the espresso itself.

public interface ICoffee
{
    string Description { get; }
    decimal Cost { get; }
}

public class Espresso : ICoffee
{
    public string Description => "Espresso";
    public decimal Cost => 2.00m;
}

public class MilkDecorator : ICoffee
{
    private readonly ICoffee _inner;

    public MilkDecorator(ICoffee inner) => _inner = inner;

    public string Description => _inner.Description + ", milk";
    public decimal Cost => _inner.Cost + 0.50m;
}

Observer

The idea: one object notifies many listeners when something changes.

Like a newsletter: people subscribe, and everyone gets an update when a new edition is published.

public interface IListener
{
    void Notify(string message);
}

public class NewsFeed
{
    private readonly List<IListener> _listeners = new();

    public void Subscribe(IListener listener) => _listeners.Add(listener);

    public void Publish(string message) =>
        _listeners.ForEach(listener => listener.Notify(message));
}

Chain of Responsibility

The idea: pass a request along a chain of handlers until one of them handles it.

Like customer support: a ticket is escalated level by level until someone can resolve it. Each handler decides whether to process the request or forward it.

public interface IHandler
{
    IHandler SetNext(IHandler handler);
    void Handle(string request);
}

public abstract class BaseHandler : IHandler
{
    private IHandler? _next;

    public IHandler SetNext(IHandler handler)
    {
        _next = handler;
        return handler;
    }

    public virtual void Handle(string request)
    {
        _next?.Handle(request);
    }
}

public class AuthHandler : BaseHandler
{
    public override void Handle(string request)
    {
        if (request.StartsWith("auth"))
        {
            Console.WriteLine("Auth passed");
            base.Handle(request);
        }
        else
        {
            Console.WriteLine("Auth failed — stop");
        }
    }
}

public class LoggingHandler : BaseHandler
{
    public override void Handle(string request)
    {
        Console.WriteLine($"Logging: {request}");
        base.Handle(request);
    }
}

var logging = new LoggingHandler();
var auth = new AuthHandler();
logging.SetNext(auth);

logging.Handle("auth:user-42");

Each handler only knows about the next one, so the chain can be reordered or extended without changing existing handlers.

Singleton

The idea: guarantee there is exactly one instance of a class.

Like a single settings file for an app — everyone reads the same one.

public sealed class Configuration
{
    public static Configuration Instance { get; } = new Configuration();

    private Configuration() { }

    public string AppName => "MyApp";
}

Facade

The idea: hide a complex system behind one simple front door.

Like a car ignition: you turn one key, and many parts work together underneath.

public class OrderFacade
{
    private readonly PaymentService _payment = new();
    private readonly InventoryService _inventory = new();

    public void PlaceOrder(Order order)
    {
        _payment.Charge(order);
        _inventory.Reserve(order);
    }
}

Builder

The idea: build a complex object step by step instead of one giant constructor.

Like ordering a custom burger: pick the bun, the cheese, the extras — then build it.

public class Burger
{
    public bool Cheese { get; set; }
    public bool Bacon { get; set; }
}

public class BurgerBuilder
{
    private readonly Burger _burger = new();

    public BurgerBuilder AddCheese() { _burger.Cheese = true; return this; }

    public BurgerBuilder AddBacon() { _burger.Bacon = true; return this; }

    public Burger Build() => _burger;
}

Adapter

The idea: make two incompatible interfaces work together.

Like a travel plug adapter that lets your charger fit a foreign socket.

public interface IShape
{
    double Area();
}

public class LegacyRectangle
{
    public double Width { get; set; }
    public double Height { get; set; }
}

public class RectangleAdapter : IShape
{
    private readonly LegacyRectangle _rect;

    public RectangleAdapter(LegacyRectangle rect) => _rect = rect;

    public double Area() => _rect.Width * _rect.Height;
}

MVC (Model-View-Controller)

The idea: separate data, presentation, and control logic.

The model holds the data, the view shows it, and the controller reacts to user input.

public class User
{
    public string Name { get; set; } = "Olivier";
}

public class UserController
{
    public string GetUserName() => new User().Name;
}

MVVM (Model-View-ViewModel)

The idea: bind the view directly to a view model, so the UI updates automatically when data changes.

Popular in desktop and mobile apps, where a button click changes a property and the screen reflects it without manual wiring.

public class CounterViewModel : INotifyPropertyChanged
{
    private int _count;

    public int Count
    {
        get => _count;
        set { _count = value; OnPropertyChanged(); }
    }

    public void Increment() => Count++;

    // INotifyPropertyChanged implementation omitted for brevity
}

CQRS (Command Query Responsibility Segregation)

The idea: separate writes (commands) from reads (queries).

Reads and writes often need different models and different storage. Splitting them keeps each side simple and scalable.

public record CreateOrderCommand(int Id, decimal Total);

public record GetOrderQuery(int Id);

public class CreateOrderHandler
{
    public void Handle(CreateOrderCommand command) { /* save the order */ }
}

public class GetOrderHandler
{
    public Order Handle(GetOrderQuery query) => /* load the order */ null!;
}

Event Sourcing

The idea: store every state change as an immutable event, and rebuild the current state by replaying those events.

Instead of saving the current balance, you save "deposited 100", "withdrew 40". The balance is a projection you can recompute at any time.

public interface IEvent { }

public record AccountOpened(Guid AccountId, string Owner) : IEvent;
public record MoneyDeposited(Guid AccountId, decimal Amount) : IEvent;
public record MoneyWithdrawn(Guid AccountId, decimal Amount) : IEvent;

public class Account
{
    public Guid Id { get; private set; }
    public decimal Balance { get; private set; }

    public void Apply(IEvent @event)
    {
        switch (@event)
        {
            case AccountOpened e:
                Id = e.AccountId;
                break;
            case MoneyDeposited e:
                Balance += e.Amount;
                break;
            case MoneyWithdrawn e:
                Balance -= e.Amount;
                break;
        }
    }
}

// load = replay the history
var account = new Account();
foreach (var @event in eventStore.Load(accountId))
{
    account.Apply(@event);
}

Event sourcing gives you a full audit trail, makes state reproducible, and pairs naturally with CQRS — but it costs more storage and complexity.

Wrapping up

You will not use every pattern every day — but recognising them helps you read other people's code, discuss designs clearly, and pick the right tool when a problem looks familiar.

Java and the Spring ecosystem for experts: Boot, Security, JPA, Kafka, profiles, gateway

Wed, 02 Sep 2026 00:00:00 GMT

Java keeps getting more concise, and the Spring ecosystem keeps removing boilerplate. This guide covers the language features and Spring modules an expert backend developer uses every day, then closes with a version timeline.

flowchart TD
    B[Spring Boot] --> S[Spring Security]
    B --> J[Spring Data JPA]
    B --> C[Spring Cloud Stream]
    B --> P[Profiles]
    B --> G[Spring Cloud Gateway]
    B --> BA[Spring Batch]
    C --> K[Kafka Binder]
    BA --> DB[(Database)]

Modern Java

Lambdas

A lambda is a compact implementation of a functional interface (an interface with a single abstract method). It powers the Stream API and Spring's functional DSLs.

List<String> names = List.of("Ada", "Bob", "Cara");

// lambda
names.forEach(name -> System.out.println(name));

// method reference
names.forEach(System.out::println);

The JDK ships the common functional interfaces, so you rarely write your own.

Predicate<String> isLong = s -> s.length() > 3;
Function<String, Integer> length = String::length;
Consumer<String> print = System.out::println;
Supplier<String> id = () -> UUID.randomUUID().toString();

Streams

A stream is a pipeline over a collection: a source, a chain of lazy intermediate operations, and one terminal operation that runs it.

List<Order> orders = List.of(/* ... */);

List<String> emails = orders.stream()
  .filter(o -> o.total() > 100)
  .sorted(Comparator.comparing(Order::total).reversed())
  .map(Order::customerEmail)
  .distinct()
  .limit(10)
  .toList();

Common terminal operations:

double sum = orders.stream().mapToDouble(Order::total).sum();

Map<Status, List<Order>> byStatus =
  orders.stream().collect(Collectors.groupingBy(Order::status));

boolean anyLarge = orders.stream().anyMatch(o -> o.total() > 1000);

filter, map, sorted, distinct, and limit are lazy; toList, collect, reduce, and forEach trigger the pipeline. Streams encourage immutable, declarative data processing.

Records

Records give you immutable data carriers with no boilerplate.

public record User(String name, int age) { }

Pattern matching

instanceof narrows the variable in place.

if (obj instanceof String s) {
  System.out.println(s.length());
}

Switch expressions combine with pattern matching for exhaustive, typed logic.

String result = switch (obj) {
  case Integer i -> "int " + i;
  case String s  -> "str " + s;
  default        -> "other";
};

Sealed classes

Sealed hierarchies declare every allowed subtype, so the compiler can check exhaustiveness.

public sealed interface Shape permits Circle, Square { }

public record Circle(double radius) implements Shape { }
public record Square(double side) implements Shape { }

Virtual threads

Project Loom (stable since Java 21) makes blocking code scale with cheap, lightweight threads.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
  executor.submit(() -> handleRequest());
}

Spring Boot

Spring Boot wires an application from a single annotation and sensible defaults, configured via application.yml.

@SpringBootApplication
public class Application {
  public static void main(String[] args) {
    SpringApplication.run(Application.class, args);
  }
}

Starters pull in a whole feature (web, data, security) with one dependency, and auto-configuration adapts to what is on the classpath.

Spring beans and components

A bean is any object managed by Spring's IoC container. Components are classes auto-detected by component scanning through stereotype annotations.

@Component
public class EmailService { }

@Service
public class OrderService { }

@Repository
public class OrderRepository { }

@Controller
public class OrderController { }

@Component is the generic stereotype; @Service, @Repository, and @Controller are specializations that add meaning and future behaviour.

For third-party or manually constructed objects, declare a bean in a @Configuration class.

@Configuration
public class AppConfig {
  @Bean
  OrderValidator orderValidator() {
    return new OrderValidator();
  }
}

Inject dependencies through the constructor — the modern, testable default.

@Service
public class OrderService {
  private final OrderRepository repository;
  private final EmailService email;

  public OrderService(OrderRepository repository, EmailService email) {
    this.repository = repository;
    this.email = email;
  }
}

@Autowired is the older, annotation-driven way. It can target fields, setters, or constructors.

@Service
public class OrderService {

  @Autowired
  private OrderRepository repository;

  private EmailService email;

  @Autowired
  public void setEmailService(EmailService email) {
    this.email = email;
  }
}

Field and setter injection are flexible but make dependencies mutable and harder to test. Prefer constructor injection — on a single constructor, @Autowired is even optional.

When several beans share the same type, @Qualifier picks the right one.

@Service
public class CreditCardPayment implements PaymentService { }

@Service
public class PayPalPayment implements PaymentService { }

@Service
public class CheckoutService {

  private final PaymentService payment;

  public CheckoutService(@Qualifier("payPalPayment") PaymentService payment) {
    this.payment = payment;
  }
}

The qualifier is the bean name — by default the class name with a lowercase first letter. You can set an explicit name with @Service("paypal") or @Bean("paypal").

Spring provides several bean scopes. singleton (the default) creates one instance per container; prototype creates a new instance on every request; the web scopes (request, session, application, websocket) are tied to a web context.

// singleton (default) — one instance per container
@Component
public class SingletonService { }

// prototype — a new instance on every injection
@Component
@Scope("prototype")
public class ShoppingCart { }

// request — one instance per HTTP request
@Component
@Scope(value = WebApplicationContext.SCOPE_REQUEST,
       proxyMode = ScopedProxyMode.TARGET_CLASS)
public class RequestContext { }

// session — one instance per HTTP session
@Component
@Scope(value = WebApplicationContext.SCOPE_SESSION,
       proxyMode = ScopedProxyMode.TARGET_CLASS)
public class UserSession { }

// application — one instance per ServletContext
@Component
@Scope(value = WebApplicationContext.SCOPE_APPLICATION)
public class AppWideConfig { }

// websocket — one instance per WebSocket session
@Component
@Scope(value = "websocket",
       proxyMode = ScopedProxyMode.TARGET_CLASS)
public class ChatSession { }

The short-lived scopes (request, session, websocket) need proxyMode = ScopedProxyMode.TARGET_CLASS so they can be injected into longer-lived singletons.

Spring ships shorthand annotations for the common web scopes:

@Component
@RequestScope
public class RequestContext { }

@Component
@SessionScope
public class UserSession { }

@Component
@ApplicationScope
public class AppWideConfig { }

@RequestScope and @SessionScope are shortcuts for the @Scope version with proxyMode = ScopedProxyMode.TARGET_CLASS. There is no shorthand for prototype or websocket — use @Scope for those.

Here is the complete set:

Scope	Lifetime	Shorthand
`singleton`	One instance per container	default
`prototype`	New instance on every request	—
`request`	One instance per HTTP request	`@RequestScope`
`session`	One instance per HTTP session	`@SessionScope`
`application`	One instance per `ServletContext`	`@ApplicationScope`
`websocket`	One instance per WebSocket session	—

In short, the shorthand annotations are @RequestScope, @SessionScope, and @ApplicationScope. Spring Cloud also ships @RefreshScope for @Scope("refresh"). There is no shorthand for singleton (the default), prototype, or websocket.

@SpringBootApplication enables component scanning over its package, so any annotated class there is picked up automatically.

Spring Security

Security is configured through a SecurityFilterChain bean. The lambda DSL is the modern, readable style.

@Bean
SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
  return http
    .authorizeHttpRequests(auth -> auth
      .requestMatchers("/api/public/**").permitAll()
      .anyRequest().authenticated())
    .oauth2ResourceServer(oauth -> oauth.jwt(Customizer.withDefaults()))
    .build();
}

JWT resource servers are the default for stateless APIs; method security (@PreAuthorize) guards individual service calls. Enable it with @EnableMethodSecurity and annotate the methods you want to protect.

@RestController
@RequestMapping("/api/orders")
public class OrderController {

  private final OrderService orders;

  public OrderController(OrderService orders) {
    this.orders = orders;
  }

  @PreAuthorize("hasRole('ADMIN')")
  @DeleteMapping("/{id}")
  public void cancel(@PathVariable Long id) {
    orders.cancel(id);
  }
}

@PreAuthorize accepts SpEL, so you can check roles (hasRole), authorities (hasAuthority), or the request itself (#id == authentication.name). Use @PostAuthorize to filter the returned value after the method runs.

Filters vs interceptors

Both wrap requests, but at different layers. A filter is part of the Servlet API and runs around the entire request, before Spring's DispatcherServlet. An interceptor is Spring MVC and runs inside the dispatcher, with access to the target controller.

flowchart LR
    R[Request] --> F[Filter]
    F --> D[DispatcherServlet]
    D --> I[Interceptor]
    I --> C[Controller]

A filter is for concerns that must run before Spring even sees the request:

@Component
public class RequestLoggingFilter extends OncePerRequestFilter {

  @Override
  protected void doFilterInternal(
      HttpServletRequest request,
      HttpServletResponse response,
      FilterChain chain) throws ServletException, IOException {

    long start = System.currentTimeMillis();
    chain.doFilter(request, response);
    log.info("{} {} took {} ms", request.getMethod(),
        request.getRequestURI(), System.currentTimeMillis() - start);
  }
}

An interceptor is for concerns that need the controller, such as timing a specific handler:

@Component
public class TimingInterceptor implements HandlerInterceptor {

  @Override
  public boolean preHandle(HttpServletRequest request,
      HttpServletResponse response, Object handler) {
    request.setAttribute("startTime", System.currentTimeMillis());
    return true;
  }

  @Override
  public void afterCompletion(HttpServletRequest request,
      HttpServletResponse response, Object handler, Exception ex) {
    long start = (long) request.getAttribute("startTime");
    log.info("Handler {} took {} ms", handler,
        System.currentTimeMillis() - start);
  }
}

@Configuration
public class WebConfig implements WebMvcConfigurer {

  @Override
  public void addInterceptors(InterceptorRegistry registry) {
    registry.addInterceptor(new TimingInterceptor())
        .addPathPatterns("/api/**");
  }
}

	Filter	Interceptor
Layer	Servlet API	Spring MVC
Runs	Before `DispatcherServlet`	Inside `DispatcherServlet`
Sees the controller	No	Yes (`HandlerMethod`)
Typical uses	Auth, CORS, encoding, logging	Timing, model attributes, handler-aware logging

In short: filters for the container level, interceptors for the MVC level.

@RestController vs @Controller

@Controller is the classic MVC stereotype: its methods return a view name resolved by a ViewResolver. @RestController is a convenience combination of @Controller + @ResponseBody, so methods return data serialized to JSON.

@Controller
public class PageController {

  @GetMapping("/")
  public String home() {
    return "index"; // view name, not JSON
  }
}

@RestController
@RequestMapping("/api/users")
public class UserController {

  private final UserService users;

  public UserController(UserService users) {
    this.users = users;
  }

  @GetMapping
  public List<User> list() {
    return users.findAll(); // serialized to JSON
  }
}

@GetMapping, @PostMapping, @PutMapping, and @DeleteMapping are shortcuts for @RequestMapping(method = ...). Use @Controller for server-rendered pages and @RestController for APIs.

Spring Data JPA

Entities map classes to tables, and repository interfaces generate the queries from method names.

@Entity
@Table(name = "customer")
public class Customer {
  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  private Long id;

  @Column(nullable = false)
  private String name;
}

public interface CustomerRepository extends JpaRepository<Customer, Long> {
  List<Customer> findByNameContainingIgnoreCase(String name);

  Page<Customer> findByNameContainingIgnoreCase(String name, Pageable pageable);
}

Pagination uses Pageable with Page or Slice:

Page<Customer> page = repository.findByNameContainingIgnoreCase(
    "a", PageRequest.of(0, 20, Sort.by("name")));

List<Customer> content = page.getContent();
long total = page.getTotalElements();
int pages = page.getTotalPages();

PageRequest.of(page, size) maps to offset = page * size and limit = size. Page runs an extra COUNT query for the total; use Slice to skip it when you only need a "has next" flag.

Use @Transactional on service boundaries so multiple writes commit or roll back together.

@Service
public class OrderService {

  private final OrderRepository orders;
  private final PaymentService payments;

  public OrderService(OrderRepository orders, PaymentService payments) {
    this.orders = orders;
    this.payments = payments;
  }

  @Transactional
  public Order placeOrder(Order order) {
    Order saved = orders.save(order);
    payments.charge(order.getTotal());
    return saved;
  }
}

If any step throws a RuntimeException, the whole method rolls back. Fine-tune it with rollbackFor (for checked exceptions), readOnly = true (for read-only queries), and propagation (to join or require a new transaction).

Lombok and MapStruct

Lombok

Lombok removes boilerplate with compile-time annotations. @Getter/@Setter generate accessors, @Builder a builder, and @Slf4j a logger.

@Getter
@Setter
@Builder
@NoArgsConstructor
@AllArgsConstructor
@Entity
public class Customer {
  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  private Long id;

  private String name;
}

@RequiredArgsConstructor generates a constructor for final fields, which pairs perfectly with constructor injection.

@Service
@RequiredArgsConstructor
public class OrderService {
  private final OrderRepository orders;
  private final PaymentService payments;

  public void place(Order order) {
    orders.save(order);
  }
}

@Data bundles accessors with equals/hashCode/toString, but avoid it on JPA entities, where the generated equals can behave badly on mutable state.

MapStruct

MapStruct generates type-safe mappers between DTOs and entities at compile time. Declare an interface and it produces the implementation.

@Mapper(componentModel = "spring")
public interface CustomerMapper {

  CustomerDto toDto(Customer customer);

  @Mapping(target = "id", ignore = true)
  Customer toEntity(CreateCustomerRequest request);
}

With componentModel = "spring", the mapper is a Spring bean you can inject.

@Service
@RequiredArgsConstructor
public class CustomerService {
  private final CustomerRepository repository;
  private final CustomerMapper mapper;

  public CustomerDto create(CreateCustomerRequest request) {
    return mapper.toDto(repository.save(mapper.toEntity(request)));
  }
}

Unlike reflection-based mappers, MapStruct is type-safe and fails at compile time when fields do not match.

Spring Cloud Stream with the Kafka binder

Cloud Stream abstracts the messaging infrastructure behind a binding model, so your code speaks functions, not Kafka clients.

@Bean
Function<Order, Order> processOrder() {
  return order -> {
    // validate, enrich, or transform
    return order;
  };
}

spring:
  cloud:
    stream:
      bindings:
        processOrder-in-0:
          destination: orders
        processOrder-out-0:
          destination: orders-processed
      kafka:
        binder:
          brokers: localhost:9092

Swap the binder (Kafka, Rabbit, Kafka Streams) without touching the function.

Profiles

Profiles load different configuration per environment. Files are named application-{profile}.yml, and spring.profiles.active selects them.

spring:
  profiles:
    active: dev

# application-dev.yml
server:
  port: 8080

Loading multiple profiles

Profiles are additive and ordered — activate several at once:

spring:
  profiles:
    active: dev,local

Loading rules:

A later profile overrides an earlier one.
Every application-{profile}.yml overrides the base application.yml.
With no active profile, Spring uses the default profile (application.yml only).
Activate externally with the SPRING_PROFILES_ACTIVE environment variable or --spring.profiles.active=dev,local.

A profile can pull in others with include:

spring:
  profiles:
    include: common,metrics

You can also gate beans with @Profile.

@Component
@Profile("!prod")
public class DevDataSeeder { }

Spring Cloud Gateway

The gateway routes requests to downstream services using predicates and filters.

spring:
  cloud:
    gateway:
      routes:
        - id: order-service
          uri: lb://ORDER-SERVICE
          predicates:
            - Path=/api/orders/**
          filters:
            - StripPrefix=1

Predicates match the request; filters transform it (rewrite path, add headers, circuit-break). Paired with a discovery client, lb:// load-balances across instances.

Spring Batch

Spring Batch handles large, scheduled data processing: read in chunks, process, write, with restart and retry built in. A job is made of chunk-oriented steps.

@Configuration
@EnableBatchProcessing
public class BatchConfig {

  @Bean
  public Job importUsersJob(JobRepository jobRepository, Step step) {
    return new JobBuilder("importUsersJob", jobRepository)
        .start(step)
        .build();
  }

  @Bean
  public Step step(JobRepository jobRepository,
      PlatformTransactionManager transactionManager,
      ItemReader<User> reader,
      ItemProcessor<User, User> processor,
      ItemWriter<User> writer) {
    return new StepBuilder("step", jobRepository)
        .<User, User>chunk(100, transactionManager)
        .reader(reader)
        .processor(processor)
        .writer(writer)
        .build();
  }

  @Bean
  public ItemReader<User> reader() {
    return new FlatFileItemReaderBuilder<User>()
        .name("userReader")
        .resource(new FileSystemResource("users.csv"))
        .delimited()
        .names("name", "email")
        .targetType(User.class)
        .build();
  }

  @Bean
  public ItemProcessor<User, User> processor() {
    return user -> {
      user.setEmail(user.getEmail().toLowerCase());
      return user;
    };
  }
}

Job — the whole batch process.
Step — one phase; here a chunk step that reads, transforms, and writes.
Reader / Processor / Writer — the chunk pipeline.
chunk(100) — process 100 items per transaction, so a failure rolls back one chunk, not the whole job.

Spring Batch records job and step status in a metadata store, so jobs can be restarted from where they failed.

Java version history

A condensed timeline of the major releases and their headline changes.

Version	Release	Breaking changes / news
8	Mar 2014	Lambdas, Streams, `Optional`, `java.time`; PermGen removed (Metaspace)
9	Sep 2017	Module system (JPMS/Jigsaw), JShell, `List.of`/`Map.of`
10	Mar 2018	`var` local-variable type inference
11	Sep 2018	LTS; `HttpClient`, `var` in lambdas; Java EE & CORBA modules removed
12	Mar 2019	Switch expressions (preview), Shenandoah GC
13	Sep 2019	Text blocks (preview), ZGC
14	Mar 2020	Switch expressions standard; records & pattern matching (preview)
15	Sep 2020	Text blocks standard; sealed classes (preview)
16	Mar 2021	Records standard; pattern matching for `instanceof` standard
17	Sep 2021	LTS; sealed classes standard; strong encapsulation of JDK internals
18	Mar 2022	UTF-8 default charset; simple web server
19	Sep 2022	Virtual threads (preview); record patterns (preview)
20	Mar 2023	Record patterns standard; virtual threads (2nd preview)
21	Sep 2023	LTS; virtual threads standard, pattern matching for switch, sequenced collections
22	Mar 2024	Unnamed variables & patterns; statements before `super()`
23	Sep 2024	Module import declarations (preview); primitive patterns (preview)
24	Mar 2025	Compact object headers, class-file API, stream gatherers
25	Sep 2025	LTS; structured concurrency & scoped values stable

Wrapping up

Modern Java leans on records, pattern matching, sealed types, and virtual threads to cut boilerplate and scale. The Spring ecosystem layers Boot's auto-configuration, Security's filter chain, JPA's repositories, Cloud Stream's bindings, profiles, and a gateway on top. Together they give you a production backend that is concise, typed, and easy to reason about.

Orchestrating long-running workflows with MassTransit sagas

Wed, 02 Sep 2026 00:00:00 GMT

The problem with a single transaction

A checkout rarely completes in one request. Money must be captured, stock must be set aside, and the warehouse must be told to ship. Trying to wrap all of that in one distributed transaction — a two-phase commit across services — looks tidy on paper but breaks down quickly in reality.

The catch is that no service can predict how long another will take. A payment provider might wait on a fraud review, and a stock check might be slow under load. Keeping locks open across several systems for that long is impractical and can drag the whole platform down.

A saga sidesteps this by cutting the flow into local steps that each finish quickly and can be undone on their own.

What a saga actually is

A saga is a chain of local actions where every step has a matching compensating action that reverses it when a later step fails. Instead of one atomic operation, the work is split into small, independently recoverable pieces.

Take an order as an example:

sequenceDiagram
    participant Client
    participant Saga
    participant Payments
    participant Inventory
    Client->>Saga: OrderSubmitted
    Saga->>Payments: ChargePayment
    Payments-->>Saga: PaymentSettled
    Saga->>Inventory: AllocateInventory
    Inventory-->>Saga: InventoryAllocated
    Saga->>Client: FinalizeOrder

If the inventory step reports that an item is sold out after payment has already gone through, the saga fires a reimbursement to give the money back. Each piece is decoupled, and nothing stays locked for the entire journey.

MassTransit sagas are state machines

MassTransit implements sagas through a state machine, an approach inherited from Automatonymous. Before writing code it helps to know the four parts that make up the model:

States — the positions a workflow can be in
Events — messages that push the workflow from one state to another
Behaviors — the work performed when an event lands in a given state
Instance — the persisted record holding data for a single conversation

Every state machine ships with an Initial and a Final state for free. A new instance starts in Initial, and reaching Final means the saga has finished.

Here is the state machine we are going to build:

stateDiagram-v2
    [*] --> ProcessingPayment: OrderSubmitted
    ProcessingPayment --> ReservingInventory: PaymentSettled
    ProcessingPayment --> Failed: OrderDeclined
    ReservingInventory --> Completed: InventoryAllocated
    ReservingInventory --> Failed: OrderDeclined
    Completed --> [*]
    Failed --> [*]

The saga instance

The instance is the entity that MassTransit persists between messages. It keeps the correlation key, the current state, and any business data the steps need.

public class OrderState : SagaStateMachineInstance
{
    public Guid CorrelationId { get; set; }
    public string CurrentState { get; set; } = string.Empty;

    public decimal Total { get; set; }
    public string? PaymentReference { get; set; }
    public DateTime? PlacedAt { get; set; }
    public string? BuyerEmail { get; set; }
}

CorrelationId is the identifier that ties every incoming message back to the right instance, while CurrentState records where the workflow currently stands. The remaining properties carry the data the process needs along the way.

The events

Events are the messages that drive transitions. Each one must be correlated to a specific instance through a shared identifier.

public record OrderSubmitted(Guid OrderId, decimal Total, string Email);

public record PaymentSettled(Guid OrderId, string PaymentReference);

public record InventoryAllocated(Guid OrderId);

public record OrderDeclined(Guid OrderId, string Reason);

These records travel over the bus; the saga reacts to them and may publish new commands in response.

Building the state machine

The state machine ties states, events, and behaviors together and declares which transitions are legal.

public class OrderStateMachine : MassTransitStateMachine<OrderState>
{
    public OrderStateMachine()
    {
        InstanceState(x => x.CurrentState);

        Event(() => OrderSubmitted, x => x.CorrelateById(c => c.Message.OrderId));
        Event(() => PaymentSettled, x => x.CorrelateById(c => c.Message.OrderId));
        Event(() => InventoryAllocated, x => x.CorrelateById(c => c.Message.OrderId));
        Event(() => OrderDeclined, x => x.CorrelateById(c => c.Message.OrderId));

        Initially(
            When(OrderSubmitted)
                .Then(c =>
                {
                    c.Saga.Total = c.Message.Total;
                    c.Saga.BuyerEmail = c.Message.Email;
                    c.Saga.PlacedAt = DateTime.UtcNow;
                })
                .PublishAsync(c => c.Init<ChargePayment>(new
                {
                    OrderId = c.Saga.CorrelationId,
                    Amount = c.Saga.Total
                }))
                .TransitionTo(ProcessingPayment)
        );

        During(ProcessingPayment,
            When(PaymentSettled)
                .Then(c => c.Saga.PaymentReference = c.Message.PaymentReference)
                .PublishAsync(c => c.Init<AllocateInventory>(new
                {
                    OrderId = c.Saga.CorrelationId
                }))
                .TransitionTo(ReservingInventory),
            When(OrderDeclined)
                .TransitionTo(Failed)
                .Finalize()
        );

        During(ReservingInventory,
            When(InventoryAllocated)
                .PublishAsync(c => c.Init<FinalizeOrder>(new
                {
                    OrderId = c.Saga.CorrelationId
                }))
                .TransitionTo(Completed)
                .Finalize(),
            When(OrderDeclined)
                .PublishAsync(c => c.Init<ReimbursePayment>(new
                {
                    OrderId = c.Saga.CorrelationId,
                    Amount = c.Saga.Total
                }))
                .TransitionTo(Failed)
                .Finalize()
        );

        SetCompletedWhenFinalized();
    }

    public State ProcessingPayment { get; private set; } = null!;
    public State ReservingInventory { get; private set; } = null!;
    public State Completed { get; private set; } = null!;
    public State Failed { get; private set; } = null!;

    public Event<OrderSubmitted> OrderSubmitted { get; private set; } = null!;
    public Event<PaymentSettled> PaymentSettled { get; private set; } = null!;
    public Event<InventoryAllocated> InventoryAllocated { get; private set; } = null!;
    public Event<OrderDeclined> OrderDeclined { get; private set; } = null!;
}

Notice the compensation logic: when the stock step fails after payment, the saga publishes ReimbursePayment to unwind the charge. The happy path and the failure path are declared side by side, which makes the workflow easy to read.

The consumers

The saga is the coordinator, not the doer. The actual work lives in message consumers that handle commands and report back through events.

public class ChargePaymentConsumer(
    IPaymentGateway gateway,
    ILogger<ChargePaymentConsumer> logger) : IConsumer<ChargePayment>
{
    public async Task Consume(ConsumeContext<ChargePayment> context)
    {
        try
        {
            var result = await gateway.ChargeAsync(
                context.Message.OrderId,
                context.Message.Amount);

            if (result.Succeeded)
            {
                await context.Publish<PaymentSettled>(new
                {
                    OrderId = context.Message.OrderId,
                    PaymentReference = result.Reference
                });
            }
            else
            {
                await context.Publish<OrderDeclined>(new
                {
                    OrderId = context.Message.OrderId,
                    Reason = result.RejectionReason
                });
            }
        }
        catch (Exception ex)
        {
            logger.LogError(ex, "Payment failed for order {OrderId}", context.Message.OrderId);

            await context.Publish<OrderDeclined>(new
            {
                OrderId = context.Message.OrderId,
                Reason = "Payment gateway error"
            });
        }
    }
}

Splitting responsibilities this way keeps each service focused on its own job, while the saga keeps the whole process moving in the right direction.

Wiring it up with Azure Service Bus

Persisting saga state requires a repository. We will use Entity Framework Core against SQL Server, with Azure Service Bus as the transport.

First, the required packages:

Install-Package MassTransit.EntityFrameworkCore
Install-Package MassTransit.Azure.ServiceBus.Core
Install-Package Microsoft.EntityFrameworkCore.SqlServer

Define a DbContext and a class map for the saga instance:

public class OrderSagaDbContext : SagaDbContext
{
    public OrderSagaDbContext(DbContextOptions options) : base(options) { }

    protected override IEnumerable<ISagaClassMap> Configurations
    {
        get { yield return new OrderStateMap(); }
    }
}

public class OrderStateMap : SagaClassMap<OrderState>
{
    protected override void Configure(EntityTypeBuilder<OrderState> entity, ModelBuilder model)
    {
        entity.Property(x => x.CurrentState).HasMaxLength(64);
        entity.Property(x => x.BuyerEmail).HasMaxLength(256);
        entity.Property(x => x.PaymentReference).HasMaxLength(64);
    }
}

Finally, register everything in the application:

builder.Services.AddDbContext<OrderSagaDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("SqlServer")));

builder.Services.AddMassTransit(x =>
{
    x.AddSagaStateMachine<OrderStateMachine, OrderState>()
        .EntityFrameworkRepository(r =>
        {
            r.ConcurrencyMode = ConcurrencyMode.Pessimistic;
            r.AddDbContext<DbContext, OrderSagaDbContext>();
        });

    x.UsingAzureServiceBus((context, cfg) =>
    {
        cfg.Host(builder.Configuration.GetConnectionString("ServiceBus"));
        cfg.ConfigureEndpoints(context);
    });
});

Why reach for sagas

Resilience — every step can be retried on its own, and failures trigger compensation instead of leaving the system half-done.
Visibility — the current state tells you exactly where each order stands, which simplifies debugging and monitoring.
Loose coupling — services talk through messages and can evolve separately without breaking the overall flow.
Maintainability — a change to one step does not ripple through the others.

The state machine also forces the business process to be explicit. Every state and transition is spelled out, turning a murky distributed flow into something a new team member can follow.

Wrapping up

Modeling a checkout as a MassTransit saga gives you coordinated, recoverable workflows without the pain of distributed transactions. Define the states and events, persist the instance, and let Azure Service Bus carry the messages. The result is a process that is clear, observable, and forgiving when things go wrong.

Python for finance: NumPy, pandas, and the tools of quantitative analysis

Wed, 02 Sep 2026 00:00:00 GMT

Python is the default language of modern finance because its ecosystem covers everything from data cleaning to Monte Carlo simulation. This guide walks through the core libraries with real examples.

flowchart TD
    P[Python] --> N[NumPy]
    P --> PD[pandas]
    P --> M[matplotlib]
    Y[yfinance] --> PD
    PD --> R[Returns & indicators]
    N --> R
    R --> V[Visualization]
    R --> PF[Portfolio metrics]

NumPy: vectorized financial math

NumPy gives you fast, vectorized arrays — the foundation for every financial calculation.

import numpy as np

prices = np.array([100, 102, 101, 105, 107])

# simple returns
returns = np.diff(prices) / prices[:-1]
print(returns)  # [ 0.02   -0.0098  0.0396  0.0190]

# log returns
log_returns = np.log(prices[1:] / prices[:-1])

# annualized volatility
volatility = returns.std() * np.sqrt(252)

Everything is element-wise, so you avoid Python loops and keep the math fast.

pandas: DataFrames and time series

pandas wraps data in a DataFrame with powerful time-series operations.

import pandas as pd

df = pd.DataFrame({
    'date': pd.date_range('2026-01-01', periods=5, freq='D'),
    'close': [100, 102, 101, 105, 107],
})

df['returns'] = df['close'].pct_change()
df['cum_return'] = (1 + df['returns']).cumprod() - 1

Resample, roll, and shift time series with built-in methods:

df['sma_3'] = df['close'].rolling(3).mean()
df['prev_close'] = df['close'].shift(1)

Getting market data with yfinance

yfinance downloads historical prices straight from Yahoo Finance.

import yfinance as yf

ticker = yf.Ticker('AAPL')
history = ticker.history(period='1y', interval='1d')

prices = history['Close']
returns = prices.pct_change().dropna()

You can also pull several tickers at once with yf.download.

Returns and portfolio metrics

From returns, compute the headline risk metrics.

def sharpe_ratio(returns, risk_free_rate=0.0):
    excess = returns - risk_free_rate / 252
    return excess.mean() / returns.std() * np.sqrt(252)

sharpe = sharpe_ratio(returns)
vol = returns.std() * np.sqrt(252)
ann_return = (1 + returns.mean()) ** 252 - 1

print(f"Return: {ann_return:.2%}, Vol: {vol:.2%}, Sharpe: {sharpe:.2f}")

Correlation between two assets:

a = yf.Ticker('AAPL').history(period='1y')['Close'].pct_change()
b = yf.Ticker('MSFT').history(period='1y')['Close'].pct_change()

corr = a.corr(b)

Technical indicators

Moving averages are a few pandas calls.

df['sma_20'] = df['close'].rolling(20).mean()
df['ema_20'] = df['close'].ewm(span=20, adjust=False).mean()
df['signal'] = np.where(df['sma_20'] > df['ema_20'], 1, 0)

rolling gives a simple window; ewm gives an exponential one. The crossover of a short over a long average is a classic signal.

Visualization with matplotlib

Plot prices and indicators to sanity-check the data.

import matplotlib.pyplot as plt

plt.figure(figsize=(10, 5))
plt.plot(df['date'], df['close'], label='Close')
plt.plot(df['date'], df['sma_20'], label='SMA 20')
plt.plot(df['date'], df['ema_20'], label='EMA 20')
plt.legend()
plt.show()

Monte Carlo simulation

Simulate many future price paths by sampling random shocks.

def monte_carlo(initial_price, mu, sigma, days=252, simulations=1000):
    dt = 1 / 252
    paths = np.zeros((days, simulations))
    paths[0] = initial_price
    for t in range(1, days):
        shocks = np.random.normal(mu * dt, sigma * np.sqrt(dt), simulations)
        paths[t] = paths[t - 1] * (1 + shocks)
    return paths

paths = monte_carlo(100, mu=0.07, sigma=0.20)

final_prices = paths[-1]
value_at_risk = np.percentile(final_prices, 5)

This underpins risk measures like value-at-risk and option pricing.

Wrapping up

NumPy does the math, pandas shapes the data, yfinance feeds it, and matplotlib shows it. Master these four and you can compute returns, indicators, and Monte Carlo simulations — the backbone of quantitative finance in Python.

Relational databases for experts: ACID, keys, triggers, and indexes

Wed, 02 Sep 2026 00:00:00 GMT

Relational databases power most applications for good reason: they give you strong guarantees and a clear model. This guide walks through the concepts every expert DBA lives by, with SQL examples and diagrams.

erDiagram
    CUSTOMER ||--o{ ORDER : places
    ORDER ||--|{ ORDER_LINE : contains
    PRODUCT ||--o{ ORDER_LINE : "ordered as"

ACID

ACID describes the four guarantees a transaction provides.

flowchart LR
    T[Transaction] --> A[Atomicity]
    T --> C[Consistency]
    T --> I[Isolation]
    T --> D[Durability]

Atomicity — all statements succeed or none do.
Consistency — the database moves from one valid state to another.
Isolation — concurrent transactions do not interfere.
Durability — committed data survives a crash.

stateDiagram-v2
    [*] --> Active
    Active --> Committed: COMMIT
    Active --> Aborted: ROLLBACK
    Committed --> [*]
    Aborted --> [*]

BEGIN;

UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;

COMMIT;

Primary keys

A primary key uniquely identifies every row. It is always NOT NULL and unique. Prefer a surrogate key (identity, UUID) over a natural key that can change.

CREATE TABLE customer (
  id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email VARCHAR(255) NOT NULL UNIQUE
);

Composite keys identify a row by several columns together — the classic join-table case.

CREATE TABLE order_line (
  order_id BIGINT NOT NULL,
  product_id BIGINT NOT NULL,
  quantity INT NOT NULL,
  PRIMARY KEY (order_id, product_id)
);

Foreign keys

A foreign key enforces referential integrity: every value must exist in the referenced table. ON DELETE / ON UPDATE tell the engine what to do when the parent changes.

CREATE TABLE "order" (
  id BIGINT PRIMARY KEY,
  customer_id BIGINT NOT NULL
    REFERENCES customer(id) ON DELETE CASCADE
);

CASCADE deletes the child when the parent goes; SET NULL clears the column; RESTRICT blocks the change.

SQL commands: DDL, DQL, DML, DCL, TCL

SQL divides into five command families.

DDL — Data Definition Language

Defines and changes the schema.

CREATE TABLE product (
  id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  name VARCHAR(255) NOT NULL,
  price NUMERIC(10, 2) NOT NULL
);

ALTER TABLE product ADD COLUMN active BOOLEAN DEFAULT true;

DROP TABLE product;

DQL — Data Query Language

Reads data. It is just SELECT.

SELECT id, name, price
FROM product
WHERE active
ORDER BY price DESC;

DML — Data Manipulation Language

Changes the data: INSERT, UPDATE, DELETE.

INSERT INTO product (name, price) VALUES ('Keyboard', 89.90);

UPDATE product SET price = 79.90 WHERE name = 'Keyboard';

DELETE FROM product WHERE id = 1;

UPDATE and DELETE must carry a WHERE clause — without one they affect every row.

DCL — Data Control Language

Manages permissions with GRANT and REVOKE.

GRANT SELECT, INSERT, UPDATE ON product TO app_user;
REVOKE DELETE ON product FROM app_user;

TCL — Transaction Control Language

Controls transactions with COMMIT, ROLLBACK, and SAVEPOINT.

BEGIN;

UPDATE accounts SET balance = balance - 100 WHERE id = 1;
SAVEPOINT before_credit;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;

ROLLBACK TO before_credit;
COMMIT;

Joins

Joins combine rows from two or more tables using a join condition.

-- INNER JOIN: only matching rows
SELECT c.name, o.id AS order_id, o.total
FROM customer c
JOIN "order" o ON o.customer_id = c.id;

-- LEFT JOIN: all customers, even without orders (NULL on the right)
SELECT c.name, o.id AS order_id
FROM customer c
LEFT JOIN "order" o ON o.customer_id = c.id;

-- RIGHT JOIN: all orders, even without a customer (NULL on the left)
SELECT c.name, o.id AS order_id
FROM customer c
RIGHT JOIN "order" o ON o.customer_id = c.id;

-- FULL OUTER JOIN: both sides, NULL where missing
SELECT c.name, o.id AS order_id
FROM customer c
FULL OUTER JOIN "order" o ON o.customer_id = c.id;

-- CROSS JOIN: every combination of rows
SELECT c.name, p.name
FROM customer c
CROSS JOIN product p;

-- self join: employees and their managers
SELECT e.name AS employee, m.name AS manager
FROM employee e
LEFT JOIN employee m ON m.id = e.manager_id;

Joins pair naturally with aggregation:

-- order totals from line items
SELECT o.id, SUM(ol.quantity * p.price) AS total
FROM "order" o
JOIN order_line ol ON ol.order_id = o.id
JOIN product p ON p.id = ol.product_id
GROUP BY o.id;

Use table aliases (c, o) for readability, and keep the join condition in ON rather than WHERE so the intent stays clear.

Indexes

An index speeds up lookups at the cost of write performance and storage. Most databases use a B-tree, which keeps data sorted for fast range and equality scans.

flowchart TD
    R[Root] --> N1[Node 10 - 20]
    R --> N2[Node 20 - 30]
    N1 --> L1[Leaf 10]
    N1 --> L2[Leaf 15]
    N2 --> L3[Leaf 20]
    N2 --> L4[Leaf 25]

Unique index — enforces uniqueness like a unique constraint.
Composite index — covers multiple columns, left-to-right.
Covering index — stores extra columns so the query never touches the table.
Partial index — only indexes rows matching a condition.

CREATE UNIQUE INDEX idx_customer_email ON customer(email);

CREATE INDEX idx_order_customer ON "order"(customer_id);

CREATE INDEX idx_order_line_product
  ON order_line(product_id) INCLUDE (quantity);

A rule of thumb: index the columns you filter (WHERE), join (JOIN), and sort (ORDER BY) on.

Triggers

A trigger runs automatically before or after INSERT, UPDATE, or DELETE. They are great for audit trails and derived columns. In PostgreSQL the logic lives in a trigger function.

CREATE FUNCTION audit_order() RETURNS trigger AS $$
BEGIN
  INSERT INTO audit_log (table_name, row_id, action, changed_at)
  VALUES ('order', COALESCE(NEW.id, OLD.id), TG_OP, now());
  RETURN COALESCE(NEW, OLD);
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER order_audit
AFTER INSERT OR UPDATE OR DELETE ON "order"
FOR EACH ROW EXECUTE FUNCTION audit_order();

Functions

Functions are reusable, composable pieces of logic that return a value.

A scalar function:

CREATE FUNCTION order_total(order_id BIGINT) RETURNS NUMERIC AS $$
  SELECT COALESCE(SUM(price * quantity), 0)
  FROM order_line
  JOIN product ON product.id = order_line.product_id
  WHERE order_line.order_id = order_total.order_id;
$$ LANGUAGE sql;

A table-valued function (returns a set of rows):

CREATE FUNCTION customer_orders(customer_id BIGINT)
RETURNS TABLE(order_id BIGINT, total NUMERIC, placed_at TIMESTAMPTZ) AS $$
  SELECT id, total, placed_at
  FROM "order"
  WHERE customer_id = customer_orders.customer_id;
$$ LANGUAGE sql;

Stored procedures

Procedures are like functions but can manage their own transactions and do not have to return a value. Use them for multi-step, transactional operations.

CREATE PROCEDURE transfer(from_acc BIGINT, to_acc BIGINT, amount NUMERIC)
LANGUAGE plpgsql
AS $$
BEGIN
  UPDATE accounts SET balance = balance - amount WHERE id = from_acc;
  UPDATE accounts SET balance = balance + amount WHERE id = to_acc;
  COMMIT;
END;
$$;

Isolation levels

Isolation controls how much concurrent transactions see of each other.

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

Read uncommitted — can read uncommitted data (dirty reads).
Read committed — each statement sees a stable snapshot.
Repeatable read — the whole transaction sees one snapshot.
Serializable — transactions behave as if run one at a time.

Key practices

Use stored procedures for CRUD — centralize the data logic in one place and grant access to the procedure instead of the table.
Use parameterized queries — never concatenate user input into SQL; bind values as parameters to prevent SQL injection.
Manage permissions — let users execute CRUD procedures without direct table access.

-- parameterized query: the value is bound as data, not SQL
SELECT id, name FROM customer WHERE email = $1;

-- grant execution through a procedure, not the table
GRANT EXECUTE ON PROCEDURE create_customer TO app_user;
REVOKE ALL ON customer FROM app_user;

Parameterized statements separate the SQL from the values, so input is treated as data. Combined with procedure-level grants, the surface stays small and auditable.

Wrapping up

ACID gives you correctness; keys give you integrity; indexes give you speed; triggers, functions, and procedures give you reusable, enforced logic. Mastering these — and knowing the trade-offs of each — is what separates a DBA from a developer who happens to write SQL.

Tailwind CSS for experts: best practices and tools for beautiful UI

Wed, 02 Sep 2026 00:00:00 GMT

Tailwind CSS v4 moved to a CSS-first configuration and a faster engine. This guide covers the patterns and tools that keep a Tailwind codebase clean, scalable, and good-looking.

Tailwind CSS v4

Version 4 is configured entirely in CSS. There is no tailwind.config.js; you just import it and declare your design tokens.

@import "tailwindcss";

@theme {
  --color-primary: #6366f1;
  --font-sans: 'Inter', ui-sans-serif, system-ui, sans-serif;
  --radius-lg: 0.75rem;
}

Custom utilities and variants are declared in the same file.

@utility container {
  margin-inline: auto;
  padding-inline: 1rem;
}

@custom-variant dark (&:where(.dark, .dark *));

Design tokens

Define tokens once and reference them everywhere, so colors and spacing stay consistent. Arbitrary values like bg-[#6366f1] are for one-offs, not a design system.

@theme {
  --color-primary-500: #6366f1;
  --color-primary-600: #4f46e5;
  --spacing-18: 4.5rem;
}

Then bg-primary-500, p-18, and text-primary-600 all work.

Utility-first best practices

Compose small utilities instead of writing bespoke CSS, but extract a pattern the moment it repeats.

<button class="inline-flex items-center gap-2 rounded-lg bg-primary-600 px-4 py-2 text-sm font-medium text-white hover:bg-primary-500">
  Save
</button>

Rules that keep it maintainable:

Reuse tokens, not raw values.
Sort classes automatically (see the Prettier plugin below).
Prefer gap/space-* over manual margins.
Keep responsive and state variants close to the base classes.

Reusable components

When a pattern repeats, extract it. Tailwind offers three levels.

Component classes with @apply:

.btn {
  @apply inline-flex items-center gap-2 rounded-lg px-4 py-2 text-sm font-medium;
}
.btn-primary {
  @apply bg-primary-600 text-white hover:bg-primary-500;
}

Class variants with class-variance-authority (great for React/Solid):

import { cva, type VariantProps } from 'class-variance-authority'

const button = cva('inline-flex items-center rounded-lg font-medium', {
  variants: {
    variant: {
      primary: 'bg-primary-600 text-white hover:bg-primary-500',
      ghost: 'border border-gray-300 text-gray-700',
    },
    size: {
      sm: 'px-3 py-1.5 text-sm',
      md: 'px-4 py-2 text-base',
    },
  },
  defaultVariants: { variant: 'primary', size: 'md' },
})

Merging classes with clsx + tailwind-merge:

import { clsx, type ClassValue } from 'clsx'
import { twMerge } from 'tailwind-merge'

export function cn(...inputs: ClassValue[]) {
  return twMerge(clsx(inputs))
}

// later conflicting class wins
cn('px-4', 'px-2') // 'px-2'

The component ecosystem

You do not have to build every primitive from scratch.

shadcn/ui — copy-paste, Radix-based components you own and edit.
Radix UI / Headless UI — accessible, unstyled primitives.
daisyUI — ready-made, themeable component classes.

Pair them with Tailwind for full control without the accessibility burden.

Tooling

@tailwindcss/vite — the Vite plugin (add it once, forget it).
prettier-plugin-tailwindcss — sorts utility classes for a consistent order.
clsx + tailwind-merge — compose and dedupe classes.
class-variance-authority — typed component variants.

npm install -D tailwindcss @tailwindcss/vite prettier-plugin-tailwindcss
npm install clsx tailwind-merge class-variance-authority

Making it beautiful

Beautiful UI is mostly consistency, not decoration.

Typography — one font scale, comfortable line height, constrained measure.
Spacing — stick to the 4px scale; align to a grid.
Color — a small palette with one accent; check contrast for text.
Motion — short, subtle transitions (transition, duration-150).
Dark mode — design both, driven by the dark variant.

Ready production examples

A complete, copy-pasteable setup: design tokens, a cn helper, and typed components.

Theme tokens (theme.css):

@import "tailwindcss";

@theme {
  --color-brand-50: #eef2ff;
  --color-brand-500: #6366f1;
  --color-brand-600: #4f46e5;
  --color-brand-700: #4338ca;

  --color-surface: #ffffff;
  --color-ink: #0f172a;
  --color-muted: #64748b;

  --font-sans: 'Inter', ui-sans-serif, system-ui, sans-serif;
  --shadow-card: 0 1px 2px rgb(15 23 42 / 0.06), 0 4px 12px rgb(15 23 42 / 0.08);
}

@custom-variant dark (&:where(.dark, .dark *));

Button (button.tsx) with typed variants:

import { cva, type VariantProps } from 'class-variance-authority'
import { cn } from './cn'

const buttonVariants = cva(
  'inline-flex items-center justify-center gap-2 rounded-md text-sm font-medium transition-colors focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-brand-500 disabled:pointer-events-none disabled:opacity-50',
  {
    variants: {
      variant: {
        primary: 'bg-brand-600 text-white hover:bg-brand-500',
        secondary: 'border border-slate-200 bg-surface text-ink hover:bg-slate-50',
        ghost: 'text-ink hover:bg-slate-100',
        destructive: 'bg-red-600 text-white hover:bg-red-500',
      },
      size: {
        sm: 'h-8 px-3 text-xs',
        md: 'h-10 px-4',
        lg: 'h-12 px-6 text-base',
      },
    },
    defaultVariants: { variant: 'primary', size: 'md' },
  },
)

export interface ButtonProps
  extends React.ButtonHTMLAttributes<HTMLButtonElement>,
    VariantProps<typeof buttonVariants> {}

export function Button({ className, variant, size, ...props }: ButtonProps) {
  return (
    <button
      className={cn(buttonVariants({ variant, size }), className)}
      {...props}
    />
  )
}

Card and Input (card.tsx, input.tsx):

export function Card({ className, ...props }: React.HTMLAttributes<HTMLDivElement>) {
  return (
    <div
      className={cn(
        'rounded-md border border-slate-200 bg-surface p-6 shadow-card',
        className,
      )}
      {...props}
    />
  )
}

export function Input({ className, ...props }: React.InputHTMLAttributes<HTMLInputElement>) {
  return (
    <input
      className={cn(
        'h-10 w-full rounded-md border border-slate-200 bg-surface px-3 text-sm text-ink placeholder:text-muted focus:outline-none focus:ring-2 focus:ring-brand-500',
        className,
      )}
      {...props}
    />
  )
}

These tokens and components form the base of a real design system: consistent colors, typed variants, and a single source of truth.

Wrapping up

Tailwind v4's CSS-first setup, design tokens, and component extraction (with cva and cn) give you a system that scales. Add shadcn/Radix for primitives and the Prettier plugin for order, and you get beautiful, maintainable UI.

TypeScript and JavaScript for experts: modern features and architecture

Wed, 02 Sep 2026 00:00:00 GMT

JavaScript keeps gaining small, sharp features, and TypeScript keeps turning runtime mistakes into compile-time errors. This guide covers the parts that matter for production front-end code today, with examples.

flowchart TD
    JS[JavaScript] --> A[Modern built-ins]
    A --> A1[toSorted / at / groupBy]
    A --> A2[Promise.withResolvers]
    TS[TypeScript] --> B[The type system]
    B --> B1[Discriminated unions]
    B --> B2[Utility types]
    TS --> C[Architecture]
    C --> C1[Result types]
    C --> C2[Exhaustive checks]

JavaScript: the modern essentials

Optional chaining and nullish coalescing

Read nested data without exploding, and fall back only on null/undefined.

const city = user?.address?.city
const label = name ?? 'Anonymous'
const retries = config?.retries ?? 3

Logical assignment

Mutate a variable only when it is falsy, nullish, or truthy.

user.nickname ||= user.firstName
settings.theme ??= 'dark'

Non-mutating array methods

toSorted, toReversed, toSpliced, and with return new arrays instead of mutating, which pairs perfectly with immutable state.

const sorted = items.toSorted((a, b) => a.score - b.score)
const reversed = items.toReversed()
const first = items.at(0)
const last = items.at(-1)

Grouping and cloning

Object.groupBy buckets a collection in one line, and structuredClone deep copies without JSON hacks.

const byStatus = Object.groupBy(orders, (o) => o.status)

const copy = structuredClone(original)

Promise helpers

Promise.withResolvers gives you the resolve/reject functions without wrapping a promise in a constructor.

const { promise, resolve, reject } = Promise.withResolvers<string>()

async function nextMessage(): Promise<string> {
  return promise
}

Array.fromAsync turns an async iterable into an array.

const lines = await Array.fromAsync(stream)

Promises and Observables

Promises

A promise represents a value that will be available later. async/await flattens the callbacks.

function fetchUser(id: number): Promise<User> {
  return fetch(`/api/users/${id}`).then((res) => res.json())
}

async function loadUser(id: number): Promise<User | null> {
  try {
    return await fetchUser(id)
  } catch (error) {
    console.error('failed to load user', error)
    return null
  }
}

Run independent work in parallel and collect the results:

const [a, b, c] = await Promise.all([
  fetchUser(1),
  fetchUser(2),
  fetchUser(3),
])

Observables

Observables (RxJS) model a stream of values over time. Build pipelines from operators and always unsubscribe.

import { from, fromEvent } from 'rxjs'
import { debounceTime, filter, map, switchMap } from 'rxjs/operators'

const search$ = fromEvent<InputEvent>(input, 'input').pipe(
  debounceTime(300),
  map((event) => (event.target as HTMLInputElement).value),
  filter((term) => term.length >= 3),
  switchMap((term) =>
    from(fetch(`/api/search?q=${term}`).then((res) => res.json())),
  ),
)

const subscription = search$.subscribe({
  next: (results) => console.log(results),
  error: (err) => console.error(err),
})

subscription.unsubscribe()

A promise produces one value; an observable produces many over time. Use promises for single results, observables for events and streams.

TypeScript: the type system that matters

`unknown` beats `any`

any turns the type checker off; unknown forces you to narrow first.

function parse(value: unknown): string {
  if (typeof value === 'string') return value
  throw new Error('not a string')
}

`satisfies` and `as const`

satisfies checks an object against a type without widening it, and as const locks values to their literal types.

const palette = {
  primary: '#c770f0',
  danger: '#ef4444',
} satisfies Record<string, string>

const routes = ['/', '/about', '/blog'] as const
type Route = (typeof routes)[number]

Discriminated unions

Model each state with a shared kind field, and the compiler narrows it for you — the backbone of typed reducers and state machines.

type State =
  | { kind: 'idle' }
  | { kind: 'loading' }
  | { kind: 'success'; data: User[] }
  | { kind: 'error'; message: string }

function render(state: State): string {
  switch (state.kind) {
    case 'idle': return 'Waiting…'
    case 'loading': return 'Loading…'
    case 'success': return state.data.map((u) => u.name).join(', ')
    case 'error': return state.message
  }
}

Type predicates

Narrow unknown into a concrete shape safely.

function isUser(value: unknown): value is User {
  return typeof value === 'object' && value !== null && 'id' in value
}

Template literal types

Build string types from unions — great for typed routes and API paths.

type Route = `/api/${'users' | 'orders'}/${string}`

`const` type parameters

Keep tuple literals precise without spreading as const everywhere.

function preserve<const T>(items: T[]): T[] {
  return items
}

const pair = preserve([1, 'two']) // [number, string]

Utility types

Compose new types from existing ones instead of hand-writing them.

type UserInput = Omit<User, 'id' | 'createdAt'>
type PartialUser = Partial<User>
type ReadonlyUser = Readonly<User>

Recent TypeScript features

Standard decorators

Decorators are now part of the language, no experimental flag required.

function logged(target: unknown, context: ClassMethodDecoratorContext) {
  // wrap the method
}

class Service {
  @logged
  fetchData() {
    /* ... */
  }
}

Explicit resource management

using runs cleanup deterministically via Symbol.dispose.

function readFile(path: string) {
  using handle = openFile(path)
  return handle.read()
}

`NoInfer`

Stop the compiler from inferring a type argument in a specific position.

declare function createPair<T>(first: T, second: NoInfer<T>): T

const result = createPair('a', 'b') // T is inferred from the first arg only

Architecture patterns

Result types instead of exceptions

Represent success and failure in the type, so callers cannot forget to handle errors.

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

function divide(a: number, b: number): Result<number> {
  if (b === 0) return { ok: false, error: new Error('division by zero') }
  return { ok: true, value: a / b }
}

Exhaustive checks

A never helper guarantees every case is handled when the union grows.

function assertNever(value: never): never {
  throw new Error(`Unexpected value: ${value}`)
}

// switch (state.kind) { ... default: assertNever(state) }

Branded types

Prevent mixing up identifiers that share the same underlying type.

type UserId = string & { readonly __brand: 'UserId' }
type OrderId = string & { readonly __brand: 'OrderId' }

function toUserId(id: string): UserId {
  return id as UserId
}

Immutability by default

Prefer readonly, as const, and non-mutating methods so state changes are explicit.

interface Config {
  readonly apiUrl: string
  readonly retries: number
}

ESM and tree-shaking

Use ES modules and named imports so bundlers can drop unused code, and prefer type-only imports so types never leak into runtime bundles.

import type { User } from './models'
import { fetchUsers } from './api'

Wrapping up

The modern front-end expert leans on the sharp new JavaScript APIs for data handling, and on TypeScript's discriminated unions, utility types, and result types to push errors to compile time. Adopt these patterns and your code gets smaller, safer, and far easier to reason about.

SOLID principles in practice

Sat, 15 Aug 2026 00:00:00 GMT

The SOLID principles are a set of five design guidelines that help produce maintainable, scalable software.

Principle	Focus
SRP	One reason to change
OCP	Open for extension, closed for modification
LSP	Subtypes must be substitutable
ISP	Small, focused interfaces
DIP	Depend on abstractions, not concretions

Single Responsibility

A class should have only one reason to change.

class Invoice {
    void calculateTotal() { /* ... */ }
    void print() { /* violates SRP */ }
}

Split print() into a dedicated InvoicePrinter class and each concern evolves independently.

Open/Closed Principle

A module should be open for extension but closed for modification — new behavior arrives by adding code, not by rewriting existing code.

public interface IDiscount
{
    decimal Apply(Order order);
}

public class SeasonalDiscount : IDiscount
{
    public decimal Apply(Order order) => order.Total * 0.10m;
}

public class LoyaltyDiscount : IDiscount
{
    public decimal Apply(Order order) => order.Total * 0.15m;
}

Adding a new discount type means adding a class; the existing ones stay untouched.

Liskov Substitution

Objects of a subtype should be usable anywhere the parent type is expected, without surprising behavior.

public class Rectangle
{
    public virtual int Width { get; set; }
    public virtual int Height { get; set; }
}

public class Square : Rectangle
{
    public override int Width { set { base.Width = value; base.Height = value; } }
    public override int Height { set { base.Width = value; base.Height = value; } }
}

A Square is not a faithful substitute for Rectangle — resizing one side silently changes the other. Model them separately or behind a common abstraction.

Interface Segregation

A client should not be forced to depend on methods it never uses. Prefer several narrow interfaces over one broad one.

// one fat interface
public interface IWorker
{
    void Work();
    void Eat();
}

// focused interfaces
public interface IWorkable
{
    void Work();
}

public interface IEatable
{
    void Eat();
}

Now each class implements only what it actually needs.

Dependency Inversion

High-level modules should not depend on low-level modules. Both should depend on abstractions.

public interface IClock
{
    DateTime UtcNow { get; }
}

public class SystemClock : IClock
{
    public DateTime UtcNow => DateTime.UtcNow;
}

This keeps business logic testable and decoupled from the clock.

More in-depth articles will follow — this one just sets the stage.

Mermaid diagrams in your articles

Sun, 12 Jul 2026 00:00:00 GMT

Any fenced code block tagged with mermaid is rendered as an SVG diagram. Here is a tour of what is available.

Flowchart

flowchart LR
    A[Start] --> B{Logged in?}
    B -- Yes --> C[Dashboard]
    B -- No --> D[Login page]
    D --> E[Submit credentials]
    E --> B

Sequence

sequenceDiagram
    autonumber
    participant U as User
    participant A as API
    participant D as Database
    U->>A: POST /orders
    A->>D: INSERT order
    D-->>A: ok
    A-->>U: 201 Created

Class diagram

classDiagram
    class Order {
        +id: string
        +total: number
        +submit()
    }
    class LineItem {
        +sku: string
        +qty: number
    }
    Order "1" --> "*" LineItem

State diagram

stateDiagram-v2
    [*] --> Draft
    Draft --> Published: publish()
    Published --> Archived: archive()
    Archived --> [*]

Entity relationship

erDiagram
    CUSTOMER ||--o{ ORDER : places
    ORDER ||--|{ LINE_ITEM : contains
    PRODUCT ||--o{ LINE_ITEM : "ordered as"

Gantt chart

gantt
    title Release plan
    dateFormat YYYY-MM-DD
    section Backend
    API design       :a1, 2026-07-01, 7d
    Implementation   :a2, after a1, 14d
    section Frontend
    UI design        :b1, 2026-07-01, 7d
    Implementation   :b2, after b1, 14d

Pie chart

pie title Tech stack usage
    "Java" : 40
    "C#" : 35
    "Python" : 15
    "Other" : 10

Git graph

gitGraph
    commit id: "init"
    branch feature
    checkout feature
    commit id: "feat: parser"
    checkout main
    commit id: "fix: typo"
    merge feature

Mindmap

mindmap
  root((Blog))
    Content
      Markdown
      Frontmatter
    Rendering
      Code highlighting
      Mermaid

Timeline

timeline
    title Project milestones
    2026 Q2 : Kickoff
    2026 Q3 : Beta release
    2026 Q4 : General availability

Wrap any of these in a mermaid fence and it will render on the page.

Designing a CI/CD pipeline with GitHub Actions

Fri, 05 Jun 2026 00:00:00 GMT

Automating your delivery pipeline removes manual steps and makes every merge reproducible. Here is the pipeline I use for side projects.

Overview

flowchart TD
    P[Push to main] --> L[Lint]
    L --> T[Unit tests]
    T --> S[SonarQube scan]
    S --> B[Build image]
    B --> V[Vulnerability scan]
    V --> D{Pass?}
    D -- Yes --> E[Deploy]
    D -- No --> R[Notify & block]

The workflow file

name: ci

on:
  push:
    branches: [main]
  pull_request:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm run test -- --coverage
      - run: npm run build

Release process

Releases are cut from tags and follow a staged rollout.

gantt
    title Release rollout
    dateFormat  YYYY-MM-DD
    section Deploy
    Tag release        :2026-06-01, 1d
    Staging            :2d
    Canary (5%)        :2d
    Full rollout       :2d

Rollback sequence

If a release breaks, the rollback is fully automated.

sequenceDiagram
    participant M as Monitoring
    participant O as Orchestrator
    participant K as Kubernetes
    M->>O: error rate > 1%
    O->>K: kubectl rollout undo
    K-->>O: rollout reverted
    O-->>M: healthy again

Keep the pipeline fast, deterministic, and observable — everything else follows.

Welcome to my technical blog

Tue, 02 Jun 2026 00:00:00 GMT

Why a blog?

I built this space to share the notes and lessons I gather while working on side projects and production systems. Expect deep dives on SolidJS, .NET, Java, Angular, and the tooling around them.

Markdown power

Articles are written as plain Markdown files, so I can focus on content. The renderer supports the usual suspects out of the box:

Headings, lists, and blockquotes
Tables
Links and images
Fenced code blocks with syntax highlighting
Mermaid diagrams

Syntax highlighting

Code blocks are highlighted automatically based on the language tag:

export interface Feature<T> {
  run(input: T): Promise<T>
}

export const identity = <T,>(value: T): T => value

public sealed class Greeter
{
    public string Hello(string name) => $"Hello, {name}!";
}

Mermaid diagrams

Diagrams render from a mermaid code block:

flowchart TD
    A[Write Markdown] --> B{Contains mermaid?}
    B -- Yes --> C[Render SVG diagram]
    B -- No --> D[Render plain HTML]
    C --> E[Show article]
    D --> E

Sequence diagrams work too:

sequenceDiagram
    participant Client
    participant API
    participant Cache
    Client->>API: GET /posts
    API->>Cache: lookup
    alt hit
        Cache-->>API: data
    else miss
        API-->>API: build response
        API->>Cache: store
    end
    API-->>Client: 200 OK

Wrapping up

That is the basics. Stay tuned for more detailed technical articles.