📚 آشنایی با کتابخانه‌ی datetime در پایتون ⏰
اگر با زمان و تاریخ سروکار داری (مثل ثبت لاگ‌ها، زمان‌بندی کارها یا ساخت تایمرها)، کتابخانه‌ی قدرتمند و داخلی datetime یکی از دوست‌داشتنی‌ترین ابزارهای پایتونه!

بیاید چند تا مثال ساده ولی مفید ببینیم 👇

🕒 به‌دست آوردن زمان و تاریخ فعلی:

from datetime import datetime

now = datetime.now()
print(now)
# خروجی مثل: 2025-11-11 14:35:22.456789

📆 فقط تاریخ یا فقط ساعت:

print(now.date())  # خروجی: 2025-11-11
print(now.time())  # خروجی: 14:35:22.456789

⏳ ساخت زمان دلخواه:

birthday = datetime(1998, 7, 21, 9, 30)
print(birthday)
# 1998-07-21 09:30:00

🧮 محاسبه فاصله بین دو تاریخ:

from datetime import date

start = date(2025, 1, 1)
end = date(2025, 11, 11)
delta = end - start
print(delta.days)  # خروجی: 314

🧠 نکته کاربردی:
برای تبدیل زمان به فرمت دلخواه از متد strftime() استفاده کن:

print(now.strftime("%d/%m/%Y %H:%M"))
# خروجی: 11/11/2025 14:35

✨ خلاصه:
کتابخانه‌ی datetime به‌صورت پیش‌فرض در پایتون نصب شده و برای هر نوع کار با زمان، تاریخ و فاصله بین آن‌ها فوق‌العاده کاربردی است.a

#پایتون #آموزش_پایتون #datetime #ترفند_کدنویسی

خیلی جالبه که به محض اینکه API سایتم رو راه اندازی کردم، چند دقیقه بعد سرویس CloudFlare از دسترس خارج شد.

شرمنده ام کلودفلر جان...

🔴 قطعی تاریخی کلودفلر – ۱۸ نوامبر ۲۰۲۵ (۲۷ آبان ۱۴۰۴)
یکی از بزرگ‌ترین قطعی‌های تاریخ اینترنت
رخ داد!

از حدود ۱۴:۵۰ به وقت ایران، میلیون‌ها سایت و سرویس معروف (از جمله X، ChatGPT، Discord، Spotify، Grindr و …) همزمان داون شدند.

مدت قطعی اصلی: بیش از ۳ ساعت
بدترین قطعی کلودفلر از سال ۲۰۱۹ تا حالا
علت واقعی (طبق گزارش رسمی کلودفلر): یک تغییر ساده در مجوزهای دسترسی دیتابیس ClickHouse → کوئری هر ۵ دقیقه یک‌بار شروع به تولید ردیف‌های تکراری کرد → فایل پیکربندی Bot Management از ۶۰ فیچر به بیش از ۵۰۰ فیچر باد کرد → فایل غول‌آسا به تمام سرورهای جهانی پخش شد → نرم‌افزار اصلی (نوشته‌شده با Rust) پنیک کرد و خطای ۵xx داد.

جالبه که اول فکر کردن حمله DDoS عظیمه، چون مشکل متناوب بود!
سرویس‌های آسیب‌دیده:
بخش CDN و امنیت اصلی
بخش های Turnstile، Workers KV
داشبورد و لاگین کاربران
همچنین Cloudflare Access و WARP
حتی صفحه وضعیت خودشون هم داون شد!

راه‌حل: برگرداندن نسخه قدیمی فایل + پچ فوری کد
کلودفلر قول داده:
اعتبارسنجی سخت‌گیرانه‌تر فایل‌های پیکربندی
محدودیت سخت روی اندازه فایل‌ها
تست‌های بهتر قبل از rollout

این قطعی نشون داد چقدر اینترنت امروز به چند شرکت معدود وابسته‌ست؛ یک باگ ساده داخلی می‌تونه نصف دنیا رو فلج کنه!

