به عنوان کسی که اول با php کار میکردم بعد اومدم سمت Java میخوام به یک مشکل بزرگ توی استک php اشاره کنم

مشکل اینه که phpرو حالت پیشفرض برای هر درخواست کاربر همه چیو از صفر load میکنه و مموری رو بین درخواست های مختلف share نمیکنه

چیزیو توی مموری نگه نمیداره و برای هر درخواست برنامه از اول bootstrap میشه

هر درخواست =
اجرای composer autoload
ایجاد connection‌ها
انجام task
حذف کامل state

در حالی که وقتی با جاوا کار میکنی اپلیکیشن یکبار توی مموری load میشه و هر درخواست توی thread جدید همون اپلیکیشن یا process هندل میشه و مموری process بین thread ها یعنی درخواست ها share میشه

و خب بنظرم توی اپلیکیشن های امروزی که تعداد کاربران که با وبسایت کار میکنن زیاده این یک مشکل بزرگ هست

چرا؟
چون Resource های سنگین مثل Connection هارو برای هر درخواست از اول باز میکنه و امکان Connection pooling نیست

یعنی اگه مثلا کد php ما میخواد یک api توی سرویس دیگه ای رو تحت پروتکل Http صدا بزنه برای هر درخواستِ کاربر، php باید کانکشن جدید بسازه و tcp handshake هر بار تکرار میشه

یا وقتی میخواد با دیتابیس ارتباط بگیره برای هر درخواست یهConnection جدید باز میکنه که به شدت کارایی برنامه رو میاره پایین. چون کانکشن های دیتابیس علاوه بر tcp handshake ها باید به ازای هر کانکشن که ایجاد میشه احراز هویت و لاگین هم انجام بشه. یا سمت سرور دیتابیس برای هر کانکشن یک process جدید توی سیستم عامل ایجاد میشه که یه بار اضافه روی سرور دیتابیس هم میندازه

در حالی که اگه state حفظ بشه میشه این Connection ها وResource های سنگین رو باز نگه داشت و چندین بار ازشون استفاده کرد و یا اصطلاحا Pool کرد که کارایی برنامه بشدت میره بالا

مطمعنا برای ارتباط به هر سرور و ابزار خاصی این مشکل ایجاد کانکشن های جدید هست

تو فکرم اینه که اگه کد php میخواد مثلا با gRPC با یک میکروسرویس دیگه ارتباط داشته باشه کل مزیت streaming این پروتکل از دست میره و نمیتونه اون Persistent connection رو داشته باشه و همه تعاملات رو با اون انجام بده در واقع Multiplexing از بین میره. و برای هر درخواست gRPC یک کانکشن جدید ساخته میشه!!!!!

البته وقتی از php-fpm برای serve اپلیکیشن استفاده می‌کنید. php-fpm میتونه به ازای هر woker process کانکشن هارو توی مموری نگه داره (پیشفرض اینکارو نمیکنه)

اما خب این کانکشن به ازای هرworker process هست و باز بین درخواست ها share نمیشه. صرفا درخواست جدیدی که با اونworker process هندل بشه این کانکشن رو میتونه داشته باشه.

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

و تو این حالتم نمیشه از پروتکل هایی که همه تعاملات رو با یک کانکشن انجام میدن استفاده کرد. Multiplexing برای این ساخته شد که با یک کانکشن همه تعاملات انجام بشه. ولی تو این حالت به ازای هر worker processو درخواستی که هندل میکنه یک کانکشن داریم

فقط هم gRPC نیست، برای ارتباط گرفتن با کافکا هم کلاینت کافکا از یک کانکشن برای بهینه کردن و رد بدل اطلاعات با بروکر استفاده میکنه

حتی RabbitMQکه channel هارو توی یک تک کانکشنtcp هندل میکنه

ابزار های مختلفی مثل FrankenPHP/Swoole/RoadRunnner یا Laravel Octane برای حل چنین مشکلاتی ساخته شدن که phpرو تبدیل به اپلیکیشن سرور میکنن

