Forem: CJ

LGTM != Production Ready: Why your CI pipeline is missing the most important step

CJ — Wed, 04 Feb 2026 22:18:34 +0000

We have linters for syntax and scanners for security. It’s time we started linting for "will this wake me up at 3 AM?"

We have all been there.

You submit a Pull Request. The CI passes green. Your colleagues review it and comment "LGTM!" The code is merged and deployed.

Three days later, at 3:17 AM, PagerDuty fires.

The root cause wasn't a syntax error. It wasn't a logic bug that unit tests could catch. It was something subtle: an HTTP client missing a timeout setting that caused a cascading failure when a downstream service hiccuped.

The "Senior Intuition" Gap
Why did the PR review miss that missing timeout?

Because standard code reviews usually focus on code style, logic correctness, and maintainability. Standard static analysis tools catch syntax errors or obvious security flaws.

But nobody is actively grepping for operational maturity.

Usually, catching these latent failure modes relies on "senior engineer intuition." It's that Spidey-Sense that a battle-hardened SRE develops after years of being woken up on-call. They glance at code and immediately think: “Where is the backoff retry logic here?” or “This unchecked environment variable is going to brick boot-up one day.”

The problem is that senior intuition doesn't scale. You can't clone your best SRE to review every PR.

The Failure of Checklists
Many organizations try to solve this with the dreaded "Production Readiness Checklist" — a dusty Confluence page with 50 questions like "Have you considered failure domains?"

Let’s be honest: nobody uses these. They are manual, tedious, done at the very end of the development lifecycle (too late to change architecture), and are usually just "checkbox theatre" to appease management.

If it's not automated, it doesn't exist.

Shifting "Operability" Left
We need to treat operational requirements the same way we treat code style. If gofmt fails, you can't merge. If your code contains latent operational risks, you shouldn't be able to merge either.

I wanted a tool that codified that "senior engineer intuition" into something executable. I wanted a scanner that doesn't care about my variable names, but cares deeply about whether my application will survive a partial network outage.

Since I couldn't find one that fit my needs, I built it.

Introducing Production-Readiness
Production-Readiness is an open-source, opinionated scanner designed to detect operational blind spots before they hit production.

It’s not a replacement for Prometheus or Datadog. It’s a pre-flight check. It looks for the patterns that look "correct" in code but cause fires in production.

What does it actually catch?
Unlike a standard linter, this tool is looking for semantic operational patterns. Here are just a few examples of rules that are difficult to catch with standard regex grep:

1.The "Hanging Client" Trap It's shockingly easy in many languages to instantiate an HTTP client with infinite timeouts by default.

The Risk: A slow downstream dependency ties up all your threads/goroutines, eventually crashing your service.
The Fix: The scanner flags clients initialized without explicit timeouts.

2.Missing Graceful Shutdown

The Risk: When Kubernetes scales down a pod, it sends a SIGTERM. If your app doesn't catch it and finish in-flight requests, you drop user traffic during every deployment or auto-scale event.
The Fix: The scanner looks for the presence of signal handling wiring.

3.Unvalidated Configuration

The Risk: Your app ne``eds an API_KEY environment variable to start. You deploy, and it crash-loops because the variable was missing in the new environment.
The Fix: The scanner checks if critical configuration inputs have validation checks associated with them.

Seeing it in Action
The tool is written in Go and designed to be a single binary you can drop into any CI pipeline.

You run it against your source code directory:

$ pr scan ./my-microservice

And it gives you a prioritized report of operational risks:

Conclusion
The gap between "code that works" and "code that runs reliably in production" is massive. We need to stop relying on hope and manual checklists to bridge that gap.

By automating the detection of operational anti-patterns, we can ship faster and, more importantly, sleep better.

The project is open source and we are just getting started defining the rules of what makes software "production-ready."

If you've ever been burned by a "silly" configuration mistake in prod, give it a spin.

👉 Star the repo on GitHub: https://github.com/chuanjin/production-readiness

🚀 Introducing Production Readiness — A Practical Guide to Shipping Software That Survives Reality

CJ — Fri, 02 Jan 2026 16:31:26 +0000

Shipping code is easy.
Running it reliably in production is not.

After years of working as a senior software engineer and tech lead across large enterprises and startups, I’ve repeatedly seen the same pattern:

Systems that work perfectly in development
MVPs that collapse under real traffic
Teams reinventing the same production checklists again and again

So I decided to turn that experience into an open-source project:

👉 Production Readiness

What Is Production Readiness?

Production Readiness is a curated, opinionated, and practical checklist for engineers who want to ship software that is:

Observable
Secure
Scalable
Operable
Maintainable

It is not a theoretical document or a vendor pitch.
It is a hands-on guide based on real production incidents, postmortems, and lessons learned the hard way.

Think of it as:

A pre-flight checklist before going live
A review guide for architecture and DevOps decisions
A shared vocabulary between developers, SREs, and tech leads

Why This Project Exists

Most teams focus heavily on:

Features
Velocity
Frameworks

Far fewer invest early in:

Observability
Failure modes
Operational ownership
Security defaults
Cost awareness