پست‌مورتِم رسمی:
https://blog.cloudflare.com/18-november-2025-outage/

#کلودفلر #قطعی_اینترنت #CloudflareOutage

🚀 راه‌اندازی API وب‌سایت AliZakaee.ir

بالاخره API رسمی وب‌سایتم رو راه‌اندازی کردم!
از این به بعد می‌تونید به‌صورت مستقیم و از طریق درخواست‌های JSON به محتوای بلاگ دسترسی داشته باشید.

🔗 آدرس اصلی API:
https://alizakaee.ir/api/

📌 لیست پست‌ها:
https://alizakaee.ir/api/posts/

این API با Django REST Framework ساخته شده و فعلاً به صورت عمومی و Read-Only در دسترسه.
هدفم اینه که توسعه‌دهنده‌ها و کسایی که می‌خوان داده‌های بلاگ رو توی اپلیکیشن‌ها یا سرویس‌های خودشون استفاده کنن، بتونن خیلی راحت بهش متصل بشن.

در پست جدید بلاگم، کامل توضیح دادم که API چطور کار می‌کنه، چه فیلدهایی برمی‌گردونه، و چطور می‌شه ازش استفاده کرد.
👇 می‌تونید از لینک زیر مطالعه کنید:

🌐 لینک پست بلاگ:

https://alizakaee.ir/blog/%D8%B1%D8%A7%D9%87%D8%A7%D9%86%D8%AF%D8%A7%D8%B2%DB%8C-api-%D9%88%D8%A8%D8%B3%D8%A7%DB%8C%D8%AA-alizakaeeir/

از شدت خستگی و بی حوصلگی برای تست نوشتن و همین‌طور برای بررسی کردن اینکه کیفیت تست نویسی Claude Sonnet 4.5 چطور هستش، ازش خواستم برام تست بنویسه با توجه به کدبیسم.

اول اینکه ٢۵٠٠ خط تست نوشت، ٢۵٠٠!
دوم اینکه به edge case هایی فکر کرد که عملاً من نمیدونستم حتی می‌تونه مشکل ایجاد کنه، خط به خط کد رو خوندم و میتونم بگم فوق‌العاده هست!

یک موردی هم که خیلی‌ شنیدم که میگن A.I. فقط تستی می‌نویسه که پس بشه، اصلاً اینطور نبود و اتفاقاً داخل ران اول، ٩تا تست فیل شد که منتهی شد به رفع مشکل کد توسط من.

خلاصه اینکه مواردی که خلاقیت دو چندان نمی‌خواد مثل تست نویسی رو بدین به A.I. چون اون هم می‌تونه خلاقیت بیشتری داشته باشه و با توجه به دایره اطلاعاتش کیس های بیشتری رو لحاظ کنه و هم اینکه در زمان شما صرفه‌جویی کنه و شما روی فیچرهای اصلی کار کنید.

و اینکه داخل پرامپتتون حتماً بیان کنید که ملاکتون صرفاً پس شدن تست ها نیست و میخواین جامع و کامل باشن و ازش بخواین کامل هم کامنت گذاری کنه.

در زمینه دیتای مورد نیاز برای آموزش شما همیشه دو دسته دیتا دارید، آموزش و تست
اما آیا این تقسیم بندی درسته؟

در مورد دیتای آموزش بحثی نیست و شما ازش برای آموزش مدل استفاده می‌کنید.

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

در واقع دیتای توسعه همون دیتاییه که شما ازش برای انتخاب مدل، تنظیم ابرپارامترها (hyperparameters)، جلوگیری از overfitting و تنظیم معماری استفاده می‌کنید. این دقیقاً چیزی هست که در ادبیات علمی به validation set شناخته میشه.

