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

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

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

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

@codehalics | کدهالیک

مدل GPT-6 Luna کاملاً رایگان و نامحدود شد

سرویس DuckDuckGo از طریق DuckAi این مدل رو بدون نیاز به ثبت‌نام و کارت بانکی باز کرده.

قابلیت هایی که بهت میده :
• چت با Luna
• تولید تصویر
• مکالمه صوتی کامل (روی موبایل هم خوب کار می‌کنه)

https://duck.ai


@codehalics | کدهالیک

بک‌اند دولوپر یا مهندس بک‌اند؟

هر دوشون کد می‌زنن، API می‌نویسن و با دیتابیس کار می‌کنن. پس فرقشون کجاست؟جوابش توی همین ویدیوئه

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

🎓 جزئیات دوره و قسمت‌های رایگان:
https://codehalic.ir/courses/backend-engineering-bootcamp

@codehalic | کدهالیک

چین یه OCR اوپن سورس منتشر کرده که می‌تونه ده‌ها صفحه PDF رو یک‌جا بخونه!

اسمش Unlimited-OCR و توسط Baidu توسعه داده شده.

تا الان خیلی از ابزارهای OCR برای خوندن یه PDF طولانی، صفحات رو جداجدا پردازش می‌کردن. اما Unlimited-OCR اومده این محدودیت رو تا حد زیادی برطرف کنه.

https://github.com/baidu/Unlimited-OCR

@codehalics | کدهالیک

با یه روز تأخیر، روز جهانی دختر رو به دخترای برنامه‌نویس تبریک می‌گم؛ همون اقلیت کمیابی که وسط این همه دولوپر پسر هنوز دارن با باگ‌ها می‌جنگن
ویدیوش بامزه بود واقعا :))))))

@codehalics | کدهالیک

25 دلار کردیت GLM 5.3 flash و DeepSeek v4.1 flash رو هم این پلتفرم بهتون میده :

https://console.river.ai

@codehalics | کدهالیک

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

وقتی از فونت سفارشی استفاده می‌کنیم، بهتره به‌جای فایل‌های TTF یا OTF از فرمت WOFF2 استفاده کنیم، چون برای وب ساخته شده و معمولاً حجم خیلی کمتری داره.

ولی فقط تبدیل فونت به WOFF2 کافی نیست.

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

یکی دیگه از کارهای مهم، Subset کردنه؛ یعنی فقط کاراکترهایی رو داخل فایل فونت نگه داریم که واقعاً توی پروژه بهشون نیاز داریم.

برای سایت‌های فارسی این بخش خیلی مهمه، چون اگه Subset اشتباه انجام بشه ممکنه بعضی حروف فارسی، اعداد یا علائم از فونت حذف بشن.

استفاده از font-display هم کمک می‌کنه متن منتظر لود شدن فونت نمونه و کاربر محتوا رو سریع‌تر ببینه مثلا اگر روی swap بزاری تا زمانی که فونتت لود شه یه فونت دیفالت نشون میده بعد وقتی لود شد تازه با فونت تو نشون میده متن صفحه رو !

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

استفاده از Variable Font هم توی بعضی پروژه‌ها انتخاب خوبیه، چون چند وزن مختلف رو داخل یک فایل می‌ده و تعداد فایل‌هایی که باید دانلود بشن کمتر می‌شه.

در نهایت بهینه‌سازی فونت ترکیب WOFF2، وزن‌های کمتر، Subset درست، font-display مناسب و Preload حساب‌شده‌ست که واقعاً تفاوت ایجاد می‌کنه.

@codehalics | کدهالیک

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

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

متأسفانه صابر راستی‌کردار در سال ۱۴۰۲ و در ۳۶ سالگی درگذشت. بخش مهمی از تجربه‌ی بهتر ما از متن فارسی روی وب، مدیون کارهایی مثل همین فونت‌ها و ابزارهاییه که رایگان و متن‌باز در اختیار همه گذاشت.

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

یاد صابر راستی‌کردار و اثری که برای وب فارسی به جا گذاشت، گرامی.

https://github.com/rastikerdar/vazirmatn

@codehalics | کدهالیک

جمنای ۴ بالاخره معرفی شد !
بالاخره گوگل به خودش اومد و این مدل بسیار خفن با اسم آرگون از امروز روی حساب های پرو و پلاس در دسترسند !

@codehalics | کدهالیک