The result?

“It worked yesterday. Why is production down?”

This repository aims to close that gap by answering questions like:

What must be in place before launch?
What should be automated vs manual?
What risks are acceptable at each stage?
What do experienced teams check instinctively — but never write down?

What’s Inside the Repository?

The project is structured into clear, actionable sections, including:

Architecture & Design Readiness
Deployment & CI/CD
Observability (logs, metrics, tracing)
Security & Access Control
Reliability & Failure Handling
Scalability & Performance
Operations & Incident Response
Cost & Sustainability

Each item is:

Concrete (not buzzwords)
Tool-agnostic where possible
Suitable for startups and mature systems

Who Is This For?

If you are:

A senior engineer reviewing systems before launch
A tech lead setting engineering standards
A startup founder shipping your first production system
A DevOps/SRE tired of repeating the same advice

This project is for you.

Even if you disagree with parts of it — that’s a feature, not a bug. It’s designed to spark discussion and improvement.

Open Source & Community-Driven

This is an open-source project, and I want it to grow with the community.

You can contribute by:

Suggesting missing checklist items
Sharing real-world lessons learned
Improving structure or clarity
Adding examples from different domains (SaaS, IoT, fintech, etc.)

⭐ If you find it useful, please consider giving it a star — it helps the project reach more engineers and signals that this kind of practical knowledge matters.

👉 Repository: https://github.com/chuanjin/production-readiness

Final Thoughts

Production readiness is not a checkbox you tick at the end.
It’s a mindset you build into how you design, develop, and operate software.

My hope is that this project helps teams:

Fail less catastrophically
Sleep better after deployments
Spend more time building value instead of firefighting

If that resonates with you, I’d love your feedback — and your star ⭐.

Thanks for reading.

Connect Django to PostgreSQL in Docker

CJ — Sat, 23 May 2020 12:04:28 +0000

Django uses SQLite database by default, now we want to switch it to postgreSQL. Firstly, we fetch postgreSQL docker image and start an instance

docker pull postgres
docker run --name my-postgres -v /tmp/my-pgdata:/var/lib/postgresql/data -e POSTGRES_PASSWORD=my-password -p 127.0.0.1:5432:5432 -d postgres

The docker instance name can be whatever you want, here it's named my-postgres for instance, and we mount a volume (e.g /tmp/my-pgdata) to our container, so that the database files are easier to access for other tools or applications on our host system. And remember to forward the default postgreSQL port and use -d to put it to background. Next, we install postgreSQL command line client if you haven't done that yet.

sudo apt-get install postgresql-client

Then, we connect to postgreSQL, either command below should work, postgres is the default database and user name

psql postgresql://postgres:my-password@127.0.0.1:5432/postgres
docker exec -it my-postgres psql postgresql://postgres:my-password@127.0.0.1:5432/postgres

If everything goes as expected, we should be able to connect and list the databases

~ ❯ docker exec -it my-postgres psql postgresql://postgres:my-password@127.0.0.1:5432/postgres
psql (12.3 (Debian 12.3-1.pgdg100+1))
Type "help" for help.

postgres=# \l
                                 List of databases
   Name    |  Owner   | Encoding |  Collate   |   Ctype    |   Access privileges
-----------+----------+----------+------------+------------+-----------------------
 postgres  | postgres | UTF8     | en_US.utf8 | en_US.utf8 |
 template0 | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
           |          |          |            |            | postgres=CTc/postgres
 template1 | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
           |          |          |            |            | postgres=CTc/postgres
(3 rows)

After it's up and running, we install the postgreSQL adapter psycopg2 to our Django project

pip install psycopg2

Modify settings.py in the project to use Postgres instead

. . .

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'postgres',
        'USER': 'postgres',
        'PASSWORD': 'my-password',
        'HOST': '127.0.0.1',
        'PORT': '5432'
    }
}

. . .

Now, we are ready to go

python manage.py makemigrations
python manage.py migrate
python manage.py createsuperuser
python manage.py runserver

Let's switch to the database, we can see the default tables are created by Django, cheers!

postgres=# \c postgres
You are now connected to database "postgres" as user "postgres".
postgres=# \dt
                   List of relations
 Schema |            Name            | Type  |  Owner
--------+----------------------------+-------+----------
 public | account_emailaddress       | table | postgres
 public | account_emailconfirmation  | table | postgres
 public | auth_group                 | table | postgres
 public | auth_group_permissions     | table | postgres
 public | auth_permission            | table | postgres
 public | auth_user                  | table | postgres
 public | auth_user_groups           | table | postgres
 public | auth_user_user_permissions | table | postgres
 public | authtoken_token            | table | postgres
 public | django_admin_log           | table | postgres
 public | django_content_type        | table | postgres
 public | django_migrations          | table | postgres
 public | django_session             | table | postgres
 public | django_site                | table | postgres
(18 rows)

Let's deploy now

CJ — Wed, 13 May 2020 21:38:00 +0000

Previously, we have Setup the blog using Hexo and deploy it to Github page. Additionally, we can deploy it to Vercel(formerly zeit). We can either go to their website to connect it to our Github, Gitlab, etc, or install command line interface and deploy with one hit.
npm i -g vercel
Just run vercel or vc inside the project, it will guide you to setup for the first time and deploy automatically. Note, the command was used to be called now.

Bring fortune to your Linux terminal with cowsay figlet lolcat

CJ — Fri, 08 May 2020 21:07:41 +0000

We will cover a few interesting commands today, they are figlet toilet lolcat fortune cowsay shuf. To learn a new command, I believe the best way is always to check tldr for the basic usage and then play with it.

Not only cow and dragon, but also many other options are available to choose. Check them with

ls /usr/share/cowsay/cows

To pick one randomly, shuf comes in. And to fetch only file name without extension, there're more than one way to do so.

Now, time to put them all together, and try to run it a few more times to see the results.

echo "Enjoy and have fun\!" | lolcat -a

Learn AWK by examples

CJ — Thu, 07 May 2020 18:49:15 +0000

Practise makes perfect.
Good code and examples are usually self-explanatory.

Check man or GNU online guide to get more information.

Alternatives of man in Linux command line

CJ — Fri, 01 May 2020 20:46:11 +0000

When we need help in Linux command line, man is usually the first friend we check for more information. But it became my second line support after I met other alternatives, e.g. tldr, cheat and eg.

tldr

tldr stands for too long didn't read, it is a simplified and community-driven man pages. Maybe we forget the arguments to a command, or just not patient enough to read the long man document, here tldr comes in, it will provide concise information with examples. And I even contributed a couple of lines code myself to help a little bit with the project on Github. It is very easy to install: npm install -g tldr, and there are many clients available to pick to be able to access the tldr pages. E.g. install Python client with pip install tldr,

To display help information, run tldr -h or tldr tldr.

Take curl as an example

tldr++

tldr++ is an interactive tldr client written with go, I just steal the gif from its official site.

cheat

Similarly, cheat allows you to create and view interactive cheatsheets on the command-line. It was designed to help remind *nix system administrators of options for commands that they use frequently, but not frequently enough to remember. It is written in Golang, so just download the binary and add it into your PATH.

eg

eg provides useful examples with explanations on the command line.

So I consult tldr, cheat or eg before I ask man and Google.

Capture Network Packet

CJ — Tue, 28 Apr 2020 15:21:17 +0000

Tcpdump is a very useful tool to capture network packets.
e.g. to capture TCP packet from interface lo0 via port 9999

sudo tcpdump -i lo0 port 9999 -XX -v

Here demostrate sending some UDP packets, using tcpdump to capture them and using Tcpreplay to playback.

Send some UDP packets via port 9999
Listen UDP packets from port 9999
Capture UDP packet using Tcpdump, save captured packets into a file
Playback captured packets
Listen UDP packets to verify

Let's have more fun! Assuming we have captured some UDP packets using the command below:

sudo tcpdump -i en0 udp port 3333 -XX -v -w li.pcap

Then we use tcprewrite command to reverse the source and destination.

And if we double check the modified .pcap file, it shows as we want.

I also wrote a shell script to rewrite the network package automatically.

References:

AQI

CJ — Tue, 28 Apr 2020 14:11:23 +0000

Air Quality Index

I'v been experimenting to fetch data related to AQI in China recently.

A good resource is http://aqicn.org, which provides air pollution data in a good way by city, and I try to write a python script to crawl the data from it.

Another website is http://www.stateair.net/, it reports AQI from US consulate in Chinese major cities, i.e. Beijing, Shanghai, Guangzhou, Chengdu and Shenyang. Similarly, the code to fetch data from it shown below.

Both of the code above are using Python and handy packages like requests and Beautiful Soup.

The stateair website also provides historical data for download in CSV format, therefore I use those data to create a simple visulization page. Check it from https://chuanjin.github.io/pm25/ and source code is availabe from Github repo.

Last but not least, I found pm25.in website, and they provide real time data for all Chinese cities, even better, they have opened their API for develper and I also created a Python library based on their API. Code available from https://github.com/chuanjin/python-aqi-zh

New Vim Hack

CJ — Tue, 28 Apr 2020 13:55:00 +0000

Previously I am using spf13 for my vim configuration. However it is a bit sluggish for me since it includes too much settings and plugins which might not be needed for my daily usage, therefore I deicide to move to this vimrc.

New plugins installed manually such as vim-rails, vim-autoformat, YouCompleteMe, tagbar, vim-ctrlp-tjump etc.

Ctags is also needed for go to definition.

I remove/comment out the line to have deafault key mapping for multiple selection in plugins_config.vim

let g:multi_cursor_next_key="\<C-s>"

Here is how it looks for my_configs.vim

Final look:

Transfer file over TCP/UDP

CJ — Tue, 28 Apr 2020 13:44:18 +0000

This is a small lab I have done to see how easy to use python to transfer file over TCP and UDP. File formats including plain text, MS word, pdf, image and vedio.

MQTT security

CJ — Tue, 28 Apr 2020 13:18:13 +0000

We have covered the MQTT Basics and MQTT with websockets support, now we talk about security.