@DevTwitter | <Hossein Soleimani/>

این ارور "declared and not used" واقعا یکی از بزرگترین مزیت‌های گولنگ نسبت به پایتون بوده تا اینجا.
داره میگه آقا، اگر متغیری رو تعریف کردی، حق نداری بلااستفاده ولش کنی! یا باید پاکش کنی، یا کامنت، و یا اینکه استفادش کنی

@DevTwitter | <Matin SenPai/>

سیستم مدیریت تایمرها در Unity
(برای LiveOps، فیچرها، Cooldownها و Eventها)

یکی از الگوهای اشتباه و رایجی که بارها در پروژه‌های Unity (کوچک و حتی بزرگ) دیدم اینه که:
- هر Feature تایمر مخصوص به خودش رو داره
- هر برنامه‌نویس منطق زمان‌بندی رو جداگانه پیاده‌سازی میکنه

این رویکرد شاید در کوتاه‌مدت جواب بده، اما در مقیاس بزرگ باعث میشه:
کد تکراری زیاد شود - Code Duplication
نگهداری پروژه سخت‌تر شود - Maintainability
خوانایی کد کم بشود - Readability
توسعه ی کد سخت بشود - Scalability
اعمال تغییرات سراسری تقریباً غیرممکن شود

از دید معماری نرم‌افزار، هر زمان منطق‌های تکراری و پایدار داریم، باید بدونیم که این منطق‌ها می‌تونن با یک سیستم مرکزی مدیریت بشن.
در بازی‌ها هم تایمرها همه‌جا هستند . مثلاً:
- فیچر Daily Reward با بازه‌ی ۲۴ ساعته
- آفرها یا بسته‌های فروشگاهی با زمان چند ساعته
- فیچر های متنوع که زمان محدودی دادن

حالا فرض کنید تصمیم بگیریم همه‌ی تایمرها از حالت Local خارج شوند و به زمان سرور (UTC) متصل شوند.
اگر هر تایمر جداگانه پیاده‌سازی شده باشد، این تغییر به یک فاجعه تبدیل می‌شود
اما با یک سیستم مرکزی، معمولاً با تغییر در یک نقطه، این قانون روی همه‌ی تایمرها اعمال میشه

به همین دلیل، من یک TimerManager عمومی طراحی کردم که از هر Feature یا Script قابل استفاده است اما مدیریت زمان‌بندی‌ها به‌صورت مرکزی انجام میشه
کار باهاش خیلی ساده هست .

ویژگی‌های TimerManager
️ مدیریت تایمرها بر اساس Key
️ استفاده از Callback برای بروزرسانی UI
️ استفاده از API برای شروع و توقف تایمر
️ نمایش زمان در فرمت های مختلف
️ ادغام ساده در هر Feature

امیدوارم این پیاده‌سازی براتون کاربردی باشه.
کد کامل در GitHub:
https://github.com/seidmoh3n/Unity-Timer-Manager

@DevTwitter | <Mohsen Mirshamsi/>

بعضی پروژه‌ها به ما یادآوری می‌کنن که وب‌سایت‌ها فقط برای انتقال اطلاعات نیستن؛می‌تونن یه «تجربه» باحال باشن و سایت Floor796 دقیقاً یکی از همون‌هاست!

اینجا با یه وب‌سایت معمولی طرف نیستید؛
با یه نقاشی متحرک روبه‌روئید که توی پیکسل‌به‌پیکسلش زندگی جریان داره.

چرا این سایت انقدر خاصه؟
چون یه دنیای پیکسلیِ بی‌نهایت پیش‌روتونه، پر از کاراکترهای نوستالژیک! وقتی زوم می‌کنی، تازه می‌فهمی چه خبره!!!

هر لایه از این ایستگاه فضایی پر از کاراکترهاییه که باهاشون خاطره داریم؛ از دنیای گیم گرفته تا انیمیشن‌های معروف، همه اینجا جمع شدن. فقط کافیه زوم کنید تا غرق جزئیات و داستان‌های ریز و درشتش بشید.
https://floor796.com/