یکمی اگر تئوری موسیقی بلد باشین و گام‌های موسیقی رو بشناسین با گام Lydian آشناییت دارید! اما اگر هم اصلاً سراغ موسیقی نرفتید، «گام» یا Scale رو مثل پالت رنگی یک نقاش در نظر بگیرید؛ مجموعه‌ای از چند نت که وقتی کنار هم چیده میشن، حال و هوای آهنگ رو مشخص می‌کنن که مثلاً شاد باشه، غمگین باشه یا رازآلود. حالا گام Lydian یک پالت جادوییه که توش فقط با یک تغییر کوچیک روی نت چهارم، موسیقی یهو از زمین کنده میشه و حس معلق بودن، شگفتی، مدرنیته و طلوع یک عصر جدید رو به آدم میده. جالبه بدونید توی موزیک ویدیوهای معرفی هوش مصنوعی مثل Gemini، GPT و Claude هم دقیقاً از همین تئوری و تکنیک روان‌شناختی Warm Futurism استفاده می‌کنن. غول‌های تکنولوژی برای اینکه نشون بدن یک هوش فوق‌بشری ساختن اما قرار نیست مثل فیلم‌های علمی‌تخیلی ازش بترسیم، به جای صداهای سرد و رباتیک، این گام فضایی Lydian رو روی گام‌های گرم مثل Bb و F می‌برن و با سازهای بادی مثل Trombone، French Horn و Saxophone اجراش می‌کنن؛ چون این سازها فقط با «نفس انسان» جون می‌گیرن و صدای جریان هوا توی ساز، ناخودآگاه به ما حس زندگی، امنیت و هم‌نفسی میده. در واقع با ترکیب نفس گرم انسان توی سازهای بادی و این گام روشن و آینده‌نگر، خیلی هنرمندانه به مغز ما میگن که از این قدرت فرابشری نترس، چون این آینده‌ی هیجان‌انگیز، رفیق و همراه توئه.

@codehalics | کدهالیک

مثلا موسیقی معروف فیلم Interstellar از هانس زیمر رو یادتونه؟ با اینکه کل فیلم یه غم و دلتنگی عمیق داره، ولی زیمر چرخه اصلی آهنگ رو از روی نت فا شروع می‌کنه و طوری نت‌ها رو می‌چینه که مغز ما همون کشش جادویی گام F Lydian رو همراه با صدای غول‌پیکرترین ساز بادی دنیا یعنی ارگ کلیسا می‌شنوه؛ و دقیقا به خاطر همینه که به محض شنیدنش، حس می‌کنیم از زمین کنده شدیم و وسط کهکشان و زمان معلقیم!

@codehalics | کدهالیک

تا حالا شده توی پروداکشن ببینید سرویس‌هاتون Timeout میدن و ریکوئست‌ها توی صف می‌مونن، در حالی که مصرف CPU زیر ۱۰ درصده و رم کاملاً آزاده؟ اینجا دقیقاً جاییه که با ThreadPool Starvation روبرو شدید. توی C# و .NET این فاجعه معمولاً به خاطر Sync-over-Async رخ میده؛ یعنی وقتی کدهای Async رو با .Result یا .Wait() بلاک می‌کنید. در این حالت تردهای موجود قفل میشن و چون اون تسک‌ها برای اجرای Continuation خودشون باز هم به ترد آزاد نیاز دارن و الگوریتم Hill Climbing دات‌نت هم خیلی کند ترد جدید تزریق می‌کنه، سرور عملاً فریز میشه. راه حلش هم توی دات‌نت فقط رعایت کردن قانون Async All The Way و استفاده نکردن از کدهای Blocking روی تردهای ThreadPool هست.

@codehalics | کدهالیک

از اون طرف توی Node.js که خیلی‌ها فکر می‌کنن کلاً Single-Thread هست، کتابخونه زیربنایی libuv یک ThreadPool داره که دیفالت فقط ۴ تا ترد برای کارهای سنگین و Blocking مثل File System، عملیات Crypto (مثل bcrypt)، پکیج zlib و dns.lookup در نظر گرفته. حالا اگر ۴ تا ریکوئست همزمان بیان و با کاری مثل هش کردن پسورد هر ۴ تا ترد رو درگیر کنن، ریکوئست پنجم که فقط میخواد یک فایل ساده بخونه یا DNS رو لوکاپ کنه پشت این صف قفل میشه؛ یعنی Event Loop کاملاً بیکاره ولی کل I/O های وابسته به ThreadPool فلج شدن. برای جلوگیری از این گلوگاه توی نود، باید توی پروداکشن سایز UV_THREADPOOL_SIZE رو بیشتر کنید، به جای dns.lookup سراغ dns.resolve برید و پردازش‌های سنگین CPU-bound رو به Worker Threads منتقل کنید.

@codehalics | کدهالیک