پس دیتای تست چی شد؟
تست عملاً اختیاری هستش و ضروری نیست و بررسی مدل بر حسب دیتای تست صرفاً برای این هست که شما بتونید بدون bias به عملکرد اون مدل پی ببرید اما زمانی که مدل شما انتخاب شده باشه با توجه به دیتای dev، شما الزاماً نیازی به دیتای تست ندارید.

به صورت علمی، دیتای تست فقط یک‌بار و در پایان فرآیند آموزش استفاده میشه تا عملکرد نهایی مدل بدون هیچ‌گونه bias ناشی از مشاهده قبلی دیتا اندازه‌گیری بشه
دلیل علمی این موضوع اینه که هرچقدر روی dev تست کنید و روی dev بهبود بدید، dev برای شما اطلاعات لیک می‌کنه (information leakage) و به مرور باعث overfitting نسبت به dev میشه. تست از این جهت ضروری نیست که روی روند آموزش نقشی نداره و فقط یک معیار نهایی برای گزارش عملکرده.

پس به صورت کلی، تقسیم بندی دیتا به دو دسته آموزش و تست یک اشتباه رایجه و درست این قضیه یا دیتای آموزش و توسعه هست یا آموزش و توسعه و تست.

در صورتی که بخواین بررسی کنید مدل آموزش دیده توسط شما، دچار underfitting یا overfitting شده یا نه باید واریانس و bias (که ما اینجا از جهت گیری استفاده می‌کنیم برای بیانش) رو بررسی کنید.

در بررسی داده های ما که به دو دسته آموزش و توسعه تقسیم شدند ممکنه چند حالت پیش بیاد:

١. جهت گیری بالا و واریانس کم

در این حالت مدل شما دچار underfitting شده و مثل دانش آموزی هست که خوب درس نخونده و سوالات رو نمی‌تونه جواب بده.

در این حالت برای حل این مشکل، باید اندازه شبکه عصبی، چه از لحاظ تعداد لایه و چه نورون افزایش پیدا کنه و این مورد تقریباً همیشه باعث کاهش جهت گیری میشه و کار دیگه ای که میشه انجام داد اینه که نرخ آموزش (learning rate) رو کاهش داد که باعث میشه سرعت آموزش کاهش پیدا کنه اما مشکل جهت گیری حل بشه.

٢. جهت گیری کم و واریانس بالا:

در این حالت شما دچار overfitting شدید که مثل دانش آموزی هست که عیناً سوالات رو حفظ کرده و اگر سوالات یکم تغییر کنه دیگه نمیتونه جواب بده.

برای رفع این مشکل اول اینکه یاید حجم و تعداد داده ها رو افزایش بدید ث تقریباً این مورد همیشه باعث کاهش واریانس میشه ولی مقدار کمی هم جهت گیری رو افزایش میده و کار دیگه ای هم که میشه کرد این هست که داده ها رو منظم کرد.

—

در هر دو مورد ذکر شده میتونید مدل و معماری های مختلف رو هم تست کنید تا ببینید نتیجه بهتری خواهید داشت یا خیر اما این مورد الزاماً باعث بهبود نمیشه ولی در هر حال جزء مواردی هست که باید بررسی و تست کنید.

—

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

چرا منظم سازی داده ها باعث کاهش overfitting میشه؟

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

ما در L1 و L2 دنبال این هستیم که وزن ها رو کوچکتر کنیم و میگیم هرچقدر وزن بیشتر باشه مدل بیشتر جریمه میشه.

تفاوت L1 و L2 در این هست که L1 بعضی از ویژگی ها رو عملاً صفر و حذف می‌کنه که برای انتخاب ویژگی مناسبه ولی L2 چیزی رو صفر نمیکنه بلکه نزدیک به صفر می‌کنه و برای زمانی مناسبه که ما چندین ویژگی داریم و نمیخوایم هیچکدوم حذف بشن.
این موارد هم که گفته شد در اصل از طریق وزن ها انجام میشه.
در مورد L2 که پر کاربردتره باید بگم که ما عملاً هر بار میایم و قبل از اعمال گرادیان اصلی، وزن ها رو در یک عدد کوچکتر از یک ضرب می‌کنیم که این باعث میشه هر دفعه کم بشه و به همین دلیل بهش weight decay هم میگن.

