Cryo Learn

گیت واقعاً چطور کار می‌کند: blob، tree، کامیت و ref

Thu, 29 Oct 2026 09:00:00 +0000

بیشتر آدم‌ها گیت را به شکل فهرستی از دستورها یاد می‌گیرند که باید حفظ شوند. این روش جواب می‌دهد تا وقتی که چیزی خراب شود: یک rebase تاریخچه را طوری بازنویسی می‌کند که انتظارش را نداشتید، یک reset --hard کار یک روزتان را «پاک» می‌کند، یا ناگهان در وضعیت detached HEAD هستید. آن‌وقت دستورها دیگر منطقی به نظر نمی‌رسند.

در لایهٔ زیرین، گیت به‌طرز شگفت‌آوری ساده است. یک انبار کلید-مقدار از اشیاء تغییرناپذیر است، به‌علاوهٔ چند اشاره‌گرِ جابه‌جاشدنی که به آن‌ها ref می‌گویند. وقتی هر دو را با چشم خودتان ببینید، هر دستور گیت خلاصه می‌شود در «چند شیء اضافه کن، بعد یک اشاره‌گر را جابه‌جا کن».

اگر با کار روزمره با برنچ‌ها راحت باشید، بیشترین بهره را از این مقاله می‌برید. اگر نه، اول روش کاری عملی با برنچ‌های گیت برای مبتدی‌ها را بخوانید.

ذخیره‌سازی بر اساس محتوا

گیت همه‌چیز (محتوای فایل‌ها، پوشه‌ها، کامیت‌ها) را به شکل شیء (object) ذخیره می‌کند و نام هر شیء، هش SHA-1ِ محتوای آن است. از گیت بخواهید یک متن را هش کند:

$ echo 'hello' | git hash-object --stdin
ce013625030ba8dba906f756967f9e9ca394464a

این دستور را روی هر کامپیوتری و در هر مخزنی اجرا کنید، همین هش را می‌گیرید. گیت یک سرآیند کوچک (کلمهٔ blob، یک فاصله، اندازه بر حسب بایت و یک بایت null) و بعد از آن محتوا را هش می‌کند، و شما می‌توانید بدون گیت هم همین را بازتولید کنید:

$ printf 'blob 6\0hello\n' | sha1sum
ce013625030ba8dba906f756967f9e9ca394464a  -

این طراحی پیامدهای بزرگی دارد. محتوای یکسان فقط یک بار ذخیره می‌شود، هر چقدر هم که فایل‌ها یا کامیت‌های زیادی آن را داشته باشند. و چون نام به محتوا وابسته است، یک شیء هرگز نمی‌تواند تغییر کند: یک بایت را عوض کنید و یک شیء دیگر با یک نام دیگر خواهید داشت.

چهار نوع شیء

نوع	چه چیزی را ذخیره می‌کند	به چه اشاره می‌کند
blob	محتوای یک فایل (بدون نام و بدون مجوزها)	هیچ‌چیز
tree	یک پوشه: نام‌ها، حالت‌ها (mode) و هش ورودی‌هایش	blobها و treeهای دیگر
commit	یک عکس فوری: نویسنده، ثبت‌کننده، تاریخ و پیام	یک tree و کامیت(های) والد
tag	یک تگ annotated: سازندهٔ تگ، پیام و امضای اختیاری	معمولاً یک کامیت

بیایید یک مخزن کوچک بسازیم و به اشیاء واقعی نگاه کنیم:

git init -b main demo && cd demo
mkdir src
echo "# Demo" > README.md
echo 'print("hello")' > src/app.py
git add . && git commit -m "First commit"

همین یک کامیت پنج شیء ساخت که به شکل فایل‌های فشرده زیر .git/objects/ ذخیره شده‌اند؛ نام پوشه دو کاراکتر اول هش است و نام فایل بقیهٔ آن:

$ find .git/objects -type f
.git/objects/08/05455a24b6c68fbc38d0fa5d121f735984285d
.git/objects/11/b15b1a4584b08fa423a57964bdbf018b0da0d5
.git/objects/16/ae6a2afcc370fa1a06bc31edcacc3a7f2c41cc
.git/objects/60/546c2588e9d75d822392d6f296e1fd99f04c96
.git/objects/ef/6ad6746727fa1d0efcf4a020ec3caeda5ccf64

بیشتر هش‌های شما یکی خواهند بود

blobها و treeها فقط به محتوا وابسته‌اند؛ پس اگر همین فایل‌ها را ساخته باشید، آن چهار هش روی کامپیوتر شما هم دقیقاً همین‌ها هستند. اما هش کامیت فرق می‌کند: نام، ایمیل و زمانِ دقیقِ شما در آن هست.

خواندن اشیاء با cat-file

git cat-file -p هر شیئی را خوانا چاپ می‌کند. از کامیتی شروع کنید که HEAD به آن اشاره می‌کند:

$ git cat-file -p HEAD
tree 60546c2588e9d75d822392d6f296e1fd99f04c96
author Ada <ada@example.com> 1793256281 +0000
committer Ada <ada@example.com> 1793256281 +0000

First commit

یک کامیت فقط چند خط متن است. دقیقاً به یک tree اشاره می‌کند: عکس فوریِ کل پروژه. آن را دنبال کنید:

$ git cat-file -p 60546c2
100644 blob 0805455a24b6c68fbc38d0fa5d121f735984285d    README.md
040000 tree ef6ad6746727fa1d0efcf4a020ec3caeda5ccf64    src

$ git cat-file -p ef6ad67
100644 blob 11b15b1a4584b08fa423a57964bdbf018b0da0d5    app.py

$ git cat-file -p 11b15b1
print("hello")

دقت کنید نام فایل‌ها کجا نگه داشته می‌شود: در treeها، نه در blobها. تغییر نام یک فایل یک tree تازه می‌سازد اما از همان blob قبلی استفاده می‌کند.

حالا یک فایل را تغییر دهید و دوباره کامیت کنید:

$ echo 'print("hello, world")' > src/app.py
$ git commit -am "Greet the world"
$ git cat-file -p HEAD
tree 17b6cd9de955edb28d8a9b0e4668f588ba3c664a
parent 16ae6a2afcc370fa1a06bc31edcacc3a7f2c41cc
...
$ git cat-file -p 'HEAD^{tree}'
100644 blob 0805455a24b6c68fbc38d0fa5d121f735984285d    README.md
040000 tree b6dcf64039da33b42fb025d2cc49c6d070c65686    src

کامیت جدید یک خط parent دارد که به کامیت اول اشاره می‌کند. tree ریشهٔ آن یک tree تازه برای src دارد (چون app.py تغییر کرده)، اما README.md هنوز به همان blobِ قبلی، یعنی 0805455، اشاره می‌کند. فایل‌های تغییرنکرده هیچ هزینه‌ای ندارند.

دو کامیت: دومی به والدش و به یک tree تازه اشاره می‌کند؛ blobِ README که تغییر نکرده بین هر دو tree مشترک است، و main و HEAD به جدیدترین کامیت اشاره می‌کنند

عکس فوری، نه تفاوت‌ها

هر کامیت یک عکس فوریِ کامل (یک tree) ذخیره می‌کند، نه فهرستی از تغییرات. git diff و git show تغییرات را در لحظه و با مقایسهٔ دو tree محاسبه می‌کنند. برای صرفه‌جویی در فضای دیسک، git gc بعداً اشیاء را در packfileها بسته‌بندی می‌کند و اشیاء مشابه را به شکل delta فشرده می‌کند؛ اما این فقط جزئیاتِ ذخیره‌سازی است و از دید بقیهٔ گیت پنهان است.

refها: برنچ‌ها فایل‌های ۴۱ بایتی هستند

اگر اشیاء هرگز تغییر نمی‌کنند، یک برنچ چطور «جلو می‌رود»؟ برنچ‌ها شیء نیستند؛ ref هستند: فایل‌های کوچکی که یک هش کامیت را در خود دارند.

$ cat .git/HEAD
ref: refs/heads/main

$ cat .git/refs/heads/main
ffb68609991f7ac36c595767d2d91545868364cb

HEAD معمولاً نام برنچ فعلی را نگه می‌دارد و فایلِ برنچ یک هش کامیت را. وقتی کامیت می‌کنید، گیت اشیاء جدید را می‌نویسد و بعد همان یک فایلِ برنچ را با هش جدید بازنویسی می‌کند. از دید برنچ، کامیت کردن فقط همین است.

این چند چیز را توضیح می‌دهد که در غیر این صورت جادو به نظر می‌رسند:

ساختن برنچ آنی است، اندازهٔ مخزن هر چقدر که باشد: git branch experiment فقط یک فایل ۴۱ بایتیِ تازه می‌نویسد. (گیت ممکن است بعداً refها را به یک فایل واحد به نام .git/packed-refs منتقل کند که به همان شکل کار می‌کند.)
detached HEAD یعنی HEAD به‌جای ref: refs/heads/... مستقیماً یک هش کامیت را در خود دارد. کامیت‌های جدید همچنان کار می‌کنند، اما هیچ برنچی جلو نمی‌رود که آن‌ها را به خاطر بسپارد.
تگ‌ها refهایی زیر refs/tags/ هستند که طبق قرارداد هرگز جابه‌جا نمی‌شوند.

یک کامیت را با دست بسازید

برای اینکه ثابت کنیم چیزی بیشتر از این در کار نیست، بیایید فایلی را بدون git add و git commit کامیت کنیم؛ فقط با دستورهای سطح پایین گیت که به آن‌ها «plumbing» می‌گویند:

# 1. Store the content as a blob (-w writes it into .git/objects)
blob=$(echo "Made without git add" | git hash-object -w --stdin)

# 2. Put it into the staging area (the index) under a file name
git update-index --add --cacheinfo 100644 "$blob" NOTES.txt

# 3. Turn the index into a tree object
tree=$(git write-tree)

# 4. Create a commit object pointing to that tree, with HEAD as its parent
commit=$(git commit-tree "$tree" -p HEAD -m "Commit made by hand")

# 5. Move the branch pointer
git update-ref refs/heads/main "$commit"

$ git log --oneline
8e0d264 Commit made by hand
ffb6860 Greet the world
16ae6a2 First commit

یک کامیت کاملاً معمولی. اگر حالا git status را اجرا کنید، می‌بینید NOTES.txt حذف‌شده نشان داده می‌شود: این فایل در کامیت و در index هست، اما ما هرگز آن را در پوشهٔ کاری ننوشتیم. git restore NOTES.txt این را درست می‌کند. این‌ها سه جایی هستند که یک فایل در گیت می‌تواند باشد: پایگاه دادهٔ اشیاء، index و پوشهٔ کاری شما.

این‌ها چه چیزهایی را توضیح می‌دهند

rebase کامیت‌های جدید می‌سازد. هش هر کامیت، هش والدش را هم در بر می‌گیرد. وقتی یک برنچ را rebase می‌کنید، هر کامیت والد تازه‌ای می‌گیرد؛ پس گیت مجبور است کامیت‌های کاملاً جدید با هش‌های جدید بسازد، حتی اگر تغییرات کد یکسان باشند. کامیت‌های قدیمی هنوز وجود دارند؛ فقط برنچ حالا به جای دیگری اشاره می‌کند. به همین دلیل rebase کردنِ کامیت‌هایی که دیگران قبلاً pull کرده‌اند دردسر می‌سازد: آن‌ها هنوز کامیت‌های قدیمی را دارند.

reset فقط یک اشاره‌گر را جابه‌جا می‌کند. git reset --hard HEAD~2 برنچ فعلی را دو کامیت عقب می‌برد (و فایل‌های شما را هم با آن هماهنگ می‌کند). خودِ کامیت‌ها پاک نمی‌شوند.

reflog به خاطر دارد اشاره‌گرها کجا بوده‌اند. هر بار که HEAD یا یک برنچ جابه‌جا می‌شود، گیت آن را ثبت می‌کند. پس یک کامیتِ «گم‌شده» معمولاً فقط یک دستور با شما فاصله دارد:

$ git reset --hard HEAD~2        # oops
$ git reflog
16ae6a2 HEAD@{0}: reset: moving to HEAD~2
8e0d264 HEAD@{1}: ...
$ git reset --hard 8e0d264       # or: git branch rescue 8e0d264

این تور ایمنی تاریخ انقضا دارد

کامیت‌هایی که هیچ برنچ، تگ یا ورودیِ reflogی به آن‌ها نمی‌رسد، بالاخره توسط git gc پاک می‌شوند. به‌طور پیش‌فرض ورودی‌های reflog برای کامیت‌های دست‌نیافتنی بعد از ۳۰ روز منقضی می‌شوند (و برای بقیه بعد از ۹۰ روز). کار گم‌شده را زود بازیابی کنید و هرگز فرض نکنید کامیتی که push نشده تا ابد امن است.

یکپارچگی در خودِ ساختار است. چون هش هر کامیت tree آن را پوشش می‌دهد و هش هر tree، blobهایش را، یک هش کامیت ضامنِ کل تاریخچهٔ پشت سرش است. یک بایت را در هر جای گذشته عوض کنید تا همهٔ هش‌های بعد از آن عوض شوند. (گیت دقیقاً به همین دلیل به‌تدریج از SHA-1 به SHA-256 مهاجرت می‌کند؛ همین حالا هم می‌توانید آن را با git init --object-format=sha256 امتحان کنید.)

دستورهای plumbingِ ارزشمند

دستور	چه کاری می‌کند
`git cat-file -t <obj>`	نوع یک شیء را نشان می‌دهد
`git cat-file -p <obj>`	یک شیء را خوانا چاپ می‌کند
`git ls-tree -r HEAD`	همهٔ فایل‌های tree یک کامیت را به‌صورت بازگشتی فهرست می‌کند
`git rev-parse main`	یک نام (برنچ، تگ، `HEAD~2`…) را به هش تبدیل می‌کند
`git hash-object -w <file>`	یک فایل را به‌عنوان blob ذخیره می‌کند
`git update-ref <ref> <hash>`	یک ref را به یک کامیت اشاره می‌دهد
`git count-objects -vH`	نشان می‌دهد چند شیء وجود دارد و چقدر فضا گرفته‌اند

جمع‌بندی

گیت یک انبار اشیاء بر اساس محتوا است: نام هر شیء هش محتوای آن است، پس اشیاء هرگز تغییر نمی‌کنند.
blobها محتوای فایل‌ها را نگه می‌دارند، treeها پوشه‌ها و نام‌ها را، و کامیت‌ها به یک tree و والد(های) خود اشاره می‌کنند.
کامیت‌ها عکس فوری هستند؛ فایل‌های تغییرنکرده به‌رایگان بین آن‌ها مشترک‌اند.
برنچ‌ها، تگ‌ها و HEAD همه ref هستند: فایل‌های کوچکی که یک هش یا نامِ یک ref دیگر را در خود دارند.
rebase، reset و amend اشیاء جدید می‌سازند و اشاره‌گرها را جابه‌جا می‌کنند. تاریخچه را در جا ویرایش نمی‌کنند، و به همین دلیل reflog معمولاً می‌تواند همه‌چیز را برگرداند.

دفعهٔ بعد که یک دستور گیت غافلگیرتان کرد، دو سؤال بپرسید: چه اشیائی ساخت، و کدام اشاره‌گر را جابه‌جا کرد؟

پروسس‌های لینوکس از درون: fork، exec، سیگنال‌ها و زامبی‌ها

Thu, 29 Oct 2026 09:00:00 +0000

ls را تایپ می‌کنید و Enter را می‌زنید. فهرستی از فایل‌ها ظاهر می‌شود و اعلانِ خط فرمان برمی‌گردد. پشت این ماجرا، کرنل یک پروسس ساخته، برنامه‌اش را عوض کرده، وضعیتِ خروجش را جمع کرده و بعد از آن تمیزکاری کرده؛ فقط با چند فراخوانیِ سیستمی که همهٔ برنامه‌های لینوکس به آن‌ها تکیه دارند.

دانستنِ این فراخوانی‌ها خیلی چیزها را توضیح می‌دهد که در غیر این صورت مرموز به نظر می‌رسند: چرا cd نمی‌تواند یک برنامهٔ بیرونی باشد، کد خروج ۱۳۷ چه معنایی دارد، چرا kill -9 باید آخرین چاره‌تان باشد، پروسس‌های زامبی از کجا می‌آیند و چرا یک کانتینر گاهی دقیقاً ده ثانیه docker stop را نادیده می‌گیرد. مثال‌ها از ماژول os پایتون استفاده می‌کنند که تقریباً یک‌به‌یک به فراخوانی‌های سیستمیِ زیرین نگاشت می‌شود، به‌علاوهٔ ابزارهای استانداردی مثل ps. اگر چند اسکریپت شل نوشته باشید بهرهٔ بیشتری می‌برید؛ نوشتن اسکریپت‌های Bash که خراب نمی‌شوند را ببینید.

فراخوانی‌های fork و exec: هر برنامه‌ای این‌طور شروع می‌شود

لینوکس پروسس‌های جدید را در دو مرحلهٔ جدا می‌سازد:

fork() یک کپی از پروسسِ فراخواننده می‌سازد. والد و فرزند از همان خطِ کد ادامه می‌دهند، با همان محتوای حافظه، فایل‌های باز و متغیرهای محیطی. تنها تفاوت، مقدارِ بازگشتیِ fork() است: در فرزند 0 و در والد، PID فرزند.
exec() برنامه‌ای را که در پروسسِ فعلی اجرا می‌شود با یک برنامهٔ جدید جایگزین می‌کند. PID همان می‌ماند؛ کد، حافظه و پشته دور ریخته می‌شوند و از فایل اجراییِ جدید از نو بارگذاری می‌شوند.

شل ls را این‌طور اجرا می‌کند: خودش را fork می‌کند، بعد فرزند ls را exec می‌کند و والد منتظر می‌ماند. همین کار در پایتون:

import os

print(f"parent: my PID is {os.getpid()}", flush=True)
pid = os.fork()

if pid == 0:
    # Child: a copy of the parent. Replace it with the `ls` program.
    print(f"child:  my PID is {os.getpid()}, my parent is {os.getppid()}", flush=True)
    os.execvp("ls", ["ls", "-d", "/tmp"])
    print("never printed: exec only returns if it fails")
else:
    # Parent: wait for the child and collect its exit status.
    _, status = os.waitpid(pid, 0)
    print(f"parent: child {pid} exited with code {os.waitstatus_to_exitcode(status)}")

$ python3 forkexec.py
parent: my PID is 726920
child:  my PID is 726922, my parent is 726920
/tmp
parent: child 726922 exited with code 0

چرا flush=True مهم است

exec کلِ برنامه را جایگزین می‌کند، از جمله بافرِ خروجیِ پایتون را. اگر خروجی به یک پایپ یا فایل برود بافر می‌شود، و هر چیزی که هنوز flush نشده بی‌صدا از دست می‌رود. همین برای printf زبان C هم صدق می‌کند. قبل از fork یا exec، خروجی را flush کنید.

جدا بودنِ این دو فراخوانی همان چیزی است که شل‌های یونیکس را این‌قدر انعطاف‌پذیر می‌کند. بین fork و exec، فرزند هنوز کدِ شل را اجرا می‌کند؛ پس می‌تواند اول محیطِ خودش را مرتب کند: توصیف‌گرهای فایل (file descriptor) را برای > file یا | جابه‌جا کند، پوشه را عوض کند و متغیرهای محیطی را تنظیم کند. بعد برنامه را exec می‌کند که همهٔ این‌ها را به ارث می‌برد.

این همچنین توضیح می‌دهد چرا cd باید یک دستورِ داخلیِ شل (builtin) باشد. یک پروسسِ فرزند فقط می‌تواند پوشهٔ کاریِ خودش را عوض کند، و این تغییر با خارج شدنش از بین می‌رود. برای عوض کردنِ پوشهٔ خودِ شل، شل باید خودش این کار را بکند.

زندگیِ یک پروسس: شل (PID 4100) یک فرزند (PID 4101) را fork می‌کند، فرزند ls را exec می‌کند، ls با کد ۰ خارج می‌شود، فرزند تا وقتی شل wait را صدا بزند زامبی می‌ماند و بعد ناپدید می‌شود

کدهای خروج و wait

وقتی یک پروسس تمام می‌شود، یک وضعیتِ خروج (exit status) برای والدش باقی می‌گذارد: طبق قرارداد ۰ برای موفقیت و ۱ تا ۲۵۵ برای شکست. والد آن را با wait() یا waitpid() جمع می‌کند و شل آن را در $? می‌گذارد.

اگر پروسس با یک سیگنال کشته شده باشد، شل 128 + شمارهٔ سیگنال را گزارش می‌کند. این‌ها مدام در لاگ‌ها و خروجیِ CI دیده می‌شوند:

کد خروج	معنی
`0`	موفقیت
`1`، `2`، …	برنامه خطایی گزارش کرده (معنایش در هر برنامه فرق می‌کند)
`126` / `127`	دستور پیدا شد اما اجرایی نیست / دستور پیدا نشد
`130`	با SIGINT (۲) کشته شد: کسی `Ctrl`+`C` را زد
`137`	با SIGKILL (۹) کشته شد: اغلب OOM killer (قاتلِ کمبود حافظه)، یا کانتینری که از سقف حافظه‌اش فراتر رفته
`143`	با SIGTERM (۱۵) کشته شد: یک درخواستِ عادیِ خاموش شدن، مثلاً `docker stop` یا یک دیپلوی

سیگنال‌ها: خبر دادن به یک پروسس

سیگنال یک اعلانِ کوچک و ناهمگام است که کرنل یا پروسسِ دیگری (با kill) به یک پروسس می‌فرستد. با وجود اسمش، kill هر سیگنالی را می‌فرستد؛ SIGTERM فقط پیش‌فرض است. آن‌هایی که بیشتر می‌بینید:

