This repository provides a fully automated, one-command deployment of a self-hosted Supabase stack. The setup script (`setup.sh`) orchestrates the entire process: it installs dependencies, clones the repository, generates cryptographic secrets and JWT tokens, configures environment variables, and layers optional docker-compose overrides for Authelia 2FA, Nginx or Caddy reverse proxy, and SSL via Let's Encrypt. The architecture is a Docker Compose multi-service deployment including Supabase Studio, Kong API gateway, GoTrue auth, PostgREST, Realtime, Storage, Edge Functions, and a custom Postgres image. The code is production-grade with robust error handling, CI/CD pipelines (GitHub Actions) that test every configuration matrix (caddy/nginx, basic auth/authelia/redis), and comprehensive integration tests covering CRUD operations, storage, realtime subscriptions, and edge functions. The repository also includes advanced utilities for key management (asymmetric JWTs, opaque API keys) and a sophisticated Postgres 15-to-17 upgrade script (`upgrade-pg17.sh`) that handles binary extraction, pg_upgrade, and post-migration patches. While primarily a deployment tool, the scripts demonstrate high craftsmanship and are safely reusable as templates for similar self-hosting scenarios.
The Gren compiler is a production-grade toolchain for the Gren programming language, a fork of Elm. It functions as a compiler, build tool, package manager, and REPL, targeting JavaScript and HTML output. The system is architected in two stages: a Haskell backend responsible for the core compilation pipeline (parsing, type inference via Hindley-Milner unification, optimization, and code generation) and a Gren frontend (compiled to JavaScript) that handles the CLI interface, dependency resolution, and orchestration of the backend process via JSON IPC. The codebase demonstrates strong software engineering practices, particularly in its use of monadic error handling (Reporting.Result, Reporting.Task), composable pretty-printing (Reporting.Doc), and efficient data structures (Data.Utf8, Type.UnionFind). The parser is specifically designed for space-sensitive grammars, and the type system includes advanced features like constraint solving, occurs check, and pattern match exhaustiveness verification. While actively maintained, the project carries medium technical drift. It relies on unsafe GHC primitives for performance, maintains a dual-language codebase (Haskell and Gren), and inherits the complexity of forking a rapidly evolving upstream project (Elm). Some modules are notably large, and there are incomplete features marked by TODOs. Despite these risks, the core compiler logic and several of its internal libraries are well-crafted and represent high-quality, reusable components.
CellTypist is a Python library and command-line tool for cell type classification in single-cell RNA-seq (scRNA-seq) data. It implements a complete annotation workflow: training logistic regression classifiers on labeled expression matrices (with optional SGD mini-batching and GPU-accelerated cuML backends), annotating query cells using either custom-trained or pre-trained models, and visualizing marker gene expression via dotplots. The package is architected as a conventional Python library with a click-based CLI (entry point: celltypist.command_line:main), a models submodule that manages remote pre-trained artifacts, and a samples module for loading bundled example data. The primary data flow starts with an AnnData object containing raw counts, which is normalized, scaled, and filtered through feature selection before being passed to the classifier. For annotation, the trained model (or a downloaded pre-trained model) is applied to query cells, producing cell type labels and confidence scores. Models are fetched on-demand from celltypist.cog.sanger.ac.uk and cached locally, with a force_update flag to bypass the cache. External dependencies include scanpy, anndata, scikit-learn, click, numpy, scipy, pandas, and matplotlib. The repository is hybrid in nature: while the core deliverable is a software library, it also ships pre-trained models, a cross-species gene mapping reference (Cynomolgus/Rhesus orthologs), and tutorial Jupyter notebooks that demonstrate the API. These data assets make it a valuable resource for bioinformatics researchers even beyond the code itself. The tutorial notebook (docs/notebook/celltypist_tutorial_ml.ipynb) is a usage guide rather than a research artifact, relying on 12 built-in pre-trained models and demo data fetched from the same remote server. The project is maintained but not rapidly evolving; the last significant release was January 2025, and the codebase shows signs of technical drift. The pickle-based model format could break across Python or scikit-learn versions, and the tutorial notebook may produce different outputs with newer versions of scanpy or CellTypist. The force_update mechanism and backup_url fallback in the data-loading code indicate awareness of external data unavailability, but these fallbacks could themselves become stale.
This repository provides a Python library for creating, reading, and writing AUTOSAR XML (ARXML) files, targeting Classic AUTOSAR platforms from R19-11 to R22-11. It covers a broad range of AUTOSAR elements—software components, port interfaces, data types, constants, compu methods, service needs, and more—through an object-oriented model with full XML serialization. The library is not an end-user application but a tool for automotive engineers and tool integrators to programmatically generate ARXML artifacts for import into commercial AUTOSAR toolchains. It also includes an early-stage code generator that produces C type definitions (Rte_Type.h) from the XML model. The architecture follows a layered design: an XML model layer (autosar.xml) with element classes, enums, and references; a workspace abstraction that manages packages, documents, and template application; and a generator layer that transforms the XML model into an intermediate representation for code generation. A notable design pattern is the template system (ElementTemplate/GenericTemplate) that decouples high-level element recipes from their serialization, enabling config-driven generation of entire projects from TOML configuration files. The library is supported by a comprehensive test suite that exercises round-trip XML serialization for hundreds of element types. The codebase shows good craftsmanship—clean separation of concerns, consistent use of base classes (Identifiable, Describable), version-aware enum handling, and typed reference system. However, it is still in development (v0.5.7) with many planned releases and a roadmap that implies future breaking changes. Several AUTOSAR elements remain unimplemented, and the test suite relies on exact XML string comparisons, making it brittle. The project is maintained by a single contributor with no PyPI release, posing adoption and continuity risks. Overall, it is a solid, functional library for its domain but not yet production-ready for all use cases.
This repository provides a comprehensive, modular set of Bash scripts to automate the installation and configuration of Apache Guacamole—an open-source remote desktop gateway. The primary orchestrator '1-setup.sh' handles interactive prompts and silent install variables to deploy Guacamole server and client from source, integrate MySQL/MariaDB as the backend database, set up Nginx as a reverse proxy, and optionally configure TLS (self-signed or Let's Encrypt), multi-factor authentication (TOTP, Duo, LDAP), and extra UI features like quick-connect and session recording storage. The scripts are well-structured with extensive error checking, logging, distro-specific workarounds, and support for modular post-install add-ons. Though not a library for reuse, the code demonstrates solid shell scripting craftsmanship, security hardening (fail2ban integration, firewall rules), and separation of concerns. The repository serves as a turnkey deployment toolkit for production-grade Guacamole environments.
Starter template for Cucumber-JVM with Java and Maven. It is not a production application: the only production source file is an empty Belly class, while all meaningful code lives in the test tree. RunCucumberTest is a JUnit Platform Suite that boots the Cucumber engine, cucumber.properties supplies glue and plugin configuration, and belly.feature defines one scenario whose step definitions are bound via annotations. Running `./mvnw test` executes the suite and prints pretty output; one step passes, one is intentionally aborted with a TODO, and one is undefined. The repository's actual purpose is to demonstrate a minimal Cucumber setup and serve as a starting point for BDD projects. Architecturally this is a Maven build with test-scoped dependencies only: cucumber-java, cucumber-junit-platform-engine, junit-platform-suite, and assertj-core. Dependencies are imported through BOMs, Java 17 is configured as the release target, and the Maven wrapper pins Maven 3.10.0. The primary data flow is Gherkin -> Cucumber engine -> annotated JUnit step methods -> AssertJ assertions. There is no web server, API, or business logic. The repository includes CI that runs the tests on Ubuntu and Windows across Java 17 and 21, Renovate for dependency updates, and a Zizmor workflow for GitHub Actions security analysis, indicating active project maintenance.
This repository implements the Adaptive Query Optimization (AQO) extension for PostgreSQL, a machine learning-based system that improves query planning by learning from historical query execution statistics. The extension integrates with PostgreSQL's planner and executor via hook mechanisms to override cardinality estimation with predictions from per-query-class k-nearest neighbors regression models. It features a multi-layer architecture: preprocessing (query classification and mode handling), cardinality estimation (ML-based prediction), postprocessing (statistics collection and model updates), and shared memory persistence for query statistics and ML models. Key operational modes include disabled, learn, intelligent, controlled, and forced, controlled via GUCs. The system automatically tunes learning/usage flags based on prediction stability and includes background workers for maintenance. The extension requires patching PostgreSQL source and rebuilding, with tight coupling to internal planner structures (e.g., RelOptInfo, Plan nodes) and executor functions. Deployment involves setting shared_preload_libraries, configuring GUCs like AQO.mode, and managing memory limits for query classes and feature subspaces. It provides SQL interfaces for managing query classes (enable/disable, status checks) and EXPLAIN integration for runtime visibility. The test suite includes pgbench integration, SQL scripts for feature validation, and Perl scripts for pg_stat_statements compatibility. While the core AQO logic is highly specialized to PostgreSQL, two components demonstrate extractable excellence: the hash function for query normalization (ignoring constants/whitespace) and the standalone k-NN regression implementation with linear smoothing. These show non-obvious skill in handling SQL variability and efficient online learning. However, the deep integration with PostgreSQL internals, version-specific patching requirements, and complex state management introduce maintenance challenges and technical debt risks, particularly during PostgreSQL version upgrades.
KC3Kai is a mature Chrome extension for the browser game Kantai Collection (KanColle), providing an enhanced game viewer, data analysis, and automation tools. It operates as a DevTools panel and content script, intercepting game API calls to display real-time fleet status, battle predictions, quest tracking, resource graphs, and expedition scoring. The architecture is monolithic with global singletons (KC3Master, KC3SortieManager, PlayerManager) and a tab-based Strategy Room UI for historical data analysis (ship drops, event stats, PvP replays, Akashi improvement planner). It integrates with community databases (TsunDB, PoiDB, KCRDB) for data submission and uses IndexedDB for persistent storage of sorties, battles, and encounters. While primarily an application, it contains significant data analysis components such as battle prediction algorithms, anti-air cut-in calculations, and quest synchronization logic, making it a hybrid tool with strong data engineering aspects.
meta-openembedded is the OpenEmbedded/Yocto Project's collection of supplementary layers (meta-oe, meta-python, meta-networking, meta-multimedia, meta-gnome, meta-xfce, meta-filesystems, meta-initramfs, etc.), providing BitBake recipes and patches to build hundreds of open-source packages for embedded Linux. It is not a runtime application; it is build-system metadata (.bb, .bbappend, .inc, .bbclass) plus configuration files, systemd units, init scripts, and cross-compilation patches. The entry points are layer.conf files that register each layer into a Yocto build, and image/packagegroup recipes that aggregate packages into test images. At runtime, the 'product' this repository produces is embedded Linux distributions and images: filesystem tools, kernel utilities, networking daemons, multimedia codecs, Python/Perl modules, XFCE/GNOME desktop environments, and initramfs components. Its primary data flow is source fetch via SRC_URI from upstream tarballs/git, patch application, cross-compilation through OE classes, and packing/installation onto target images. The repository contains very little application logic itself; most engineering effort is in recipe metadata, build-system classes, and patches that adapt upstream software to musl/glibc, newer compilers, and embedded constraints. Maintenance is active: recent commits, ongoing updates for GCC/CMake/Python evolution, and steady recipe additions. However, it carries substantial technical debt: many patches are marked Upstream-Status: Pending or Inappropriate, several upstream projects are inactive, and the sheer recipe count creates constant drift risk. Although a few data-like assets exist (DVB scan tables, static passwd/group files, fontconfig data), they are configuration payloads for recipes, not research artifacts; the dominant character is application/build infrastructure.
This repository provides board support packages for the LiteX open-source FPGA SoC builder. It contains over 150 platform definitions (pinouts, connectors, toolchain setup) and corresponding target scripts that assemble a complete SoC (CPU, memory, peripherals) for each FPGA board. The architecture is a collection of Python modules organized into `litex_boards/platforms/` and `litex_boards/targets/`, with each target being a standalone script that can be invoked via `python -m litex_boards.targets.<board> --build --load`. The system supports a wide range of FPGA families (Xilinx, Lattice, Intel/Altera, Gowin, Efinix, CologneChip) and integrates with the broader LiteX ecosystem (LiteDRAM, LiteEth, LitePCIe, etc.) for memory controllers, networking, and high-speed interfaces. Key entry points are the `main()` functions in each target file, which use `LiteXArgumentParser` for CLI argument handling and `Builder` for bitstream generation. The repository is community-maintained under litex-hub and includes CI scripts for consistency checks, board inventory generation, and regression tests.
NME (Native Media Engine) is a cross-platform game and multimedia framework for the Haxe programming language. It provides a native runtime that compiles Haxe code to C++ via hxcpp and links against platform-specific backends for iOS, Android, Windows, macOS, Linux, and Web (Emscripten). The engine includes a 2D/3D rendering pipeline with both software and OpenGL backends, an audio subsystem with multiple backends (SDL, OpenAL, PulseAudio, ALSA, WebAudio), input handling (keyboard, mouse, touch, joystick), font rendering, and a build toolchain. The architecture is a library/framework with a core set of common components and platform-specific implementations selected at compile time. Key entry points include the `nme` CLI tool for building and running projects, the Haxe library under `src/nme/`, and the C++ engine under `project/src/`. External dependencies include Haxe, hxcpp, platform SDKs, and vendored libraries (LZMA, Clipper, Poly2Tri, FreeType, JPEG, Ogg, SDL, etc.). The codebase is large and contains both high-quality reusable components and some aging third-party code.
This repository is Microsoft's multi-language TPM 2.0 Software Stack (TSS) library, providing APIs to communicate with Trusted Platform Module 2.0 devices. It includes implementations in C++, C#, Java, Python, and TypeScript/Node.js, all sharing a common architecture derived from auto-generated type definitions from TCG specifications. The library handles TPM command marshaling, session management (HMAC, policy, encryption), cryptographic operations (via OpenSSL in C++), and device abstraction (Windows TBS, Linux kernel/abrmd, TCP simulator). It also includes a code generator (TssCodeGen) that parses TPM specification Word documents to produce language-specific bindings, ensuring consistency across languages. Additionally, the repository contains a test framework (Tpm2Tester) for TPM 2.0 compliance testing and a Windows platform crypto provider tool (PCPTool). While primarily a software library, the code generation pipeline and test infrastructure demonstrate a systematic approach to specification-driven development. The repository is actively maintained but shows some technical drift in vendored OpenSSL headers and incomplete language implementations (Java missing HMAC sessions).
WDExtract is a command-line utility for extracting and analyzing Windows Defender/Virus Definition files. It processes VDM (Virus Definition Module) containers and MRT.exe (Malicious Removal Tool) files to extract embedded data, including PE executables, DLLs, and security signatures. The tool can also merge base VDM files with their delta updates and extract raw RMDX containers without further processing. Built with C++ and Windows API, it uses zlib for decompression and implements custom logic for parsing PE files, applying VCDIFF delta patches, and extracting resources from PE files. The application is actively maintained with recent commits and uses GitHub Actions for Windows-based builds.
This repository provides a single Bash script (`jenkins-backup.sh`) that reliably archives a Jenkins CI server's configuration, plugins, jobs (including nested folders), secrets, nodes, and user data into a compressed tarball. It is designed to be run from a shell or as a Jenkins job itself, with support for spaces in job names and the CloudBees Folder plugin. The script is well-structured with functions for job traversal (`backup_jobs`), cleanup, and main orchestration, handling edge cases like empty directories and pinned plugins. The repository also includes a comprehensive testing suite using Docker, Itamae, and Serverspec, with a custom Serverspec type to verify archive contents. It is a focused, production-grade utility for Jenkins backup automation.
Direktiv is an event-driven serverless orchestration and automation platform. It enables users to define, execute, and monitor workflows using TypeScript or YAML, manage API gateways with a plugin chain (authentication, inbound transformation, target routing, outbound transformation), schedule tasks via cron, handle events (CloudEvents), and orchestrate services on Kubernetes/Knative. The system is designed for integration and automation scenarios, providing a low-code page builder, workflow editor, and comprehensive management UI. The architecture consists of a Go backend (API server, workflow engine, gateway, scheduler, sidecar, telemetry) and a React/TypeScript frontend. Key entry points include the CLI (`cmd/main.go`), REST API (`internal/api/`), workflow runtime (`internal/engine/runtime/`), gateway router (`internal/gateway/`), and cron scheduler (`internal/sched/`). Data flows involve compiling workflows from TypeScript to an internal representation, executing them via a state machine, persisting state in PostgreSQL, and using NATS for cluster-wide messaging and event streaming. External dependencies include PostgreSQL, NATS, Kubernetes/Knative, OpenTelemetry, and various Go and Node.js libraries. The frontend is a modern React SPA using TanStack Router, Radix UI, react-hook-form, Zod, and i18next. It provides editors for workflows, endpoints (OpenAPI), services, pages (block editor), and gateway routes, along with dashboards for instances, events, logs, and monitoring. The UI includes a reusable design system with components like Button, Dialog, Table, and Pagination, all demonstrated in Storybook. The backend uses a custom Go-like language (likely a DSL) for its core modules, which may pose maintenance challenges but enables tight integration with the platform's specific needs.
The Apache Dubbo website repository hosts the source code for the official Apache Dubbo project website. It is built using the Hugo static site generator with the Docsy theme, providing documentation in multiple languages and versions. The repository also includes a self-contained Vue.js benchmark application for visualizing Dubbo performance data, along with reusable search and glossary functionalities for the documentation site. The site is deployed via GitHub Actions to GitHub Pages.
This repository is an unofficial, experimental fork of GNU Emacs hosted on GitHub. It diverges from the official Emacs source in several key areas: performant long-line handling without narrowing, tree-sitter-based font highlighting and syntactic parsing (replacing the traditional PPSS parser), a rewritten non-blocking Gnus, rewritten process management, and moving garbage collector rudiments. The codebase is a full desktop text editor application with a C core (src/), a large gnulib portability layer (lib/), X11/Lucid widget libraries (lwlib/, oldXMenu/), platform-specific backends for Windows, Haiku, macOS, and GTK, and an extensive Emacs Lisp library (lisp/). The build system uses autoconf/automake with a standard ./autogen.sh && ./configure && make workflow. The project is actively maintained (last commit July 2026) but carries significant technical drift due to its experimental nature, legacy platform support, and infrequent upstream merges.
gblog is an open-source personal blog template and live website built on Astro. It statically generates pages from Markdown/MDX content collections, providing a typical blog surface: post listing, categories, timeline, friends page, full-text RSS, sitemap, 404 page, and SEO/OpenGraph metadata. The site integrates Algolia DocSearch, Giscus-based comments, Umami/Google Analytics, and an image optimization pipeline with blur-up placeholders. It also includes a small Cloudflare Pages Functions API backing a "life snapshots" gallery, with uploads stored in R2 and metadata in KV, plus a client-side React timeline component that progressively loads gallery entries from that API with a local fallback. The codebase is a hybrid of polished infrastructure and personal content. The Astro config uses modern integrations (MDX, Tailwind, React, Partytown, compress, sitemap), and several support modules are cleanly isolated — e.g., a Sharp-based blur placeholder generator, a full-content MDX RSS endpoint built on Astro's experimental container, and an idempotent batch image conversion/upload script using OpenDAL. The project is actively maintained by a single author and reflects real production use, but it has no automated test suite, contains a couple of small leftover TODOs (e.g., BackTop button), and couples some configuration values (Algolia API key, analytics IDs) directly into source. Overall, this is a well-structured application template for someone wanting a fully-featured, visually polished Astro blog. It demonstrates solid architecture for a personal project: clear separation of content, components, support utilities, and deployment functions. While it is not a library, several of its support modules and edge-function patterns can be lifted into other Astro or Cloudflare projects with minimal adaptation. The primary value is as a production-grade reference implementation of a static blog with serverless image/gallery extensions.
This repository is the NVIDIA BioNeMo Agent Toolkit — a collection of 31 skills that give coding/scientific agents (Claude Code, Codex, any SKILL.md-compatible harness) domain knowledge for life-science workflows: protein structure prediction, molecular docking, generative chemistry, and related tasks. Skills execute in the user's own environment (workstation, notebook, cluster) and wrap NVIDIA NIM (NVIDIA Inference Microservices) APIs — both hosted endpoints and local Docker deployments. The toolkit is not an installable Python package; it is a skill catalog with supporting tooling, dual-licensed (Apache-2.0 OR CC-BY-4.0).
Kemono Downloader is a cross-platform desktop application built with PyQt6 that downloads posts and creator content from the fan-archiving sites Kemono.cr, Coomer.st, and Pawchive.pw. It provides a tabbed interface with Post Downloader, Creator Downloader, Thumbnail Downloader, Settings, Help, and Browser Extension tabs. The application supports concurrent downloads (1–10 threads), file deduplication via an SQLite hash database, retry logic with exponential backoff, proxy/Tor integration, user-agent rotation, and a multilingual UI (English, Japanese, Korean, Chinese). A companion browser extension (Chrome/Firefox) offers an alternative download interface directly on the target sites. The architecture is a monolithic PyQt6 GUI with heavy use of QThread subclasses for background tasks (detection, file preparation, downloading, cancellation). Communication between threads and the UI is handled via PyQt signals, with a `_safe_emit` guard to prevent crashes after widget destruction. The application relies on external REST APIs from the target sites, parses JSON responses and HTML content (via BeautifulSoup) to extract files, and uses asyncio for concurrent file downloads within the Creator Downloader. Settings are persisted via QSettings, and file hashes are stored in a thread-safe SQLite database for deduplication and corruption detection. The codebase demonstrates solid engineering practices: extensive pytest coverage (over 100 test files), pre-commit hooks (black, isort, ruff, mypy, pyright), CI across three OSes, and a well-documented changelog. However, it exhibits some code duplication between the post and creator downloader modules, heavy monkeypatching in tests, and threading complexity that includes workarounds for Python 3.14 and Windows SSL issues. The application is entirely dependent on the availability and API stability of the third-party archive sites, which introduces inherent fragility.