پس به صورت کلی مدل رو مجبور کنیم بیش از حد پیچیده نشه و وزن‌های خیلی بزرگ نداشته باشه.
چون وزن‌های بزرگ معمولاً نشونهٔ اینه که مدل روی نویز و جزئیات بی‌ربط داده زوم کرده.

راه اندازی سرور توسعه قابل دسترسی با Zero Trust

به عنوان یک دولوپر، شاید با این قضیه برخورد کنید که نیاز داشته باشید یکسری از اندپوینت هایی که دارید فقط قابل استفاده از طرف افراد خاصی باشه به صورت ریموت تا امنیت پروژه بالاتر بره.
برای این کار روش های مختلفی وجود داره و اینجا ما به معرفی روش Zero Trust متعلق به CloudFlare می پردازیم که نقشه کلی به این صورت هست که دولوپر مد نظر باید کلاینت WARP رو نصب کنه و وارد اکانت مربوط به خودش بشه و اگر اون اکانت تعریف شده باشه، امکان دسترسی به سرور براش فراهم میشه.

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

از منوی سمت چپ، وارد قسمت زیر بشین:
Teams & Resources > Devices > Management > Device enrollment > Device enrollment permissions > Manage
▫️در قسمت Access policies، بر روی گزینه Create new plicy کلیک کنید.
▫️در قسمت Policy name یک اسم انتخاب کنید و کمی پایین تر، در قسمت Add rules و بخش Include، شرط رو بر روی Emails قرار بدید و در کادر Value، ایمیل های مد نظر خودتون که میخواین دسترسی داشته باشن رو وارد کنید.
▫️بر روی دکمه Save کلیک کنید.
❗️داخل این قسمت میتونید از مثلاً ایمیل کلی شرکتتون استفاده کنید و تک تک ایمیل ها رو در قسمت دیگه ای وارد کنید، برای مثال:
Email ending in: @yourcomapny.com

به بخش زیر مراجعه کنید:
Teams & Resources > Devices > Device profiles > Create new profile
▫️در قسمت Name نام مورد نظر خودتون رو وارد کنید.
▫️در قسمت Build an expression، قسمت Selector رو بر روی User Email ست کنید و Operator رو هم بر روی in قرار بدید و در قسمت Value آدرس ایمیل های مجاز مد نظرتون رو وارد کنید.
▫️در قسمت Device tunnel protocol، گزینه MASQUE رو انتخاب کنید.
▫️در قسمت Service mode، گزینه Gateway with WARP رو انتخاب کنید.
▫️در قسمت Split Tunnels، گزینه Include IPs and domains رو انتخاب کنید و زمانی که ازتون خواست بهش مورد اضافه کنید، از منوی Selector گزینه IP Address رو انتخاب و قسمت Value هم آی پی سرور خودتون رو وارد کنید.
▫️بر روی گزینه Save profile کلیک کنید.

به بخش زیر مراجعه کنید:
Network > Connectors > Cloudflare Tunnels > Create a tunnel
▫️از قسمت Select your tunnel type گزینه Cloudflare رو انتخاب کنید.
▫️در قسمت Tunnel name، یک نام برای تونل خودتون انتخاب کنید.
▫️با فرض اینکه سرور شما لینوکس هستش، از قسمت Choose your environment گزینه Debian رو انتخاب کنید و بعد از اون دستوراتی که بهتون نمایش داده میشه رو بدون تغییر در کنسول سرورتون وارد کنید.
▫️در قسمت Route Traffic، بر روی گزینه CIDR کلیک و آی پی سرور خودتون رو وارد کنید.
▫️بر روی گزینه Save کلیک کنید.