سیگنال	شماره	رفتار پیش‌فرض	منبع معمول
SIGHUP	1	پایان دادن	ترمینال بسته شده؛ خیلی از دیمن‌ها با آن تنظیماتشان را دوباره بارگذاری می‌کنند
SIGINT	2	پایان دادن	`Ctrl`+`C`
SIGQUIT	3	پایان دادن + core dump	`Ctrl`+`\`
SIGKILL	9	پایان دادن، قابل گرفتن نیست	`kill -9`، OOM killer
SIGTERM	15	پایان دادن	`kill`، `systemctl stop`، `docker stop`
SIGCHLD	17	نادیده گرفتن	یک پروسسِ فرزند خارج یا متوقف شده
SIGSTOP / SIGTSTP	19 / 20	مکث	`kill -STOP` / `Ctrl`+`Z`

(شماره‌ها مربوط به لینوکس روی x86 و ARM هستند؛ برای دیدنِ فهرست کامل روی سیستم خودتان kill -l را اجرا کنید.)

یک پروسس می‌تواند بیشترِ سیگنال‌ها را با تابعِ خودش مدیریت کند یا نادیده بگیرد. دو سیگنال هرگز قابل گرفتن یا نادیده گرفتن نیستند: SIGKILL و SIGSTOP. کرنل مستقیماً روی آن‌ها عمل می‌کند.

خاموش شدنِ مؤدبانه

به همین دلیل باید اول SIGTERM بفرستید و SIGKILL را فقط به‌عنوان آخرین چاره به کار ببرید. SIGTERM اجازه می‌دهد برنامه درخواستی را که در حال پاسخ دادن به آن است تمام کند، داده‌ها را روی دیسک بنویسد، اتصال‌های پایگاه داده را ببندد و فایل‌های قفل را پاک کند. SIGKILL آن را وسطِ یک دستورالعمل متوقف می‌کند، بدون هیچ فرصتی برای تمیزکاری.

مدیریتِ SIGTERM چند خط بیشتر نیست:

import signal, time

running = True

def stop(signum, frame):
    global running
    print(f"got {signal.Signals(signum).name}, finishing the current job...", flush=True)
    running = False

signal.signal(signal.SIGTERM, stop)

while running:
    time.sleep(1)        # pretend to work
print("clean exit", flush=True)

$ python3 worker.py &
$ kill %1
got SIGTERM, finishing the current job...
clean exit

تابعِ مدیریت‌کننده فقط یک پرچم را تنظیم می‌کند؛ حلقهٔ اصلی آن را بررسی می‌کند و در یک نقطهٔ امن خارج می‌شود. انجام دادنِ کارِ واقعی داخلِ یک signal handler پرخطر است، چون می‌تواند برنامهٔ شما را هر جایی قطع کند. اسکریپت‌های Bash همین توانایی را با trap 'cleanup' TERM دارند.

مدیرهای سرویس هم از همین الگو پیروی می‌کنند: systemctl stop سیگنال SIGTERM می‌فرستد، صبر می‌کند (به‌طور پیش‌فرض ۹۰ ثانیه) و بعد SIGKILL می‌فرستد. docker stop همین کار را با یک مهلتِ ۱۰ ثانیه‌ای انجام می‌دهد.

زامبی‌ها

وقتی یک فرزند خارج می‌شود، کرنل هنوز نمی‌تواند آن را کاملاً دور بریزد: ممکن است والد هنوز وضعیتِ خروجش را بخواهد. پس پروسس به یک زامبی تبدیل می‌شود. دیگر حافظه یا فایلِ بازی ندارد، فقط یک ورودی در جدول پروسس‌ها که PID و وضعیتِ خروجش را نگه می‌دارد و منتظر است والد wait() را صدا بزند. به جمع‌آوریِ این وضعیت درو کردن (reaping) می‌گویند و زامبی را حذف می‌کند.

والدی که هرگز wait() را صدا نمی‌زند، زامبی‌ها را پشت سر جا می‌گذارد. بیایید یکی بسازیم:

import os, time

pid = os.fork()
if pid == 0:
    os._exit(0)          # the child exits immediately...
print(f"child PID: {pid}")
time.sleep(60)           # ...but the parent never calls wait()

$ python3 zombie.py &
child PID: 726905
$ ps -o pid,ppid,stat,cmd --ppid $!
    PID    PPID STAT CMD
 726905  726903 Z    [python3] <defunct>

حرف Z در ستونِ STAT و عبارتِ <defunct> نشانهٔ زامبی‌اند. چند زامبی بی‌خطرند، اما هر کدام یک PID را اشغال می‌کنند، و یک سرورِ باگ‌دار که زامبی نشت می‌دهد در نهایت می‌تواند سقفِ PIDها را پر کند؛ از آن لحظه هیچ چیزی روی آن ماشین نمی‌تواند پروسسِ جدیدی شروع کند.

نمی‌توانید یک زامبی را بکُشید: از قبل مرده است، پس سیگنال‌ها اثری ندارند. والد را درست کنید تا wait() را صدا بزند، یا والد را متوقف کنید. وقتی یک والد می‌میرد، فرزندانش (زنده یا زامبی) به PID 1 سپرده می‌شوند (یا به نزدیک‌ترین پروسسی که به‌عنوان «subreaper» علامت خورده)، و آن پروسس خودکار آن‌ها را درو می‌کند. روی یک سیستمِ معمولی PID 1 همان systemd است و در درو کردن خیلی خوب عمل می‌کند.

پروسسِ PID 1 خاص است، و کانتینرها آن را به مشکلِ شما تبدیل می‌کنند

داخل یک کانتینر systemdی وجود ندارد. هر دستوری که ایمیج اجرا می‌کند، در PID namespace کانتینر PID 1 می‌شود، و PID 1 دو مسئولیتِ اضافه دارد:

کرنل رفتارهای پیش‌فرضِ سیگنال را روی آن اعمال نمی‌کند. سیگنالی که PID 1 برایش handler نصب نکرده باشد به‌سادگی نادیده گرفته می‌شود. برنامهٔ معمولی‌ای که به رفتارِ پیش‌فرضِ «پایان دادن»ِ SIGTERM تکیه دارد، docker stop را نادیده می‌گیرد، ده ثانیهٔ مهلت را همان‌جا می‌نشیند و بعد با SIGKILL کشته می‌شود.
همهٔ یتیم‌ها را به ارث می‌برد؛ پس باید آن‌ها را درو کند، وگرنه زامبی‌ها انباشته می‌شوند.

اولی را بدون Docker هم می‌توانید ببینید. unshare یک برنامه را به‌عنوان PID 1 در یک PID namespace تازه اجرا می‌کند:

$ sudo unshare --fork --pid --mount-proc python3 -c 'import time; time.sleep(30)' &
$ pid=$(pgrep -n -f 'time.sleep')    # the Python process, as seen from outside
$ sudo kill -TERM "$pid"             # nothing happens: PID 1 has no SIGTERM handler
$ sudo kill -KILL "$pid"             # this works: SIGKILL from the parent namespace

راه‌حل‌ها ساده‌اند:

یک پروسسِ init کوچک را به‌عنوان PID 1 اجرا کنید: docker run --init ابزار tini را اضافه می‌کند که سیگنال‌ها را به برنامهٔ شما می‌رساند و زامبی‌ها را درو می‌کند. کاربرانِ Kubernetes می‌توانند tini (یا dumb-init) را به‌عنوان entrypoint به ایمیج اضافه کنند.
کاری کنید برنامه‌تان SIGTERM را صریحاً مدیریت کند، مثل worker.py در بالا.
در Dockerfile از شکلِ exec استفاده کنید، یعنی CMD ["python3", "app.py"]، نه CMD python3 app.py. شکلِ shell دستورِ /bin/sh -c "python3 app.py" را اجرا می‌کند؛ پس شل PID 1 می‌شود و SIGTERM را به برنامهٔ شما نمی‌رساند.
اسکریپت‌های entrypoint را با exec "$@" تمام کنید. exec شل را با برنامهٔ شما جایگزین می‌کند (همان exec بالا)؛ پس برنامه‌تان PID 1 می‌شود و سیگنال‌ها را مستقیماً دریافت می‌کند.

بررسیِ پروسس‌ها

هر پروسس یک پوشه زیرِ /proc/<PID>/ دارد و بیشترِ ابزارها فقط از آن می‌خوانند:

ps -eo pid,ppid,stat,etime,cmd --forest   # every process, as a tree
pstree -p                                 # a compact tree with PIDs
cat /proc/1234/status                     # state, parent, memory, threads, signal masks
tr '\0' ' ' < /proc/1234/cmdline          # the full command line
ls -l /proc/1234/fd                       # open files, sockets and pipes
cat /proc/1234/environ | tr '\0' '\n'     # its environment (needs permission)

حرفِ اولِ ستونِ STAT می‌گوید یک پروسس مشغول چه کاری است:

وضعیت	معنی
`R`	در حال اجرا، یا آمادهٔ اجرا
`S`	خواب، منتظرِ چیزی (بیشترِ پروسس‌ها، بیشترِ وقت‌ها)
`D`	خوابِ وقفه‌ناپذیر، معمولاً منتظرِ دیسک یا ذخیره‌سازِ شبکه‌ای؛ حتی SIGKILL هم تا برگشتنش صبر می‌کند
`T`	متوقف‌شده (SIGSTOP، `Ctrl`+`Z` یا یک دیباگر)
`Z`	زامبی: خارج شده و منتظرِ درو شدن است

پروسسی که در وضعیتِ D گیر کرده و کشته نمی‌شود، تقریباً همیشه نشان‌دهندهٔ یک مشکلِ ذخیره‌سازی است (یک NFS mount هنگ‌کرده، یک دیسکِ در حال خرابی)، نه مشکلی در خودِ برنامه.

جمع‌بندی

پروسس‌های جدید با fork() (کپی از پروسس فعلی) و exec() (جایگزین کردنِ برنامه‌اش) ساخته می‌شوند. فاصلهٔ بین این دو جایی است که شل‌ها redirect و پایپ‌ها را آماده می‌کنند.
والد وضعیتِ خروج را با wait() جمع می‌کند؛ کدهای خروجِ بالای ۱۲۸ یعنی «با سیگنالِ (کد − ۱۲۸) کشته شد»: 130 یعنی Ctrl+C، 137 یعنی SIGKILL/OOM و 143 یعنی SIGTERM.
SIGTERM بفرستید و به برنامه‌ها فرصتِ خاموش شدن بدهید؛ SIGKILL قابل گرفتن نیست و همهٔ تمیزکاری‌ها را رد می‌کند.
زامبی‌ها فرزندانِ خارج‌شده‌ای هستند که کسی درویشان نکرده؛ والد را درست کنید یا بکُشید، نه زامبی را.
در کانتینرها، PID 1 سیگنال‌هایی را که مدیریت نمی‌کند نادیده می‌گیرد و باید یتیم‌ها را درو کند: از --init/tini، CMD به شکلِ exec و exec "$@" در entrypointها استفاده کنید.

نوشتن اسکریپت‌های Bash که خراب نمی‌شوند

Thu, 29 Oct 2026 09:00:00 +0000

اسکریپت‌های Bash معمولاً با چند دستور شروع می‌شوند که در یک فایل چسبانده شده‌اند. روی کامپیوتر خودتان، با فایل‌های خودتان، در یک روز خوب کار می‌کنند. بعد یک شب نام فایلی فاصله دارد، دیسک پر می‌شود یا دستوری وسط کار شکست می‌خورد، و اسکریپت طوری ادامه می‌دهد که انگار هیچ اتفاقی نیفتاده؛ گاهی هم سر راه چیزهای اشتباهی را پاک می‌کند.

راه‌حل‌ها کم و مکانیکی‌اند. این مقاله عادت‌هایی را مرور می‌کند که باعث می‌شوند اسکریپت‌ها با سروصدا و به‌شکل امن شکست بخورند، و بعد همه را در یک اسکریپت پشتیبان‌گیری که واقعاً می‌توانید از آن استفاده کنید ترکیب می‌کند. فرض بر این است که با دستورهای دستورهای ضروری لینوکس که هر برنامه‌نویسی باید بداند راحت هستید.

هر اسکریپت را یک‌جور شروع کنید

#!/usr/bin/env bash
set -euo pipefail

خط اول (که به آن shebang می‌گویند) مشخص می‌کند کدام برنامه فایل را اجرا کند. /usr/bin/env bash برنامهٔ bash را هر جا که نصب شده باشد پیدا می‌کند، که روی macOS و BSD مهم است. یک بار با chmod +x script.sh فایل را اجرایی کنید و آن را با ./script.sh اجرا کنید.

خط دوم چیزی را روشن می‌کند که معمولاً حالت سخت‌گیرانه (strict mode) نامیده می‌شود. هر حرف جلوی یک شکستِ بی‌صدای متفاوت را می‌گیرد.

حالت سخت‌گیرانه چه چیزهایی را می‌گیرد: set -e بعد از یک cd ناموفق متوقف می‌شود، set -u یک متغیرِ غلط‌نوشته را به خطا تبدیل می‌کند و pipefail باعث می‌شود اگر هر دستوری در یک پایپ‌لاین شکست بخورد، کل پایپ‌لاین شکست بخورد

گزینهٔ set -e: با اولین خطا متوقف شو

Bash به‌طور پیش‌فرض شکست‌ها را نادیده می‌گیرد و به هر حال خط بعدی را اجرا می‌کند:

cd /var/www/myapp-typo        # fails: No such file or directory
rm -rf ./*                    # ...and now runs in whatever directory you were in

با set -e، اسکریپت به محض اینکه دستوری شکست بخورد (کد خروجِ غیرصفر برگرداند) خارج می‌شود. شکست‌هایی که انتظارشان را دارید، مثل grepی که چیزی پیدا نمی‌کند، را می‌توان صریحاً مدیریت کرد:

if grep -q "ERROR" app.log; then
    echo "Errors found"
fi

grep -q "ERROR" app.log || echo "No errors"   # || also counts as handling it

جاهایی که set -e کمکی نمی‌کند

set -e در شرط‌ها (if، while، &&، ||) نادیده گرفته می‌شود و دو نقطهٔ کورِ معروف هم دارد:

local out=$(some_command) هرگز شکست نمی‌خورد، چون کد خروجی که می‌گیرید مالِ local است. اعلان و مقداردهی را در دو خط جدا انجام دهید: اول local out و بعد out=$(some_command).
((count++)) وقتی count صفر بوده ۱ برمی‌گرداند، که با set -e اسکریپت را می‌کُشد. به‌جای آن از count=$((count + 1)) استفاده کنید.

گزینهٔ set -u: متغیرِ تعریف‌نشده ممنوع

یک غلط تایپی در نام متغیر معمولاً بی‌صدا به یک رشتهٔ خالی تبدیل می‌شود:

name="Ada"
echo "Hello, $nme"            # prints "Hello, " without set -u

این در یک echo آزاردهنده است و در rm -rf "$build_dir/"* خطرناک. با set -u، استفاده از متغیری که مقدار ندارد خطاست:

./greet.sh: line 3: nme: unbound variable

برای متغیرهایی که مجازند نباشند، با ${var:-default} مقدار پیش‌فرض بدهید، یا با ${var:?message} با پیامِ خودتان شکست بخورید:

port=${PORT:-8080}                          # use $PORT if set, otherwise 8080
: "${API_KEY:?API_KEY must be set}"         # stop with this error if it's missing

گزینهٔ set -o pipefail: شکست‌های داخل پایپ‌لاین

کد خروجِ یک پایپ‌لاین معمولاً کد خروجِ آخرین دستور آن است؛ پس شکست‌های قبلی در پایپ ناپدید می‌شوند:

$ false | true; echo $?
0
$ set -o pipefail
$ false | true; echo $?
1

بدون آن، mysqldump mydb | gzip > backup.sql.gz حتی وقتی dump شکست می‌خورد «موفق» است، چون gzip با خوشحالی یک ورودیِ خالی را فشرده می‌کند. با pipefail، اگر هر دستوری در پایپ‌لاین شکست بخورد، کل پایپ‌لاین شکست می‌خورد.

متغیرها را داخل کوتیشن بگذارید

این بزرگ‌ترین منبعِ باگ‌های شل است. یک $var بدون کوتیشن روی فاصله‌ها شکسته می‌شود و بعد به‌عنوان الگوی wildcard گسترش پیدا می‌کند:

file="my report.txt"
rm $file          # rm: cannot remove 'my': No such file or directory
                  # rm: cannot remove 'report.txt': No such file or directory
rm "$file"        # removes "my report.txt"

و اگر متغیری * داشته باشد، گسترشِ بدون کوتیشن آن را به فهرستی از فایل‌های پوشهٔ فعلی تبدیل می‌کند. قانون ساده است: همیشه دور متغیرها و جایگزینی‌های دستور (command substitution) کوتیشن دوتایی بگذارید: "$file"، "$(date +%F)"، "${files[@]}". استثناهای نادر عمدی‌اند و یک کامنت توضیحی لازم دارند.

برای فرستادنِ همهٔ آرگومان‌های اسکریپت به یک دستور دیگر، از "$@" استفاده کنید. هر آرگومان را دست‌نخورده نگه می‌دارد، حتی وقتی فاصله داشته باشد؛ $* و $@ بدون کوتیشن این کار را نمی‌کنند:

# called as: ./wrapper.sh "a b" c
for arg in "$@"; do echo "[$arg]"; done   # [a b] [c]
for arg in $*;   do echo "[$arg]"; done   # [a] [b] [c]

برای شرط‌ها از [[ ]] استفاده کنید

در Bash، [[ -f "$file" ]] را به [ -f "$file" ] ترجیح دهید. کلمه‌ها را نمی‌شکند، پس یک کوتیشنِ جاافتاده خرابش نمی‌کند، و از &&، || و تطبیق الگو مثل [[ $name == *.txt ]] پشتیبانی می‌کند.

خواندنِ درستِ فایل، خط‌به‌خط

for line in $(cat file) روی کلمه‌ها حلقه می‌زند، نه خط‌ها، و سر راه wildcardها را هم گسترش می‌دهد. روش درست این است:

while IFS= read -r line; do
    echo "Processing: $line"
done < hosts.txt

IFS= فاصله‌های ابتدا و انتهای خط را نگه می‌دارد و -r جلوی تفسیر بک‌اسلش‌ها به‌عنوان کاراکتر escape را می‌گیرد.

پاک‌سازی با trap

اسکریپت‌ها اغلب فایل‌های موقت می‌سازند. mktemp فایلی با نامی یکتا و غیرقابل حدس می‌سازد (هرگز /tmp/myscript.tmp را ثابت در کد ننویسید)، و trap ... EXIT تضمین می‌کند که آن فایل هر طور اسکریپت تمام شود پاک شود: به‌طور عادی، به‌خاطر خطا با set -e، یا وقتی Ctrl+C را می‌زنید:

tmpdir=$(mktemp -d)
trap 'rm -rf "$tmpdir"' EXIT

curl -fsSL https://example.com/data.csv -o "$tmpdir/data.csv"
# ...work with the file; no matter what happens, $tmpdir is deleted at the end

به کوتیشن تکی دقت کنید: $tmpdir وقتی trap اجرا می‌شود گسترش پیدا می‌کند، نه وقتی تعریف می‌شود. فقط kill -9 (یعنی SIGKILL) از trap رد می‌شود، چون هیچ چیزی نمی‌تواند آن سیگنال را بگیرد.

تابع‌ها، آرگومان‌ها و خطاها

die() {
    echo "Error: $*" >&2      # error messages go to stderr
    exit 1
}

require_dir() {
    local dir=$1              # local: don't leak into the rest of the script
    [[ -d "$dir" ]] || die "'$dir' is not a directory"
}

داخل یک تابع، $1، $2… و "$@" آرگومان‌های خودِ تابع هستند. برای هر متغیری که تابع می‌سازد از local استفاده کنید، خطاها را در خروجیِ خطای استاندارد (>&2) چاپ کنید تا با خروجیِ واقعی قاطی نشوند، و با یک کد غیرصفر خارج شوید تا فراخواننده (یک آدم، cron یا CI) بفهمد مشکلی پیش آمده.

یک مثال کامل: اسکریپت پشتیبان‌گیری

این اسکریپتی است که از یک پوشه آرشیو می‌سازد، فقط چند آرشیوِ آخر را نگه می‌دارد و همهٔ نکته‌های بالا را عملاً به کار می‌گیرد:

#!/usr/bin/env bash
# backup.sh: archive a directory and keep only the newest few archives.
set -euo pipefail

usage() {
    echo "Usage: $0 SOURCE_DIR DEST_DIR [KEEP]" >&2
    exit 2
}

[[ $# -ge 2 ]] || usage
src=$1
dest=$2
keep=${3:-7}

[[ -d "$src" ]] || { echo "Error: '$src' is not a directory" >&2; exit 1; }
mkdir -p "$dest"

# Write to a temporary file first, so a failed run never leaves a half-written archive behind
tmpfile=$(mktemp "$dest/.backup.XXXXXX")
trap 'rm -f "$tmpfile"' EXIT

name="$(basename "$src")-$(date +%Y%m%d-%H%M%S).tar.gz"
tar -czf "$tmpfile" -C "$(dirname "$src")" "$(basename "$src")"
mv "$tmpfile" "$dest/$name"
echo "Created $dest/$name"

# The timestamp in the name sorts alphabetically, so the glob lists the oldest first
archives=("$dest/$(basename "$src")"-*.tar.gz)
excess=$(( ${#archives[@]} - keep ))
for (( i = 0; i < excess; i++ )); do
    rm -- "${archives[i]}"
    echo "Removed ${archives[i]}"
done

$ ./backup.sh "my site" backups 2
Created backups/my site-20261029-081312.tar.gz
$ ./backup.sh "my site" backups 2
Created backups/my site-20261029-081313.tar.gz
$ ./backup.sh "my site" backups 2
Created backups/my site-20261029-081314.tar.gz
Removed backups/my site-20261029-081312.tar.gz

چند جزئیات که ارزش دیدن دارند:

پوشهٔ مبدئی را که نامش فاصله دارد درست مدیریت می‌کند، چون همهٔ متغیرها داخل کوتیشن‌اند.
آرشیو با یک نامِ موقت نوشته می‌شود و در پایان تغییر نام داده می‌شود. تغییر نام داخل یک پوشه اتمی است؛ پس پوشهٔ پشتیبان‌ها هرگز یک آرشیوِ نیمه‌کاره ندارد، حتی اگر tar شکست بخورد یا دیسک پر شود. (mktemp همچنین فایل را فقط برای خودتان خواندنی می‌کند، که برای پشتیبان مناسب است.)
rm -- پایانِ گزینه‌ها را مشخص می‌کند؛ پس نام فایلی که با - شروع می‌شود با یک گزینه اشتباه گرفته نمی‌شود.
استفادهٔ غلط با کد ۲ و خطاهای واقعی با کد ۱ خارج می‌شوند؛ پس یک کار cron یا پایپ‌لاین CI می‌تواند آن‌ها را از هم تشخیص دهد.

بگذارید ShellCheck اسکریپت‌هایتان را بازبینی کند

ShellCheck یک linter برای اسکریپت‌های شل است. کوتیشن‌های جاافتاده، تلهٔ local، تفاوت $* و "$@" و ده‌ها اشتباه دیگر را می‌گیرد و برای هر کدام توضیح می‌دهد. با sudo apt install shellcheck (یا brew install shellcheck) نصبش کنید، shellcheck backup.sh را اجرا کنید و آن را به ویرایشگر یا CIتان اضافه کنید. سریع‌ترین راه برای جا انداختنِ همهٔ این عادت‌هاست.

جمع‌بندی

با #!/usr/bin/env bash و set -euo pipefail شروع کنید و بدانید set -e به کجاها نمی‌رسد.
هر گسترشی را داخل کوتیشن بگذارید: "$var"، "$(cmd)"، "$@".
برای مقدارهای اختیاری و الزامی از ${var:-default} و ${var:?message} استفاده کنید.
فایل‌های موقت را با mktemp بسازید و با trap '...' EXIT پاکشان کنید.
خطاها را به >&2 بفرستید، با کدهای خروجِ معنادار خارج شوید و ShellCheck را اجرا کنید.

ریبیس تعاملی: کامیت‌هایتان را قبل از اشتراک‌گذاری مرتب کنید

Thu, 29 Oct 2026 09:00:00 +0000

کارِ واقعی شلوغ است. یک فرمِ نیمه‌کاره را کامیت می‌کنید، بعد «WIP»، بعد «fix typo»، بعد یک print برای دیباگ که یادتان رفته پاکش کنید. تا وقتی مشغول کارید اشکالی ندارد، اما این تاریخچهٔ خوبی برای تحویل به بازبین نیست، و برای پیدا کردنش شش ماه بعد در git log یا git blame از آن هم بدتر است.

ریبیس تعاملی (interactive rebase) به شما اجازه می‌دهد برنچ خودتان را قبل از اشتراک‌گذاری بازنویسی کنید: کامیت‌ها را با هم ادغام کنید، پیامشان را از نو بنویسید، ترتیبشان را عوض کنید، آن‌ها را تقسیم یا حذف کنید. وقتی با برنچ‌ها راحت شدید، این یکی از مفیدترین مهارت‌هایی است که در گیت می‌توانید یاد بگیرید. اگر هنوز راحت نیستید، اول روش کاری عملی با برنچ‌های گیت برای مبتدی‌ها را بخوانید.

برنچِ شلوغ

این یک برنچ فیچر با پنج کامیت روی main است:

$ git log --oneline main..
746aec7 debug print
451c410 fix typo
63d1135 Add password validation
0ce6ff7 WIP
4430f61 Add login form

main.. یعنی «کامیت‌هایی از این برنچ که در main نیستند». چیزی که می‌خواهیم به اشتراک بگذاریم فقط دو کامیت است: Add login form (به‌همراه WIP و رفع غلط تایپی که هر دو روی همان فرم بودند) و Add password validation، بدون print دیباگ.

شروع ریبیس تعاملی

git rebase -i main

گیت ویرایشگرتان را با یک فهرست کار (todo list) باز می‌کند؛ برای هر کامیت یک خط:

pick 4430f61 Add login form
pick 0ce6ff7 WIP
pick 63d1135 Add password validation
pick 451c410 fix typo
pick 746aec7 debug print

# Rebase 1c893f9..746aec7 onto 1c893f9 (5 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
#                    commit's log message, unless -C is used, ...
# d, drop <commit> = remove commit
# ...

فهرست کار نسبت به git log برعکس است

git log جدیدترین کامیت را اول نشان می‌دهد. فهرست کار قدیمی‌ترین را اول نشان می‌دهد، چون گیت کامیت‌ها را به همین ترتیب دوباره اعمال می‌کند. آن را مثل یک اسکریپت از بالا به پایین بخوانید.

گیت از main شروع می‌کند و خط‌ها را یکی‌یکی اجرا می‌کند. کلمهٔ اول هر خط را عوض کنید تا بلایی که سر آن کامیت می‌آید عوض شود:

دستور	چه کاری می‌کند
`pick`	کامیت را همان‌طور که هست نگه می‌دارد
`reword`	تغییرات را نگه می‌دارد، اما می‌ایستد تا پیام را ویرایش کنید
`edit`	کامیت را اعمال می‌کند و بعد مکث می‌کند تا آن را تغییر دهید (amend، تقسیم و…)
`squash`	در کامیتِ بالایی ادغام می‌شود و هر دو پیام را با هم ترکیب می‌کند
`fixup`	در کامیتِ بالایی ادغام می‌شود و پیامِ این کامیت را دور می‌ریزد
`drop`	کامیت را حذف می‌کند (پاک کردنِ خط هم همین کار را می‌کند)
`exec`	در این نقطه یک دستور شل اجرا می‌کند و اگر شکست بخورد می‌ایستد

ادغام، جابه‌جایی و حذف

فهرست کار را این‌طور ویرایش کنید، بعد ذخیره کنید و ویرایشگر را ببندید:

pick 4430f61 Add login form
fixup 0ce6ff7 WIP
fixup 451c410 fix typo
pick 63d1135 Add password validation
drop 746aec7 debug print

سه چیز را عوض کردیم: دو کامیتِ کوچک به fixup Add login form تبدیل شدند، fix typo را بالا بردیم تا درست زیرِ کامیتی قرار بگیرد که اصلاحش می‌کند، و print دیباگ حذف شد.

$ git rebase -i main
Successfully rebased and updated refs/heads/login-form.

$ git log --oneline main..
486c6b2 Add password validation
24c6dfe Add login form

فهرست کار از بالا به پایین خوانده می‌شود: دو fixup در Add login form ذوب می‌شوند، Add password validation می‌ماند و print دیباگ حذف می‌شود؛ نتیجه دو کامیتِ تمیز است

دقت کنید که هش‌ها عوض شدند، حتی برای Add password validation که به محتوایش دست نزدیم. ریبیس هرگز کامیت‌ها را ویرایش نمی‌کند: کامیت‌های جدیدی با همان تغییرات می‌سازد. این نکته جلوتر، موقع push، مهم می‌شود.

squash یا fixup؟

وقتی پیامِ کامیت دوم چیزی دارد که ارزش نگه‌داشتن دارد از squash استفاده کنید: گیت ویرایشگر را با هر دو پیام باز می‌کند تا آن‌ها را با هم ترکیب کنید. برای کامیت‌های «اوه، یادم رفت» که پیامشان را به هر حال پاک می‌کردید، fixup را به کار ببرید.

کامیت‌های fixup: در حین کار مرتب کنید

جابه‌جا کردنِ دستیِ خط‌ها خسته‌کننده می‌شود. اگر از قبل می‌دانید یک تغییر مال کدام کامیت است، موقع کامیت کردن به گیت بگویید:

# Spotted a bug in "Add password validation"? Fix it, then:
git commit -a --fixup=486c6b2

گیت کامیتی به نام fixup! Add password validation می‌سازد. بعداً --autosquash همهٔ این کامیت‌ها را زیرِ کامیتِ هدفشان می‌برد و برایتان fixup علامت می‌زند:

$ git rebase -i --autosquash main

pick 24c6dfe Add login form
pick 486c6b2 Add password validation
fixup 4eb2adb fixup! Add password validation

فقط ذخیره کنید و ببندید. برای اینکه این رفتار پیش‌فرض شود، git config --global rebase.autoSquash true را اجرا کنید.

تقسیم یک کامیت با edit

گاهی یک کامیت دو کارِ بی‌ربط انجام می‌دهد. آن را edit علامت بزنید تا گیت درست بعد از اعمالش مکث کند:

edit 9a1c2d3 Add login form and fix footer links
pick 3f7e8b1 Add password validation

git reset HEAD^                 # undo the commit, keep its changes as unstaged edits
git add login.html
git commit -m "Add login form"
git add footer.html
git commit -m "Fix footer links"
git rebase --continue           # carry on with the rest of the todo list

وقتی هر دو تغییر در یک فایل هستند، git add -p اینجا به کار می‌آید: دربارهٔ هر تکه از تغییرات جداگانه از شما می‌پرسد.

وقتی تداخل پیش می‌آید

جابه‌جا یا حذف کردن کامیت‌ها ممکن است تداخل (conflict) ایجاد کند، دقیقاً مثل merge. گیت می‌ایستد و می‌گوید کدام فایل‌ها تداخل دارند. سه راه دارید:

# fix the files, then mark them as resolved and continue
git add login.html
git rebase --continue

git rebase --skip      # drop the commit that conflicts and move on
git rebase --abort     # give up: put the branch back exactly as it was

--abort تور ایمنی شماست. تا وقتی ریبیس تمام نشده، هیچ چیزی واقعاً تغییر نکرده است.

تست‌ها را روی تک‌تکِ کامیت‌ها اجرا کنید

git rebase -i main --exec "npm test" (یا -x) بعد از هر کامیت یک خط exec اضافه می‌کند. اگر تست‌ها هر جایی شکست بخورند، ریبیس روی همان کامیتی می‌ایستد که آن‌ها را خراب کرده. این یک بررسی نهاییِ عالی است که هر کامیت به‌تنهایی کار می‌کند؛ همان چیزی که بعدها git bisect را مفید می‌کند.

ریبیس بدون جابه‌جا کردنِ برنچ

git rebase -i main برنچ شما را روی آخرین نسخهٔ main هم می‌برد. معمولاً همین را می‌خواهید، اما اگر main خیلی جلو رفته باشد، به تداخل‌هایی می‌خورید که هیچ ربطی به مرتب‌سازیِ شما ندارند. برای مرتب کردن کامیت‌ها سرِ جایشان، با همان نقطهٔ شروع:

git rebase -i --keep-base main

نقطهٔ شروع را مستقیم هم می‌توانید بدهید: git rebase -i HEAD~3 اجازه می‌دهد سه کامیت آخر را ویرایش کنید.

push کردنِ یک برنچِ بازنویسی‌شده

چون کامیت‌ها جدیدند، برنچی که قبل از ریبیس push کرده بودید دیگر با ریموت جور نیست و یک git push معمولی رد می‌شود. از این استفاده کنید:

git push --force-with-lease

برخلاف --force، اگر از آخرین fetch شما کس دیگری روی برنچِ ریموت push کرده باشد، --force-with-lease از بازنویسی آن خودداری می‌کند؛ پس نمی‌توانید تصادفاً کارِ هم‌تیمی‌تان را پاک کنید.

قانون طلایی ریبیس

فقط کامیت‌هایی را بازنویسی کنید که هیچ‌کس روی آن‌ها کار نساخته است. مرتب کردنِ برنچ فیچرِ خودتان قبل از pull request (یا در حین آن) مشکلی ندارد. ریبیس کردنِ main، یا برنچی که هم‌تیمی‌هایتان pull کرده‌اند، برایشان نسخه‌هایی از کامیت‌های قدیمی و یک merge دردناک باقی می‌گذارد.

برگرداندن یک ریبیس

ریبیس را تمام کرده‌اید و پشیمانید؟ گیت جای قبلیِ برنچ شما را در ORIG_HEAD نگه می‌دارد:

git reset --hard ORIG_HEAD

این فقط درست بعد از ریبیس کار می‌کند، چون دستورهای دیگر هم ORIG_HEAD را به‌روز می‌کنند. برای عقب‌تر، reflog هر جایی را که برنچتان بوده به خاطر دارد (git reflog). گیت واقعاً چطور کار می‌کند توضیح می‌دهد چرا کامیت‌های قدیمی هنوز آنجا هستند.

جمع‌بندی

git rebase -i main یک فهرست کار از کامیت‌های برنچتان باز می‌کند، با قدیمی‌ترین در ابتدا.
pick را به reword، edit، squash، fixup یا drop تغییر دهید و برای عوض کردن ترتیب کامیت‌ها، خط‌ها را جابه‌جا کنید.
git commit --fixup=<commit> به‌همراه --autosquash مرتب‌سازی را تقریباً خودکار می‌کند.
--abort یک ریبیسِ در جریان را متوقف می‌کند؛ ORIG_HEAD و reflog یک ریبیسِ تمام‌شده را برمی‌گردانند.
ریبیس کامیت‌های جدید می‌سازد، پس با --force-with-lease push کنید، و هرگز کامیت‌هایی را که دیگران روی آن‌ها کار ساخته‌اند ریبیس نکنید.

دیسکریپتورها در پایتون: پروتکلی که پشت property و متدهاست

Thu, 29 Oct 2026 09:00:00 +0000

تا حالا فکر کرده‌اید @property چطور یک متد را به چیزی تبدیل می‌کند که شبیه یک attributeِ ساده است؟ یا وقتی obj.method() را صدا می‌زنید، self دقیقاً از کجا می‌آید؟ یا فیلدهای مدل در Django و ستون‌های SQLAlchemy از کجا می‌فهمند متعلق به کدام شیء هستند؟

همهٔ این‌ها روی یک سازوکار کوچک بنا شده‌اند: پروتکل دیسکریپتور (descriptor protocol). این یکی از معدود بخش‌های واقعاً «جادویی» پایتون است و وقتی آن را بفهمید، هم می‌توانید سازوکار درونی زبان را بخوانید و هم منطق attributeها را تمیزتر و قابل‌استفادهٔ مجدد بنویسید.

اگر دکوریتورها هنوز برایتان تازه‌اند، اول دکوریتورها در پایتون، قدم‌به‌قدم را بخوانید؛ در ادامه از آن‌ها استفاده می‌کنیم.

دیسکریپتور چیست؟

دیسکریپتور هر شیئی است که کلاسش دست‌کم یکی از این متدها را تعریف کرده باشد:

__get__(self, obj, objtype=None)   # called when the attribute is read
__set__(self, obj, value)          # called when it is assigned
__delete__(self, obj)              # called on `del obj.attr`

نکتهٔ مهم: این فقط وقتی کار می‌کند که دیسکریپتور به‌عنوان attributeِ کلاس ذخیره شده باشد. وقتی پایتون دنبال obj.attr می‌گردد و روی کلاس به یک دیسکریپتور می‌رسد، به‌جای برگرداندن خودِ دیسکریپتور، متد آن را صدا می‌زند.

اولین دیسکریپتور شما: یک attributeِ اعتبارسنجی‌شده

فرض کنید هر Product باید price و quantity مثبت داشته باشد. با property باید همان getter و setter را دو بار بنویسید. با دیسکریپتور، قانون را یک بار می‌نویسید و دوباره از آن استفاده می‌کنید:

class Positive:
    """A number that must stay above zero."""

    def __set_name__(self, owner, name):
        self.public_name = name
        self.private_name = "_" + name

    def __get__(self, obj, objtype=None):
        if obj is None:          # accessed on the class: Product.price
            return self
        return getattr(obj, self.private_name)

    def __set__(self, obj, value):
        if value <= 0:
            raise ValueError(f"{self.public_name} must be positive, got {value!r}")
        setattr(obj, self.private_name, value)


class Product:
    price = Positive()
    quantity = Positive()

    def __init__(self, name, price, quantity):
        self.name = name
        self.price = price          # goes through Positive.__set__
        self.quantity = quantity

>>> p = Product("Keyboard", 49.0, 3)
>>> p.price
49.0
>>> vars(p)
{'name': 'Keyboard', '_price': 49.0, '_quantity': 3}
>>> p.quantity = -1
ValueError: quantity must be positive, got -1

سه جزئیات ارزش دقت دارد:

__set_name__ (از پایتون ۳٫۶ به بعد) فقط یک بار و هنگام ساخته شدن کلاس صدا زده می‌شود و نام attributeی را که دیسکریپتور به آن نسبت داده شده می‌گیرد. همین است که یک کلاس Positive می‌فهمد از price محافظت می‌کند یا از quantity.
obj is None یعنی attribute از روی خودِ کلاس خوانده شده (Product.price)، نه از یک نمونه. قرارداد این است که در این حالت خودِ دیسکریپتور برگردانده شود؛ این کار باعث می‌شود ابزارهایی مثل help() درست کار کنند.
مقدارهای واقعی روی نمونه و با نام‌های _price و _quantity ذخیره می‌شوند. دیسکریپتور فقط تنظیمات را نگه می‌دارد.

ترتیب جست‌وجوی attributeها

برای استفادهٔ مطمئن از دیسکریپتورها باید قوانین دقیقی را بدانید که object.__getattribute__ برای obj.attr دنبال می‌کند. دیسکریپتورها دو نوع‌اند:

دیسکریپتور داده (data descriptor) متد __set__ یا __delete__ را تعریف می‌کند (Positive و property دیسکریپتور داده‌اند).
دیسکریپتور غیرداده (non-data descriptor) فقط __get__ را تعریف می‌کند (توابع معمولی دیسکریپتور غیرداده‌اند).

پایتون اول دیسکریپتور داده روی کلاس را بررسی می‌کند، بعد دیکشنری نمونه را، بعد دیسکریپتورهای غیرداده و attributeهای کلاس را، و در آخر __getattr__ را

این تفاوت مهم است، چون دیکشنری نمونه بین این دو قرار می‌گیرد. می‌توانید خودتان ثابتش کنید:

class DataDesc:
    def __get__(self, obj, objtype=None):
        return "data descriptor"

    def __set__(self, obj, value):
        raise AttributeError("read-only")


class NonDataDesc:
    def __get__(self, obj, objtype=None):
        return "non-data descriptor"


class Demo:
    a = DataDesc()
    b = NonDataDesc()


d = Demo()
d.__dict__["a"] = "instance dict"     # bypass __set__ and write directly
d.__dict__["b"] = "instance dict"

print(d.a)   # data descriptor   ← beats the instance dict
print(d.b)   # instance dict     ← beats the non-data descriptor

همین یک قانون بخش بزرگی از رفتار پایتون را توضیح می‌دهد؛ در بخش‌های بعد می‌بینید چطور.

متدها دیسکریپتور هستند

توابع یک متد __get__ دارند. وقتی یک تابع را از طریق یک نمونه می‌خوانید، __get__ یک متد bound برمی‌گرداند؛ شیء کوچکی که هم تابع و هم نمونه را به خاطر دارد. self از همین‌جا می‌آید:

>>> class Greeter:
...     def hello(self):
...         return "hi"
...
>>> g = Greeter()
>>> f = Greeter.__dict__["hello"]    # the raw function, no descriptor magic
>>> f
<function Greeter.hello at 0x7fc890f70160>
>>> f.__get__(g, Greeter)            # exactly what g.hello does
<bound method Greeter.hello of <__main__.Greeter object at 0x7fc890f63760>>
>>> g.hello == f.__get__(g, Greeter)
True

چون توابع دیسکریپتور غیرداده هستند، attributeی با همان نام روی نمونه برنده می‌شود. به همین دلیل می‌توانید یک متد را فقط برای یک شیء عوض کنید (که برای mock کردن در تست‌ها خیلی به کار می‌آید):

>>> g.hello = lambda: "patched"
>>> g.hello(), Greeter().hello()
('patched', 'hi')

classmethod و staticmethod هم دیسکریپتور غیرداده‌اند: __get__ آن‌ها به‌جای نمونه، کلاس را bind می‌کند یا اصلاً چیزی را bind نمی‌کند.

ساختن property از صفر

property یک دیسکریپتور داده است که به زبان C نوشته شده، اما یک نسخهٔ کارآمد از آن به پایتون خالص در یک صفحه جا می‌شود:

class MyProperty:
    def __init__(self, fget, fset=None):
        self.fget = fget
        self.fset = fset

    def __get__(self, obj, objtype=None):
        if obj is None:
            return self
        return self.fget(obj)

    def __set__(self, obj, value):
        if self.fset is None:
            raise AttributeError("read-only attribute")
        self.fset(obj, value)

    def setter(self, fset):
        return type(self)(self.fget, fset)    # a new descriptor with both functions


class Temperature:
    def __init__(self, celsius):
        self.celsius = celsius

    @MyProperty
    def fahrenheit(self):
        return self.celsius * 9 / 5 + 32

    @fahrenheit.setter
    def fahrenheit(self, value):
        self.celsius = (value - 32) * 5 / 9

>>> t = Temperature(100)
>>> t.fahrenheit
212.0
>>> t.fahrenheit = 32
>>> t.celsius
0.0

@MyProperty همان fahrenheit = MyProperty(fahrenheit) است. بعد @fahrenheit.setter یک دیسکریپتور دوم می‌سازد که هر دو تابع را نگه می‌دارد و نام را به آن نسبت می‌دهد. چون MyProperty همیشه __set__ را تعریف می‌کند، حتی بدون setter هم دیسکریپتور داده است؛ به همین دلیل یک property فقط‌خواندنی را نمی‌توان با مقداردهی روی نمونه پوشاند.

cached_property: استفادهٔ آگاهانه از ترتیب جست‌وجو

functools.cached_property استفادهٔ هوشمندانه‌ای از همان قانون قبلی است. این یک دیسکریپتور غیرداده است: در اولین دسترسی، متد شما را اجرا می‌کند و نتیجه را با همان نام در __dict__ نمونه ذخیره می‌کند. از آن به بعد دیکشنری نمونه در جست‌وجو برنده می‌شود و __get__ دیگر هرگز صدا زده نمی‌شود:

>>> from functools import cached_property
>>> class Report:
...     def __init__(self, rows):
...         self.rows = rows
...
...     @cached_property
...     def total(self):
...         print("computing…")
...         return sum(self.rows)
...
>>> r = Report([3, 4, 5])
>>> r.total
computing…
12
>>> r.total          # served straight from r.__dict__
12
>>> vars(r)
{'rows': [3, 4, 5], 'total': 12}
>>> del r.total      # clear the cache; the next access recomputes

cached_property به dict نمونه نیاز دارد

چون کش در obj.__dict__ نگه داشته می‌شود، cached_property روی کلاس‌هایی که __slots__ را بدون "__dict__" تعریف کرده‌اند کار نمی‌کند.

باگ کلاسیک: ذخیرهٔ وضعیت روی خودِ دیسکریپتور

برای هر attributeِ کلاس فقط یک شیء دیسکریپتور وجود دارد که همهٔ نمونه‌ها در آن شریک‌اند. اگر داده‌های هر شیء را روی self داخل دیسکریپتور ذخیره کنید، همهٔ نمونه‌ها در آن شریک می‌شوند:

class Broken:
    def __get__(self, obj, objtype=None):
        return self.value

    def __set__(self, obj, value):
        self.value = value     # stored on the descriptor, which every instance shares


class Account:
    balance = Broken()


a, b = Account(), Account()
a.balance = 100
b.balance = 5
print(a.balance)   # 5  ← a's balance was overwritten by b

به‌جای آن مقدارها را روی obj ذخیره کنید، همان‌طور که Positive با setattr(obj, self.private_name, value) این کار را می‌کند.

مراقب بازگشت بی‌پایان باشید

داخل __set__ هرگز ننویسید setattr(obj, self.public_name, value). مقداردهی به نام عمومی دوباره __set__ را صدا می‌زند، و این تا ابد ادامه پیدا می‌کند. همیشه با یک نام دیگر ذخیره کنید، یا مستقیم در obj.__dict__ بنویسید.

کجاهای دیگر به دیسکریپتورها برمی‌خورید

وقتی الگو را بشناسید، همه‌جا آن را می‌بینید:

قابلیت	نوع دیسکریپتور	کاری که `__get__` انجام می‌دهد
متدهای معمولی	غیرداده	یک متد bound برمی‌گرداند
`classmethod` / `staticmethod`	غیرداده	کلاس را bind می‌کند / چیزی را bind نمی‌کند
`property`	داده	تابع getter را صدا می‌زند
`functools.cached_property`	غیرداده	یک بار محاسبه می‌کند و در `obj.__dict__` کش می‌کند
ورودی‌های `__slots__`	داده	یک خانهٔ ثابت در حافظهٔ شیء را می‌خواند
فیلدهای Django، ستون‌های SQLAlchemy	بسته به نوع فیلد	مقدار را از پایگاه داده می‌خواند، تبدیل یا ردیابی می‌کند

حتی می‌توانید دیسکریپتورهای __slots__ را مستقیم ببینید:

>>> class Point:
...     __slots__ = ("x", "y")
...
>>> Point.__dict__["x"]
<member 'x' of 'Point' objects>

جمع‌بندی

دیسکریپتور یک attributeِ کلاس است که کلاسش __get__، __set__ یا __delete__ را تعریف کرده باشد.
دیسکریپتورهای داده (با __set__ یا __delete__) بر دیکشنری نمونه مقدم‌اند؛ دیسکریپتورهای غیرداده به آن می‌بازند.
متدها، property، classmethod، staticmethod، cached_property و __slots__ همه روی دیسکریپتورها ساخته شده‌اند.
با __set_name__ نام attribute را بفهمید و مقدارهای هر نمونه را روی خودِ نمونه ذخیره کنید، هرگز روی دیسکریپتور.
وقتی منطق یکسانی برای attributeها (اعتبارسنجی، تبدیل، بارگذاری تنبل) در چند attribute یا چند کلاس تکرار می‌شود، سراغ یک دیسکریپتور سفارشی بروید.

بهترین راه برای اینکه این موضوع در ذهنتان بماند: یک REPL باز کنید، دیسکریپتوری بنویسید که در هر متدش چیزی چاپ کند، و ببینید پایتون دقیقاً کِی آن را صدا می‌زند.

حلقهٔ رویداد در جاوااسکریپت: تسک‌ها، میکروتسک‌ها و رندر

Thu, 29 Oct 2026 09:00:00 +0000

حتماً می‌دانید که await تابع را متوقف می‌کند بی‌آنکه صفحه قفل شود. اما آن تابع دقیقاً کِی ادامه پیدا می‌کند؟ چرا یک پرامیسِ resolve‌شده همیشه قبل از setTimeout(fn, 0) اجرا می‌شود؟ و چرا پیام «در حال بارگذاری…» که درست قبل از یک محاسبهٔ سنگین تنظیم می‌کنید، گاهی هرگز روی صفحه دیده نمی‌شود؟

جواب هر سه سؤال یکی است: حلقهٔ رویداد (event loop). وقتی بتوانید آن را در ذهنتان اجرا کنید، یک دسته از باگ‌های زمان‌بندی، تست‌های ناپایدار و رابط‌های کاربریِ کُند دیگر رازآلود نیستند. این مقاله فرض می‌کند با پرامیس‌ها و async/await راحت هستید؛ اگر نه، از درک async/await در جاوااسکریپت شروع کنید.

اجزای اصلی

جاوااسکریپت در مرورگر روی یک رشتهٔ اصلی (main thread) اجرا می‌شود و این رشته فقط کد شما را اجرا نمی‌کند؛ ورودی‌های کاربر را هم پردازش می‌کند و صفحه را هم رسم می‌کند. چهار چیز در این رشته شریک‌اند:

پشتهٔ فراخوانی (call stack): توابعی که همین الان در حال اجرا هستند. حلقهٔ رویداد فقط وقتی وارد عمل می‌شود که پشته خالی باشد.
صف تسک‌ها (task queue): واحدهای کاملِ کار که منتظر نوبت‌اند؛ مثل callbackِ یک setTimeout، یک هندلر کلیک یا یک postMessage از یک worker. (مستندات به این‌ها task می‌گویند؛ اسم macrotask را هم زیاد می‌بینید.)
صف میکروتسک‌ها (microtask queue): کارهای کوچکِ پیگیری، که بیشترشان واکنش‌های پرامیس هستند (callbackهای .then() و کدِ بعد از await)، به‌علاوهٔ queueMicrotask() و callbackهای MutationObserver.
مراحل رندر: callbackهای requestAnimationFrame و بعد محاسبهٔ استایل، چیدمان (layout) و رسم (paint).

یک دور از حلقه

اگر جزئیات را کنار بگذاریم، مرورگر این کار را تا ابد تکرار می‌کند:

while (true) {
  const task = taskQueue.takeOldest();
  if (task) run(task);                     // 1. exactly ONE task

  while (microtaskQueue.length > 0) {      // 2. EVERY microtask,
    run(microtaskQueue.shift());           //    including ones added meanwhile
  }

  if (isTimeToRender()) {                  // 3. maybe a frame
    runAnimationFrameCallbacks();
    updateStyleLayoutAndPaint();
  }
}

هر دور از حلقهٔ رویداد یک تسک را اجرا می‌کند، بعد صف میکروتسک‌ها را خالی می‌کند و اگر وقتش رسیده باشد یک فریم رندر می‌کند

کل ماجرا در یک عدم‌تقارن است: حلقه هر بار فقط یک تسک برمی‌دارد، اما صف میکروتسک‌ها را کاملاً خالی می‌کند؛ حتی اگر میکروتسک‌ها مدام میکروتسک‌های تازه اضافه کنند. رندر فقط بین تسک‌ها انجام می‌شود، آن هم فقط وقتی نمایشگر آمادهٔ فریم تازه است (در یک صفحهٔ ۶۰ هرتزی تقریباً هر ۱۶٫۷ میلی‌ثانیه).

اسکریپت شما هم یک تسک است

اجرای اولیهٔ یک <script> خودش یک تسک است. به همین دلیل callbackهای پرامیسی که در حین آن ساخته می‌شوند، به محض تمام شدن اسکریپت و قبل از هر تایمری اجرا می‌شوند.

خروجی را پیش‌بینی کنید

این یک معمای کلاسیک است. قبل از خواندن جواب، ترتیب را خودتان حدس بزنید:

console.log("script start");

setTimeout(() => console.log("timeout"), 0);

Promise.resolve()
  .then(() => console.log("then 1"))
  .then(() => console.log("then 2"));

queueMicrotask(() => console.log("microtask"));

(async () => {
  console.log("async start");
  await null;
  console.log("async after await");
})();

console.log("script end");

script start
async start
script end
then 1
microtask
async after await
then 2
timeout

قدم‌به‌قدم:

اول کد همگام اجرا می‌شود: script start، بعد async start (یک تابع async تا اولین await به‌صورت همگام اجرا می‌شود) و بعد script end.
در همین حین سه میکروتسک به ترتیب در صف قرار گرفتند: then 1، microtask و ادامهٔ تابع async. اما callbackِ تایمر به صف تسک‌ها رفت.
تسکِ اسکریپت تمام می‌شود، پس صف میکروتسک‌ها خالی می‌شود. اجرای then 1 پرامیس بعدیِ زنجیره را resolve می‌کند و then 2 را به انتهای صف اضافه می‌کند. به همین دلیل then 2 بعد از async after await می‌آید.
فقط وقتی صف میکروتسک‌ها خالی شد، حلقه سراغ تسک بعدی می‌رود: تایمر.

معنی setTimeout(fn, 0) این است: «fn را در یک تسکِ آینده اجرا کن»، نه «همین الان اجرایش کن». هر میکروتسکی که از قبل در صف است، و هر میکروتسکی که آن‌ها به صف اضافه می‌کنند، زودتر اجرا می‌شود.

میکروتسک‌ها می‌توانند صفحه را گرسنه نگه دارند

چون حلقه تا وقتی صف میکروتسک‌ها خالی نشده از مرحلهٔ ۲ بیرون نمی‌آید، میکروتسکی که مدام میکروتسک دیگری زمان‌بندی کند، هرگز به صفحه اجازهٔ رندر یا پاسخ‌گویی نمی‌دهد:

function spinForever() {
  Promise.resolve().then(spinForever);   // freezes the tab: rendering never gets a turn
}

اگر پرامیس را با یک تایمر عوض کنید، صفحه پاسخ‌گو می‌ماند؛ چون هر callbackِ تایمر یک تسک جداست و حلقه می‌تواند بینِ آن‌ها رندر کند:

function spinPolitely() {
  setTimeout(spinPolitely, 0);           // one task per call: the browser can paint in between
}

setTimeout(fn, 0) واقعاً صفر نیست

وقتی تایمرها پنج لایه تودرتو شوند، مرورگرها تأخیر را دست‌کم ۴ میلی‌ثانیه در نظر می‌گیرند، و در تب‌های پس‌زمینه تایمرها را خیلی بیشتر کُند می‌کنند. هیچ‌وقت برای زمان‌بندیِ دقیق به تایمرها تکیه نکنید.

چرا پیام «در حال پردازش» هرگز نمایش داده نمی‌شود

این رایج‌ترین باگ حلقهٔ رویداد در دنیای واقعی است:

button.addEventListener("click", () => {
  status.textContent = "Crunching numbers…";
  crunchNumbers();                 // synchronous, takes ~2 seconds
  status.textContent = "Done!";
});

کاربر هرگز متن «Crunching numbers…» را نمی‌بیند. DOM به‌روز شده است، اما رسم صفحه فقط بین تسک‌ها انجام می‌شود و هندلر کلیک یک تسکِ طولانی است. وقتی نوبت رسم برسد، متن دیگر «Done!» شده است. در این دو ثانیه صفحه همهٔ کلیک‌ها و کلیدها را هم نادیده می‌گیرد.

راه‌حل این است که کار طولانی را تکه‌تکه کنید و بین تکه‌ها کنترل را به حلقهٔ رویداد واگذار کنید (yield). این واگذاری باید یک تسک تازه بسازد: await Promise.resolve() فقط یک میکروتسک در صف می‌گذارد، پس هرگز به مرورگر فرصت رسم نمی‌دهد.

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();                              // newer browsers
  }
  return new Promise((resolve) => setTimeout(resolve, 0)); // works everywhere
}

async function processAll(items) {
  let lastYield = performance.now();

  for (const item of items) {
    processItem(item);

    if (performance.now() - lastYield > 50) {   // a "long task" is anything over 50 ms
      await yieldToMain();                      // let the browser paint and handle input
      lastYield = performance.now();
    }
  }
}

حالا پیام بارگذاری نمایش داده می‌شود، کلیک‌ها پردازش می‌شوند و کار همچنان سریع تمام می‌شود، چون فقط هر ۵۰ میلی‌ثانیه یک بار کنترل را واگذار می‌کند، نه بعد از هر آیتم. هرجا scheduler.yield() در دسترس باشد انتخاب بهتری است: مرورگر به ادامهٔ کار شما نسبت به بقیهٔ تسک‌های منتظر اولویت می‌دهد، پس کدهای دیگر نمی‌توانند مدام جلوی کار شما بپرند.

وقتی تکه‌تکه کردن کافی نیست

اگر خودِ کار چند ثانیه محاسبهٔ خالص است (مثل پردازش یک فایل خیلی بزرگ یا پردازش تصویر)، آن را به یک Web Worker منتقل کنید. هر worker رشته و حلقهٔ رویداد خودش را دارد، پس رشتهٔ اصلی آزاد می‌ماند.

requestAnimationFrame: کار در لحظهٔ درست

callbackهای requestAnimationFrame در مرحلهٔ ۳ و درست قبل از رسم صفحه اجرا می‌شوند. به همین دلیل جای درستِ به‌روزرسانی‌های بصری هستند: دقیقاً یک بار در هر فریم اجرا می‌شوید؛ نه دو بار بین دو رسم، و نه وسط یک رسم.

function animate(time) {
  box.style.transform = `translateX(${(time / 5) % 600}px)`;
  requestAnimationFrame(animate);       // schedule the next frame
}

requestAnimationFrame(animate);

اگر همین انیمیشن را با setTimeout(animate, 16) پیش ببرید، با نمایشگر هماهنگ نمی‌ماند؛ بعضی فریم‌ها دو به‌روزرسانی می‌گیرند و بعضی هیچ، و این همان لرزشی است که کاربر حس می‌کند.

یک نکتهٔ ظریف: میکروتسک‌ها بین شنونده‌های رویداد

میکروتسک‌ها هر بار که پشتهٔ فراخوانی خالی می‌شود اجرا می‌شوند، نه فقط در پایان یک تسک. به دو شنونده روی یک دکمه نگاه کنید:

button.addEventListener("click", () => {
  Promise.resolve().then(() => console.log("microtask 1"));
  console.log("listener 1");
});

button.addEventListener("click", () => {
  Promise.resolve().then(() => console.log("microtask 2"));
  console.log("listener 2");
});

عامل اجرا	خروجی
کلیکِ واقعیِ کاربر	`listener 1`، `microtask 1`، `listener 2`، `microtask 2`
`button.click()` در کد	`listener 1`، `listener 2`، `microtask 1`، `microtask 2`

وقتی کاربر کلیک می‌کند، مرورگر هر شنونده را با پشتهٔ خالی صدا می‌زند، پس میکروتسک‌ها بین آن‌ها اجرا می‌شوند. اما وقتی کد شما button.click() را صدا می‌زند، کد شما هنوز روی پشته است، پس همهٔ میکروتسک‌ها منتظر می‌مانند تا هر دو شنونده تمام شوند. اگر تستی که کلیک را شبیه‌سازی می‌کند با صفحهٔ واقعی فرق داشت، این نکته را به یاد بیاورید.

Node.js دو صف دیگر هم دارد

Node.js همین مدل را دارد (هر بار یک تسک، و خالی کردن میکروتسک‌ها بعد از هر callback) اما دو ابزار زمان‌بندیِ مخصوص به خودش را هم اضافه می‌کند:

setTimeout(() => console.log("timeout"), 0);
setImmediate(() => console.log("immediate"));
Promise.resolve().then(() => console.log("promise"));
process.nextTick(() => console.log("nextTick"));

اگر این کد را به‌صورت یک اسکریپت CommonJS اجرا کنید، اول nextTick، بعد promise و در آخر timeout و immediate چاپ می‌شوند؛ ترتیبِ این دو آخری ممکن است از اجرایی به اجرای دیگر عوض شود.

callbackهای process.nextTick() قبل از میکروتسک‌های پرامیس اجرا می‌شوند. با احتیاط از آن استفاده کنید: فراخوانی بازگشتیِ nextTick هم درست مثل میکروتسک‌های بازگشتی، حلقه را گرسنه نگه می‌دارد.
setImmediate() در یک مرحلهٔ مخصوص بعد از callbackهای I/O اجرا می‌شود. داخل یک callbackِ I/O همیشه قبل از setTimeout(fn, 0) اجرا می‌شود؛ اما در اسکریپت اصلی ترتیبشان تضمینی نیست.

ماژول‌های ES

در یک ماژول ES (فایل .mjs) ممکن است promise قبل از nextTick چاپ شود، چون خودِ بدنهٔ ماژول از داخل صف میکروتسک‌ها اجرا می‌شود. کدی ننویسید که به ترتیبِ دقیقِ nextTick و پرامیس‌ها وابسته باشد.

جمع‌بندی

حلقهٔ رویداد یک تسک را اجرا می‌کند، بعد همهٔ میکروتسک‌ها را، بعد اگر وقت فریم تازه رسیده باشد رندر می‌کند و دوباره تکرار می‌کند.
callbackهای پرامیس، کدِ بعد از await و queueMicrotask() میکروتسک هستند: همیشه قبل از تایمر، رویداد یا رسمِ بعدی اجرا می‌شوند.
میکروتسکی که تا ابد میکروتسک زمان‌بندی کند صفحه را قفل می‌کند؛ تایمرها این کار را نمی‌کنند، چون هر کدام یک تسک جداست.
کارهای همگامِ طولانی جلوی رسم صفحه و پردازش ورودی را می‌گیرند. آن‌ها را تکه‌تکه کنید و با setTimeout یا scheduler.yield() کنترل را واگذار کنید. await Promise.resolve() کنترل را واگذار نمی‌کند.
برای به‌روزرسانی‌های بصری از requestAnimationFrame و برای محاسبات سنگین از Web Worker استفاده کنید.

دفعهٔ بعد که چیزی «به ترتیب اشتباه» اجرا شد، از خودتان بپرسید: این یک تسک است یا میکروتسک، و چه چیزهای دیگری در همان صف هستند؟

جست‌وجوی دودویی بدون باگ‌های یکی‌کم‌ویکی‌زیاد

Thu, 29 Oct 2026 09:00:00 +0000

جست‌وجوی دودویی (binary search) در یک جمله خلاصه می‌شود: به آیتمِ وسط نگاه کن، بعد نیمه‌ای را که نمی‌تواند چیزِ موردنظرت را داشته باشد دور بریز. هر مرحله بازهٔ باقی‌مانده را نصف می‌کند؛ پس حتی یک میلیارد آیتمِ مرتب فقط حدود ۳۰ مرحله لازم دارد. این یعنی O(log n)؛ اگر Big-O برایتان تازه است، از نماد Big-O با کد واقعی شروع کنید.

درست نوشتنش اما داستان دیگری است. جان بنتلی در کتاب Programming Pearls می‌گوید وقتی از برنامه‌نویس‌های حرفه‌ای خواست جست‌وجوی دودویی بنویسند، حدود ۹۰ درصدشان باگ داشتند. نسخهٔ کتابخانهٔ استاندارد جاوا هم یک باگ سرریز (overflow) داشت که حدود نُه سال کسی متوجهش نشد. مقصرهای همیشگی خطاهای یکی‌کم‌ویکی‌زیاد (off-by-one) هستند: < یا <=؟ mid یا mid + 1؟ حلقه کِی تمام می‌شود؟

این مقاله یک الگو به شما می‌دهد که جواب این سؤال‌ها را خودش می‌دهد، و نشان می‌دهد تا کجا می‌شود از آن استفاده کرد.

سؤالی که باید پرسید

«آیا x در لیست هست؟» ضعیف‌ترین شکلِ جست‌وجوی دودویی است. سؤالِ بسیار مفیدتر این است:

اولین آیتمی که بزرگ‌تر یا مساوی x است کجاست؟

به این معمولاً کران پایین (lower bound) می‌گویند. چند سؤال را هم‌زمان جواب می‌دهد: آیا x وجود دارد، اگر چند بار تکرار شده از کجا شروع می‌شود، و برای مرتب ماندنِ لیست باید کجا درج شود.

یک الگو: بازهٔ نیمه‌باز

def lower_bound(a, x):
    """Index of the first item >= x, or len(a) if every item is smaller."""
    lo, hi = 0, len(a)            # invariant: the answer is between lo and hi (inclusive)
    while lo < hi:
        mid = (lo + hi) // 2
        if a[mid] < x:
            lo = mid + 1          # a[mid] is too small, so the answer is to its right
        else:
            hi = mid              # a[mid] could be the answer: keep it in range
    return lo

هر خط از ناوردا (invariant) نتیجه می‌شود؛ همان جمله‌ای که در کامنت آمده و در تمام اجرای حلقه درست می‌ماند:

hi از len(a) شروع می‌شود، نه len(a) - 1، چون «هیچ آیتمی به اندازهٔ کافی بزرگ نیست» هم جوابِ معتبری است.
اگر a[mid] < x باشد، mid و همهٔ آیتم‌های قبل از آن کوچک‌اند؛ پس جواب دست‌کم mid + 1 است.
در غیر این صورت a[mid] >= x است، پس mid ممکن است جواب باشد. نمی‌توانیم از آن بگذریم؛ پس hi = mid، نه mid - 1.
بازه در هر دور کوچک‌تر می‌شود (mid همیشه از hi کمتر است)، پس حلقه تمام می‌شود. وقتی lo == hi شد، فقط یک نامزد باقی مانده و همان جواب است.

بیایید جست‌وجوی 23 را دنبال کنیم:

lower_bound در جست‌وجوی ۲۳: بازه از کلِ لیست شروع می‌شود، بعد به اندیس‌های ۰ تا ۵، ۳ تا ۵، ۳ تا ۴ و در آخر به اندیس ۴، یعنی اولین ۲۳، می‌رسد

a = [3, 8, 12, 15, 23, 23, 31, 42, 56, 70]
lower_bound(a, 23)   # 4  (the first 23)
lower_bound(a, 20)   # 4  (20 would be inserted before the first 23)
lower_bound(a, 99)   # 10 (bigger than everything: len(a))
lower_bound(a, 1)    # 0

حالا بررسیِ عضویت یک خط است، بدون هیچ حالت خاصی داخل حلقه:

def contains(a, x):
    i = lower_bound(a, x)
    return i < len(a) and a[i] == x

کران بالا و شمارش

< را به <= تغییر دهید تا کران بالا (upper bound) را بگیرید: اولین آیتمی که اکیداً از x بزرگ‌تر است.

def upper_bound(a, x):
    lo, hi = 0, len(a)
    while lo < hi:
        mid = (lo + hi) // 2
        if a[mid] <= x:
            lo = mid + 1
        else:
            hi = mid
    return lo

این دو با هم کلِ بلوکِ آیتم‌های مساوی را به شما می‌دهند؛ پس شمردنِ تکراری‌ها در یک لیست مرتب O(log n) طول می‌کشد، نه O(n):

upper_bound(a, 23) - lower_bound(a, 23)   # 2
a[lower_bound(a, 23):upper_bound(a, 23)]  # [23, 23]

پایتون این‌ها را از قبل دارد

ماژول bisect دقیقاً همین است: bisect.bisect_left(a, x) همان lower_bound است و bisect.bisect_right(a, x) همان upper_bound. bisect.insort(a, x) آیتم را طوری درج می‌کند که لیست مرتب بماند. از پایتون ۳٫۱۰ این توابع key= هم می‌گیرند، مثلاً bisect_left(users, 35, key=lambda u: u.age). در کد واقعی از این‌ها استفاده کنید؛ وقتی به نسخهٔ کلی‌ترِ پایین نیاز دارید، خودتان بنویسید.

نسخهٔ کلی: اولین True

دوباره به آن دو تابع نگاه کنید. تنها چیزی که فرق می‌کند یک شرط است که مدتی False است و از یک جایی به بعد True:

index:      0      1      2      3      4     5     6     ...
a[i] >= 23: False  False  False  False  True  True  True  ...
                                        ↑ the answer

پس جست‌وجوی دودویی در واقع مرزِ یک سؤالِ بله/نه را پیدا می‌کند، به شرطی که جواب‌ها هرگز از True به False برنگردند. این ارزشِ یک تابعِ جداگانه را دارد:

def first_true(lo, hi, pred):
    """Smallest i in [lo, hi) where pred(i) is True, or hi if there is none.
    pred must be False, False, ..., True, True over that range."""
    while lo < hi:
        mid = (lo + hi) // 2
        if pred(mid):
            hi = mid
        else:
            lo = mid + 1
    return lo

lower_bound(a, x) فقط همان first_true(0, len(a), lambda i: a[i] >= x) است. اما شرط اصلاً به آرایه نیازی ندارد.

جست‌وجوی دودویی روی جواب

ریشهٔ دومِ صحیحِ n بزرگ‌ترین r است که r * r <= n. به بیان دیگر، یکی کمتر از اولین r است که r * r > n:

def isqrt(n):
    return first_true(0, n + 1, lambda r: r * r > n) - 1

isqrt(50)          # 7
isqrt(10**12)      # 1000000, in about 40 steps

این ترفند یک خانوادهٔ کامل از مسئله‌های «کمترین مقداری که جواب می‌دهد را پیدا کن» را حل می‌کند. فرض کنید یک کامیون باید بسته‌ها را به ترتیب تحویل دهد، روزی capacity کیلوگرم بار ببرد و همه‌چیز باید ظرف days روز تحویل داده شود. کمترین ظرفیتی که کافی است چقدر است؟

def days_needed(weights, capacity):
    days, load = 1, 0
    for w in weights:
        if load + w > capacity:      # doesn't fit: start a new day
            days, load = days + 1, 0
        load += w
    return days

def min_capacity(weights, days):
    lo, hi = max(weights), sum(weights)
    return first_true(lo, hi, lambda c: days_needed(weights, c) <= days)

min_capacity([3, 2, 2, 4, 1, 4], days=3)   # 6: [3, 2] [2, 4] [1, 4]

پیدا کردنِ مستقیمِ ظرفیت سخت است، اما بررسیِ یک ظرفیت آسان است، و جواب یکنوا (monotonic) است: اگر ظرفیت ۶ کافی باشد، ۷ هم کافی است. جست‌وجوی دودویی یک بررسیِ آسان را به یک جست‌وجوی سریع تبدیل می‌کند: O(n log S) به‌جای امتحان کردنِ تک‌تکِ ظرفیت‌ها تا S = sum(weights).

چند جزئیاتِ مرزی که همه از همان الگو نتیجه می‌شوند: ظرفیت نمی‌تواند از سنگین‌ترین بسته کمتر باشد، پس lo = max(weights). hi = sum(weights) را می‌دهیم با اینکه first_true هرگز خودِ hi را امتحان نمی‌کند: اگر هیچ ظرفیتِ کوچک‌تری جواب ندهد، hi را برمی‌گرداند، که درست است، چون بردنِ همه‌چیز در یک روز همیشه شدنی است.

یکی را از قبل می‌شناسید: git bisect

git bisect دقیقاً همین الگوریتم روی کامیت‌هاست: سؤال این است که «آیا باگ در این کامیت هست؟» و جواب‌ها دقیقاً در یک نقطه از «نه» به «بله» تغییر می‌کنند. هزار کامیت فقط حدود ۱۰ آزمایش لازم دارد.

باگ‌هایی که باید حواستان باشد

باگ	چه چیزی خراب می‌شود	راه‌حل
`hi = len(a) - 1` همراه با `while lo < hi`	`len(a)` هرگز برگردانده نمی‌شود و آخرین آیتم هرگز بررسی نمی‌شود	یک قرارداد انتخاب کنید (ما بازهٔ نیمه‌باز `[lo, hi)` را برداشتیم) و به آن پایبند بمانید
`lo = mid` به‌جای `mid + 1`	وقتی `hi = lo + 1` باشد، `mid == lo` تا ابد: حلقهٔ بی‌پایان	هر شاخه باید بازه را کوچک‌تر کند
`hi = mid - 1`	وقتی `a[mid]` خودش جواب است، ممکن است از آن رد شود	`mid` را فقط وقتی کنار بگذارید که قطعاً جواب نیست
`(lo + hi) / 2` در جاوا، C، Go و…	روی آرایه‌های بزرگ، `lo + hi` می‌تواند از یک int سی‌ودوبیتی سرریز کند	از `lo + (hi - lo) / 2` استفاده کنید (عددهای صحیح پایتون سرریز نمی‌شوند)
جست‌وجو در داده‌های نامرتب	بی‌صدا جوابی برمی‌گرداند که معقول به نظر می‌رسد اما غلط است	اول مرتب کنید، یا مطمئن شوید شرط واقعاً یکنواست

آن را با نسخهٔ کُند بسنجید

جست‌وجوی دودویی نامزدِ کاملی برای تستِ مقایسه با روش brute-force است: یک پیمایشِ خطی به‌وضوح درست است، پس روی هزاران ورودیِ تصادفی، از جمله لیست‌های خالی و تکراری‌ها، با آن مقایسه کنید:

import random

for _ in range(10_000):
    a = sorted(random.randint(0, 20) for _ in range(random.randint(0, 15)))
    x = random.randint(-2, 22)
    expected = next((i for i, v in enumerate(a) if v >= x), len(a))
    assert lower_bound(a, x) == expected, (a, x)

مقدارهای کوچک (۰ تا ۲۰) تعداد زیادی تکراری و حالت مرزی می‌سازند. این نوع تست همهٔ باگ‌های جدول بالا را در کسری از ثانیه پیدا می‌کند.

جمع‌بندی

به‌جای «آیا x اینجاست؟» بپرسید «اولین آیتمِ ≥ x کجاست؟» (کران پایین).
از بازهٔ نیمه‌باز [lo, hi) با while lo < hi، lo = mid + 1 و hi = mid استفاده کنید. هر مرحله بازه را کوچک‌تر می‌کند و در پایان lo جواب است.
جست‌وجوی دودویی مرزِ هر سؤالِ بله/نهِ یکنوا را پیدا می‌کند؛ پس می‌توانید روی جواب‌ها (ظرفیت‌ها، اندازه‌ها، زمان‌ها، کامیت‌ها) جست‌وجو کنید، نه فقط روی آرایه‌ها.
در پایتون اول سراغ bisect بروید.
با یک نسخهٔ brute-force و ورودی‌های تصادفیِ کوچک تست کنید.

توابع پنجره‌ای در SQL: جمع تجمعی، رتبه‌بندی و میانگین متحرک

Thu, 29 Oct 2026 09:00:00 +0000

دیر یا زود گزارشی چیزی می‌خواهد که از GROUP BY برنمی‌آید. هر فروش را کنار مجموعِ منطقه‌اش نشان بده. فروشنده‌ها را در هر منطقه رتبه‌بندی کن. درآمد این ماه را کنار ماه قبل نشان بده. با GROUP BY برای هر گروه یک ردیف می‌گیرید و جزئیات از دست می‌رود؛ آدم‌ها معمولاً سراغ self-join، زیرکوئری یا یک حلقه در کد برنامه می‌روند.

توابع پنجره‌ای (window functions) همهٔ این‌ها را در یک کوئری حل می‌کنند. آن‌ها مقدارها را روی مجموعه‌ای از ردیف‌های مرتبط (همان پنجره) محاسبه می‌کنند، بدون اینکه آن‌ها را در هم فشرده کنند: هر ردیفِ ورودی همچنان در خروجی هست و مقدارِ محاسبه‌شده به شکل یک ستون جدید به آن اضافه می‌شود.

این توابع در PostgreSQL، MySQL 8 به بعد، SQL Server، Oracle و SQLite 3.25 به بعد کار می‌کنند. مثال‌های زیر همان‌طور که هستند در SQLite اجرا می‌شوند. اگر هنوز با JOINها راحت نیستید، از JOINها در SQL با مثال‌های ساده شروع کنید.

داده‌های نمونهٔ ما

CREATE TABLE sales (rep TEXT, region TEXT, amount INTEGER);
INSERT INTO sales VALUES
  ('Ana', 'North', 900), ('Ben', 'North', 700), ('Cleo', 'North', 700), ('Dev', 'North', 400),
  ('Eve', 'South', 1200), ('Finn', 'South', 650), ('Gus', 'South', 300);

CREATE TABLE monthly (month TEXT, revenue INTEGER);
INSERT INTO monthly VALUES
  ('2026-01', 12000), ('2026-02', 15000), ('2026-03', 11000),
  ('2026-04', 18000), ('2026-05', 21000), ('2026-06', 19500);

مقایسهٔ GROUP BY با پنجره

این مجموعِ هر منطقه با GROUP BY است. هفت ردیف وارد می‌شود و دو ردیف بیرون می‌آید:

SELECT region, SUM(amount) AS total
FROM sales
GROUP BY region;

region	total
North	2700
South	2150

حالا همان SUM، اما با یک OVER بعد از آن، که آن را به یک تابع پنجره‌ای تبدیل می‌کند:

SELECT rep, region, amount,
       SUM(amount) OVER (PARTITION BY region) AS region_total,
       ROUND(100.0 * amount / SUM(amount) OVER (PARTITION BY region), 1) AS pct_of_region
FROM sales
ORDER BY region, amount DESC;

rep	region	amount	region_total	pct_of_region
Ana	North	900	2700	33.3
Ben	North	700	2700	25.9
Cleo	North	700	2700	25.9
Dev	North	400	2700	14.8
Eve	South	1200	2150	55.8
Finn	South	650	2150	30.2
Gus	South	300	2150	14.0

هر هفت ردیف می‌مانند. PARTITION BY region ردیف‌ها را مثل GROUP BY گروه‌بندی می‌کند، اما به‌جای اینکه هر گروه را در یک ردیف فشرده کند، به هر ردیف دسترسی به کلِ گروهش را می‌دهد. با یک OVER () خالی، پنجره کلِ نتیجه است.

PARTITION BY ردیف‌ها را به یک پنجرهٔ North و یک پنجرهٔ South تقسیم می‌کند؛ هر ردیف مقدارهای خودش را نگه می‌دارد و مجموعِ پنجره‌اش به آن اضافه می‌شود، و با ORDER BY این مجموع به جمع تجمعی تبدیل می‌شود

ساختار OVER

function(...) OVER (
    PARTITION BY ...   -- which rows belong together (optional)
    ORDER BY ...       -- the order of rows inside each partition (optional)
    ROWS BETWEEN ...   -- which of those rows to use for this row (optional)
)

همهٔ بخش‌ها اختیاری‌اند و هر کدام نتیجه را تغییر می‌دهد. یکی‌یکی سراغشان می‌رویم.

رتبه‌بندی با ROW_NUMBER، RANK و DENSE_RANK

توابع رتبه‌بندی داخل پنجره به یک ORDER BY نیاز دارند. تنها تفاوتشان در رفتار با مقدارهای مساوی است، و داده‌های ما یک تساوی دارد: Ben و Cleo هر دو ۷۰۰ فروخته‌اند.

SELECT rep, amount,
       ROW_NUMBER() OVER (ORDER BY amount DESC) AS row_num,
       RANK()       OVER (ORDER BY amount DESC) AS rnk,
       DENSE_RANK() OVER (ORDER BY amount DESC) AS dense_rnk
FROM sales
ORDER BY amount DESC, rep;

rep	amount	row_num	rnk	dense_rnk
Eve	1200	1	1	1
Ana	900	2	2	2
Ben	700	3	3	3
Cleo	700	4	3	3
Finn	650	5	5	4
Dev	400	6	6	5
Gus	300	7	7	6

ROW_NUMBER همیشه ۱، ۲، ۳، ۴… می‌دهد، بدون تساوی. اینکه Ben یا Cleo عدد ۳ را بگیرد به پایگاه داده بستگی دارد، مگر اینکه یک معیارِ دوم مثل ORDER BY amount DESC, rep اضافه کنید.
RANK به مقدارهای مساوی یک عدد می‌دهد و بعد عدد را جا می‌اندازد: ۳، ۳، ۵. مثل مسابقه‌ای که دو دونده با هم مدال برنز می‌گیرند.
DENSE_RANK به مقدارهای مساوی یک عدد می‌دهد و جا نمی‌اندازد: ۳، ۳، ۴.

N تای برتر در هر گروه

«دو فروشندهٔ برتر در هر منطقه» یکی از رایج‌ترین سؤال‌های گزارش‌گیری است و توابع پنجره‌ای آن را ساده می‌کنند. اما نمی‌توانید مستقیماً روی یک تابع پنجره‌ای فیلتر کنید:

SELECT rep FROM sales WHERE ROW_NUMBER() OVER (ORDER BY amount) <= 2;
-- Error: misuse of window function ROW_NUMBER()

توابع پنجره‌ای بعد از WHERE، GROUP BY و HAVING محاسبه می‌شوند، درست قبل از ORDER BY و LIMIT نهایی. پس رتبه را در یک زیرکوئری یا CTE حساب می‌کنید و بعد نتیجه را فیلتر می‌کنید:

WITH ranked AS (
  SELECT rep, region, amount,
         ROW_NUMBER() OVER (PARTITION BY region ORDER BY amount DESC, rep) AS pos
  FROM sales
)
SELECT region, pos, rep, amount
FROM ranked
WHERE pos <= 2
ORDER BY region, pos;

region	pos	rep	amount
North	1	Ana	900
North	2	Ben	700
South	1	Eve	1200
South	2	Finn	650

اگر می‌خواهید فروشنده‌های هم‌امتیاز هر دو در فهرست بیایند، به‌جای ROW_NUMBER() از RANK() استفاده کنید.

جمع تجمعی

به پنجرهٔ یک تابع تجمیعی ORDER BY اضافه کنید تا تجمعی شود: هر ردیف همه‌چیز را از ابتدای پارتیشن تا خودش جمع می‌زند.

SELECT month, revenue,
       SUM(revenue) OVER (ORDER BY month) AS running_total
FROM monthly;

month	revenue	running_total
2026-01	12000	12000
2026-02	15000	27000
2026-03	11000	38000
2026-04	18000	56000
2026-05	21000	77000
2026-06	19500	96500

با اضافه کردن PARTITION BY، جمع تجمعی برای هر گروه از نو شروع می‌شود؛ مثلاً مجموعِ «از ابتدای سال تا امروز» که هر ژانویه صفر می‌شود.

مقایسه با ردیف قبلی: LAG و LEAD

LAG(column) مقدار را از ردیفِ قبلی در پنجره برمی‌گرداند و LEAD(column) از ردیفِ بعدی. تغییرِ ماه‌به‌ماه به یک تفریقِ ساده تبدیل می‌شود:

SELECT month, revenue,
       LAG(revenue) OVER (ORDER BY month) AS prev_month,
       revenue - LAG(revenue) OVER (ORDER BY month) AS change
FROM monthly;

month	revenue	prev_month	change
2026-01	12000	NULL	NULL
2026-02	15000	12000	3000
2026-03	11000	15000	-4000
2026-04	18000	11000	7000
2026-05	21000	18000	3000
2026-06	19500	21000	-1500

ماه اول ردیفِ قبلی ندارد، پس LAG مقدار NULL برمی‌گرداند. LAG(revenue, 1, 0) به‌جای آن 0 برمی‌گرداند، و LAG(revenue, 12) دوازده ردیف عقب می‌رود که برای مقایسهٔ سال‌به‌سال به کار می‌آید.

قاب‌های پنجره: میانگین متحرک

قاب (frame) تعیین می‌کند کدام ردیف‌های پارتیشن برای ردیفِ فعلی حساب شوند. میانگینِ متحرکِ سه‌ماهه از ردیف فعلی و دو ردیفِ قبل از آن استفاده می‌کند:

SELECT month, revenue,
       ROUND(AVG(revenue) OVER (
         ORDER BY month
         ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
       ), 1) AS avg_3m
FROM monthly;

month	revenue	avg_3m
2026-01	12000	12000.0
2026-02	15000	13500.0
2026-03	11000	12666.7
2026-04	18000	14666.7
2026-05	21000	16666.7
2026-06	19500	19500.0

دو ماه اول میانگینِ ردیف‌های کمتری را می‌گیرند، چون قبل از آن‌ها چیزی نیست. قاب‌های مفیدِ دیگر ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING (پنجره‌ای که ردیف فعلی وسطش است) و ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING (کلِ پارتیشن) هستند.

قابِ پیش‌فرض یک غافلگیری دارد

با ORDER BY و بدون قاب، پیش‌فرض RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW است. RANGE ردیف‌هایی را که مقدارِ ORDER BY مساوی دارند یک قدم حساب می‌کند. یک جمع تجمعی روی amount DESC اجرا کنید تا ببینید Ben و Cleo، که هر دو ۷۰۰ دارند، هر دو ۳۵۰۰ نشان می‌دهند، چون هر کدام دیگری را هم در بر می‌گیرد. وقتی جمعِ دقیقاً ردیف‌به‌ردیف می‌خواهید، ROWS UNBOUNDED PRECEDING بنویسید.

همین پیش‌فرض یک معمای کلاسیک را توضیح می‌دهد: LAST_VALUE(revenue) OVER (ORDER BY month) مقدارِ ردیفِ فعلی را برمی‌گرداند، نه ماهِ آخر را، چون قابِ پیش‌فرض در ردیف فعلی تمام می‌شود. با ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING کلِ پارتیشن را به آن بدهید.

پنجره روی نتایجِ گروه‌بندی‌شده

توابع پنجره‌ای بعد از GROUP BY اجرا می‌شوند، پس می‌توانند روی خودِ گروه‌ها کار کنند. اینجا سهمِ هر منطقه از کلِ فروش را حساب می‌کنیم: SUM(amount) داخلی مجموعِ منطقه است و SUM(...) OVER () بیرونی این مجموع‌ها را روی همهٔ منطقه‌ها جمع می‌زند:

SELECT region,
       SUM(amount) AS total,
       ROUND(100.0 * SUM(amount) / SUM(SUM(amount)) OVER (), 1) AS pct_of_all
FROM sales
GROUP BY region;

region	total	pct_of_all
North	2700	55.7
South	2150	44.3

پنجره‌ای را که چند بار استفاده می‌کنید نام‌گذاری کنید

اگر چند ستون پنجرهٔ یکسانی دارند، آن را یک بار با بخشِ WINDOW بعد از WHERE/GROUP BY/HAVING تعریف کنید: SELECT ..., FIRST_VALUE(revenue) OVER w, LAG(revenue) OVER w FROM monthly WINDOW w AS (ORDER BY month);

برگهٔ تقلب

چه می‌خواهید	از چه استفاده کنید
مجموعِ گروه کنار هر ردیف	`SUM(x) OVER (PARTITION BY g)`
شمارهٔ ردیفِ یکتا در هر گروه	`ROW_NUMBER() OVER (PARTITION BY g ORDER BY x)`
رتبه‌بندی با در نظر گرفتن تساوی	`RANK()` یا `DENSE_RANK()`
جمع تجمعی	`SUM(x) OVER (ORDER BY t ROWS UNBOUNDED PRECEDING)`
مقدارِ ردیفِ قبلی / بعدی	`LAG(x)` / `LEAD(x)`
میانگین متحرک	`AVG(x) OVER (ORDER BY t ROWS BETWEEN n PRECEDING AND CURRENT ROW)`
N تای برتر در هر گروه	`ROW_NUMBER()` در یک CTE، بعد `WHERE pos <= N`

جمع‌بندی

تابع پنجره‌ای یک تابعِ معمولی است که بعد از آن OVER (...) می‌آید. روی ردیف‌های مرتبط محاسبه می‌کند اما همهٔ ردیف‌ها را نگه می‌دارد.
PARTITION BY ردیف‌ها را گروه‌بندی می‌کند، ORDER BY آن‌ها را داخل هر گروه مرتب می‌کند و قاب (ROWS BETWEEN ...) ردیف‌هایی را که در هر محاسبه به کار می‌روند انتخاب می‌کند.
ROW_NUMBER، RANK و DENSE_RANK فقط در رفتار با تساوی‌ها فرق دارند.
توابع پنجره‌ای بعد از WHERE و GROUP BY اجرا می‌شوند؛ پس فیلتر روی آن‌ها را در یک CTE یا زیرکوئری انجام دهید.
حواستان به قابِ پیش‌فرض باشد: برای جمع تجمعیِ دقیق از ROWS استفاده کنید و کلِ پارتیشن را به LAST_VALUE بدهید.

وقتی کوئری‌هایتان میلیون‌ها ردیف را خلاصه می‌کنند، سرعت مهم می‌شود؛ ایندکس‌ها و پلن کوئری در SQL قدم طبیعیِ بعدی است.

ایندکس‌ها و پلن کوئری در SQL: سریع کردن کوئری‌های کُند

Thu, 29 Oct 2026 09:00:00 +0000

کوئری‌ای که روی لپ‌تاپ شما در یک چشم به هم زدن جواب می‌دهد، ممکن است روی سرور اصلی چند ثانیه طول بکشد. معمولاً خودِ کوئری ایرادی ندارد: فقط جدول از هزار ردیف به چند میلیون ردیف رسیده و پایگاه داده برای پیدا کردن همان چند ردیفی که خواسته‌اید، تک‌تکِ ردیف‌ها را می‌خواند.

ایندکس‌ها این مشکل را حل می‌کنند؛ اما فقط ایندکسِ درست، و فقط اگر کوئری شما اجازه بدهد پایگاه داده از آن استفاده کند. در این مقاله یک جدول یک‌میلیون‌ردیفی می‌سازید، می‌بینید یک کوئری از ۱۰۰ میلی‌ثانیه به کمتر از یک میلی‌ثانیه می‌رسد، و یاد می‌گیرید پلن کوئری را بخوانید تا بفهمید چرا.

از SQLite استفاده می‌کنیم، چون تقریباً همه‌جا نصب است و سرور نمی‌خواهد. همین ایده‌ها مستقیم در PostgreSQL و MySQL هم صدق می‌کنند؛ آخر مقاله جدولی برای تطبیق اصطلاحات آمده است. اگر JOINها هنوز برایتان تازه‌اند، از JOINها در SQL با مثال‌های ساده شروع کنید.

ساختن یک میلیون ردیف

یک پایگاه دادهٔ تازه با sqlite3 shop.db باز کنید و این را در آن بچسبانید. این کد جدول orders را می‌سازد و آن را با یک میلیون سفارش تصادفی از ۵۰ هزار مشتری پر می‌کند:

CREATE TABLE orders (
  id          INTEGER PRIMARY KEY,
  customer_id INTEGER NOT NULL,
  status      TEXT    NOT NULL,
  total       REAL    NOT NULL,
  created_at  TEXT    NOT NULL
);

WITH RECURSIVE n(i) AS (
  SELECT 1 UNION ALL SELECT i + 1 FROM n WHERE i < 1000000
)
INSERT INTO orders (customer_id, status, total, created_at)
SELECT abs(random()) % 50000 + 1,
       CASE abs(random()) % 10 WHEN 0 THEN 'pending' WHEN 1 THEN 'cancelled' ELSE 'shipped' END,
       (abs(random()) % 50000) / 100.0,
       datetime('2024-01-01', '+' || (abs(random()) % 86400000) || ' seconds')
FROM n;

بعد با .timer on زمان‌سنجی را روشن کنید. از این به بعد هر کوئری گزارش می‌دهد چقدر طول کشیده است.

خواندن پلن کوئری

اگر قبل از هر کوئری EXPLAIN QUERY PLAN بنویسید، SQLite به‌جای اجرای آن، راهبردش را نشان می‌دهد:

EXPLAIN QUERY PLAN
SELECT * FROM orders WHERE customer_id = 4242;

QUERY PLAN
`--SCAN orders

