Incremental History Sync Needs Explicit Cache Coverage
Keep local-history caches truthful by committing records, coverage ranges, and source watermarks together, then exposing partial and offline states explicitly.
01Fichil · Focused data tasks
Make spreadsheet work repeatable.
Excel / CSV cleanup and recurring reports.
Start with a small sample and the output you need. Agree the rules, deliverables and quote before work begins.
02Services
Start with one defined task
Excel / CSV cleanup and repeatable reports are the first focused service. The engineering notes below show how I approach verification and delivery.
Combining exports, fixing inconsistent columns, or rebuilding the same weekly report? Start with one input sample and the result you need.
See the Service and ScopeScope, price and timing are confirmed after reviewing the sample. Work starts only after both sides agree.
56bilingual engineering notes
Open sourcesite repositoryCI + exact SHArelease evidence03Blog
Latest Engineering Notes
Recent field notes from debugging, backend work, DevOps, and AI-assisted development.
Prove Message-Automation Safety Offline Before Touching a Live Client
Use a mock adapter, trusted policy, durable action state, and fault-injection tests to verify stop conditions before connecting message automation to a live client.
Export a Report Through One Cursor
Separate all-rows XLSX export from page queries: consume one result cursor, preserve permissions and cell conversion, stage the file, and verify failure cleanup.
04Signal index
Follow the systems you work with.
Move through the notebook by engineering domain, from production debugging to delivery and integration.
05Core Cases
Selected Engineering Cases
Public, source-backed examples showing how I diagnose, change, and verify complex systems without exposing client identities or private data.
01Reliability
SQLPerformanceProduction
Production Reliability & Performance
A production dashboard showed zero while business data existed. The request path loaded large detail sets into Java, timed out, and left the UI's default value visible as if it were real data.
Change scope
- Trace the request from UI state through Java queries and production data volume
- Move summary calculation into database aggregates without changing the API contract
Verification evidence
- Reconciled old and new results with read-only checks
- Made failures visible instead of presenting them as valid zeroes
02Open Source
Open SourceAI-AssistedSites
AI-Assisted fichil.com
This site is an open-source delivery system: Hugo Markdown remains the content source, vinext renders the Sites application, and validated changes move through CI, exact-SHA release evidence, and version-based rollback.
Change scope
- Bilingual content and application changes remain reviewable in Git
- People define release policy; protected checks can auto-merge narrowly scoped blog updates
Verification evidence
- The deployed commit is exposed through /version.json
- Production rollback uses a previously known-good Sites version
03Integration
WMS/TMS/YMSSAP/ERPReconciliation
Enterprise Logistics Integration
Integration work across WMS, TMS, YMS, SAP/ERP, carriers, billing, proof of delivery, and OpenAPI requires more than connecting endpoints: identity, ownership, state, retry, and reconciliation rules must agree.
Change scope
- Define contracts, ownership boundaries, state mappings, idempotency, and error semantics
- Close inbound, inventory, outbound, transport, billing, yard, and external API flows
Verification evidence
- Verify final state through database reconciliation and full-domain smoke scenarios
- Keep unavailable third parties outside the platform's internal acceptance decision
06Working method
An Open, Reviewable Way of Working
I use this site as both an engineering notebook and a public record of how I work. Each useful case starts from observed behavior, follows the real data and runtime path, limits the change surface, and ends with verification.
- Evidence before edits: logs, process arguments, database state, network paths, and reproducible failures.
- Small, reversible changes: preserve existing contracts and parallel business flows unless the requirement explicitly changes them.
- Verification at the real boundary: reconcile data, test retries and failures, build release artifacts, and confirm the deployed version.
- AI-assisted, policy-gated: people define the delivery policy and remain accountable; narrowly scoped bilingual blog PRs may auto-merge only after protected checks, while other changes remain human-reviewed.
Core Stack
01Java / Spring / REST APIs
02MySQL / SQL troubleshooting
03Linux / Runtime / Networking
04Docker / GitHub Actions
05WMS / TMS / YMS / SAP integration
06Codex / AI-assisted engineering
From system signal to exact release
OBSERVE
Capture reproducible runtime signals.
ISOLATE
Narrow the real failure boundary.
VERIFY
Confirm the repair with reviewable evidence.
RELEASE
Deliver the exact reviewed commit.
What do you want your files to produce?
Describe the manual step, the files you start with and the output you want. A short description is enough for the first email; samples and scope can be agreed afterwards.
Start with a short description
Tell me the result you need
You do not need a full specification. Use these prompts and leave anything you do not know blank.
fichilzhang@gmail.com
The button opens your email app. Review and send the message yourself, or paste the template into webmail.
What I need to produce: What I currently do by hand: Input files and approximate rows / frequency: Desired output (an example is welcome): My system / Excel version: Preferred date and budget range, if known: I can provide an anonymized sample: