Developer Productivity

A `.gitignore` file uses glob-style patterns to tell Git which files and directories to never track, regardless of whether they exist in the working directory — build artifacts, dependency folders, local environment files, and editor-specific metadata are the most common candidates. Patterns are matched relative to the `.gitignore` file's own location unless they start with a slash, and a trailing slash restricts a pattern to directories only — small syntax details that are easy to get wrong in a way that either ignores too much or too little.

SQL as a language has a formal ANSI/ISO standard, but every major database — SQL Server, MySQL, PostgreSQL, Oracle — extends and deviates from it with its own dialect-specific functions, quoting conventions, and syntax extensions. A SQL formatter that only handles the standard subset will mis-format or fail on real-world queries that use any database's specific extensions, which is why dialect awareness matters more for SQL tooling than it does for most other structured languages.

Markdown itself was never formally specified by its original creator, which led to years of incompatible dialects across different tools; the CommonMark specification was created specifically to end that fragmentation with a precise, testable grammar. Markdown tables specifically are not part of CommonMark at all — they're a widely-adopted extension originating from GitHub Flavored Markdown (GFM), which is why table rendering support varies more between Markdown processors than most other Markdown syntax.

Cron expressions describe a recurring schedule using five whitespace-separated fields — minute, hour, day of month, month, and day of week — each accepting a specific value, a range, a step, or a wildcard. The fields' fixed order and mixed semantics (day of month and day of week are evaluated with OR logic when both are restricted, not AND) is the single most common source of a cron schedule silently running at the wrong time.

A common task when starting a new project is generating a `.gitignore` tailored to your actual stack rather than reusing a generic template that misses framework-specific build artifacts. Use the Gitignore Generator to produce a stack-appropriate starting file, then review it against your project's actual build output before the first commit — it's far easier to add a missing pattern before sensitive or generated files are ever tracked than to purge them from history afterward.

When working with SQL across a team or reviewing a slow query log, use the SQL Formatter to make a query's structure — joins, subqueries, conditionals — actually readable, and the SQL Minifier for the opposite case, when a query needs to be embedded compactly in application code or a configuration value. Use the SQL Pretty Diff when comparing two versions of a query (before and after an optimization, or across a migration) to see exactly what changed rather than re-reading both queries side by side from scratch.

When documenting a project or writing a comparison table for a README or wiki page, use the Markdown Table Generator to build correctly-aligned rows and headers rather than hand-aligning pipe characters, which is tedious and easy to get subtly misaligned in a way that still renders but looks wrong in a plain-text diff.

When setting up a recurring automated task — a backup script, a cleanup job, a scheduled report — use the Cron Expression Generator to build the schedule expression from a plain description of when it should run, then verify the generated expression's next few trigger times before deploying it, since a cron mistake typically doesn't produce an error, just a job that silently runs at the wrong time or not at all.

Mistake: adding a `.gitignore` pattern after files matching it have already been committed. Git only applies ignore rules to untracked files — a file that's already tracked keeps being tracked regardless of a new matching pattern, until it's explicitly removed from version control with a separate command.

Mistake: assuming a SQL query formatted or validated against the ANSI standard will behave identically across SQL Server, MySQL, PostgreSQL, and Oracle — dialect-specific functions, quoting rules (backticks versus double quotes for identifiers), and pagination syntax (LIMIT versus TOP versus ROWNUM) all differ, and code that works on one database can fail outright on another.

Troubleshooting: if a Markdown table renders as plain text with visible pipe characters instead of an actual table, check for a missing or malformed separator row (the line of dashes and colons directly under the header row) — it's easy to accidentally delete or mis-type when hand-editing a table, and its absence is the single most common reason a table silently fails to render.

Troubleshooting: if a cron job runs at an unexpected time, check the day-of-month and day-of-week fields specifically — when both are restricted to something other than a wildcard, most cron implementations treat them as an OR condition, not an AND, which surprises people expecting the schedule to require both conditions simultaneously.

`.gitignore` pattern syntax is documented directly in Git's own official documentation (the gitignore manual page) rather than a separate standards body — Git itself is the authority on how its own ignore patterns are matched.

SQL is standardized by ANSI/ISO (ISO/IEC 9075), though in practice every major database implements a superset with vendor-specific extensions, which is why dialect-aware formatting matters in practice more than strict adherence to the base standard.

Markdown's core syntax is standardized by the CommonMark Specification; table syntax specifically originates from GitHub Flavored Markdown (GFM)'s extension to CommonMark, not the core specification itself.

The five-field cron schedule format originates from Unix cron implementations and is described in POSIX; many modern schedulers (systemd timers, cloud-based schedulers) extend the base five-field format with additional fields (such as seconds) or convenience shortcuts (such as @daily or @hourly) that aren't part of the original format.

Format SQL for anything a human will read or review (code review, documentation, debugging); minify it only when a compact representation is actually required, such as embedding a query in a constrained configuration value — formatting and minifying are complementary tools for different audiences, not competing choices for the same use case.

When authoring a `.gitignore`, start from a stack-specific generated template rather than a single generic one, and review it against your project's actual build output — a template that's close but not exact for your specific tooling is a common source of either tracked build artifacts or accidentally-ignored source files.

When a recurring task's timing genuinely matters (billing cycles, data retention, off-peak maintenance windows), verify a generated cron expression's actual next several trigger times before deploying it, rather than trusting the expression's syntax alone — syntactically valid and semantically correct are not the same guarantee for cron schedules specifically, given the day-of-month/day-of-week OR-logic surprise.

Beyond the basic five-field syntax, real-world cron usage almost always involves at least one of the special characters: a comma for a list of values (e.g. running at minutes 0 and 30), a hyphen for a range (e.g. hours 9 through 17), and a slash for a step value (e.g. every 15 minutes within a range) — combining these correctly is what makes an expression like "*/15 9-17 * * 1-5" (every 15 minutes, 9am to 5pm, Monday through Friday) both compact and precise.

A cron schedule's actual effective time zone is a frequent source of confusion: most cron implementations run in the system's local time zone by default, which means a schedule that seems correct in development can trigger at an unexpected hour once deployed to a server running in a different time zone, or shift unexpectedly around daylight saving transitions in time zones that observe it.

For genuinely simple, common schedules, many modern schedulers support shorthand strings (@daily, @weekly, @monthly) as an alternative to the five-field syntax — these aren't part of the original cron specification and aren't universally supported, so verify your specific scheduler actually accepts them before relying on the shorthand form in production.