@DevTwitter | <Soheil Ghanbary/>

هوش مصنوعی Z.ai مدل GLM-4.7 رو معرفی کرد. طبق اعلام خودشون کیفیت کد زنی تقریباً مشابه Opus 4.5 از شرکت آنتروپیک رو داره.

با تنظیماتی که تو لینک زیر هست خیلی راحت میشه داخل Cursor هم استفاده کرد.
https://docs.z.ai/devpack/tool/cursor

@DevTwitter | <Mohammad/>

#کوته_نیوز

اون قضیه 0.002 دلار به ازای هر دقیقه برای self-hosted runnerهای گیت‌هاب که قرار بود از اول مارس ۲۰۲۶ شروع بشه در پی سر و صداهای زیادش فعلاً به تعویق افتاد.

@DevTwitter | <Hamed/>

چارت جی اس(Chart.js) یه کتابخونه اوپن سورس جاوااسکریپتیه که برای ساخت نمودارهای تمیز توی وب هستش و با canvas کار می‌کنه. راه‌اندازیش ساده‌ست و برای نمایش داده‌ها به شکل خطی میله‌ای دایره‌ای و کلی مدل دیگه عالیه:
https://chartjs.org
لینک گیتهاب:
https://github.com/chartjs/Chart.js

@DevTwitter | <Shayan GeeDook/>