به منوی زیر مراجعه کنید:
Traffic policies > Traffic settings > Proxy and inspection
▫️گزینه Allow Secure Web Gateway to proxy traffic را فعال و تیک تمامی موارد موجود در Select protocols to forward را بزنید.

به بخش زیر مراجعه کنید:
Traffic policies > Firewall policies > Network > Add a policy
▫️در قسمت Policy name، عنوان Access را وارد کنید.
▫️در قسمت Build an expression بخش Traffic بر روی گزینه Add condition کلیک کنید و Selector گزینه Destination IP را انتخاب و Operator را in قرار داده و در قسمت Value آی پی سرور خود را وارد کنید. (1)
▫️بر روی گزینه And کلیک کرده و Selector را بر روی Destination Port قرار دهید و Operator را in و در قسمت Value پورت سرور خود که معمولاً 22 است را وارد کنید. (2)
▫️در قسمت Identity بخش Selector را بر روی User Email قرار داده و Operator را بروی in تنظیم و در قسمت Value ایمیل های مد نظر خود را وارد کنید. (3)
▫️در قسمت Select an action گزینه Action را بر روی Allow قرار دهید. (4)
▫️بر روی گزینه Save policy کلیک کنید.
▫️مجدداً بر روی گزینه Add a policy کلیک کنید و نام آن را Block قرار دهید و بخش 1 و 2 را عیناً تکرار کنید و بخش 3 را انجام ندهید و در بخش 4 گزینه Block را انتخاب و ذخیره سازی رو انجام دهید.
❗️مطمئن شوید که در لیست قوانین، آیتم Access بالاتر از آیتم Block قرار دارد.

وارد سرور مجازی خود شوید و دستور زیر را وارد کنید:

nano /etc/ssh/sshd_config

▫️خطی که ListenAddress را دارد را از حالت کامنت خارج کنید و آنرا به ListenAddress 127.0.0.1 تغییر دهید و فایل را ذخیره کنید.
▫️دستور زیر را در کنسول خود وارد کنید:

sudo systemctl restart ssh
sudo ufw deny 22/tcp

تبریک!
حالا تنها کاربرانی که از طریق Zero Trust به ورک اسپیس شما وصل شوند می توانند از سرور مد نظر استفاده کنند.

نحوه نصب و استفاده از Zero Trust

▫️به این آدرس مراجعه و فایل نصبی سازگار با سیستم عامل خود را دانلود کنید.
▫️بعد از نصب و ورود، در منوی برنامه WARP بر روی گزینه Account کلیک کنید.
▫️بر روی گزینه Login to Cloudflare Zero Trust کلیک کنید و نام تیمی که در مرحله اول وارد کردید را انتخاب کنید.
▫️در صفحه باز شده آدرس ایمیل خود را وارد و کد ارسال شده به ایمیل را وارد کنید.
▫️پس از ورود به برنامه، دکمه اتصال را بزنید.

حالا می توانید به سرور توسعه خود تنها در صورت متصل بودن به Zero Trust وصل شوید.

چرا داخل دیتاست های بزرگ، باید از mini batch gradient decent استفاده کنیم؟

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

در روش mini batch، شما داده ها رو بخ بسته های کوچک تر (توان عدد ٢) تقسیم می‌کنید و برای مثال اگر یک میلیون داده داشته باشید، در هر ایپاک با فرض بچ های ١٠٢۴ عددی، تقریباً ۵٠٠٠ بار گرادیان آپدیت میشه و این یعنی سرعت بیشتر.

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

این کار باعث میشه که شما از GPU هم به نحو بهتری استفاده کنید چون صرفاً بجای محاسبه یک‌جا برای کل داده‌، میتونید چندین پروسه هم‌زمان و موازی انجام بدید چون بچ های زیادی داردید.

