Emmanuel Vaïsse evaisse

PocketBase JavaScript (Goja Engine) - Specific Behaviors & Limitations

This document covers the unique aspects, limitations, and unexpected behaviors when working with PocketBase's embedded JavaScript engine (Goja). These are critical differences from standard Node.js or browser JavaScript environments.

PocketBase JavaScript SDK Documentation

ALWAYS use english for code and documentation
ALWAYS prefer conventions over configurations
ALWAYS Create small, focused components and files instead of large files
ALWAYS use tests, and static analysis tools if available
ALWAYS consider whether the code needs refactoring given the latest request. Maybe there is code that is not used anymore. If it does, refactor the code to be more efficient and maintainable. Spaghetti code is your enemy.
ALWAYS be generous with golden testing and code documentation
ALWAYS consider their is a CI (github workflows or other)
ALWAYS use the best accessibility semantics and tools. To ensure accessibility is always working, use ARIA labels for web and Semantics Widget for flutter. use them for testing also.
Follow the project's conventions if present.
When exploring a project, if you struggle to search, write python scripts to explore the project and write some markdown files to make it easier next time.

Tarot de Marseille Guide

Rules for Drawing Tarot de Marseille

Traditional Drawing Methods

Single Card Draw

The simplest method for daily guidance or quick answers.

Shuffle the deck while focusing on your question
Draw one card from the top or fan out the deck and select intuitively

Nouveautés de Dart pour les version 3.6, 3.7 et 3.8

Ce document présente toutes les fonctionnalités et améliorations majeures apparues dans Dart entre les versions 3.5 (août 2024) et 3.8 (mai 2025).

Dart 3.6 (Novembre 2024)

1. Séparateurs de chiffres (Digit Separators)

La fonctionnalité principale de Dart 3.6 est l'introduction des séparateurs de chiffres pour améliorer la lisibilité des nombres.

Google Way of Dart

Copyright :

There are countless Flutter coding conventions floating around. From the popular “Flutter Clean Architecture” to community-driven style guides, developers have been following external conventions for years. I was one of them.

For the past 5 years, I followed community best practices, enforced strict linting rules, and structured my Flutter apps according to popular Medium articles and YouTube tutorials. My code was “clean,” and my architecture was “proper.”

Development Stack with Flutter

Flutter app, with provider for dependency management.
Always run flutter analyze to fix all errors, when there is errors, just run dart fix --apply before trying to manipulate the code by yourself
Always ensure your code is fully tested, with flutter test() or widgetTest(), add be generous with goldenTest and screen captures also
Always prefer type-safe alternative to dynamic, late and other risky behaviors
Do not cast with as keyword, but always prefer pattern matching to safely cast and test types
Never use the dynamic keyword, nor late, but prefer Object? which is safer
Always use flutter theme extension to allow UI customization, for every group of UI widgets you build, add a theme extension and refer to hit using context to customize the widgets.

	import 'dart:core';

	/// Démo d’égalité, hashCode et comparaison d’entités.
	///
	/// Points clés:
	/// - L’égalité logique (operator ==) est basée sur l’ID en minuscules.
	/// - Le hashCode est cohérent avec == (utilise le même critère).
	/// - compareTo (Comparable<MyEntity>) illustre un ordre de tri.
	///
	/// Subtilités:

	import 'package:flutter/material.dart';
	import 'package:provider/provider.dart';

	class MyBudgetModel {
	final Set<String> activeCategories;

	MyBudgetModel(this.activeCategories);
	}

	class MyBudgetController extends ChangeNotifier {

	#!/usr/bin/env python3

	import argparse
	import json
	import os
	import platform
	import sys
	import urllib.request
	import zipfile
	from pathlib import Path