وال پنل یه پنل ساخت و مدیریت ادمین نان سودو برای پنل های x-ui هست، اگه استفاده کردید خوشحال میشم با استار از ریپو حمایت کنید
( http://github.com/primeZdev/whale-panel )

@DevTwitter | <primeZ/>

خبر خوب برای برنامه نویس های C# که میخوان از AI استفاده کنن

استک اصلی‌ من ASP .NET Core و Blazor هست و باهاش پروژه‌های زیادی انجام داده ام. پایتون هم کار کرده‌ام، ولی بیشتر برای کارهای دم‌دستی و مرتبط با AI و Data Science.

چند سال اخیر، برای AI و کار با لایبرری‌ها مجبور شدم بیشتر سراغ پایتون برم و راستش همیشه یه گلایه تو ذهنم بود
اینکه چرا کامیونیتی مایکروسافت تو این حوزه خیلی جدی وارد نمی‌شه.

حالا چرا با پایتون ننویسیم؟ فرض کن با دات نت یه سری پروژه جدی نوشتی و حالا میخوایی برای کمک به کاربر، امکانات AI اضافه کنی: باید روی سرور پروداکشن پایتون داشته باشی و API بدی و از اپلیکیشن دات نت اون API رو صدا کنی! تازه این اول کاره! امنیت، لاگ و ... که باید با اپلیکیشن خودت integrate بشه!

یه خورده با Semantic Kernel و چند لایبرری دیگه کار کردم، ولی صادقانه بگم، خیلی Solid بنظرم نیومد و به دلم ننشستن…

تا اینکه اخیراً با Microsoft Agent Framework آشنا شدم و کمی باهاش کار کردم. رویکردش واقعاً جالب بود

هم برای Python هست، هم برای C# — و همین موضوع جذابیتش رو چند برابر می‌کنه.

چند تا نکته‌ی جذابش که من دوست داشتم:

می‌تونی ازش برای ساخت چت‌بات‌های ساده تا سیستم‌های پیچیده چند‌عامل‌ (multi-agent) استفاده کنی — همه با پترن‌های قابل فهم و توسعه‌پذیر

و Graph-based Workflows داره که می‌تونی چند Agent رو به هم وصل کنی و یک جریان کاری هوشمند بسازی GitHub

پشتیبانی کامل از امکاناتی مثل Functions/Tool و Agent Memory , MCP Servers و Thread و Agent History/Storage و ...

همینظور Observability / Telemetry داخلی هم داره — یعنی می‌تونی رفتار Agent ها رو دنبال و دیباگ کنی (برای پروژه‌های پروداکشن خیلی مهمه!)

ابزار DevUI هم داره که بهت Interactive UI می‌ده برای دیدن گام‌به‌گام عملکرد Agent ها و workflow ها

و بهترین بخشش اینه که APIهاش در Python و C# خیلی شبیه هم هستن — پس می‌تونی راحت بین دو زبان کار کنی بدون اینکه حس کنی زندانی یه اکوسیستم شدی

به نظرم این یکی از بهترین قدم‌های مایکروسافت برای AI Agents هست — هم برای تجربه‌های سریع و هم برای ساختن سیستم‌های جدی در پروژه های دات نت

https://github.com/microsoft/agent-framework

@DevTwitter | <Amir Pournasserian/>

اگر دوست دارید از youtube-dl یا yt-dlp استفاده کنید ولی با ترمینال راحت نیستید، این برنامه کارتون رو راحت‌تر می‌کنه
https://github.com/database64128/youtube-dl-wpf/

راحت‌ از یوتیوب دانلود کنید
با این برنامه می‌توانید فرمت‌ها و کیفیت‌های مختلف را انتخاب کنید، زیرنویس اضافه کنید، پلی‌لیست دانلود کنید و تنظیمات پیشرفته مثل مسیر ذخیره، پروکسی و غیره رو راحت میشه توش ست کرد

@DevTwitter | <POURYA/>

ریپوزیتوری Awesome-PHP-Security | مرجع جامع امنیت در توسعه PHP

ریپوزیتوری Awesome-PHP-Security یک ریپوزیتوری منتخب و حرفه‌ای از منابع امنیت PHP است که ابزارهای تخصصی، تحلیل کد ایستا، راهنماهای امن‌سازی و آموزش‌های کاربردی را یکجا ارائه می‌دهد تا توسعه‌دهندگان بتوانند امنیت نرم‌افزارهای PHP خود را به‌صورت استاندارد و قابل‌اعتماد ارتقا دهند.

ویژگی‌های کلیدی

- مجموعه‌ای curated از ابزارهای امنیت نرم‌افزار
- پوشش تحلیل کد ایستا (SAST) و بررسی آسیب‌پذیری‌ها
- دسترسی به مشاوره‌ها و Best Practiceهای امنیتی PHP
- منابع آموزشی معتبر برای Secure Coding
- مناسب برای توسعه‌دهندگان، تیم‌های DevSecOps و معماران نرم‌افزار

موارد استفاده

- افزایش امنیت اپلیکیشن‌های PHP در محیط‌های Production
- شناسایی و کاهش آسیب‌پذیری‌های رایج نرم‌افزاری
- بهبود کیفیت کد با رویکرد Secure Development
- پشتیبانی از فرآیندهای DevSecOps و CI/CD
- مرجع سریع برای تصمیم‌گیری‌های امنیتی در پروژه‌های PHP

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


ریپو در GitHub:
https://github.com/guardrailsio/awesome-php-security

@DevTwitter | <Pardis CO./>

توی نسخه‌های جدید Go یک قابلیت تازه و البته آزمایشی اضافه شده که حسابی سروصدا کرده: Green Tea.

قبل از اینکه بریم سراغش، بد نیست یادآوری کنیم مدل قدیمی GC چه مشکلی داشت.

در نسخه‌های قبلی، GC هیچ اطلاعاتی نداشت که بین دو Cycle دقیقا کجای حافظه تغییر کرده. برای همین مجبور بود هر بار کل هیپ رو اسکن کنه؛ حتی اگر فقط چند درصدش دست خورده بود. نتیجه؟ مصرف بالای CPU، کمک‌گیری سنگین از mutator assist و یه‌سری وقفه های ریز که روی تجربه‌ی اجرا تاثیر میذاشت.

تو رویکرد جدید،گو میاد heap رو به segmentهای کوچیک تقسیم میکنه و هر موقع allocation یا pointer write اتفاق میافته، فقط همون segment به‌عنوان dirty علامت می‌خوره. وقتی GC شروع میشه، دیگه خبری از اسکن کل heap نیست؛ فقط بخش‌هایی بررسی می‌شن که واقعا تغییر کردن در طول یک چرخه

خروجی این تغییر هم کاملا ملموسه: کاهش مصرف CPU (تا حدود ۳۵٪ طبق گزارش‌ها)و وقفه های GC کوتاه‌تر و کم‌مزاحم‌تر.

@DevTwitter | <Go Talk/>

اینو همه می‌دونن
که هوش مصنوعی، پادشاه مهارت‌های آینده‌است 👑

پس چرا تو مسیری نباشی که آینده‌اش تضمینه؟

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

❄️ دی‌ماه امسال، قدم در راه موفقیت بذار:
🔗https://dnkr.ir/yA7Bz

سیستم کند است؟ این ۴ عدد دروغ نمی‌گویند

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

در این پُست به چهار متریک بنیادی می‌پردازیم که شناخت آن‌ها برای هر مهندس نرم‌افزار ضروری است.

1- معیار Queries Per Second (QPS)
این معیار نشان می‌دهد سیستم شما در هر ثانیه چند درخواست ورودی دریافت می‌کند.
برای مثال، اگر سرور در یک ثانیه ۱۰۰۰ درخواست دریافت کند، مقدار QPS برابر با ۱۰۰۰ خواهد بود.
در نگاه اول، QPS متریکی ساده به نظر می‌رسد، اما چالش اصلی در پایداری آن نهفته است. بسیاری از سیستم‌ها قادر به حفظ QPS بالا در بازه‌های زمانی طولانی نیستند و در شرایط فشار، به‌تدریج دچار افت عملکرد می‌شوند.

2- معیار Transactions Per Second (TPS)
این معیار تعداد تراکنش‌های کاملاً انجام‌شده در هر ثانیه را نشان می‌دهد.
یک تراکنش شامل کل مسیر پردازش درخواست است؛ از دریافت درخواست تا تعامل با دیتابیس و بازگشت پاسخ نهایی.
برخلاف QPS که صرفاً تعداد درخواست‌های ورودی را نشان می‌دهد، TPS بیانگر میزان کار واقعی انجام‌شده است و معمولاً مهم‌ترین متریک از دیدگاه کسب‌وکار محسوب می‌شود.

3- معیار Concurrency (همزمانی)
این معیار تعداد درخواست‌های فعالی است که سیستم در یک لحظه در حال پردازش آن‌هاست.
برای مثال، ممکن است سیستم ۱۰۰ درخواست در ثانیه دریافت کند، اما اگر پردازش هر درخواست ۵ ثانیه طول بکشد، در عمل با ۵۰۰ درخواست همزمان مواجه خواهیم بود.
همزمانی بالا به معنای نیاز به مدیریت بهینه‌تر منابع، connection pool مناسب و کنترل دقیق‌تر threadها است.

4- معیار Response Time
این معیار مدت زمانی است که از آغاز یک درخواست تا دریافت پاسخ نهایی سپری می‌شود.
این متریک هم در سطح کلاینت و هم در سطح سرور اندازه‌گیری می‌شود و نقش کلیدی در تجربه کاربری و توان پردازشی سیستم دارد.

رابطه بین متریک‌ها:
این چهار متریک به‌طور مستقل عمل نمی‌کنند و رابطه‌ی مشخصی میان آن‌ها وجود دارد:
QPS = Concurrency ÷ Average Response Time
بر اساس این رابطه، افزایش همزمانی یا کاهش میانگین زمان پاسخ، منجر به افزایش توان پردازشی (Throughput) سیستم می‌شود.

تحلیل صحیح عملکرد سیستم بدون درک دقیق این متریک‌ها ممکن نیست.

@DevTwitter | <Amir Rahimi Nejad/>

میدونستید چرا Nginx همه‌جا هست؟

سال‌ها Apache بازیگر بی‌رقیبِ دنیای وب‌سرورها بود.
تقریباً ۲۰ سال تمام.
تا اینکه Nginx اومد و بدون سر و صدا، بازی رو عوض کرد.

امروز Nginx پشت صحنه‌ی خیلی از غول‌های اینترنت نشسته:
Netflix، Airbnb، Dropbox
نه به‌خاطر اینکه جدیدتر یا مد روزه،
بلکه چون مشکلاتی رو حل کرد که توی ترافیک بالا، Apache به‌سختی از پسشون برمی‌اومد.

اما چرا Nginx اینقدر محبوب شد؟
- همزمان هزاران کانکشن رو راحت هندل می‌کنه
- به‌عنوان Reverse Proxy فوق‌العاده عمل می‌کنه
- به‌عنوان Load Balancing ساده و قدرتمند
- دارای Cache داخلی برای سرعت بیشتر
ب-ه عهده گرفتن SSL Termination و سبک‌تر کردن اپلیکیشن‌ها

توی خیلی از معماری‌های مدرن، Nginx دیگه فقط «وب‌سرور» نیست؛
عملاً مغز هدایت ترافیک و خط اول امنیت سیستم حساب می‌شه.

@DevTwitter | <Amir Rahimi Nejad/>

پلتفرم codewars فقط حل مسئله نیست، یاد گرفتن طرز فکره. Codewars یه پلتفرمه برای تمرین برنامه‌نویسی و حل مسئله با زبان‌های مختلف؛
جایی که می‌تونی چالش‌های کوچیک الگوریتمی حل کنی و مهارتت رو کم‌کم تقویت کنی.
چیزی که برای من Codewars رو واقعاً ارزشمند کرده، فقط حل کردن کاتاها نیست؛
بعد از حل مسئله، دیدن راه‌حل بقیه‌ست.
مثلاً امروز روی یه چالش کار می‌کردم که در ظاهر ساده بود،
ولی تا زمانی که الگوی مسئله رو درست نفهمیدم، پیاده‌سازیش گیج‌کننده می‌شد.
بعد از اینکه خودم حلش کردم و رفتم سراغ solutions:
دیدم بعضی‌ها همون مسئله رو با چند خط ساده‌تر حل کرده بودن
بعضی‌ها از نگاه کاملاً متفاوتی استفاده کرده بودن
و بعضی راه‌حل‌ها واقعاً طرز فکرم رو نسبت به مسئله عوض کرد
برای من این بخش دقیقاً مثل یه code review واقعی و رایگان عمل می‌کنه.
یه پیشنهاد ساده:
فرقی نمی‌کنه برنامه‌نویس باشی یا تو هر زمینه‌ی دیگه‌ای کار کنی—
اگر روزی فقط یک چالش کوچیک حل کنی:
توی یک ماه -> حدود ۳۰ تمرین
توی یک سال -> بیشتر از ۳۶۰ بار فکر کردن، تحلیل کردن و حل مسئله
این حجم تمرین، بدون اغراق:
طرز فکرت رو قوی‌تر می‌کنه
حل مسئله‌ت رو بهتر می‌کنه
و تأثیرش رو مستقیم توی کارت می‌بینی
برای من Codewars فقط تمرین برنامه‌نویسی نیست؛
یه عادت خوبه برای رشد مداوم.

@DevTwitter | <Ahmad Aghazade/>

بعضی وقتا گلوگاه performance دیتابیس از query یا infra نیست، از primary key میاد.

اUUID چون randomه، هر insert رو می‌فرسته یه جای متفاوت از B-treeی که برای ایندکس ها ساخته شده و ممکنه باعث شه درخت دوباره ساخت بشه؛ نتیجه‌اش cache miss، page split و write cost بالاتره. زیر بار دیتابیس زود به سقف CPU می‌رسه.

در مقابل، bigint auto-increment همیشه آخر index می‌نویسه و رفتار دیتابیس قابل پیش‌بینی میشه. تو تست‌های واقعی، فقط با عوض کردن UUID به bigserial، throughput چند برابر بهتر شده بدون اینکه data model یا business logic تغییر کنه.
اprimary key تصادفی یعنی مالیات دائمی روی هر write

راه بهتر اینه که primary key داخلی bigint باشه و یه public UUID برای بیرون سیستم داشته باشی. اگه client-generated id لازم داری، می‌تونی از time-orderd مثله Snowflake استفاده کنی تا keyها تقریبا ترتیبی باشن و توی سیستم های توزیع شده هم یکتا باشن و هم index اذیت نشه.


@DevTwitter | <Go Talk | گو تاک/>

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

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

این کتابخونه از aiohttp، httpx و requests هم سریع‌تره و سینتکس مشابه‌ای به هر سه داره و به راحتی میشه ازش استفاده کرد. کدنویسی sync و async رو همزمان پشتیبانی می‌کنه.

میتونید با دستور زیر کتابخونه رو نصب کنید:

pip3 install -U pyfasthttp

یه مثال از کتابخونه:

from fasthttp import Client

with Client() as client:
    resp = client.get("https://httpbin.org/get")
    print(resp.status_code)
    print(resp.json())

گیت هاب پروژه:
https://github.com/shayanheidari01/fasthttp


@DevTwitter | <ShythonX/>

حضور zod-ir در داکیومنت رسمی Zod + انتشار نسخه v1.5.4

از زمان انتشار نسخه 1.2 که فقط روی "ولیدیشن" تمرکز داشتم و در پست قبلی معرفی کردم، هدفم حل چالش‌های دیتای ایرانی در Zod بود. اما در مسیر توسعه، نیاز به چیزی فراتر از true/false حس می‌شد. امروز نسخه v1.5.4 با رویکرد جدید Data Extraction (استخراج دیتا) منتشر شد.

خبر ویژه: پول‌ریکوست پروژه در ریپوی اصلی Zod مرج شد و اکنون zod-ir رسماً به عنوان ابزار استاندارد ولیدیشن ایرانی در بخش Ecosystem داکیومنت Zod معرفی شده است و می‌تونید با خیال راحت توی پروژه‌های بزرگ ازش استفاده کنید.

تغییرات کلیدی نسبت به نسخه‌های قبل: در این نسخه، پکیج علاوه بر بررسی صحت داده، متادیتای کاربردی را برای UI استخراج می‌کند:
۱. خدمات شهری و خودرو (Vehicle & Bills):
- پلاک: استخراج استان و شهر محل پلاک خودرو.
- قبض: استخراج مبلغ، نوع قبض (آب، برق،...) و شناسه پرداخت از روی شناسه قبض (محاسبه خودکار).

۲. امور مالی (Financial):
- ورودی مالی ترکیبی (zFinancial): دیگه فرقی نمی‌کنه کاربر کارت بزنه یا شبا. سیستم خودش تشخیص می‌ده و آبجکت کامل (شامل لوگو، رنگ و نام بانک) رو برمی‌گردونه.
- بانکی: تشخیص نام بانک، رنگ سازمانی و لوگو (SVG) از روی شماره کارت یا شبا.
- کریپتو: ولیدیشن Native آدرس‌های TRC20 ،BTC و ETH (بدون وابستگی سنگین).

۳. تماس و مکان (Contact & Location):
- تلفن ثابت (جدید): استخراج نام استان و شهر (فارسی/EN) از روی پیش‌شماره.
- کد پستی (بهبود یافته): بازنویسی الگوریتم تشخیص شهر با متد Best Match (رفع تداخل رنج‌های پستی).
- موبایل: تشخیص اپراتور (همراه اول، ایرانسل و...) و ارائه لوگوی اپراتور.

تشکر از شایان زمانی عزیز (Shayan Zamani) بابت مشارکت در مدرن‌سازی زیرساخت و بیلد سیستم این نسخه.

الان zod-ir یک ابزار کامل برای تیم‌های فرانت‌اند است که هم دیتای ورودی را چک می‌کند و هم دیتای خروجی را فرمت‌شده تحویل می‌دهد.

نصب: npm i zod-ir

https://www.npmjs.com/package/zod-ir

https://github.com/Reza-kh80/zod-ir

@DevTwitter | <Reza Kheradmandi/>