SCAN یعنی پیمایش کامل جدول: SQLite هر یک میلیون ردیف را می‌خواند و تک‌تک بررسی می‌کند. خودِ کوئری را اجرا کنید؛ در آزمایش ما حدود ۱۰۰ میلی‌ثانیه طول کشید تا چند ردیف انگشت‌شمار را برگرداند. شاید زیاد به نظر نرسد، تا وقتی که یک صفحه آن را بیست بار اجرا کند، یا هزار کاربر هم‌زمان آن صفحه را باز کنند.

ایندکس B-tree چطور کار می‌کند

ایندکس یک نسخهٔ جداگانه و مرتب‌شده از یک یا چند ستون است که هر ورودی‌اش به ردیف اصلی اشاره می‌کند. پایگاه‌های داده آن را به شکل یک B-tree نگه می‌دارند: درختی کم‌عمق از صفحه‌ها (page) که هر کدام صدها کلید مرتب را در خود دارند. برای پیدا کردن 4242، پایگاه داده صفحهٔ ریشه را می‌خواند، اشاره‌گرِ بازه‌ای را که 4242 در آن است دنبال می‌کند و همین را تکرار می‌کند تا به یک صفحهٔ برگ برسد. چون هر صفحه به صدها فرزند منشعب می‌شود، یک میلیون ردیف فقط سه یا چهار سطح لازم دارد.

