Certificate

# ===== Skills checklist =====
# After the regex track you should be able to:
# [x] Compile patterns at module scope; never inside hot loops
# [x] Pick the right flavour (PCRE2, JS, RE2, .NET) for the job
# [x] Use named groups + verbose mode for any pattern > 40 chars
# [x] Match common shapes (URL, email, UUID, IP, hex, date)
# [x] Parse log lines with anchored + named-group patterns
# [x] Identify + rewrite ReDoS-prone patterns
# [x] Use re2 / Go regexp for untrusted patterns
# [x] Use regex tools (regex101, debuggex) to test before shipping
# [x] Know when NOT to use regex (HTML, JSON, CSV, code parsing)

# ===== Bookmark =====
# - https://regex101.com                visual tester + explanations
# - https://debuggex.com                railroad diagrams
# - 'Mastering Regular Expressions' (Friedl) -- the only book worth reading
# - https://www.regular-expressions.info
# - https://github.com/google/re2       linear-time regex engine

# ===== Portfolio project (4-8 hours) =====
# Build a small log analyser:
# 1) Parse a real production log format (nginx, Apache, JSON-lines app log)
# 2) Compile patterns at module scope, named groups, verbose mode
# 3) Summarise: top paths, top errors, p95 latency, requests by hour
# 4) Detect anomalies: 5xx spikes, unusual user agents, repeated 4xx from one IP
# 5) CLI with --since, --until, --top N flags
# 6) Tests: known-good + known-bad samples
# 7) README explains the patterns used + complexity

# Bonus:
# - Run via cron + write daily summary to a dashboard
# - Stream mode: tail -f + live updates
# - Detect + flag ReDoS-prone patterns in your own codebase

# ===== What 'good' looks like =====
# - Patterns are short, named, anchored
# - Verbose mode used for any non-trivial regex
# - Compiled at module scope, not in loops
# - Tests cover edge cases (truncated lines, UTF-8, etc.)
# - ReDoS-prone shapes refused or rewritten
# - Documented complexity (engines + worst-case input size)

# ===== Common mistakes to avoid =====
# - re.match vs re.search confusion
# - Greedy quantifiers eating across lines unintentionally
# - No anchors -> partial matches accepted
# - Recompiling inside the hot loop
# - 'Email regex' that rejects valid addresses

# ===== Next steps =====
# - Learn lookbehinds (variable-length in modern engines)
# - PCRE2 advanced features: atomic groups, possessive quantifiers
# - Parser combinators when regex stops scaling
# - Tree-sitter for code parsing
# - Anti-patterns in your codebase: grep for nested quantifiers

# ===== Self-test =====
# If you can:
# 1) Parse a real production log format into a dataframe in 20 minutes
# 2) Spot a ReDoS pattern in a PR and suggest a safe rewrite
# 3) Decide regex vs library for any 'parse X' task in under a minute
# you have completed the track. Ship the log analyser and call it done.

# ===== Track wrap-up =====
# Regex is a tool, not a language to live in. Use it for line-oriented text,
# log parsing, extraction, validation. Reach for a real parser when nested
# structure or correctness matters. The track makes you fluent enough to know
# which is which — that judgment is the actual skill.

// /certificate/regex