ضمن اینکه در روش batch شما کم‌ترین میزان نویز و دقیق‌ترین گرادیان رو دارید ولی به شدت کند هست.
در روش SGD یا Stochastic Gradient Decent هر نمونه خودش یک سری آموزشی هست که سرعت بیشتری در آپدیت وزن ها داره اما مسیر رسیدن به وزن بهینه خیلی نویز زیادی داره و نسبت به batch به سخت افزار خیلی کمتری نیاز داره.

روش Mini-batch Gradient Decent دقیقاً بین این دو قرار گرفته که هم سرعت خیلی‌ خوبی داره و هم دقت خوبی اما توجه کنید که همیشه الزاماً به مینیموم نمیرسه و گاهی اطراف اون قرار میگیره و همچنین در هر ایپاک الزاماً هزینه شما کاهش پیدا نمیکنه و عادی هست که افزایش هم داشته باشه در هر حالی که در بچ حتی اگر یک مرحله افزایش داشته باشید یعنی یک اشکال اساسی وجود داره و باید مثلاً نرخ یادگیری رو کم کنید.

برای انتخاب سایز مینی بچ هم اگر کمتر از ٢٠٠٠ دیتا دارید، از روش بچ استفاده کنید ولی اگر بیشتر هست، از توان های عدد ٢ مثل ۶۴،١٢٨.٢۵۶ و ۵١٢ استفاده کنید چون به دلیل نحوه هندل شدن حافظه کامپیوتر، می‌تونه عملکرد بهتری رو به شما بده.

کلادفلر (Cloudflare) دوباره دون شد!

سلام و درود

من دارم روی یک پروژه کار می کنم که ترکیبی از هوش مصنوعی و جنگو هست و داخل ایران این نوع پروژه اولین بار هست که داره اجرا میشه.

خود من روی بک اند و بخش ترین کردن مدل متمرکزم و میخوام یک نفر دیگه به تیم اضافه کنم که بتونه قالب های آماده بخش هایی render که based هستند رو ادیت کنه و مچ کنه با مدلاسیون در حال توسعه.
در نتیجه باید اطلاعات در مورد جنگو و فرانت اند داشته باشند ایشون.

قطعاً ایشون به عنوان همکار پروژه خواهند بود و بعد از درآمدزایی، مزایا و حقوق دریافت خواهند کرد.

در صورت تمایل به همکاری لطفاً به من پیام بدین: @ITheEqualizer

اولین حمله DDoS «آفلاین» علیه تاکسی اینترنتی گوگل!

‏حتما می‌دانید که در بعضی شهرهای آمریکا تاکسی‌های خودران رسماً شروع به کار کرده‌اند؛ با یک اپلیکیشن روی موبایل، درخواست تاکسی می‌دهید و چند دقیقه بعد یک ماشین بدون راننده (که توسط هوش مصنوعی هدایت می‌شود) جلوی پایتان می‌ایستد.

‏حالا در اتفاقی عجیب، یک جوان ۲۳ ساله با هماهنگی ۵۰ نفر دیگر، همگی وارد طولانی‌ترین خیابان بن‌بست سان‌فرانسیسکو شد‌ه‌اند و همزمان از سرویسی به نام Waymo (که متعلق به شرکت آلفابت، هولدینگ گوگل است) درخواست تاکسی کردند…

‏هدف‌شان هم صرفا ایجاد اختلال در فرایند سرویس‌دهی بوده و هیچ‌کدام سوار تاکسی‌ها نشدند!

‏نتیجه چه بود؟
‏▫️بیش از ۵۰ خودروی بدون راننده به یک خیابان بن‌بست هجوم آوردند و همگی گیر افتادند!
‏▫️هوش مصنوعی خودروها عملاً آچمز شد و پشتیبانی Waymo مجبور شد به‌طور موقت کل ناوگان آن محدوده را از مدار خارج کند.

‏به همین سادگی، یک حمله DDoS آفلاین رقم خورد؛ نه روی سرورها، بلکه وسط خیابان!