جست‌وجوی customer_id برابر 4242 در B-tree یک صفحهٔ ریشه، یک صفحهٔ میانی و یک صفحهٔ برگ را می‌خواند و بعد فقط ردیف‌های منطبق را برمی‌دارد

یک ایندکس بسازید و دوباره به پلن نگاه کنید:

CREATE INDEX idx_orders_customer ON orders (customer_id);

EXPLAIN QUERY PLAN
SELECT * FROM orders WHERE customer_id = 4242;

QUERY PLAN
`--SEARCH orders USING INDEX idx_orders_customer (customer_id=?)

SEARCH ... USING INDEX یعنی SQLite در ایندکس تا ورودی‌های منطبق پیش می‌رود و بعد فقط همان ردیف‌ها را از جدول برمی‌دارد. حالا همان کوئری در کمتر از یک میلی‌ثانیه اجرا می‌شود، یعنی تقریباً صد برابر سریع‌تر؛ و این فاصله با بزرگ‌تر شدن جدول بیشتر هم می‌شود: هزینهٔ پیمایش کامل با دو برابر شدن جدول دو برابر می‌شود، اما جست‌وجو در ایندکس تقریباً تغییری حس نمی‌کند.

ایندکس‌های ترکیبی: ترتیب ستون‌ها همه‌چیز است

کوئری‌های واقعی روی بیش از یک ستون فیلتر می‌کنند. این یک نمونهٔ رایج است: سفارش‌های اخیر یک مشتری، به ترتیب تاریخ.

SELECT * FROM orders
WHERE customer_id = 4242 AND created_at >= '2025-01-01'
ORDER BY created_at;

اگر فقط idx_orders_customer وجود داشته باشد، پلن یک خط دوم هم دارد:

QUERY PLAN
|--SEARCH orders USING INDEX idx_orders_customer (customer_id=?)
`--USE TEMP B-TREE FOR ORDER BY