یه سوال جذابی که همیشه توی مصاحبه‌ها می‌پرسن اینه که وقتی یه برنامه Node.js رو ران می‌کنیم، واقعاً چند تا ترد توی سیستم‌عامل ساخته میشه؟ خیلی‌ها میگن ۱ دونه، یا اگر حرفه‌ای‌تر باشن میگن با ۴ تای libuv میشه ۵ تا! اما اگر یه اسکریپت ساده نود رو ران کنید و توی لینوکس تردهای اون Process رو بشمارید، می‌بینید که بین ۷ تا ۱۱ ترد بالا میاد. واقعیت اینه که فقط Event Loop و اجرای کد جاوااسکریپت شما روی ۱ ترد (Main Thread) انجام میشه؛ در کنارش موتور V8 معمولاً ۴ تا ترد بک‌گراند برای کارهای Garbage Collection و JIT Compilation (بهینه‌سازی کدها) می‌سازه، ۱ ترد برای هندل کردن سیگنال‌ها و Inspector بالا میاد، و به محض اینکه اولین عملیات File System یا Crypto رو انجام بدید، ۴ تردِ پیش‌فرضِ libuv هم بهشون اضافه میشن و جمعاً ۱۱ تا ترد رو تشکیل میدن.

اینو همیشه یادتون باشه که جواب درست اینه که حدود 11 تا ترد nodejs میسازه ! خیلی دیدم توی مصاحبه ها میپرسن و آدما میگن نمیدونیم و برای پوزیشن های سنیور نود جی اس شاید سوال مسخره ای بنظر بیاد ولی خب توی ذهنتون داشته باشین که 11 تردش چ شکلی ساخته میشه قطعا مشخص میکنه که شما از اینترنال nodejs هم کمی باخبرید !

@codehalics | کدهالیک

اینم حیفم میاد راجبش صحبت نکنم چون ایده بسیار بسیار جذابی داره
ایده الگوریتم Hill Climbing دقیقاً مثل اینه که توی یه کوهستان کاملاً مه‌آلود بخواید با چشم بسته به نوک قله برسید؛ تنها راهش اینه که یه قدم آزمایشی بردارید، اگر دیدید رفتید بالاتر، به همون مسیر ادامه بدید و اگر دیدید رفتید پایین‌تر، برگردید عقب. توی دات‌نت هم Runtime از قبل نمی‌دونه دقیقاً چند تا ترد برای سرور شما بهینه است (چون تردِ کم باعث صف کشیدن ریکوئست‌ها میشه و تردِ زیاد هم با Context Switching شدید، CPU رو خفه می‌کنه). برای همین الگوریتم Hill Climbing میاد به صورت آزمایشی ترد اضافه می‌کنه و خروجی سیستم (Throughput) رو می‌سنجه؛ اگر دید با اضافه کردن ترد، تسک‌های بیشتری در ثانیه انجام میشن، به ساختن ترد ادامه میده، اما به محض اینکه ببینه اضافه کردن ترد جدید باعث افت پرفورمنس شده، می‌فهمه به قله رسیده و جلوی ساخت تردهای بیشتر رو می‌گیره.

یه الگوریتم دیگ هم شبیه به این داریم بهش میگن Control Loop که کوبرنتیز توی Autoscaling داره ازش استفاده میکنه منتهی به هیچ وجه به فراغ بالی Hill Climbing نیست چون اضافه کردن بی ملاحظه پاد روی یه سرور میتونه خیلی سریع اونو نابود کنه و شبکمون رو بفنا بده راجبش حتما یه تحقیقی کنید !

@codehalics | کدهالیک

حالا باگ کجاست؟ خیلی ساده است ممکنه گول بخورن !
فرض کنید دقیقاً همون لحظه‌ای که الگوریتم به صورت تصادفی ۲ تا ترد اضافه می‌کنه، GC هم شروع به کار می‌کنه و Throughput سیستم به شدت می‌ریزه پایین! الگوریتم بیچاره گول می‌خوره و فکر می‌کنه اضافه کردن اون ۲ تا ترد باعث افت پرفورمنس شده، پس سریع تردها رو می‌کُشه! یا برعکس، یه لحظه ترافیک سبک میشه و الگوریتم فکر می‌کنه اضافه کردن ترد باعث معجزه شده و بی‌خود ترد می‌سازه. نتیجه این میشه که سیستم دچار Thrashing (نوسان شدید) میشه و مدام در حال ساختن و کشتن تردهاست!
یه اتفاق بامزه دیگم میوفته بالاتر گفتم که ترد ها بلاک میشن کسی دیگ نمیتونه ترد بسازه خب توی اونم throughput ما صفر میشه بعد بازم این الگوریتم که طراحی کردیم میشکنه چون فکر میکنه سیستم باری روش نیست پس دیگ ترد نمیسازه و ما تا ابد توی دور باطل میمونیم تو یه حالت برزخی طور چون تردی ساخته نمیشه تردامونم بلاکن سیستم نمیدونه چیکار کنه همه چی بظاهر درسته ولی بلاک شدن !

ایده های طراحی الگوریتم و سیستم دیزاین این موضوع رو امشب باهم بررسی میکنیم که چطوری تیم دات نت تونستن جلوی این موضوع رو بگیرن تا به این موضوع برسیم خوشحال میشم راجبش فکر کنین بنظرم فکر کردن به این مسائل مهندسی خیلی خیلی ذهن مارو برای حل مسائل پیش رومون باز میکنه

@codehalics | کدهالیک