USE TEMP B-TREE FOR ORDER BY یعنی ردیف‌ها نامرتب برمی‌گردند و SQLite باید خودش آن‌ها را مرتب کند. یک ایندکس ترکیبی روی هر دو ستون، فیلتر و مرتب‌سازی را با هم حل می‌کند:

CREATE INDEX idx_orders_customer_created ON orders (customer_id, created_at);

QUERY PLAN
`--SEARCH orders USING INDEX idx_orders_customer_created (customer_id=? AND created_at>?)

ایندکس ترکیبی را مثل دفترچهٔ تلفنی تصور کنید که اول بر اساس نام خانوادگی و بعد بر اساس نام مرتب شده است. داخل بخش «4242»، ورودی‌ها از قبل بر اساس created_at مرتب‌اند؛ پس پایگاه داده مستقیم به اولین تاریخی که لازم دارد می‌پرد و از آنجا جلو می‌رود. بدون هیچ مرحلهٔ مرتب‌سازی.

حالا ستون‌ها را برعکس امتحان کنید. اول دو ایندکسِ مشتری را حذف کنید تا SQLite نتواند آن‌ها را انتخاب کند:

DROP INDEX idx_orders_customer;
DROP INDEX idx_orders_customer_created;
CREATE INDEX idx_orders_created_customer ON orders (created_at, customer_id);

QUERY PLAN
`--SEARCH orders USING INDEX idx_orders_created_customer (created_at>?)

هنوز SEARCH نوشته، پس به نظر درست می‌آید. اما در آزمایش ما ۹۵ میلی‌ثانیه طول کشید؛ تقریباً به کندیِ حالتی که اصلاً ایندکس نداشتیم. داخل پرانتز را نگاه کنید: فقط created_at>? از ایندکس استفاده می‌کند. این بازه حدود دو سوم همهٔ سفارش‌ها را می‌پوشاند و SQLite باید تک‌تک آن ورودی‌ها را برای customer_id = 4242 بررسی کند. قبل از ادامه، این ایندکس را حذف کنید (DROP INDEX idx_orders_created_customer;).

قانون ترتیب ستون‌ها

اول ستون‌هایی را بگذارید که با = مقایسه می‌شوند، و در آخر یک ستون برای بازه (>، <، BETWEEN) یا برای ORDER BY. ایندکسی روی (a, b, c) به کوئری‌هایی روی a به‌تنهایی یا روی a و b هم کمک می‌کند، اما به کوئری‌هایی که فقط روی b یا فقط روی c هستند نه. به این قانون پیشوند سمت چپ (leftmost prefix) می‌گویند.

SEARCH به معنی سریع نیست

همیشه ببینید کدام ستون‌ها داخل پرانتز آمده‌اند. یک SEARCH که فقط از یک بازهٔ گسترده استفاده می‌کند، می‌تواند تقریباً به کندیِ یک SCAN باشد.

ایندکس‌های پوشا: اصلاً سراغ جدول نروید

حتی با یک ایندکس عالی، هر ردیف منطبق یک پرشِ اضافه از ایندکس به جدول لازم دارد تا بقیهٔ ستون‌ها خوانده شود. اگر ایندکس از قبل همهٔ ستون‌هایی که کوئری لازم دارد را داشته باشد، پایگاه داده می‌تواند کلاً از جدول بگذرد:

CREATE INDEX idx_orders_customer_created_total
  ON orders (customer_id, created_at, total);

EXPLAIN QUERY PLAN
SELECT created_at, total FROM orders WHERE customer_id = 4242;

QUERY PLAN
`--SEARCH orders USING COVERING INDEX idx_orders_customer_created_total (customer_id=?)

COVERING INDEX (ایندکس پوشا) بهترین پلنی است که برای یک جست‌وجو می‌توانید بگیرید. بیشترین اثرش روی کوئری‌هایی است که ردیف‌های زیادی برمی‌گردانند، مثل گزارش‌ها و داشبوردها. این هم یک دلیل خوب دیگر برای پرهیز از SELECT * است: وقتی ستون‌های کمتری بخواهید، ایندکس پوشا ممکن می‌شود.

اشتباه‌هایی که بی‌صدا ایندکس را از کار می‌اندازند

ایندکس فقط وقتی کمک می‌کند که پایگاه داده بتواند شرط شما را مستقیم با مقدارهای مرتب‌شده مقایسه کند. اگر ستون را داخل یک تابع یا عبارت بگذارید، دیگر نمی‌تواند. فرض کنید یک ایندکس ساده روی created_at اضافه کرده‌ایم و سفارش‌های یک روز را می‌خواهیم:

CREATE INDEX idx_orders_created ON orders (created_at);

-- ✗ a full SCAN: date() has to be computed for every one of the million entries (≈600 ms)
SELECT count(*) FROM orders WHERE date(created_at) = '2025-03-14';

-- ✓ a SEARCH on idx_orders_created (created_at>? AND created_at<?) (<1 ms)
SELECT count(*) FROM orders
WHERE created_at >= '2025-03-14' AND created_at < '2025-03-15';

هر دو همان تعداد را برمی‌گردانند. به شکل دوم sargable می‌گویند (از Search ARGument ABLE): ستون به‌تنهایی در یک طرف مقایسه آمده است. چند قاتل رایج دیگرِ ایندکس:

به‌جای…	بنویسید…
`WHERE date(created_at) = '2025-03-14'`	`WHERE created_at >= '2025-03-14' AND created_at < '2025-03-15'`
`WHERE price * 1.2 > 100`	`WHERE price > 100 / 1.2`
`WHERE lower(email) = 'ada@example.com'`	ایمیل‌ها را با حروف کوچک ذخیره کنید، یا روی خودِ عبارت ایندکس بسازید (پایین‌تر)
`WHERE name LIKE '%son'`	وایلدکارتِ ابتدای الگو نمی‌تواند از B-tree استفاده کند؛ جست‌وجوی تمام‌متن را در نظر بگیرید

وقتی واقعاً باید روی یک عبارت فیلتر کنید، روی خودِ همان عبارت ایندکس بسازید. SQLite، PostgreSQL و MySQL (از نسخهٔ ۸) همه از این پشتیبانی می‌کنند:

CREATE INDEX idx_orders_day ON orders (date(created_at));
-- now WHERE date(created_at) = '2025-03-14' uses: SEARCH orders USING INDEX idx_orders_day (<expr>=?)

ایندکس‌های جزئی: فقط ردیف‌هایی را ایندکس کنید که کوئری می‌گیرید

فرض کنید یک کار پس‌زمینه مدام سفارش‌های در انتظار (pending) را می‌خواهد که فقط ۱۰ درصد جدول‌اند. یک ایندکس جزئی (partial index) فقط همین ردیف‌ها را در خود دارد:

CREATE INDEX idx_orders_pending ON orders (created_at) WHERE status = 'pending';

EXPLAIN QUERY PLAN
SELECT id, created_at FROM orders
WHERE status = 'pending' AND created_at < '2024-02-01';

QUERY PLAN
`--SEARCH orders USING INDEX idx_orders_pending (created_at<?)

در پایگاه دادهٔ ما این ایندکس ۲٫۷ مگابایت جا می‌گیرد، در برابر ۲۷ مگابایت برای یک ایندکس کامل روی created_at. ایندکس‌های کوچک‌تر سریع‌تر جست‌وجو می‌شوند، راحت‌تر در حافظه جا می‌گیرند و به‌روزرسانی‌شان ارزان‌تر است. PostgreSQL هم ایندکس جزئی دارد؛ MySQL ندارد.

ایندکس‌ها رایگان نیستند

هر ایندکس یک ساختار دادهٔ دوم است که پایگاه داده باید مرتب نگهش دارد. هر INSERT، هر UPDATE روی یک ستونِ ایندکس‌شده و هر DELETE باید همهٔ ایندکس‌های جدول را به‌روز کند. در آزمایش ما، درج ۲۰۰ هزار ردیفِ دیگر در جدول یک‌میلیونی بدون ایندکس ثانویه حدود نیم ثانیه و با سه ایندکس ثانویه بیش از هفت ثانیه طول کشید.

پس هر ستونی را «محض احتیاط» ایندکس نکنید:

ستون‌هایی را ایندکس کنید که در WHERE، JOIN و ORDER BYِ کوئری‌های پرتکرار می‌آیند.
یک ایندکس ترکیبیِ خوب‌طراحی‌شده را به چند ایندکس تک‌ستونی ترجیح دهید.
دنبال ایندکس‌های تکراری بگردید: وقتی (customer_id, created_at) وجود دارد، (customer_id) به خاطر قانون پیشوند سمت چپ زائد است.
ستون‌هایی که فقط چند مقدار متمایز دارند (مثل status) به‌تنهایی به‌ندرت ایندکس خوبی می‌شوند. از آن‌ها در یک ایندکس جزئی یا به‌عنوان ستون‌های بعدیِ یک ایندکس ترکیبی استفاده کنید.
بعد از تغییرات بزرگ در داده‌ها ANALYZE را اجرا کنید تا برنامه‌ریز کوئری آمار به‌روز برای انتخاب بین ایندکس‌ها داشته باشد.

خواندن پلن در PostgreSQL و MySQL

واژه‌ها فرق می‌کنند، اما سؤال‌ها همان‌اند: پیمایش کامل است یا جست‌وجو، از کدام ایندکس استفاده می‌شود و آیا مرحلهٔ مرتب‌سازیِ اضافه‌ای هست؟

چه اتفاقی می‌افتد	SQLite	`EXPLAIN` در PostgreSQL	`EXPLAIN` در MySQL
کل جدول را می‌خواند	`SCAN orders`	`Seq Scan on orders`	`type: ALL`
از ایندکس استفاده می‌کند و بعد ردیف‌ها را برمی‌دارد	`SEARCH ... USING INDEX`	`Index Scan` / `Bitmap Heap Scan`	`type: ref` یا `range`
فقط با خودِ ایندکس جواب می‌دهد	`USING COVERING INDEX`	`Index Only Scan`	`Extra: Using index`
مرحلهٔ مرتب‌سازیِ اضافه	`USE TEMP B-TREE FOR ORDER BY`	`Sort`	`Extra: Using filesort`

در PostgreSQL از EXPLAIN ANALYZE استفاده کنید تا کوئری واقعاً اجرا شود و تعداد واقعیِ ردیف‌ها و زمان‌ها را کنار تخمین‌های برنامه‌ریز ببینید. وقتی تخمینی با تعداد واقعی فاصلهٔ زیادی دارد، معمولاً مقصر آمارِ قدیمی است.

جمع‌بندی

SCAN همهٔ ردیف‌ها را می‌خواند؛ SEARCH ... USING INDEX از طریق یک B-tree مرتب مستقیم سراغ ردیف‌های منطبق می‌رود.
در ایندکس‌های ترکیبی ستون‌های تساوی را اول بگذارید و بعد یک ستون برای بازه یا مرتب‌سازی. ایندکس‌ها فقط به پیشوند سمت چپ خودشان کمک می‌کنند.
ایندکس پوشا بدون دست زدن به جدول به کوئری جواب می‌دهد.
توابع و محاسبات روی ستونِ ایندکس‌شده ایندکس را از کار می‌اندازند. شرط را بازنویسی کنید یا روی عبارت ایندکس بسازید.
ایندکس‌های جزئی وقتی فقط زیرمجموعه‌ای از ردیف‌ها را کوئری می‌گیرید، ایندکس را کوچک نگه می‌دارند.
هر ایندکس نوشتن را کُندتر می‌کند. برای کوئری‌های واقعی ایندکس بسازید و پلن را قبل و بعد از آن بررسی کنید.

مهم‌ترین عادت: قبل از اضافه کردن ایندکس EXPLAIN بگیرید، و بعد از اضافه کردنش دوباره EXPLAIN بگیرید.

الگوریتم دایکسترا: کوتاه‌ترین مسیرها با صف اولویت

Thu, 29 Oct 2026 09:00:00 +0000

اپ نقشه‌تان که مسیری پیدا می‌کند، روتری که تصمیم می‌گیرد یک بسته را به کجا بفرستد، شخصیتی در یک بازی که دور موانع راه می‌رود: همه نسخه‌هایی از یک سؤال‌اند. در گرافی که یال‌هایش وزن دارند، ارزان‌ترین مسیر از اینجا به هر جای دیگر کدام است؟

برای گراف‌های بدون وزن، جست‌وجوی سطح‌اول (BFS) جواب می‌دهد: اول یک قدم دورتر را بگرد، بعد دو قدم، بعد سه قدم. وزن‌ها این را خراب می‌کنند. مسیری با سه یالِ ارزان می‌تواند از مسیری با یک یالِ گران بهتر باشد؛ پس «کمترین تعداد قدم» دیگر یعنی «کوتاه‌ترین» نیست. الگوریتم دایکسترا (Dijkstra) که ادسخر دایکسترا در سال ۱۹۵۹ منتشرش کرد، این مشکل را با یک قاعده حل می‌کند: همیشه نزدیک‌ترین گرهِ تمام‌نشده را بعد از همه گسترش بده.

این مقاله الگوریتم را در پایتون می‌سازد، آن را روی یک گراف واقعی دنبال می‌کند، توضیح می‌دهد چرا کار می‌کند و به جزئیاتی می‌پردازد که نسخهٔ کتاب درسی را از نسخه‌ای که می‌شود به آن اعتماد کرد جدا می‌کند: ورودی‌های کهنه در هیپ، تساوی‌ها، وزن‌های منفی و پیچیدگی. باید با Big-O (نماد Big-O با کد واقعی) و دیکشنری‌های پایتون راحت باشید.

گراف نمونه

شش مکان که با جاده به هم وصل‌اند و روی هر جاده زمانِ سفر نوشته شده. جاده‌ها دوطرفه‌اند.

گرافی با شش گره. کوتاه‌ترین فاصله‌ها از A: A برابر ۰، C برابر ۲، B برابر ۳، D برابر ۸، E برابر ۱۰ و F برابر ۱۲. درخت کوتاه‌ترین مسیرِ برجسته از یال‌های A–C، C–B، B–D، D–E و E–F تشکیل شده

گراف را به شکل یک نقشهٔ مجاورت (adjacency map) نگه می‌داریم: برای هر گره، دیکشنری‌ای از همسایه‌ها و وزنِ یال‌ها.

from collections import defaultdict

edges = [("A", "B", 4), ("A", "C", 2), ("B", "C", 1), ("B", "D", 5), ("C", "D", 8),
         ("C", "E", 10), ("D", "E", 2), ("D", "F", 6), ("E", "F", 2)]

graph = defaultdict(dict)
for u, v, w in edges:
    graph[u][v] = w
    graph[v][u] = w      # undirected: add both directions

ایده

برای هر گره یک فاصلهٔ موقت نگه دارید: ۰ برای مبدأ و بی‌نهایت برای بقیه. بعد این را تکرار کنید:

گرهِ تمام‌نشده‌ای را که کمترین فاصلهٔ موقت را دارد انتخاب کنید. فاصلهٔ آن حالا نهایی است.
همهٔ یال‌هایش را آزادسازی (relax) کنید: اگر عبور از این گره فاصلهٔ کوتاه‌تری از فاصلهٔ فعلیِ یک همسایه به او می‌دهد، همسایه را به‌روز کنید.

تنها بخشِ سخت مرحلهٔ ۱ است: پیدا کردنِ سریعِ کمترین فاصله. پیمایشِ همهٔ گره‌ها در هر مرحله O(V) هزینه دارد. یک صف اولویت (یک هیپ دودویی) آن را به O(log V) می‌رساند.

پیاده‌سازی

ماژول heapq پایتون یک لیستِ ساده را به یک min-heap تبدیل می‌کند. این ماژول عملیاتِ «کاهش کلید» (decrease key) ندارد؛ پس وقتی فاصلهٔ یک گره بهتر می‌شود، فقط یک ورودیِ جدید push می‌کنیم و ورودیِ قدیمی را در هیپ رها می‌کنیم. وقتی ورودیِ قدیمی بالاخره بیرون می‌آید، آن را کهنه (stale) تشخیص می‌دهیم و از آن رد می‌شویم. به این حذف تنبل (lazy deletion) می‌گویند و تقریباً همهٔ پیاده‌سازی‌های پایتون همین‌طور کار می‌کنند.

import heapq

def dijkstra(graph, source):
    dist = {source: 0}
    prev = {}                             # prev[node] = the node we reached it from
    heap = [(0, source)]
    while heap:
        d, node = heapq.heappop(heap)
        if d > dist[node]:
            continue                      # stale entry: we already found a shorter way here
        for neighbor, weight in graph[node].items():
            new_dist = d + weight
            if new_dist < dist.get(neighbor, float("inf")):
                dist[neighbor] = new_dist
                prev[neighbor] = node
                heapq.heappush(heap, (new_dist, neighbor))
    return dist, prev

>>> dist, prev = dijkstra(graph, "A")
>>> dist
{'A': 0, 'B': 3, 'C': 2, 'D': 8, 'E': 10, 'F': 12}

گره‌هایی که از مبدأ نمی‌شود به آن‌ها رسید، اصلاً در dist ظاهر نمی‌شوند.

بازسازیِ مسیر

dist طولِ هر کوتاه‌ترین مسیر را می‌دهد؛ prev اجازه می‌دهد خودِ مسیر را با حرکت به عقب از مقصد بازسازی کنیم:

def path_to(prev, source, target):
    path = [target]
    while path[-1] != source:
        path.append(prev[path[-1]])       # KeyError means target is unreachable
    return path[::-1]

>>> path_to(prev, "A", "F")
['A', 'C', 'B', 'D', 'E', 'F']

اشاره‌گرهای prev یک درخت کوتاه‌ترین مسیر با ریشهٔ مبدأ می‌سازند: همان یال‌های برجسته در نمودار. دقت کنید بهترین مسیر به B جادهٔ مستقیم (۴) نیست، بلکه دور زدن از طریق C است (۲ + ۱ = ۳).

دنبال کردنِ قدم‌به‌قدم

این همهٔ عملیات‌های هیپ برای گراف ماست. به ورودی‌های کهنه دقت کنید: B، D، E و F هر کدام دو بار push می‌شوند، چون بعد از push اول مسیرِ کوتاه‌تری پیدا شده.

Pop	کار	هیپ بعد از آن
(0, A)	A نهایی؛ B = 4، C = 2	(2, C) (4, B)
(2, C)	C نهایی؛ B = 3، D = 10، E = 12	(3, B) (4, B) (10, D) (12, E)
(3, B)	B نهایی؛ D = 8	(4, B) (8, D) (10, D) (12, E)
(4, B)	کهنه، رد شو	(8, D) (10, D) (12, E)
(8, D)	D نهایی؛ E = 10، F = 14	(10, D) (10, E) (12, E) (14, F)
(10, D)	کهنه، رد شو	(10, E) (12, E) (14, F)
(10, E)	E نهایی؛ F = 12	(12, E) (12, F) (14, F)
(12, E)	کهنه، رد شو	(12, F) (14, F)
(12, F)	F نهایی	(14, F)
(14, F)	کهنه، رد شو	خالی

چرا درست است

ادعای اصلی این است: وقتی گره‌ای با فاصلهٔ فعلی‌اش d از هیپ بیرون می‌آید، هیچ مسیرِ کوتاه‌تری به آن وجود ندارد.

فرض کنید مسیرِ کوتاه‌تری وجود داشت. این مسیر از مبدأ (که از قبل نهایی شده) شروع می‌شود و به گرهِ ما ختم می‌شود؛ پس جایی در طول آن اولین گرهی هست که هنوز نهایی نشده؛ اسمش را u بگذارید. بخشی از مسیر که قبل از u است از گره‌های نهایی‌شده می‌گذرد؛ پس u با همان فاصله آزادسازی شده و با کلیدی در هیپ نشسته که از طولِ مسیر تا u بیشتر نیست. چون همهٔ وزن‌ها نامنفی‌اند، یال‌های باقی‌مانده فقط می‌توانند به آن اضافه کنند؛ پس کلیدِ u حداکثر به اندازهٔ طولِ آن مسیرِ کوتاه‌تر است، که از d کمتر است. اما در این صورت هیپ باید u را قبل از گرهِ ما به ما می‌داد. تناقض.

این استدلال دقیقاً به یک فرض تکیه دارد: وزن‌های نامنفی. آن را بردارید تا کل ماجرا فرو بریزد.

یال‌های منفی خرابش می‌کنند

graph = {"A": {"B": 2, "C": 3}, "B": {"D": 2}, "C": {"B": -2}, "D": {}}

فاصلهٔ واقعی تا B برابر ۱ است (A → C → B) و تا D برابر ۳. اما دایکسترا B (با فاصلهٔ ۲) را قبل از C (با فاصلهٔ ۳) بیرون می‌کشد؛ پس B را تمام‌شده حساب می‌کند پیش از آنکه مسیرِ ارزان‌تر از طریق C دیده شود. نسخه‌های کتاب درسی که گره‌ها را «تمام‌شده» علامت می‌زنند B = 2 و D = 4 برمی‌گردانند، که غلط است.

نسخهٔ تنبلِ ما اینجا اتفاقاً خودش را درست می‌کند، چون وقتی فاصلهٔ کوتاه‌تر پیدا می‌شود B را دوباره push می‌کند و بعد B را دوباره پردازش می‌کند. به این تکیه نکنید: با یال‌های منفی یک گره ممکن است بارها و بارها دوباره پردازش شود و روی گراف‌های بدخواهانه زمان اجرا نمایی می‌شود. اگر گرافتان ممکن است وزن منفی داشته باشد، از الگوریتم Bellman–Ford با پیچیدگی O(V·E) استفاده کنید که دورهای منفی را هم تشخیص می‌دهد؛ جایی که اصلاً کوتاه‌ترین مسیری وجود ندارد.

تست با Bellman–Ford

Bellman–Ford کوتاه و کُند است، و همین آن را به یک پیاده‌سازیِ مرجعِ عالی تبدیل می‌کند: همهٔ یال‌ها را V − 1 بار آزادسازی کنید. مقایسهٔ dijkstra() با آن روی چند هزار گرافِ تصادفیِ کوچک با وزن‌های نامنفی راهی سریع برای پیدا کردنِ باگ‌های پیاده‌سازی‌تان است.

پیچیدگی

هر گره فقط یک بار پردازش می‌شود (ورودی‌های بعدی‌اش به‌عنوان کهنه رد می‌شوند)؛ پس هر یال حداکثر یک بار در هر جهت آزادسازی می‌شود و حداکثر یک push ایجاد می‌کند. در نتیجه هیپ O(E) ورودی دارد و هر push و pop هزینهٔ O(log E) دارد. چون E حداکثر V² است، log E حداکثر 2 log V است، که نتیجه می‌دهد:

زمان: O((V + E) log V) با یک هیپ دودویی.
حافظه: O(V + E) برای گراف، فاصله‌ها و هیپ.

برای گراف‌های چگال، که E نزدیک به V² است، یک نسخهٔ ساده‌ترِ O(V²) بدون هیپ در واقع سریع‌تر است: یک آرایه از فاصله‌ها نگه دارید و هر بار برای پیدا کردنِ کمینه آن را پیمایش کنید. ساختارهای نظری مثل هیپ فیبوناچی به O(E + V log V) می‌رسند، اما سربارشان در عمل به‌ندرت می‌ارزد.

جزئیات عملی

زود متوقف شوید. اگر فقط مسیر به یک مقصد را لازم دارید، به محض اینکه آن را pop کردید برگردید. فاصله‌اش در همان لحظه نهایی است و روی یک گراف بزرگ می‌توانید از بیشترِ کار صرف‌نظر کنید:

        d, node = heapq.heappop(heap)
        if node == target:
            return d

تساوی در هیپ. ورودی‌های هیپ تاپل‌اند؛ پس وقتی دو فاصله برابرند پایتون خودِ گره‌ها را مقایسه می‌کند. برای رشته‌ها و عددها مشکلی نیست، اما اشیائی که از < پشتیبانی نمی‌کنند TypeError می‌دهند. یک شمارنده را به‌عنوان معیارِ دوم اضافه کنید:

from itertools import count

tiebreak = count()
heapq.heappush(heap, (new_dist, next(tiebreak), neighbor))

وزن‌های اعشاری. با وزن‌های float، دو مسیرِ «هم‌طول» ممکن است به‌خاطر خطای گرد کردن کمی فرق کنند. وقتی خودِ مسیر دقیقاً مهم است، با یک حدِ تحمل مقایسه کنید یا به عددهای صحیح (سانتی‌متر، میلی‌ثانیه) تبدیل کنید.

قدم‌های بعدی

الگوریتم A* همان دایکسترا به‌علاوهٔ یک تابع تخمین (heuristic) است: هیپ را بر اساس distance + estimate_to_target مرتب می‌کند. با یک تخمینِ خوب (مثل فاصلهٔ خط مستقیم روی نقشه) گره‌های بسیار کمتری را می‌گردد و همچنان کوتاه‌ترین مسیر را پیدا می‌کند، به شرطی که تخمین هرگز بیشتر از مقدار واقعی نباشد.
مسیریابیِ شبکه مستقیماً از دایکسترا استفاده می‌کند: روترهای OSPF با آن کوتاه‌ترین مسیرها را روی نقشهٔ شبکه حساب می‌کنند.
شبکه‌های جاده‌ای در مقیاس یک قاره از تکنیک‌های پیش‌پردازش مثل contraction hierarchies استفاده می‌کنند که در هسته‌شان جست‌وجوهایی به سبک دایکسترا هست.

جمع‌بندی

دایکسترا کوتاه‌ترین مسیرها را از یک مبدأ در گراف‌هایی با وزن یالِ نامنفی پیدا می‌کند.
همیشه نزدیک‌ترین گرهِ تمام‌نشده را گسترش دهید؛ یک min-heap (heapq) آن را در O(log V) پیدا می‌کند.
بدون decrease-key، ورودی‌های تکراری push کنید و از ورودی‌های کهنه رد شوید (if d > dist[node]: continue).
اشاره‌گرهای prev را برای بازسازیِ مسیرها نگه دارید؛ این‌ها یک درخت کوتاه‌ترین مسیر می‌سازند.
زمان اجرا O((V + E) log V) است؛ برای یال‌های منفی از Bellman–Ford و برای گراف‌های خیلی چگال از پیمایشِ آرایه با O(V²) استفاده کنید.

آبشار و Specificity در CSS: چرا استایل‌هایتان اعمال نمی‌شوند

Thu, 29 Oct 2026 09:00:00 +0000

یک قاعدهٔ CSS می‌نویسید. صفحه را دوباره بارگذاری می‌کنید. هیچ چیزی عوض نمی‌شود. DevTools را باز می‌کنید و آنجاست، خط خورده: قاعدهٔ دیگری در جایی برنده شده. پس یک کلاس اضافه می‌کنید، بعد یک ID، بعد !important، و شش ماه بعد هیچ‌کس جرئت نمی‌کند به استایل‌شیت دست بزند.

اینکه کدام قاعده برنده می‌شود هیچ چیزِ تصادفی‌ای ندارد. وقتی چند اعلان (declaration) یک ویژگی را روی یک عنصر تنظیم می‌کنند، مرورگر آبشار (cascade) را اجرا می‌کند: یک توالیِ ثابت از معیارهای تعیین برنده. این توالی را یاد بگیرید تا هر بار برنده را پیش‌بینی کنید و CSSی بنویسید که اصلاً به !important نیاز نداشته باشد. (اگر هنوز با چیدمان راحت نیستید، Flexbox یا Grid در CSS شروع خوبی است.)

آبشار، به ترتیب

مرورگر برای هر ویژگیِ هر عنصر، همهٔ اعلان‌هایی را که اعمال می‌شوند جمع می‌کند و بعد آن‌ها را به این ترتیب مقایسه می‌کند. اولین مرحله‌ای که تفاوتی پیدا کند تصمیم می‌گیرد؛ مرحله‌های بعدی فقط تساوی را می‌شکنند.

آبشار اعلان‌ها را مرحله‌به‌مرحله مقایسه می‌کند: منشأ و اهمیت، استایل درون‌خطی، لایهٔ آبشار، specificity و در آخر ترتیب ظاهر شدن؛ اولین مرحله‌ای که تفاوتی داشته باشد برنده را انتخاب می‌کند

منشأ و اهمیت. استایل‌شیت‌های شما بر استایل‌های پیش‌فرضِ مرورگر غلبه می‌کنند. اعلانی که با !important علامت خورده بر همهٔ اعلان‌های معمولی غلبه می‌کند.
استایل‌های درون‌خطی. ویژگیِ style="…" بر هر سلکتوری در استایل‌شیت غلبه می‌کند.
لایه‌های آبشار. اگر از @layer استفاده کنید، استایل‌های لایه‌های بعدی بر لایه‌های قبلی غلبه می‌کنند، سلکتورهایشان هر چه باشد.
Specificity. سلکتورِ دقیق‌تر برنده است.
ترتیب ظاهر شدن. اگر همه‌چیزِ دیگر برابر باشد، اعلانی که آخر می‌آید برنده است.

بیشترِ غافلگیری‌های روزمره در مرحله‌های ۴ و ۵ اتفاق می‌افتند، پس از همان‌جا شروع کنیم.

محاسبهٔ specificity

Specificity امتیازی است که از سه عدد ساخته می‌شود و معمولاً به شکل (A, B, C) نوشته می‌شود:

A: تعداد سلکتورهای ID (#header)
B: تعداد سلکتورهای کلاس (.card)، سلکتورهای attribute ([type="email"]) و شبه‌کلاس‌ها (:hover، :focus، :nth-child())
C: تعداد سلکتورهای نوع (p، button) و شبه‌عنصرها (::before)

سلکتورِ همگانیِ * و ترکیب‌کننده‌ها (، >، +، ~) هیچ امتیازی ندارند.

سلکتور	Specificity
`p`	(0, 0, 1)
`.card p`	(0, 1, 1)
`.card .title`	(0, 2, 0)
`a:hover`	(0, 1, 1)
`input[type="email"]`	(0, 1, 1)
`ul li::before`	(0, 0, 3)
`#sidebar a`	(1, 0, 1)
`#nav .item a:hover`	(1, 2, 1)
`*`	(0, 0, 0)

برای مقایسهٔ دو سلکتور، اول A را مقایسه کنید. فقط اگر A برابر بود سراغ B بروید، و فقط اگر B برابر بود سراغ C. بین ستون‌ها هیچ «انتقالی» وجود ندارد: یک ID یعنی (1, 0, 0) بر سلکتوری با بیست کلاس یعنی (0, 20, 0) غلبه می‌کند.

این یک غافلگیریِ کلاسیک است:

#main .button { background: gray; }   /* (1, 1, 0) */
.button.primary { background: blue; } /* (0, 2, 0) */

<div id="main">
  <button class="button primary">Save</button>   <!-- gray! -->
</div>

دکمهٔ primary خاکستری است، با اینکه .button.primary از نظر یک آدم دقیق‌تر به نظر می‌رسد و بعدتر هم آمده. ID در ستون A برنده می‌شود و کار هرگز به مرحلهٔ ۵ نمی‌رسد.

بگذارید DevTools حساب کند

در مرورگرهای مبتنی بر Chromium، نشانگر ماوس را روی یک سلکتور در پنل Styles نگه دارید تا specificity آن را ببینید. زبانهٔ Computed مقدار نهاییِ هر ویژگی را نشان می‌دهد و وقتی بازش کنید، همهٔ قاعده‌هایی را که سعی کرده‌اند آن را تنظیم کنند، با برنده در ابتدا.

شبه‌کلاس‌های :is()، :not()، :has() و :where()

این شبه‌کلاس‌ها فهرستی از سلکتورها می‌گیرند و امتیازشان طور دیگری حساب می‌شود:

:is()، :not() و :has() specificity دقیق‌ترین آرگومانشان را می‌گیرند. :is(#nav, .menu) a امتیاز (1, 0, 1) دارد، حتی وقتی از طریق .menu منطبق می‌شود.
:where() همیشه specificity صفر دارد، هر چه داخلش باشد.

همین :where() را برای پیش‌فرض‌هایی که باید راحت بازنویسی شوند عالی می‌کند:

/* (0, 0, 1): any later class beats it */
:where(.prose) a { color: royalblue; }

/* (0, 1, 1): would beat most component styles, which is usually not what you want */
.prose a { color: royalblue; }

ارث‌بری همان آبشار نیست

بعضی ویژگی‌ها، بیشترشان مربوط به متن مثل color، font-family و line-height، به ارث می‌رسند: اگر هیچ چیزی آن‌ها را روی یک عنصر تنظیم نکند، عنصر مقدارِ والدش را می‌گیرد. بقیه، مثل margin، border و background، به ارث نمی‌رسند.

تله اینجاست: یک مقدارِ به‌ارث‌رسیده همیشه به هر قاعده‌ای که مستقیماً خودِ عنصر را هدف می‌گیرد می‌بازد، سلکتورِ آن قاعده هر قدر هم ضعیف باشد.

#article { color: darkred; }   /* (1, 0, 0), but applies to the div */
p { color: black; }            /* (0, 0, 1), applies to the p itself */

<div id="article">
  <p>This text is black, not dark red.</p>
</div>

Specificity فقط قاعده‌هایی را مقایسه می‌کند که با یک عنصرِ واحد منطبق می‌شوند. قاعدهٔ #article با div منطبق می‌شود؛ پاراگراف فقط از آن ارث می‌برد، و ارث‌بری فقط وقتی وارد عمل می‌شود که هیچ قاعده‌ای color را روی خودِ پاراگراف تنظیم نکند.

چهار کلیدواژه به شما اجازه می‌دهند این را روی هر ویژگی‌ای صریحاً کنترل کنید:

کلیدواژه	معنی
`inherit`	مقدارِ والد را بگیر
`initial`	از مقدارِ پیش‌فرضِ ویژگی در مشخصات CSS استفاده کن
`unset`	برای ویژگی‌های ارثی مثل `inherit`، برای بقیه مثل `initial`
`revert`	به همان چیزی برگرد که استایل‌شیتِ خودِ مرورگر تنظیم می‌کند

کلیدواژهٔ !important و استایل‌های درون‌خطی

!important در مرحلهٔ ۱ از صف جلو می‌زند، حتی قبل از اینکه به specificity نگاه شود. دقیقاً به همین دلیل دردسر می‌سازد: تنها راهِ بازنویسیِ یک اعلانِ !important یک اعلانِ !important دیگر است که در مرحله‌های بعدی برنده شود، و این‌طور مسابقهٔ تسلیحاتی شروع می‌شود.

ویژگی‌های style درون‌خطی (مرحلهٔ ۲) بر هر سلکتوری غلبه می‌کنند، اما به !important در استایل‌شیت می‌بازند.

کلیدواژهٔ !important را برای کلاس‌های کمکی نگه دارید

یک استفادهٔ معقول، یک کلاسِ کمکیِ کوچک است که باید همیشه برنده شود، مثل .hidden { display: none !important; }. استفاده از آن برای حل یک مشکلِ specificity فقط مشکل را تا دفعهٔ بعد پنهان می‌کند.

لایه‌های آبشار: specificity تحت کنترل

لایه‌های آبشار (@layer، که از سال ۲۰۲۲ در همهٔ مرورگرهای اصلی پشتیبانی می‌شود) یک مرحله بالاتر از specificity اضافه می‌کنند. ترتیب لایه‌هایتان را یک بار اعلام می‌کنید و از آن به بعد لایهٔ بعدی بر لایهٔ قبلی غلبه می‌کند، سلکتورها هر چه باشند:

@layer reset, vendor, components, utilities;

@layer vendor {
  #app .btn { background: gray; }       /* (1, 1, 0) */
}

@layer components {
  .btn { background: royalblue; }       /* (0, 1, 0), and it wins */
}

در عبارتِ @layer، لایهٔ components بعد از vendor آمده؛ پس .btn آن با وجود specificity خیلی کمتر برنده می‌شود. این برای CSS کتابخانه‌های بیرونی ایده‌آل است: آن را در یک لایهٔ اولیه بپیچید (@import url("library.css") layer(vendor);) تا استایل‌های خودتان بدون ترفندهای specificity بر آن غلبه کنند.

دو جزئیاتِ ارزشمند: استایل‌هایی که در هیچ لایه‌ای نیستند بر همهٔ استایل‌های لایه‌دار غلبه می‌کنند، و برای اعلان‌های !important ترتیب لایه‌ها برعکس می‌شود؛ یعنی !important یک لایهٔ قبلی بر !important لایهٔ بعدی غلبه می‌کند.

عادت‌هایی که جلوی جنگِ specificity را می‌گیرند

با کلاس استایل بدهید، نه با ID. IDها را برای لینک‌های داخلی و جاوااسکریپت نگه دارید.
سلکتورها را کوتاه و تخت نگه دارید. .card-title به‌جای .sidebar .card > h2.title. سلکتورهای تخت specificity مشابهی دارند، پس ترتیبِ کد و لایه‌ها تصمیم می‌گیرند، و استدلال دربارهٔ این‌ها آسان است.
پیش‌فرض‌ها و ریست‌ها را در :where() بپیچید تا بازنویسی‌شان ساده باشد.
از @layer استفاده کنید تا استایل‌های پایه و کتابخانه‌های بیرونی زیرِ کامپوننت‌هایتان قرار بگیرند.
وقتی قاعده‌ای اعمال نمی‌شود، اول DevTools را نگاه کنید: خط خورده است (در آبشار باخته)، نیست (سلکتور منطبق نمی‌شود)، یا با هشدار نشان داده شده (مقدارِ نامعتبر)؟

جمع‌بندی

آبشار برنده را به ترتیبی ثابت انتخاب می‌کند: منشأ و !important، استایل‌های درون‌خطی، لایه‌ها، specificity و بعد ترتیب ظاهر شدن.
Specificity یعنی (IDها، کلاس‌ها/attributeها/شبه‌کلاس‌ها، عنصرها/شبه‌عنصرها) که ستون‌به‌ستون و بدون انتقال مقایسه می‌شوند.
:is()، :not() و :has() امتیازِ قوی‌ترین آرگومانشان را می‌گیرند؛ :where() صفر اضافه می‌کند.
مقدارهای به‌ارث‌رسیده به هر قاعده‌ای که مستقیماً خودِ عنصر را هدف بگیرد می‌بازند.
سلکتورهای کلاسیِ تخت، :where() و @layer را به IDها و !important ترجیح دهید.

Stacking Context در CSS: چرا z-index: 9999 کار نمی‌کند

Thu, 29 Oct 2026 09:00:00 +0000

این یکی از رایج‌ترین باگ‌های CSS است. مودال z-index: 9999 دارد. هدر سایت z-index: 10 دارد. و هدر روی مودال رسم می‌شود. 99999 را امتحان می‌کنید، بعد !important را؛ هیچ چیزی عوض نمی‌شود.

مرورگر خراب نیست. z-index رتبه‌بندیِ سراسریِ همهٔ عنصرهای صفحه نیست. فقط عنصرهای داخل یک stacking context را مرتب می‌کند، و مودال شما داخل contextی گیر افتاده که در کل زیرِ هدر قرار دارد. این مقاله توضیح می‌دهد مرورگر چطور تصمیم می‌گیرد چه چیزی رو باشد، چه چیزهایی این contextها را می‌سازند (اغلب تصادفی) و چطور contextی را که باعث باگ شده پیدا و درست کنید. فرض بر این است که با آبشار (آبشار و Specificity در CSS) و موقعیت‌دهی (positioning) راحت هستید.

باگ

<header class="site-header">…</header>
<main class="page">
  <div class="modal">…</div>
</main>

.site-header { position: sticky; top: 0; z-index: 10; }
.page        { position: relative; z-index: 1; }
.modal       { position: fixed; inset: 0; z-index: 9999; }

مودال زیرِ هدر رسم می‌شود. برای فهمیدنِ دلیلش به دو ایده نیاز داریم: ترتیب رسم داخل یک stacking context، و اینکه contextها چطور تودرتو می‌شوند.

ترتیب رسم داخل یک stacking context

stacking context گروهی از عنصرهاست که مرورگر آن‌ها را با هم و به‌عنوان یک واحد رسم می‌کند. داخل هر کدام، ترتیب رسم از پایین به بالا این است:

پس‌زمینه و حاشیه‌های عنصری که context را می‌سازد
نوادگانِ موقعیت‌دار با z-index منفی (منفی‌ترین اول)
جعبه‌های بلوکیِ معمولی، به ترتیب سند
floatها
محتوای درون‌خطی: متن، تصویرها، inline-blockها
نوادگانِ موقعیت‌دار با z-index: auto یا 0، به ترتیب سند
نوادگانِ موقعیت‌دار با z-index مثبت، از کوچک‌ترین

دو پیامد آدم‌ها را غافلگیر می‌کند. اول، عنصرهای موقعیت‌دار حتی بدون هیچ z-indexی بالای عنصرهای بدون موقعیت رسم می‌شوند: اضافه کردنِ تنهای position: relative می‌تواند یک عنصر را به جلو بیاورد. دوم، z-index فقط روی عنصرهای موقعیت‌دار (relative، absolute، fixed، sticky) و آیتم‌های flex و grid اثر دارد. روی یک بلوکِ ایستای معمولی نادیده گرفته می‌شود.

contextها مثل شماره‌نسخه تودرتو می‌شوند

قانونِ کلیدی این است: هر stacking context داخل context والدش به‌عنوان یک لایهٔ واحد رسم می‌شود، در جایگاهی که z-index خودش تعیین می‌کند. هر چیزی داخل آن، درون همان لایه کشیده می‌شود؛ پس یک فرزند هرگز نمی‌تواند از جایگاهِ والدش فرار کند، z-index خودش هر قدر هم بالا باشد.

یک مدل ذهنیِ خوب، شماره‌نسخه‌هاست. در مثال ما، context ریشه دو لایه دارد: هدر (10) و .page (1). عدد 9999 مودال فقط داخل .page معنا دارد؛ پس جایگاهِ واقعی‌اش چیزی مثل 1.9999 است:

context ریشه هدر را با z-index 10 و main.page را با z-index 1 در خود دارد. z-index 9999 مودال فقط داخل main.page اعمال می‌شود، پس ترتیبِ واقعی‌اش 1.9999 است که از 10 کمتر است

مرورگر اول در سطحِ ریشه 10 را با 1 مقایسه می‌کند و هدر برنده می‌شود. عدد 9999 اصلاً هرگز با هدر مقایسه نمی‌شود. کلِ باگ همین است.

چه چیزهایی stacking context می‌سازند

این فهرستِ مهم است، چون بیشترِ stacking contextها تصادفی ساخته می‌شوند؛ به‌عنوان اثرِ جانبیِ ویژگی‌ای که به دلیل دیگری اضافه شده:

ویژگی	وقتی context می‌سازد که…
`position: relative` / `absolute`	`z-index` هر چیزی جز `auto` باشد
`position: fixed` / `sticky`	همیشه
آیتمِ flex یا grid	`z-index` هر چیزی جز `auto` باشد
`opacity`	کمتر از `1` باشد
`transform`، `scale`، `rotate`، `translate`	هر چیزی جز `none` باشد
`filter`، `backdrop-filter`	هر چیزی جز `none` باشد
`clip-path`، `mask`، `perspective`	هر چیزی جز `none` باشد
`mix-blend-mode`	هر چیزی جز `normal` باشد
`isolation`	`isolate` باشد
`will-change`	نامِ یکی از ویژگی‌های بالا را بیاورد
`contain`	`layout`، `paint`، `strict` یا `content` باشد
`container-type`	`size` یا `inline-size` باشد

به‌علاوهٔ عنصر ریشه (<html>) که همیشه یک context است.

پس یک انیمیشنِ fade-in (opacity: 0.99 در طول transition)، یک «ترفند کارایی» مثل transform: translateZ(0) یا یک will-change: transform روی یک wrapper، هر کدام می‌توانند همهٔ z-indexهای داخلشان را گیر بیندازند. علت‌های کلاسیک در دنیای واقعی:

یک wrapper انیمیشن‌دار برای صفحه با transform که همهٔ مودال‌ها و منوهای کشویی داخلش را گیر می‌اندازد.
یک هدرِ sticky در یک بخش از صفحه و یک منوی کشویی داخلِ بخشِ sticky دیگری.
یک کارت با opacity: 0.95 که tooltipاش زیرِ کارتِ بعدی می‌رود.

ویژگی transform موقعیتِ fixed را هم خراب می‌کند

والدی با transform، filter، perspective یا will-change: transform فقط یک stacking context نمی‌سازد: بلوکِ دربرگیرنده (containing block) برای نوادگانِ position: fixed هم می‌شود. آن‌وقت مودالِ «fixed» شما به‌جای viewport نسبت به همان والد جای می‌گیرد و با آن اسکرول می‌شود. اگر یک عنصرِ fixed هم جایش اشتباه است و هم در لایهٔ اشتباه است، دنبال یک transform بگردید.

پیدا کردنِ contextی که گیرتان انداخته

DevTools مستقیماً stacking contextها را نشان نمی‌دهد، اما با چند خط جاوااسکریپت می‌توانید پیدایشان کنید. عنصرِ مشکل‌دار را در پنل Elements انتخاب کنید و بعد این را در کنسول بچسبانید ($0 همان عنصرِ انتخاب‌شده است):

function stackingContexts(el) {
  const found = [];
  for (let node = el.parentElement; node; node = node.parentElement) {
    const s = getComputedStyle(node);
    const parent = node.parentElement && getComputedStyle(node.parentElement);
    const reasons = [];
    const flexOrGridItem = /flex|grid/.test(parent?.display ?? "");
    if (s.zIndex !== "auto" && (s.position !== "static" || flexOrGridItem))
      reasons.push(`z-index: ${s.zIndex}`);
    if (s.position === "fixed" || s.position === "sticky") reasons.push(`position: ${s.position}`);
    if (s.opacity !== "1") reasons.push(`opacity: ${s.opacity}`);
    for (const prop of ["transform", "scale", "rotate", "translate", "filter", "backdropFilter", "perspective", "clipPath"])
      if (s[prop] && s[prop] !== "none") reasons.push(prop);
    if (s.mixBlendMode !== "normal") reasons.push(`mix-blend-mode: ${s.mixBlendMode}`);
    if (s.isolation === "isolate") reasons.push("isolation: isolate");
    if (/transform|opacity|filter/.test(s.willChange)) reasons.push(`will-change: ${s.willChange}`);
    if (reasons.length) found.push({ element: node, reasons: reasons.join(", ") });
  }
  return found;
}

console.table(stackingContexts($0));

این تابع از عنصر به بالا حرکت می‌کند و همهٔ والدهایی را که stacking context می‌سازند، همراه با دلیلش، فهرست می‌کند. علت‌های رایج را پوشش می‌دهد، نه تک‌تکِ قاعده‌های جدول را. اولین ردیف همان contextی است که z-index شما در آن گیر افتاده؛ z-index عنصری را که با آن درگیرید با z-index همان والد مقایسه کنید، نه با z-index خودتان.

درست کردنش

وقتی فهمیدید کدام context عنصر را گیر انداخته، راه‌حلی را انتخاب کنید که با علت جور است:

۱. context تصادفی را حذف کنید. اگر .page واقعاً به z-index: 1 (یا آن transform یا will-change) نیاز ندارد، پاکش کنید. وقتی آن ویژگی «محض احتیاط» اضافه شده، این بهترین راه‌حل است.

۲. عنصر را بیرون ببرید. لایه‌های رویی مثل مودال‌ها، toastها و منوهای کشویی بهتر است فرزندِ مستقیمِ <body> رندر شوند، بیرون از context همهٔ کامپوننت‌ها. بیشترِ فریم‌ورک‌های رابط کاربری ابزاری برای این دارند: createPortal در React، <Teleport> در Vue و کتابخانه‌های portal در Svelte.

۳. از لایهٔ بالایی استفاده کنید. مرورگرهای مدرن یک لایهٔ بالایی (top layer) دارند که بالای کلِ سند و بیرون از همهٔ stacking contextها قرار دارد. عنصرها از طریق APIهای خودِ پلتفرم به آنجا می‌رسند؛ پس اصلاً به z-index نیازی نیست:

<dialog id="confirm">
  <p>Delete this file?</p>
  <form method="dialog"><button>Cancel</button> <button value="ok">Delete</button></form>
</dialog>

<script>
  document.getElementById("confirm").showModal();   // rendered in the top layer
</script>

<dialog>ی که با showModal() باز شود، عنصرهایی با ویژگیِ popover و عنصرهای تمام‌صفحه، همه در لایهٔ بالایی رندر می‌شوند، هر جای DOM که باشند. showModal() یک ::backdrop هم اضافه می‌کند، فوکوس را داخل دیالوگ نگه می‌دارد و با Esc بسته می‌شود؛ چیزهایی که یک مودالِ دست‌ساز معمولاً اشتباه پیاده می‌کند.

۴. کلِ context را بالا ببرید. اگر هیچ‌کدام از این‌ها جواب نداد، z-index ریشهٔ context (یعنی .page) را عوض کنید، نه عنصرِ داخلش را. یادتان باشد این کار همه‌چیزِ داخلِ .page را هم با خودش جابه‌جا می‌کند.

ویژگی isolation: isolate، نوعِ مفیدِ context

گاهی می‌خواهید یک stacking context داشته باشید. یک مثالِ رایج، لایه‌ای تزئینی پشتِ محتوای یک کارت است:

.card { position: relative; background: white; }
.card::before {
  content: "";
  position: absolute;
  inset: -4px;
  z-index: -1;                 /* behind the card's content... */
  background: linear-gradient(135deg, violet, orange);
  border-radius: inherit;
}

بدون stacking context روی .card، شبه‌عنصرِ ::before با z-index: -1 در هر contextی که کارت در آن است، در مرحلهٔ ۲ِ ترتیب رسم کشیده می‌شود: زیرِ پس‌زمینهٔ سفیدِ خودِ کارت. هالهٔ رنگی پشتِ همان کارتی پنهان می‌شود که قرار بود قابش باشد، و حتی ممکن است پشتِ پس‌زمینهٔ والدهای کارت هم برود.

به کارت context خودش را بدهید تا مشکل از بین برود:

.card { position: relative; background: white; isolation: isolate; }

حالا ::before داخلِ context کارت رسم می‌شود: بالای پس‌زمینهٔ کارت و زیرِ محتوایش. isolation: isolate دقیقاً برای همین وجود دارد. یک context می‌سازد و هیچ کار دیگری نمی‌کند: نه موقعیت‌دهی، نه مقدارِ z-indexی که باید مدیریتش کنید، نه اثر جانبی.

یک مقیاسِ z-index برای بقیه

برای عنصرهایی که واقعاً در یک context مشترک‌اند، از مسابقهٔ عددهای بزرگ‌تر و بزرگ‌تر پرهیز کنید. یک مقیاسِ کوچک را یک بار تعریف کنید، مثلاً --z-dropdown: 10; --z-sticky: 20; --z-overlay: 30; --z-toast: 40;، و فقط از همین مقدارها استفاده کنید. اگر چیزی باید بین دو سطح قرار بگیرد، این یک تصمیمِ طراحی است، نه عددی برای از خود درآوردن.

جمع‌بندی

z-index فقط عنصرهای داخل یک stacking context را مرتب می‌کند؛ contextها تودرتو می‌شوند، پس با شماره‌نسخه فکر کنید: 1.9999 < 10.
ترتیب رسم داخل یک context این است: پس‌زمینه، z-index منفی، بلوک‌ها، floatها، محتوای درون‌خطی، z-index: auto/0 و z-index مثبت.
z-index فقط روی عنصرهای موقعیت‌دار و آیتم‌های flex/grid کار می‌کند.
ویژگی‌های زیادی به‌عنوان اثر جانبی context می‌سازند: opacity کمتر از ۱، transform، filter، will-change، موقعیتِ fixed/sticky و بیشتر.
باگ‌های هم‌پوشانی را با حذفِ contextهای تصادفی، بردنِ لایه‌های رویی به <body> یا استفاده از لایهٔ بالایی (<dialog>، popover) حل کنید. وقتی عمداً یک context می‌خواهید، از isolation: isolate استفاده کنید.

لیست کامپرهنشن در پایتون: از حلقه تا یک‌خطی‌های زیبا

Mon, 26 Oct 2026 09:00:00 +0000

اگر کد پایتونِ دیگران را خوانده باشید، تقریباً حتماً چیزی شبیه این دیده‌اید:

squares = [n * n for n in range(10)]

این یک لیست کامپرهنشن (List Comprehension) است: روشی فشرده برای ساختن یک لیست جدید از روی یک مجموعهٔ قابل پیمایش. وقتی مفهومش جا بیفتد، مدام از آن استفاده خواهید کرد. در این راهنما از همان حلقهٔ for که می‌شناسید شروع می‌کنیم، فیلتر کردن و تبدیل داده را می‌بینیم، سراغ کامپرهنشنِ دیکشنری و مجموعه می‌رویم و در پایان می‌گوییم کِی نباید از آن استفاده کنید.

از حلقه‌ای که می‌شناسید شروع کنید

روش کلاسیک ساختن لیستی از مربع‌ها این است:

squares = []
for n in range(10):
    squares.append(n * n)

print(squares)  # [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]

سه خط و سه کار: ساختن یک لیست خالی، پیمایش و افزودن. کامپرهنشن همین ایده را در یک خط بیان می‌کند:

squares = [n * n for n in range(10)]

آن را این‌طور بخوانید: «به ازای هر n در range(10)، مقدار n * n را به من بده.» عبارتی که می‌خواهید جمع شود اول می‌آید و بعد حلقه‌ای که مقادیر را تولید می‌کند.

اجزای یک کامپرهنشن

هر لیست کامپرهنشن از این الگو پیروی می‌کند:

[expression for item in iterable if condition]

همین سه بخش در یک کامپرهنشن واقعی که اعداد زوجِ کمتر از ۱۰ را به توان دو می‌رساند

بخش	معنی	الزامی؟
`expression`	چیزی که در لیست جدید قرار می‌گیرد	بله
`for item in iterable`	مقادیر از کجا می‌آیند	بله
`if condition`	فقط آیتم‌هایی که شرط را دارند نگه داشته می‌شوند	خیر

فیلتر کردن با `if`

برای نگه داشتن فقط بعضی آیتم‌ها، یک شرط به انتها اضافه کنید. این‌جا اعداد زوج را نگه می‌داریم:

evens = [n for n in range(20) if n % 2 == 0]
# [0, 2, 4, 6, 8, 10, 12, 14, 16, 18]

می‌توانید هم‌زمان تبدیل و فیلتر کنید. این کد طول کلمه‌هایی را که بیش از سه حرف دارند جمع می‌کند:

words = ["git", "python", "sql", "linux", "css", "docker"]
long_word_lengths = [len(w) for w in words if len(w) > 3]
# [6, 5, 6]

انتخاب مقدار با `if ... else`

اگر بخواهید همهٔ آیتم‌ها را نگه دارید اما بعضی‌شان را تغییر دهید چه؟ یک if ... else را قبل از for بگذارید. این عبارت شرطیِ پایتون است، نه فیلتر:

scores = [92, 47, 78, 30, 85]
results = ["pass" if s >= 50 else "fail" for s in scores]
# ['pass', 'fail', 'pass', 'fail', 'pass']

قانون جایگاه را به خاطر بسپارید

if بعد از for آیتم‌ها را حذف می‌کند. if ... else قبل از for تعیین می‌کند هر آیتم به چه چیزی تبدیل شود. اولی می‌تواند لیست را کوتاه‌تر کند؛ دومی هرگز.

مثال‌های واقعی

کامپرهنشن‌ها وقتی داده را تمیز یا بازآرایی می‌کنید می‌درخشند.

یکدست کردن ورودی کاربر:

raw_emails = ["  Ada@Example.com", "grace@example.com  ", "", "LINUS@example.com"]
emails = [e.strip().lower() for e in raw_emails if e.strip()]
# ['ada@example.com', 'grace@example.com', 'linus@example.com']

بیرون کشیدن یک فیلد از لیستی از دیکشنری‌ها:

users = [
    {"name": "Ada", "active": True},
    {"name": "Grace", "active": False},
    {"name": "Linus", "active": True},
]
active_names = [u["name"] for u in users if u["active"]]
# ['Ada', 'Linus']

تخت کردن یک لیست تودرتو. حلقه‌ها به همان ترتیبی می‌آیند که در دستورهای for تودرتو می‌آمدند:

matrix = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
flat = [value for row in matrix for value in row]
# [1, 2, 3, 4, 5, 6, 7, 8, 9]

کامپرهنشنِ دیکشنری و مجموعه

همین سینتکس با آکولاد هم کار می‌کند. برای ساختن دیکشنری از key: value استفاده کنید:

words = ["git", "python", "sql"]
lengths = {w: len(w) for w in words}
# {'git': 3, 'python': 6, 'sql': 3}

دونقطه را حذف کنید تا یک مجموعه (set) بگیرید که تکراری‌ها را خودکار حذف می‌کند:

unique_lengths = {len(w) for w in words}
# {3, 6}

Generator Expression: کامپرهنشن بدون لیست

اگر کروشه‌ها را با پرانتز عوض کنید، یک generator expression دارید. این عبارت به‌جای ساختن کل لیست در حافظه، مقادیر را یکی‌یکی تولید می‌کند؛ مناسب وقتی که فقط یک بار به مقادیر نیاز دارید:

total = sum(n * n for n in range(1_000_000))

وقتی generator expression تنها آرگومانِ یک تابع باشد، مثل بالا می‌توانید پرانتزهای اضافه را حذف کنید. توابعی مثل sum()، any()، all()، max() و min() با آن‌ها عالی کار می‌کنند:

has_admin = any(u.get("role") == "admin" for u in users)

کِی کامپرهنشن ننویسیم

کامپرهنشن‌ها برای خواناتر کردن کد هستند. اگر کدی خوانایی‌اش را از دست داد، از حلقه استفاده کنید. مراقب این نشانه‌ها باشید:

در یکی دو خط به‌راحتی جا نمی‌شود. کامپرهنشن‌های تودرتو با چند شرط به‌سختی خوانده می‌شوند.
به اثر جانبی نیاز دارید. ننویسید [print(x) for x in items]. این کار لیستی دورریختنی از None می‌سازد. از حلقهٔ for استفاده کنید.
برای هر آیتم به try/except یا چند دستور نیاز دارید. کامپرهنشن فقط یک عبارت را در خود جا می‌دهد؛ یک حلقه یا یک تابع کمکی واضح‌تر است.

# Hard to read: avoid
result = [x * y for x in range(10) if x % 2 for y in range(x) if y > 2 and x + y < 12]

# Clearer: give the logic a name
def odd_pair_products(limit):
    for x in range(1, limit, 2):
        for y in range(3, x):
            if x + y < 12:
                yield x * y

result = list(odd_pair_products(10))

جمع‌بندی

[expr for x in items] همهٔ آیتم‌ها را تبدیل می‌کند.
[expr for x in items if cond] فیلتر هم می‌کند.
[a if cond else b for x in items] برای هر آیتم یک مقدار انتخاب می‌کند.
برای دیکشنری از {k: v ...}، برای مجموعه از {x ...} و برای generatorهای تنبل از (x ...) استفاده کنید.
اگر کد دارد بیش از حد زیرکانه می‌شود، حلقه معمولاً با خوانندهٔ بعدی مهربان‌تر است؛ خواننده‌ای که شاید خودتان باشید.

تمرین: یکی از اسکریپت‌هایی را که اخیراً نوشته‌اید باز کنید و دنبال الگوی «لیست خالی، حلقه، append» بگردید. آن را به کامپرهنشن تبدیل کنید و صادقانه تصمیم بگیرید کدام نسخه خواناتر است.

درک async/await در جاوااسکریپت

Wed, 21 Oct 2026 09:00:00 +0000

جاوااسکریپت کد شما را روی یک رشته (thread) اجرا می‌کند، با این حال می‌تواند فایل دانلود کند، منتظر تایمرها بماند و با پایگاه داده حرف بزند بی‌آنکه قفل شود. راز این کار کد ناهمگام (asynchronous) است و async/await خواناترین راه برای نوشتن آن است.

در این مقاله یاد می‌گیرید پرامیس واقعاً چیست، async/await چطور روی آن بنا شده، خطاها را چطور درست مدیریت کنید و چطور از رایج‌ترین اشتباهِ عملکردیِ برنامه‌نویسان دوری کنید.

مسئله: منتظر ماندن بدون مسدود کردن

فرض کنید می‌خواهید اطلاعات یک کاربر را از یک API بگیرید. شبکه ممکن است ۳۰۰ میلی‌ثانیه طول بکشد. اگر جاوااسکریپت همان‌جا می‌ایستاد و صبر می‌کرد، کل صفحه قفل می‌شد: نه کلیکی، نه اسکرولی، نه انیمیشنی.

در عوض، توابع ناهمگام بلافاصله یک پرامیس (Promise) برمی‌گردانند؛ شیئی که نمایندهٔ مقداری است که بعداً در دسترس خواهد بود.

پرامیس در ۶۰ ثانیه

هر پرامیس همیشه در یکی از سه حالت است:

pending (در انتظار): کار هنوز در جریان است
fulfilled (انجام‌شده): کار با موفقیت و با یک مقدار تمام شده
rejected (ردشده): کار با یک خطا شکست خورده

با .then() و .catch() به پرامیس واکنش نشان می‌دهید:

fetch("https://api.github.com/users/octocat")
  .then((response) => response.json())
  .then((user) => console.log(user.name))
  .catch((error) => console.error("Request failed:", error));

این روش کار می‌کند، اما با بزرگ‌تر شدن منطق، دنبال کردن زنجیره‌ها سخت می‌شود؛ مخصوصاً وقتی هر مرحله به نتیجهٔ مرحلهٔ قبل وابسته است.

ورود async/await

async/await سینتکسی است که روی پرامیس‌ها ساخته شده. با آن می‌توانید کد ناهمگامی بنویسید که مثل کد همگام خوانده می‌شود:

async function showUser(username) {
  const response = await fetch(`https://api.github.com/users/${username}`);
  const user = await response.json();
  console.log(user.name);
}

showUser("octocat");

دو قانون این کار را ممکن می‌کند:

async قبل از تابع باعث می‌شود تابع همیشه یک پرامیس برگرداند.
await همان تابع را متوقف می‌کند تا پرامیس به نتیجه برسد و بعد مقدارش را به شما می‌دهد. در این فاصله بقیهٔ کدها اجرا می‌شوند؛ فقط همین تابع منتظر می‌ماند.

await صفحه را قفل نمی‌کند

وقتی showUser روی یک await متوقف است، مرورگر آزاد است کلیک‌ها را پردازش کند، توابع دیگر را اجرا کند و صفحه را دوباره رسم کند. تابع پس از به نتیجه رسیدن پرامیس ادامه پیدا می‌کند.

مدیریت خطا با try/catch

در زنجیره‌های .then() از .catch() استفاده می‌کنید. با async/await از همان try/catch آشنا استفاده می‌کنید:

async function getUser(username) {
  try {
    const response = await fetch(`https://api.github.com/users/${username}`);

    if (!response.ok) {
      throw new Error(`HTTP ${response.status}`);
    }

    return await response.json();
  } catch (error) {
    console.error(`Could not load ${username}:`, error.message);
    return null;
  }
}

fetch فقط در خطای شبکه رد می‌شود

پاسخ 404 یا 500 پرامیسِ fetch() را رد نمی‌کند. همیشه خودتان response.ok (یا response.status) را بررسی کنید، همان‌طور که بالا دیدید.

اشتباه شمارهٔ ۱: کدی که ناخواسته پشت‌سرهم اجرا می‌شود

به این تابع نگاه کنید. مشکلش را می‌بینید؟

async function loadDashboard() {
  const user = await getUser("octocat");     // ~300 ms
  const repos = await getRepos("octocat");   // ~300 ms
  const events = await getEvents("octocat"); // ~300 ms
  return { user, repos, events };            // total: ~900 ms
}

هر درخواست منتظر می‌ماند تا قبلی تمام شود، در حالی که هیچ‌کدام به دیگری وابسته نیستند! همه را هم‌زمان شروع کنید و با Promise.all() با هم منتظرشان بمانید:

async function loadDashboard() {
  const [user, repos, events] = await Promise.all([
    getUser("octocat"),
    getRepos("octocat"),
    getEvents("octocat"),
  ]);
  return { user, repos, events };            // total: ~300 ms
}

همان نتیجه، تقریباً سه برابر سریع‌تر.

منتظر ماندنِ تک‌تکِ درخواست‌های مستقل زمان‌هایشان را جمع می‌کند؛ Promise.all آن‌ها را هم‌زمان اجرا می‌کند

انتخاب ترکیب‌کنندهٔ مناسب پرامیس

متد	انجام می‌شود وقتی…	رد می‌شود وقتی…
`Promise.all()`	همهٔ پرامیس‌ها انجام شوند	هر کدام رد شود
`Promise.allSettled()`	همهٔ پرامیس‌ها به نتیجه برسند	هرگز
`Promise.race()`	اولین پرامیسی که به نتیجه می‌رسد انجام شود	اولین پرامیسی که به نتیجه می‌رسد رد شود
`Promise.any()`	اولین پرامیس انجام شود	همهٔ پرامیس‌ها رد شوند

وقتی همهٔ نتیجه‌ها را می‌خواهید حتی اگر بعضی شکست بخورند، از Promise.allSettled() استفاده کنید؛ مثلاً برای بارگذاری چند ویجت اختیاری:

const results = await Promise.allSettled([getRepos("octocat"), getEvents("octocat")]);

for (const result of results) {
  if (result.status === "fulfilled") {
    render(result.value);
  } else {
    console.warn("Widget failed:", result.reason);
  }
}

افزودن مهلت زمانی (Timeout)

fetch() به‌طور پیش‌فرض مهلت زمانی ندارد. در مرورگرهای مدرن و Node.js نسخهٔ ۱۸ به بعد، AbortSignal.timeout() آن را در یک خط به شما می‌دهد:

async function fetchWithTimeout(url, ms = 5000) {
  const response = await fetch(url, { signal: AbortSignal.timeout(ms) });
  if (!response.ok) throw new Error(`HTTP ${response.status}`);
  return response.json();
}

اگر درخواست بیش از ms میلی‌ثانیه طول بکشد، پرامیس با یک TimeoutError رد می‌شود که می‌توانید مثل هر خطای دیگری در try/catch مدیریتش کنید.

حلقه‌ها و await

استفاده از await داخل حلقهٔ for...of آیتم‌ها را یکی‌یکی پردازش می‌کند. این دقیقاً همان چیزی است که وقتی ترتیب مهم است یا نباید یک API را زیر بار ببرید، لازم دارید:

for (const id of orderIds) {
  await processOrder(id); // waits for each one before starting the next
}

وقتی کارها مستقل‌اند، آن‌ها را به پرامیس تبدیل کنید و با هم منتظرشان بمانید:

await Promise.all(orderIds.map((id) => processOrder(id)));

forEach منتظر نمی‌ماند

orderIds.forEach(async (id) => await processOrder(id)) منتظر هیچ چیزی نمی‌ماند، چون forEach پرامیس‌هایی را که تابعِ شما برمی‌گرداند نادیده می‌گیرد. به‌جای آن از for...of یا Promise.all() استفاده کنید.

جمع‌بندی

پرامیس نمایندهٔ یک مقدار در آینده است: در انتظار، انجام‌شده یا ردشده.
توابع async همیشه پرامیس برمی‌گردانند؛ await فقط همان تابع را متوقف می‌کند.
برای خطاها از try/catch استفاده کنید و یادتان باشد با fetch() مقدار response.ok را بررسی کنید.
کارهای مستقل را با Promise.all() موازی اجرا کنید، نه اینکه یکی‌یکی منتظرشان بمانید.
هرگز به forEach برای منتظر ماندنِ callbackهای ناهمگام تکیه نکنید.

دفعهٔ بعد که await می‌نویسید، از خودتان بپرسید: آیا این خط واقعاً باید منتظر خط بالایی بماند؟ همین یک سؤال برنامه‌هایتان را به‌طور محسوسی سریع‌تر می‌کند.

روش کاری عملی با برنچ‌های گیت برای مبتدی‌ها

Wed, 14 Oct 2026 09:00:00 +0000

وقتی تازه گیت را یاد می‌گیرید، طبیعی است که همه‌چیز را مستقیم روی main کامیت کنید. این روش جواب می‌دهد، تا وقتی که مجبور شوید وسط کار روی یک فیچر باگی را درست کنید یا هم‌تیمی‌تان تغییراتی را پوش کند که با تغییرات شما تداخل دارد.

برنچ‌ها (branch) این مشکل را حل می‌کنند. در این راهنما روش کاری ساده‌ای را یاد می‌گیرید که تیم‌هایی در هر اندازه از آن استفاده می‌کنند: برای هر کار یک برنچ بسازید، آزادانه کامیت کنید و وقتی آماده شد آن را ادغام کنید.

برنچ واقعاً چیست

برنچ در گیت فقط یک اشاره‌گر متحرک به یک کامیت است. ساختنش آنی است و تقریباً هزینه‌ای ندارد، چون گیت فایل‌هایتان را کپی نمی‌کند. وقتی کامیت جدیدی می‌سازید، برنچی که روی آن هستید جلو می‌رود و به کامیت جدید اشاره می‌کند.

یک برنچ فیچر از main جدا می‌شود، کامیت‌های خودش را می‌گیرد و دوباره ادغام می‌شود

این‌جا feature/login بعد از کامیت C از main جدا می‌شود و دو کامیتِ مخصوص خودش، D و E، را می‌گیرد. کار روی یک برنچ تا وقتی ادغام نکنید روی برنچ دیگر اثری ندارد؛ ادغام، کامیتِ ادغامِ M را می‌سازد.

روش کار در یک نگاه

برنچ main محلی را به‌روز کنید.
یک برنچ فیچر بسازید.
کارتان را در قدم‌های کوچک کامیت کنید.
برنچ را پوش کنید و یک پول ریکوئست باز کنید.
برنچ را با main به‌روز نگه دارید.
ادغام کنید و بعد برنچ را حذف کنید.

بیایید قدم‌به‌قدم جلو برویم.

قدم ۱: از یک main به‌روز شروع کنید

git switch main
git pull origin main

git switch (گیت ۲.۲۳ به بعد) جایگزین مدرن‌تر و واضح‌ترِ git checkout برای جابه‌جایی بین برنچ‌هاست.

قدم ۲: یک برنچ فیچر بسازید

git switch -c feature/login-form

فلگ -c برنچ را می‌سازد و یک‌جا به آن منتقل می‌شود. از نام‌های توصیفی با پیشوند استفاده کنید تا همه بفهمند هر برنچ برای چیست:

پیشوند	کاربرد	مثال
`feature/`	قابلیت جدید	`feature/login-form`
`fix/`	رفع باگ	`fix/password-reset-email`
`docs/`	مستندات	`docs/api-examples`
`refactor/`	بهبود کد بدون تغییر رفتار	`refactor/user-service`

قدم ۳: در قدم‌های کوچک و معنادار کامیت کنید

تغییری بدهید، مرورش کنید و بعد کامیت کنید:

git status              # what changed?
git diff                # review the exact changes
git add src/login.js    # stage specific files
git commit -m "Add login form markup and validation"

پیام کامیت را برای خودِ آینده‌تان بنویسید

پیام را کوتاه و به شکل دستوری بنویسید (مثلاً «Add validation»، نه «Added validation») و توضیح دهید چه چیزی و چرا تغییر کرده، نه اینکه چطور. یک آزمون خوب: پیامتان باید این جمله را کامل کند: «If applied, this commit will…»

قدم ۴: پوش کنید و پول ریکوئست باز کنید

اولین بار که برنچ جدیدی را پوش می‌کنید، به گیت بگویید کدام برنچِ ریموت را دنبال کند:

git push -u origin feature/login-form

-u برنچِ بالادستی (upstream) را تنظیم می‌کند تا از این به بعد یک git push ساده کافی باشد. حالا در GitHub، GitLab یا Bitbucket پیشنهادی برای باز کردن یک پول ریکوئست (در GitLab به آن merge request می‌گویند) می‌بینید. این‌جا هم‌تیمی‌ها کدتان را بررسی می‌کنند، نظر می‌دهند و تست‌های خودکار پیش از رسیدن هر چیزی به main اجرا می‌شوند.

قدم ۵: برنچ را به‌روز نگه دارید

اگر در حین کار شما main جلو رفت، آن تغییرات را به برنچتان بیاورید تا تداخل‌ها را زود و در تکه‌های کوچک حل کنید:

git switch main
git pull origin main
git switch feature/login-form
git merge main

بعضی تیم‌ها به‌جای git merge main از git rebase main استفاده می‌کنند که کامیت‌های شما را روی آخرین نسخهٔ main بازپخش می‌کند و تاریخچه‌ای خطی می‌سازد. هر دو روش درست‌اند؛ از قرارداد تیمتان پیروی کنید.

هرگز تاریخچهٔ مشترک را rebase نکنید

rebase کامیت‌ها را بازنویسی می‌کند. فقط برنچ‌هایی را rebase کنید که هیچ‌کس دیگری کارش را روی آن‌ها بنا نکرده است؛ وگرنه برای هم‌تیمی‌هایتان تداخل‌های دردسرساز درست می‌کنید.

حل کردن تداخل ادغام

تداخل (conflict) وقتی پیش می‌آید که دو برنچ خط‌های یکسانی را تغییر داده باشند. گیت متوقف می‌شود و فایل را علامت‌گذاری می‌کند:

<<<<<<< HEAD
const MAX_ATTEMPTS = 5;
=======
const MAX_ATTEMPTS = 3;
>>>>>>> main

بخش HEAD نسخهٔ برنچ شماست و بخش پایینی از main می‌آید. فایل را طوری ویرایش کنید که نسخهٔ درست بماند، نشانه‌ها را پاک کنید و ادغام را تمام کنید:

git add src/config.js
git commit

قدم ۶: ادغام و مرتب‌سازی

وقتی پول ریکوئست تأیید شد، آن را از طریق پلتفرم میزبانی ادغام کنید. بعد محیط محلی را مرتب کنید:

git switch main
git pull origin main
git branch -d feature/login-form

git branch -d از حذف برنچی که ادغام نشده خودداری می‌کند، پس گزینهٔ پیش‌فرض امنی است. اگر تیمتان از squash merge استفاده می‌کند، ممکن است گیت برنچ را ادغام‌شده تشخیص ندهد. وقتی مطمئن شدید پول ریکوئست ادغام شده، git branch -D حذف را اجباری می‌کند.

دستورهای کاربردی برای به خاطر سپردن

git branch                        # list local branches
git branch -a                     # include remote branches
git log --oneline --graph --all   # visualise history
git switch -                      # jump back to the previous branch
git stash                         # shelve uncommitted changes temporarily
git stash pop                     # bring them back

جمع‌بندی

برنچ یک اشاره‌گر سبک است، پس آزادانه بسازیدش.
یک برنچ برای هر فیچر یا رفع باگ، main را همیشه آمادهٔ انتشار نگه می‌دارد.
در قدم‌های کوچک کامیت کنید، پیام‌های واضح بنویسید و برای بررسی، پول ریکوئست باز کنید.
main را مرتب در برنچتان ادغام کنید تا از تداخل‌های بزرگ جلوگیری شود.
بعد از ادغام، برنچ‌ها را حذف کنید تا مخزنتان مرتب بماند.

این روش کار را حتی در پروژه‌های تک‌نفره هم به کار ببرید. عادت‌هایی می‌سازد که پیوستن به یک تیم را آسان می‌کند.

نماد Big-O با کد واقعی

Wed, 07 Oct 2026 09:00:00 +0000

کد شما روی ۱۰۰ آیتم کار می‌کند. آیا روی ۱٬۰۰۰٬۰۰۰ آیتم هم کار خواهد کرد؟ نماد Big-O به همین سؤال جواب می‌دهد. این نماد توصیف می‌کند که زمان اجرا (یا مصرف حافظهٔ) یک الگوریتم با بزرگ‌تر شدن ورودی چطور رشد می‌کند.

برای استفاده از آن به ریاضیات پیشرفته نیازی ندارید. در این مقاله به توابع واقعی نگاه می‌کنیم، کاری را که انجام می‌دهند می‌شماریم و شهودی می‌سازیم که بتوانید روی کد خودتان به کار ببرید.

ایدهٔ اصلی: رشد، نه سرعت

Big-O نمی‌گوید یک تابع ۳ میلی‌ثانیه طول می‌کشد. می‌گوید زمان چطور مقیاس می‌پذیرد:

اگر ورودیِ یک تابع O(n) را دو برابر کنید، زمان تقریباً دو برابر می‌شود.
اگر ورودیِ یک تابع O(n²) را دو برابر کنید، زمان تقریباً چهار برابر می‌شود.

ثابت‌ها و جمله‌های کوچک‌تر را هم کنار می‌گذاریم. تابعی که 3n + 10 گام برمی‌دارد همان O(n) است، چون وقتی n بزرگ می‌شود، 3 و 10 در مقایسه با خودِ رشد اهمیتی ندارند.

O(1): زمان ثابت

مقدار کار اصلاً به اندازهٔ ورودی بستگی ندارد:

def get_first(items):
    return items[0]

def is_even(n):
    return n % 2 == 0

دسترسی به یک خانهٔ لیست، جست‌وجوی یک کلید در دیکشنری و افزودن به انتهای لیست (به‌طور میانگین) همه O(1) هستند.

O(n): زمان خطی

مقدار کار به نسبت مستقیم با ورودی رشد می‌کند. یک بار پیمایش همهٔ آیتم‌ها مثال کلاسیک آن است:

def find_max(numbers):
    largest = numbers[0]
    for n in numbers:          # runs n times
        if n > largest:
            largest = n
    return largest

عملیات O(n)ِ پنهان را هم خوب است بشناسید: x in some_list، some_list.index(x)، sum() و max() همه کل لیست را پیمایش می‌کنند.

O(n²): زمان درجهٔ دو

حلقه‌ای داخل حلقهٔ دیگر که هر دو روی ورودی اجرا می‌شوند، تقریباً n × n گام به شما می‌دهد:

def has_duplicates(items):
    for i in range(len(items)):
        for j in range(i + 1, len(items)):   # nested loop
            if items[i] == items[j]:
                return True
    return False

برای ۱٬۰۰۰ آیتم این حدود نیم میلیون مقایسه است. برای ۱٬۰۰۰٬۰۰۰ آیتم حدود ۵۰۰ میلیارد. این فاصلهٔ بین «فوری» و «فردا برگرد» است.

راه‌حل: حافظه را با سرعت معاوضه کنید

می‌توانیم has_duplicates را با به خاطر سپردنِ آیتم‌های دیده‌شده در یک set به O(n) برسانیم؛ بررسی عضویت در set به‌طور میانگین O(1) است:

def has_duplicates(items):
    seen = set()
    for item in items:          # runs n times
        if item in seen:        # O(1) on average
            return True
        seen.add(item)          # O(1) on average
    return False

یا به شکل خلاصه‌تر:

def has_duplicates(items):
    return len(set(items)) != len(items)

کمی حافظهٔ اضافه (فضای O(n)) خرج می‌کنیم تا مقدار عظیمی زمان صرفه‌جویی کنیم. این معاوضه یکی از رایج‌ترین بهینه‌سازی‌ها در کدهای دنیای واقعی است.

O(log n): زمان لگاریتمی

الگوریتم‌های لگاریتمی در هر گام مسئله را نصف می‌کنند. جست‌وجوی دودویی (binary search) روی یک لیست مرتب، مثال درسیِ آن است:

def binary_search(sorted_items, target):
    low, high = 0, len(sorted_items) - 1
    while low <= high:
        mid = (low + high) // 2
        if sorted_items[mid] == target:
            return mid
        if sorted_items[mid] < target:
            low = mid + 1       # discard the left half
        else:
            high = mid - 1      # discard the right half
    return -1

جست‌وجو در ۱٬۰۰۰٬۰۰۰ آیتم مرتب حداکثر حدود ۲۰ گام طول می‌کشد، چون ۲ به توان ۲۰ تقریباً ۱٬۰۰۰٬۰۰۰ است. داده را دو برابر کنید و فقط یک گام اضافه می‌شود.

O(n log n): نقطهٔ طلایی مرتب‌سازی

الگوریتم‌های مرتب‌سازیِ کارآمد و همه‌منظوره در O(n log n) اجرا می‌شوند؛ از جمله merge sort و Timsort که پشتوانهٔ sorted() و list.sort() در پایتون است. این فقط کمی بدتر از خطی است و بهترین حالت ممکن برای مرتب‌سازی از طریق مقایسهٔ عناصر است.

names = sorted(names)   # O(n log n)

مقایسهٔ نرخ‌های رشد

تعداد تقریبی گام‌ها برای اندازه‌های مختلف ورودی:

پیچیدگی	n = 10	n = 1,000	n = 1,000,000
O(1)	1	1	1
O(log n)	3	10	20
O(n)	10	1,000	1,000,000
O(n log n)	33	10,000	20,000,000
O(n²)	100	1,000,000	1,000,000,000,000

همان نرخ‌های رشد به شکل منحنی: با بزرگ شدن n فاصلهٔ آن‌ها به‌شدت زیاد می‌شود

یک قاعدهٔ سرانگشتی

یک پردازندهٔ مدرن که کد کامپایل‌شده اجرا می‌کند، به‌طور خیلی تقریبی ۱۰ به توان ۸ عملیات ساده در ثانیه انجام می‌دهد و پایتون کمتر از این. اگر الگوریتم شما ۱۰ به توان ۱۲ گام لازم داشته باشد، هیچ ارتقای سخت‌افزاری نجاتتان نمی‌دهد. یک الگوریتم بهتر نجاتتان می‌دهد.

چطور کد خودتان را تحلیل کنید

حلقه‌ها را پیدا کنید. حلقه‌ای روی ورودی معمولاً O(n) است. حلقه‌های تودرتو روی ورودی در هم ضرب می‌شوند: O(n²).
داخل فراخوانی توابع را ببینید. item in my_list داخل یک حلقه، یک حلقهٔ تودرتوی پنهان است.
بزرگ‌ترین جمله را نگه دارید. O(n² + n) ساده می‌شود به O(n²).
به بدترین حالت فکر کنید. اگر چیز دیگری گفته نشده باشد، Big-O معمولاً بدترین حالت را توصیف می‌کند.

یک مثال فریبنده. پیچیدگی‌اش چقدر است؟

def common_items(a, b):
    return [x for x in a if x in b]

اگر b یک لیست باشد، x in b هر بار آن را پیمایش می‌کند، پس این کد O(n × m) است. اول b را به set تبدیل کنید تا به O(n + m) برسد:

def common_items(a, b):
    b_set = set(b)                          # O(m)
    return [x for x in a if x in b_set]     # O(n)

جمع‌بندی

Big-O توصیف می‌کند مقدار کار با اندازهٔ ورودی چطور رشد می‌کند و ثابت‌ها را نادیده می‌گیرد.
کلاس‌های رایج، از سریع به کند: O(1)، O(log n)، O(n)، O(n log n) و O(n²).
حلقه‌های تودرتو و پیمایش‌های پنهان (in روی لیست) مقصرهای همیشگیِ کدهای کند هستند.
set و دیکشنری جست‌وجوی O(n) را به O(1) تبدیل می‌کنند و این معمولاً ساده‌ترین بهبود بزرگ است.

دفعهٔ بعد که کدتان با بزرگ شدن داده کند شد، اول سراغ سرور سریع‌تر نروید. سراغ Big-O بروید.

Flexbox یا Grid در CSS: کدام را کِی استفاده کنیم

Wed, 30 Sep 2026 09:00:00 +0000

Flexbox و CSS Grid دو سیستم چیدمانِ مدرن در CSS هستند و مبتدی‌ها اغلب می‌پرسند کدام «بهتر» است. جواب صادقانه این است: هیچ‌کدام. آن‌ها مسئله‌های متفاوتی را حل می‌کنند و چیدمان‌های حرفه‌ای از هر دو استفاده می‌کنند، اغلب در یک صفحه.

قانونی که باید به خاطر بسپارید

Flexbox چیزها را در یک بُعد می‌چیند: یک سطر یا یک ستون.

Grid چیزها را در دو بُعد می‌چیند: سطرها و ستون‌ها، هم‌زمان.

به بیان دیگر: Flexbox محتوامحور است؛ آیتم‌ها تعیین می‌کنند چقدر فضا لازم دارند و کانتینر فضای باقی‌مانده را تقسیم می‌کند. Grid چیدمان‌محور است؛ شما ستون‌ها و سطرها را تعریف می‌کنید و بعد آیتم‌ها را در آن‌ها قرار می‌دهید.

Flexbox آیتم‌ها را در امتداد یک محور توزیع می‌کند؛ Grid آن‌ها را هم‌زمان در سطرها و ستون‌ها تراز می‌کند

مبانی Flexbox

هر عنصری را با display: flex به یک کانتینرِ فلکس تبدیل کنید. فرزندان مستقیمش به آیتم‌های فلکس تبدیل می‌شوند و در یک سطر کنار هم قرار می‌گیرند:

.toolbar {
  display: flex;
  align-items: center;            /* alignment on the cross axis */
  justify-content: space-between; /* distribution on the main axis */
  gap: 12px;
}

ویژگی‌هایی که ۹۰ درصد مواقع به کار می‌برید:

ویژگی	کاری که انجام می‌دهد
`flex-direction`	`row` (پیش‌فرض) یا `column`
`justify-content`	فضا را در امتداد محور اصلی تقسیم می‌کند
`align-items`	آیتم‌ها را روی محور عرضی تراز می‌کند
`gap`	بین آیتم‌ها فاصله می‌گذارد
`flex-wrap`	اجازه می‌دهد آیتم‌ها به خط بعد بروند
`flex: 1` (روی یک آیتم)	آیتم بزرگ می‌شود تا فضای موجود را پر کند

مثال: نوار ناوبری

<nav class="navbar">
  <a class="logo" href="/">Brand</a>
  <ul class="links">
    <li><a href="/docs">Docs</a></li>
    <li><a href="/blog">Blog</a></li>
  </ul>
  <a class="button" href="/signup">Sign up</a>
</nav>

.navbar {
  display: flex;
  align-items: center;
  gap: 24px;
}

.links {
  display: flex;
  gap: 16px;
  margin: 0 auto 0 0;   /* the auto right margin pushes the button to the far right */
  padding: 0;
  list-style: none;
}

ترفند margin خودکار

در یک کانتینر فلکس، margin-left: auto یا margin-right: auto روی یک آیتم، تمام فضای خالیِ آن سمت را جذب می‌کند. این تمیزترین راه برای دور کردن یک آیتم از بقیه است.

مثال: وسط‌چین کردن کامل

سؤال معروفِ «چطور یک div را وسط‌چین کنم؟» با Flexbox جواب کوتاهی دارد:

.center {
  display: flex;
  justify-content: center;
  align-items: center;
}

با Grid هم display: grid; place-items: center; همین کار را می‌کند.

مبانی Grid

Grid وقتی می‌درخشد که بخواهید آیتم‌ها در هر دو جهت تراز شوند. ستون‌ها (و در صورت نیاز سطرها) را روی کانتینر تعریف کنید:

.gallery {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 20px;
}

واحد fr یعنی «یک سهم از فضای آزاد»، پس repeat(3, 1fr) سه ستونِ هم‌اندازه می‌سازد.

مثال: گریدِ کارتِ واکنش‌گرا بدون media query

این یک خط ارزش حفظ کردن دارد:

.cards {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
  gap: 24px;
}

معنایش این است: «هر تعداد ستونی که جا می‌شود بساز، هر کدام حداقل ۲۵۰ پیکسل، و آن‌ها را بکش تا سطر پر شود.» روی موبایل یک ستون می‌گیرید و روی یک مانیتور عریض شاید چهار ستون؛ بدون حتی یک media query.

مثال: چیدمان کامل صفحه

grid-template-areas در Grid به شما اجازه می‌دهد چیدمانتان را به شکل متن بکشید:

.page {
  display: grid;
  grid-template-columns: 240px 1fr;
  grid-template-rows: auto 1fr auto;
  grid-template-areas:
    "header  header"
    "sidebar main"
    "footer  footer";
  min-height: 100vh;
}

.page > header { grid-area: header; }
.page > aside  { grid-area: sidebar; }
.page > main   { grid-area: main; }
.page > footer { grid-area: footer; }

@media (max-width: 700px) {
  .page {
    grid-template-columns: 1fr;
    grid-template-rows: auto 1fr auto auto;
    grid-template-areas:
      "header"
      "main"
      "sidebar"
      "footer";
  }
}

دقت کنید که نسخهٔ موبایل فقط ناحیه‌ها را جابه‌جا می‌کند. HTML اصلاً تغییری نمی‌کند.

مقایسهٔ کنار هم

	Flexbox	Grid
ابعاد	یک (سطر یا ستون)	دو (سطرها و ستون‌ها)
رویکرد	محتوامحور	چیدمان‌محور
بهترین کاربرد	نوار ناوبری، نوار ابزار، گروه دکمه‌ها، وسط‌چینی	چیدمان صفحه، گالری، داشبورد، فرم
اندازه‌دهی	آیتم‌ها اندازهٔ خودشان را تعیین می‌کنند و بعد منعطف می‌شوند	ستون‌ها و سطرها اندازه را تعیین می‌کنند و آیتم‌ها آن را پر می‌کنند
آیتم‌های هم‌پوشان	دشوار	آسان: آیتم‌ها را در یک خانه قرار دهید

استفادهٔ هم‌زمان از هر دو

رابط‌های کاربری واقعی این دو را تودرتو به کار می‌برند. یک الگوی رایج: Grid برای ساختار کلی، Flexbox داخل هر کامپوننت:

/* Grid arranges the cards */
.cards {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
  gap: 24px;
}

/* Flexbox arranges the content inside each card */
.card {
  display: flex;
  flex-direction: column;
}

.card .footer {
  margin-top: auto;   /* pins the footer to the bottom of every card */
}

Grid همهٔ کارت‌های یک سطر را هم‌قد می‌کند و ترفند margin-top: auto فوتر کارت‌ها را تراز نگه می‌دارد، حتی وقتی مقدار متن کارت‌ها متفاوت است. جزئیاتی کوچک که طراحی را حرفه‌ای نشان می‌دهد.

راهنمای سریع تصمیم‌گیری

از خودتان بپرسید:

آیتم‌ها را در یک خط می‌چینم؟ از Flexbox استفاده کنید.
لازم است آیتم‌ها در سطرها و ستون‌ها تراز شوند؟ از Grid استفاده کنید.
محتوا باید اندازه را تعیین کند؟ از Flexbox استفاده کنید.
چیدمان باید اندازه را تعیین کند؟ از Grid استفاده کنید.

اگر مطمئن نیستید، برای کامپوننت‌های کوچک با Flexbox و برای هر چیزی که شبیه جدول، گالری یا اسکلت صفحه است با Grid شروع کنید.

جمع‌بندی

Flexbox یک‌بعدی و محتوامحور است و برای کامپوننت‌ها عالی است.
Grid دوبعدی و چیدمان‌محور است و برای ساختار صفحه و گالری‌ها عالی است.
repeat(auto-fill, minmax(…, 1fr)) بدون media query گریدِ واکنش‌گرا به شما می‌دهد.
آن‌ها را ترکیب کنید: Grid برای ساختار، Flexbox داخل اجزا.

ابزار DevTools مرورگرتان را روی هر وب‌سایت مدرنی باز کنید و چیدمان را بررسی کنید. همه‌جا این دو سیستم را در کنار هم پیدا می‌کنید.

JOINها در SQL با مثال‌های ساده

Wed, 23 Sep 2026 09:00:00 +0000

پایگاه‌های دادهٔ رابطه‌ای برای جلوگیری از تکرار، داده‌ها را در جدول‌های جداگانه نگه می‌دارند: مشتریان در یک جدول و سفارش‌ها در جدولی دیگر. JOIN راهی است برای کنار هم گذاشتن دوبارهٔ این داده‌ها هنگام کوئری گرفتن.

بهترین راه برای فهمیدن JOINها این است که کارشان را روی ردیف‌های واقعی ببینید. در تمام این راهنما از دو جدول کوچک استفاده می‌کنیم.

جدول‌های نمونه

customers (مشتریان)

id	name
1	Ada
2	Grace
3	Linus

orders (سفارش‌ها)

id	customer_id	total
101	1	49.00
102	1	15.50
103	2	99.99
104	4	25.00

به دو نکته دقت کنید: Linus هیچ سفارشی ندارد و سفارش ۱۰۴ متعلق به مشتری ۴ است که وجود ندارد (شاید حسابش حذف شده). دقیقاً در همین موارد مرزی است که JOINهای مختلف رفتار متفاوتی دارند.

می‌خواهید همراه ما امتحان کنید؟ این SQLِ آماده‌سازی است که در SQLite، PostgreSQL و MySQL کار می‌کند:

CREATE TABLE customers (id INTEGER PRIMARY KEY, name TEXT);
CREATE TABLE orders (id INTEGER PRIMARY KEY, customer_id INTEGER, total DECIMAL(10, 2));

INSERT INTO customers VALUES (1, 'Ada'), (2, 'Grace'), (3, 'Linus');
INSERT INTO orders VALUES (101, 1, 49.00), (102, 1, 15.50), (103, 2, 99.99), (104, 4, 25.00);

پایگاه داده بدون ORDER BY ترتیب ردیف‌ها را تضمین نمی‌کند، پس نتایج زیر برای خوانایی مرتب شده‌اند.

INNER JOIN: فقط ردیف‌های منطبق

INNER JOIN ردیف‌هایی را برمی‌گرداند که شرطِ JOIN در هر دو جدول برقرار باشد:

SELECT c.name, o.id AS order_id, o.total
FROM customers AS c
INNER JOIN orders AS o ON o.customer_id = c.id;

name	order_id	total
Ada	101	49.00
Ada	102	15.50
Grace	103	99.99

Linus حذف می‌شود چون سفارشی ندارد و سفارش ۱۰۴ هم حذف می‌شود چون مشتری ندارد. نوشتن JOIN به‌تنهایی یعنی INNER JOIN.

LEFT JOIN: همهٔ ردیف‌های جدول چپ

LEFT JOIN همهٔ ردیف‌های جدول چپ (جدولِ بعد از FROM) را نگه می‌دارد و هر جا در سمت راست تطابقی نباشد، NULL می‌گذارد:

SELECT c.name, o.id AS order_id, o.total
FROM customers AS c
LEFT JOIN orders AS o ON o.customer_id = c.id;

name	order_id	total
Ada	101	49.00
Ada	102	15.50
Grace	103	99.99
Linus	NULL	NULL

Linus برگشته و ستون‌های سفارشش NULL است. بعد از INNER JOIN، این پرکاربردترین JOIN است.

پیدا کردن ردیف‌های بی‌تطابق

یک ترفند کلاسیک: ترکیب LEFT JOIN با WHERE ... IS NULL برای پیدا کردن «یتیم‌ها». این‌جا مشتریانی را پیدا می‌کنیم که هرگز سفارش نداده‌اند:

SELECT c.name
FROM customers AS c
LEFT JOIN orders AS o ON o.customer_id = c.id
WHERE o.id IS NULL;

نتیجه: Linus.

RIGHT JOIN: همهٔ ردیف‌های جدول راست

RIGHT JOIN قرینهٔ آن است: همهٔ ردیف‌های جدول راست را نگه می‌دارد.

SELECT c.name, o.id AS order_id, o.total
FROM customers AS c
RIGHT JOIN orders AS o ON o.customer_id = c.id;

name	order_id	total
Ada	101	49.00
Ada	102	15.50
Grace	103	99.99
NULL	104	25.00

حالا سفارشِ یتیمِ ۱۰۴ بدون نام مشتری ظاهر می‌شود. در عمل، بیشتر برنامه‌نویسان RIGHT JOIN را با جابه‌جا کردن ترتیب جدول‌ها به LEFT JOIN تبدیل می‌کنند. کوئری وقتی خواناتر است که جدولِ «همه را نگه دار» همیشه اول بیاید.

FULL OUTER JOIN: همه‌چیز از هر دو

FULL OUTER JOIN همهٔ ردیف‌های هر دو جدول را نگه می‌دارد و هر جا بتواند آن‌ها را تطبیق می‌دهد:

SELECT c.name, o.id AS order_id, o.total
FROM customers AS c
FULL OUTER JOIN orders AS o ON o.customer_id = c.id;

name	order_id	total
Ada	101	49.00
Ada	102	15.50
Grace	103	99.99
Linus	NULL	NULL
NULL	104	25.00

برای تطبیق داده‌ها کاربردی است: مقایسهٔ دو فهرست و پیدا کردن چیزهایی که در هر طرف کم است.

پشتیبانی پایگاه‌های داده

MySQL از FULL OUTER JOIN پشتیبانی نمی‌کند؛ می‌توانید آن را با ترکیب یک LEFT JOIN و یک RIGHT JOIN به کمک UNION شبیه‌سازی کنید. SQLite از نسخهٔ ۳.۳۹.۰ به بعد از RIGHT و FULL پشتیبانی می‌کند.

جدول خلاصه

هر JOIN کدام ردیف‌ها را نگه می‌دارد، به شکل نمودار ون

JOIN	ردیف‌های بی‌تطابق را از کجا نگه می‌دارد	کاربرد معمول
`INNER JOIN`	هیچ‌کدام	داده‌ای که باید در هر دو طرف وجود داشته باشد
`LEFT JOIN`	جدول چپ	«همهٔ مشتریان، به‌علاوهٔ سفارش‌هایشان در صورت وجود»
`RIGHT JOIN`	جدول راست	به‌ندرت؛ معمولاً به LEFT JOIN تبدیل می‌شود
`FULL OUTER JOIN`	هر دو جدول	تطبیق دو مجموعه داده

تجمیع بعد از JOIN

JOINها همراه با GROUP BY واقعاً قدرتمند می‌شوند. این‌جا تعداد سفارش و مجموع خرید هر مشتری را می‌بینیم، از جمله مشتریانی که هیچ سفارشی ندارند:

SELECT
  c.name,
  COUNT(o.id)               AS order_count,
  COALESCE(SUM(o.total), 0) AS total_spent
FROM customers AS c
LEFT JOIN orders AS o ON o.customer_id = c.id
GROUP BY c.id, c.name
ORDER BY total_spent DESC;

name	order_count	total_spent
Grace	1	99.99
Ada	2	64.50
Linus	0	0.00

تفاوت COUNT(column) و COUNT(*)

COUNT(o.id) فقط مقدارهای غیر NULL را می‌شمارد، پس Linus به‌درستی 0 می‌گیرد. COUNT(*) ردیف‌ها را می‌شمارد و برای Linus عدد 1 را می‌داد، چون LEFT JOIN همچنان یک ردیف برای او تولید می‌کند.

اشتباه‌های رایج

فیلتر کردن جدول راست در WHERE بعد از LEFT JOIN. شرطی مثل WHERE o.total > 20 بی‌سروصدا ردیف‌های NULL را حذف می‌کند و LEFT JOIN شما را به INNER JOIN تبدیل می‌کند. شرط را به بخش ON منتقل کنید: LEFT JOIN orders AS o ON o.customer_id = c.id AND o.total > 20.
استفاده از شرط JOIN اشتباه. JOIN روی ستون‌های اشتباه یا بدون شرط واقعی می‌تواند یک ضرب دکارتی بسازد: هر ردیف با تک‌تک ردیف‌های دیگر جفت می‌شود.
JOIN روی ستون‌هایی با نوع دادهٔ متفاوت. این کار می‌تواند مانع استفادهٔ پایگاه داده از ایندکس‌ها شود و کوئری را کند کند.

جمع‌بندی

INNER JOIN فقط ردیف‌هایی را برمی‌گرداند که در هر دو طرف منطبق باشند.
LEFT JOIN همهٔ ردیف‌های جدول چپ را برمی‌گرداند و هر جا تطابقی نباشد NULL می‌گذارد.
RIGHT JOIN قرینهٔ LEFT است و معمولاً به LEFT JOIN بازنویسی می‌شود.
FULL OUTER JOIN همه‌چیز را از هر دو جدول برمی‌گرداند.
LEFT JOIN ... WHERE right.id IS NULL ردیف‌های بی‌تطابق را پیدا می‌کند.

دو جدول بالا را در SQLite (sqlite3 shop.db) بسازید و هر کوئری را خودتان اجرا کنید. پنج دقیقه آزمایش از یک ساعت خواندن بهتر است.

دستورهای ضروری لینوکس که هر برنامه‌نویسی باید بداند

Wed, 16 Sep 2026 09:00:00 +0000

چه روی یک سرور ابری دیپلوی کنید، چه داخل Docker کار کنید و چه فقط از ترمینالِ مک‌تان استفاده کنید، دیر یا زود دستورهای لینوکس را تایپ خواهید کرد. خبر خوب این است که چند ده دستور بیشترِ کارهای روزانه را پوشش می‌دهند.

هر بخش در ادامه دستورها، گزینه‌هایی که واقعاً به کار می‌برید و مثال‌هایی از دنیای واقعی را نشان می‌دهد.

جابه‌جایی در سیستم فایل

pwd                 # where am I?
ls -lah             # list everything: long format, hidden files, human-readable sizes
cd /var/log         # go to an absolute path
cd ..               # up one level
cd -                # jump back to the previous directory
cd                  # go home (same as cd ~)

تکمیل خودکار با Tab ساعت‌ها صرفه‌جویی می‌کند

چند حرف اول نام یک فایل یا پوشه را تایپ کنید و Tab را بزنید. شل آن را برایتان کامل می‌کند یا اگر بیش از یک گزینه وجود داشته باشد، گزینه‌ها را نشان می‌دهد.

ساختن، کپی، جابه‌جایی و حذف

mkdir -p projects/blog/src     # create nested directories in one go
touch notes.txt                # create an empty file (or update its timestamp)
cp config.yml config.yml.bak   # copy a file
cp -r src/ backup/             # copy a directory recursively
mv draft.md posts/final.md     # move and/or rename
rm old.log                     # delete a file
rm -r build/                   # delete a directory and everything in it

سطل بازیافتی در کار نیست

rm فوراً و برای همیشه حذف می‌کند. پیش از اجرای rm -r مسیرها را دوباره بررسی کنید، مخصوصاً با wildcardها یا sudo. افزودن -i باعث می‌شود rm پیش از هر حذف از شما بپرسد.

خواندن فایل‌ها

cat package.json        # print a whole (short) file
less /var/log/syslog    # scroll through a long file (q to quit, / to search)
head -n 20 app.log      # first 20 lines
tail -n 50 app.log      # last 50 lines
tail -f app.log         # follow new lines as they're written, great for live logs

جست‌وجو داخل فایل‌ها با grep

grep خط‌هایی را پیدا می‌کند که با یک الگو مطابقت دارند. یکی از مفیدترین ابزارهایی است که یاد خواهید گرفت:

grep "ERROR" app.log            # lines containing ERROR
grep -i "timeout" app.log       # case-insensitive
grep -rn "TODO" src/            # search recursively, show line numbers
grep -v "DEBUG" app.log         # lines that do NOT match
grep -c "404" access.log        # count matching lines

پیدا کردن فایل‌ها با find

find . -name "*.py"                       # all Python files below the current directory
find /var/log -name "*.log" -mtime -1     # .log files modified in the last 24 hours
find . -type f -size +100M                # files bigger than 100 MB
find . -type d -name node_modules         # directories named node_modules

پایپ و تغییر مسیر: ترکیب دستورها

قدرت واقعی خط فرمان از زنجیر کردن ابزارهای کوچک به هم می‌آید. پایپ | خروجیِ یک دستور را به ورودیِ دستور بعدی می‌فرستد:

# Top 5 IP addresses hitting your web server
cut -d' ' -f1 access.log | sort | uniq -c | sort -rn | head -5

آن را از چپ به راست بخوانید: فیلد اول (آدرس IP) هر خط را بردار، آدرس‌ها را مرتب کن، تکراری‌ها را بشمار، بر اساس تعداد از بیشترین مرتب کن و پنج مورد اول را نشان بده.

هر دستور داده را تغییر می‌دهد و از طریق پایپ به دستور بعدی می‌فرستد

تغییر مسیر (redirection) خروجی را به فایل‌ها می‌فرستد:

ls -la > files.txt          # write output to a file (overwrites it)
echo "done" >> build.log    # append to a file
npm test > test.log 2>&1    # capture both normal output and errors
wc -l < data.csv            # use a file as input: counts its lines

مجوزها با chmod و chown

ls -l را اجرا کنید تا خط‌هایی شبیه این ببینید:

-rwxr-xr-- 1 deploy www-data 2048 Oct 12 09:30 deploy.sh

رشتهٔ مجوزها به سه گروه سه‌تایی تقسیم می‌شود: مالک (rwx)، گروه (r-x) و بقیه (r--). این‌جا r یعنی خواندن، w یعنی نوشتن و x یعنی اجرا.

chmod +x deploy.sh                              # make a script executable
chmod 644 index.html                            # owner: read/write, everyone else: read-only
chmod 755 scripts/                              # owner: full access, everyone else: read and enter
sudo chown -R www-data:www-data /var/www/site   # change owner and group recursively

حالت‌های عددی با هم جمع می‌شوند: خواندن = ۴، نوشتن = ۲ و اجرا = ۱. پس 7 یعنی ۴+۲+۱ (rwx)، 5 یعنی ۴+۱ (r-x) و 4 یعنی فقط خواندن.

فرایندها: چه چیزی در حال اجراست؟

ps aux | grep node          # find running node processes
top                         # live view of CPU and memory use (q to quit)
kill 12345                  # politely ask process 12345 to stop
kill -9 12345               # force it to stop (last resort)

بسیاری از سیستم‌ها htop را هم دارند؛ جایگزینی خوش‌دست‌تر و رنگی برای top.

دیسک و حافظه

df -h               # free disk space per filesystem
du -sh *            # size of each item in the current directory
du -sh * | sort -h  # ...sorted from smallest to largest
free -h             # memory usage

مبانی شبکه

curl https://example.com          # fetch a page
curl -I https://example.com       # headers only: check status codes and caching
curl -X POST -H "Content-Type: application/json" \
     -d '{"name": "Ada"}' https://httpbin.org/post
sudo ss -tlnp                     # which programs are listening on which ports
ping -c 4 example.com             # is the host reachable?

کار روی سرورهای راه دور

ssh user@203.0.113.10                                 # log in to a server
scp report.pdf user@203.0.113.10:~/                   # copy a file to it
rsync -avz ./site/ user@203.0.113.10:/var/www/site/   # sync a whole directory efficiently

گرفتن راهنما

لازم نیست همهٔ گزینه‌ها را حفظ کنید، چون سیستم خودش را مستند کرده است:

man grep                 # the full manual (q to quit)
grep --help              # a quick summary of options
history | grep docker    # find that command you ran last week

و بهترین میان‌بُر: Ctrl+R را بزنید و شروع به تایپ کنید تا تاریخچهٔ دستورهایتان را به‌صورت تعاملی جست‌وجو کنید.

جمع‌بندی

کار	دستورها
جابه‌جایی	`pwd`، `ls`، `cd`
مدیریت فایل	`mkdir`، `touch`، `cp`، `mv`، `rm`
خواندن فایل	`cat`، `less`، `head`، `tail -f`
جست‌وجو	`grep`، `find`
ترکیب	پایپ، `>`، `>>`، `2>&1`
مجوزها	`chmod`، `chown`
سیستم	`ps`، `top`، `kill`، `df`، `du`، `free`
شبکه	`curl`، `ss`، `ssh`، `rsync`

یک ترمینال باز کنید و همان‌طور که می‌خوانید هر دستور را امتحان کنید. هدف اصلی، حافظهٔ عضلانی است و ظرف یک هفته تعجب خواهید کرد که چطور قبلاً بدون این دستورها کار می‌کردید.

دکوریتورها در پایتون، قدم‌به‌قدم

Wed, 09 Sep 2026 09:00:00 +0000

احتمالاً کدی شبیه این را در Flask، FastAPI یا Django دیده‌اید:

@app.route("/")
def home():
    return "Hello!"

آن خطی که با @ شروع می‌شود یک دکوریتور (decorator) است. دکوریتورها به شما اجازه می‌دهند بدون تغییر کدِ یک تابع، رفتاری به آن اضافه کنید؛ مثل لاگ گرفتن، زمان‌سنجی، کش کردن یا کنترل دسترسی. شاید جادویی به نظر برسند، اما از سه ایدهٔ ساده ساخته شده‌اند. بیایید یکی‌یکی سراغشان برویم.

ایدهٔ ۱: توابع شیء هستند

در پایتون، توابع هم مثل هر مقدار دیگری هستند. می‌توانید آن‌ها را به متغیرها نسبت دهید و به توابع دیگر بفرستید:

def greet(name):
    return f"Hello, {name}!"

say_hello = greet          # no parentheses: we're not calling it
print(say_hello("Ada"))    # Hello, Ada!

ایدهٔ ۲: می‌توان تابع را داخل تابع تعریف کرد

def outer():
    def inner():
        return "I'm inside!"
    return inner           # return the function itself

fn = outer()
print(fn())                # I'm inside!

ایدهٔ ۳: توابع داخلی محیط اطرافشان را به خاطر می‌سپارند

یک تابع داخلی می‌تواند از متغیرهای تابعی که آن را ساخته استفاده کند، حتی بعد از اینکه آن تابع بیرونی تمام شده باشد. به این کلوژر (closure) می‌گویند:

def make_multiplier(factor):
    def multiply(x):
        return x * factor  # "remembers" factor
    return multiply

double = make_multiplier(2)
triple = make_multiplier(3)
print(double(5), triple(5))  # 10 15

کنار هم گذاشتن: اولین دکوریتور شما

دکوریتور تابعی است که یک تابع می‌گیرد و یک تابع جدید برمی‌گرداند؛ معمولاً تابعی که تابع اصلی را با رفتاری اضافه می‌پوشاند:

def shout(func):
    def wrapper(*args, **kwargs):
        result = func(*args, **kwargs)
        return result.upper()
    return wrapper

def greet(name):
    return f"Hello, {name}!"

greet = shout(greet)       # wrap it manually
print(greet("Ada"))        # HELLO, ADA!

سینتکس @ فقط میان‌بُری برای همان خطِ greet = shout(greet) است:

@shout
def greet(name):
    return f"Hello, {name}!"

print(greet("Ada"))        # HELLO, ADA!

خط @ واقعاً چه می‌کند: دکوریتور تابع شما را می‌گیرد و جایگزینی برایش برمی‌گرداند

*args و **kwargs به wrapper اجازه می‌دهند هر آرگومانی را بپذیرد و مستقیم پاس بدهد، پس دکوریتور روی توابعی با هر امضایی کار می‌کند.

functools.wraps را فراموش نکنید

دکوریتور ما یک مشکل ظریف دارد: تابعِ پوشانده‌شده هویتش را از دست داده است.

print(greet.__name__)      # wrapper

این مشکل دیباگ کردن، ابزارهای مستندسازی و بعضی فریم‌ورک‌ها را خراب می‌کند. با functools.wraps درستش کنید؛ این تابع نام، docstring و دیگر اطلاعات تابع اصلی را روی wrapper کپی می‌کند:

from functools import wraps

def shout(func):
    @wraps(func)
    def wrapper(*args, **kwargs):
        return func(*args, **kwargs).upper()
    return wrapper

عادتش کنید

@wraps(func) را به هر دکوریتوری که می‌نویسید اضافه کنید. فقط یک خط هزینه دارد و جلوی باگ‌های گیج‌کننده را در آینده می‌گیرد.

یک دکوریتور کاربردی: زمان‌سنجی

بیایید چیزی مفید بسازیم: دکوریتوری که گزارش می‌دهد یک تابع چقدر طول می‌کشد.

import time
from functools import wraps

def timed(func):
    @wraps(func)
    def wrapper(*args, **kwargs):
        start = time.perf_counter()
        try:
            return func(*args, **kwargs)
        finally:
            elapsed = time.perf_counter() - start
            print(f"{func.__name__} took {elapsed:.3f}s")
    return wrapper

@timed
def build_report(rows):
    return sum(i * i for i in range(rows))

build_report(5_000_000)    # build_report took 0.312s

try/finally مطمئن می‌شود که زمان حتی اگر تابع خطا بدهد چاپ شود.

دکوریتورهایی که آرگومان می‌گیرند

اگر بخواهید @retry(times=3) بنویسید چه؟ آن‌وقت به یک لایهٔ دیگر نیاز دارید: تابعی که آرگومان‌ها را می‌گیرد و یک دکوریتور برمی‌گرداند.

import time
from functools import wraps

def retry(times=3, delay=1.0, exceptions=(Exception,)):
    def decorator(func):
        @wraps(func)
        def wrapper(*args, **kwargs):
            for attempt in range(1, times + 1):
                try:
                    return func(*args, **kwargs)
                except exceptions as error:
                    if attempt == times:
                        raise
                    print(f"Attempt {attempt} failed: {error}. Retrying in {delay}s…")
                    time.sleep(delay)
        return wrapper
    return decorator

@retry(times=5, delay=0.5, exceptions=(ConnectionError,))
def fetch_prices():
    ...

@retry(times=5) اول retry(...) را صدا می‌زند که decorator را برمی‌گرداند و بعد آن روی fetch_prices اعمال می‌شود. سه لایه پیچیده به نظر می‌رسد، اما هر کدام فقط یک وظیفه دارد:

لایه	دریافت می‌کند	برمی‌گرداند
`retry`	تنظیمات (`times`، `delay`…)	`decorator`
`decorator`	تابعی که باید پوشانده شود	`wrapper`
`wrapper`	آرگومان‌های هر فراخوانی	نتیجهٔ تابع

دکوریتورهای داخلی که باید بشناسید

پایتون چند دکوریتور عالیِ آماده دارد. مثلاً لازم نیست کش را خودتان بنویسید، چون functools.cache (پایتون ۳.۹ به بعد) این کار را برایتان انجام می‌دهد:

from functools import cache

@cache
def fibonacci(n):
    if n < 2:
        return n
    return fibonacci(n - 1) + fibonacci(n - 2)

print(fibonacci(100))   # 354224848179261915075, instantly

بدون @cache، این بازگشتِ ساده بیش از ۱۰ به توان ۲۰ فراخوانی تابع انجام می‌داد. با آن، هر مقدار دقیقاً یک بار محاسبه می‌شود. اگر لازم است مصرف حافظه را محدود کنید، از functools.lru_cache(maxsize=…) استفاده کنید.

دکوریتورهای داخلیِ دیگری که ارزش شناختن دارند:

@property یک متد را به شکل یک ویژگیِ فقط‌خواندنی در اختیار می‌گذارد.
@staticmethod و @classmethod متدهایی تعریف می‌کنند که به نمونه (instance) نیاز ندارند.
@dataclass متدهای __init__، __repr__ و __eq__ را برایتان می‌سازد.
@contextlib.contextmanager یک generator را به context manager برای دستور with تبدیل می‌کند.

جمع‌بندی

توابع شیء هستند: می‌توان آن‌ها را جابه‌جا کرد، برگرداند و داخل توابع دیگر تعریف کرد.
دکوریتور یک تابع می‌گیرد و نسخهٔ پوشانده‌شدهٔ آن را برمی‌گرداند؛ @deco خلاصهٔ func = deco(func) است.
برای پشتیبانی از هر امضایی از *args, **kwargs استفاده کنید و همیشه @functools.wraps را به کار ببرید.
دکوریتورهایی که آرگومان می‌گیرند یک لایهٔ اضافه لازم دارند: تابعی که دکوریتور را برمی‌گرداند.
پیش از نوشتن دکوریتور خودتان، سراغ نمونه‌های داخلی مثل @cache، @property و @dataclass بروید.

چالش: یک دکوریتور @log_calls بنویسید که هر بار تابع صدا زده می‌شود، نام و آرگومان‌هایش را چاپ کند. بعد آن را همراه با @timed روی هم بگذارید و ببینید به چه ترتیبی اجرا می‌شوند.