بلاخره، اولین Open Source پروژه‌ام را منتشر کردم؛ یک بات تلگرامی که با استفاده از مدل‌های زبانی پیشرفته متون را ترجمه می‌کند. این اولین گام هر چند کوچک در مسیر توسعه ابزارهای هوشمند است.

https://github.com/Ho3seinTork/Translator-Telegram-Bot-with-LLMs

@DevTwitter | <Diss Obedience/>

وقتی به ریکت 19 و هوک های جدیدش نگاه کردم، دیدم الان چنتا هوک داریم که داخلشون میشه با API ها ارتباط برقرار کرد.
و برام سوال شد که چه فرقی دارن پس؟
برای همین تصمییم گرفتم خیلی خلاصه نتیجه ی سوال خودم رو اینجا بنویسم.

1-useEffect
هدف: ارسال درخواست های API بعد از رندر کامپوننت.
کاربرد: برای انجام عملیات های async مثل ارسال درخواست های GET به API در سمت کلاینت.

2-use
هدف: ارسال درخواست های API پیش از رندر در Server Components.
کاربرد: برای دریافت داده ها از API در سرور پیش از رندر کردن کامپوننت ها.(این ویژگی مخصوص Server-Side Rendering است.)

3- useActionState
هدف: مدیریت وضعیت های مختلف یک عملیات async مانند لودینگ، موفقیت، و خطا.
کاربرد: برای مدیریت عملیات هایی که داده ها را تغییر می دهند (مثل ارسال *فرم* ها یا تغییر اطلاعات در سرور).

4- useTransition
هدف: انجام درخواست های async طولانی بدون مسدود کردن UI.
کاربرد: زمانی که می خواهید درخواست های زمان بر (مانند API هایی که داده های زیادی برمی گردانند) را به صورت غیر مسدودکننده ارسال کنید تا UI همچنان پاسخگو باقی بماند.

@DevTwitter | <Hossein Mohammadzadeh/>

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

https://github.com/MJavadSF/getFileType

@DevTwitter | <آقا محمد جواد آقا/>

دیدم اکانت Codecrafters با ماهی ۳۰ دلار برای ما ایرانیا به‌صرفه نیست، دست‌به‌کار شدم و Build Your Own X رو ساختم! حالا می‌تونی کامپایلر، دیتابیس، ردیس و کلی چیز دیگه رو خودت از صفر بسازی و یاد بگیری چطور کار می‌کنن!بیاید یه سر بزنید، نظرتون برام مهمه!
https://github.com/abolfazl-moeini/build-your-own-x

@DevTwitter | <Abolfazl Moeini/>

گولنگ شی‌گرا هست یا نه؟
تو یه سری آگهی‌های شغلی دیدم که جزو نیازمندی‌ها، پیاده‌سازی OOP در گولنگ ذکر شده. یه سری جاها هم نوشتن پیاده‌سازی مفاهیم OOP در گولنگ که خب منطقی‌تر به نظر می‌رسه.

برای جواب دادن به این سوال، اول ببینیم اصلاً OOP چیه؟

برنامه‌نویسی شی‌گرا یه پارادایم برنامه‌نویسیه که بر اساس یه مفهوم به اسم شی (Object) کار می‌کنه. هر شی یه سری دیتا داره و رفتارش رو هم درون خودش کپسوله می‌کنه.

چهار اصل مهم OOP هم ایناست:

- Encapsulation
- Abstraction
- Inheritance
- Polymorphism

حالا این اصول از کجا اومدن؟
آیا فقط مخصوص OOP هستن؟

نه، اینا جز اصول پایه‌ای طراحی نرم‌افزارن و توی بقیه پارادایم‌ها مثل Functional Programming هم وجود دارن. OOP اومده این اصول رو به سبک خودش پیاده‌سازی کرده.

حالا بریم سراغ گولنگ...

گولنگ بعضی از این مفاهیم رو با سبک و روش خودش پیاده‌سازی کرده، مثلاً Encapsulation رو از طریق Package-level Visibility داره، یا Polymorphism رو با Interfaceها پیاده‌سازی کرده. اما بعضی چیزا رو هم عمداً حذف کرده، مثل Class-based Inheritance، چون فلسفه Go بیشتر روی سادگی و ترکیب‌پذیری (Composition) تمرکز داره.

مشکل کجاست؟

خیلی جاها میان گولنگ رو مثل یه زبان OOP استفاده می‌کنن که بعضی وقتا تبدیل به Anti-pattern میشه. مثلاً پیاده‌سازی Factory Pattern به روش کلاسیک OOP یا Singleton به سبک جاوا و سی‌شارپ توی Go باعث پیچیدگی اضافی میشه. اینجور کدها معمولاً کار می‌کنن، ولی خوانایی و سادگی Go رو از بین می‌برن.

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

@DevTwitter | <Ali Farhadnia/>

وقتی Cache بیشتر از این که کمک کنه، دردسر می سازه!

چند وقت پیش روی یه پروژه بزرگ کار می کردم که توش Redis برای کشینگ استفاده می کردیم. همه چیز خوب پیش می رفت تا اینکه یه روز، یه تغییر ظاهرا بی ضرر تو کد باعث شد کش درست Invalid نشه. نتیجه چی شد؟ کاربرا داده های قدیمی رو می دیدن، بعضیا نمی تونستن اطلاعاتشون رو آپدیت کنن، و پشتیبانی حسابی شلوغ شد!

کش توزیع شده یه شمشیر دولبه ست!
از یه طرف، می تونه فشار روی دیتابیس رو کم کنه و سرعت پاسخ گویی رو بالا ببره، ولی از طرف دیگه، اگه درست مدیریت نشه، مشکلاتی مثل:

مشکل Cache Inconsistency – وقتی دیتا تو کش و دیتابیس ناهماهنگ می شه و بعضی کاربرا داده های قدیمی می بینن.

مشکل Cache Stampede – همه درخواست ها همزمان به کش می رسن و فشار زیادی ایجاد می کنن.

مشکل TTL Misconfiguration – تنظیم اشتباه زمان اعتبار کش که باعث می شه یا دیتا زودتر از حد لازم حذف بشه یا تا مدت زیادی به روز نشه.


اون تجربه یه درس مهم بهم داد: کش چیزی نیست که فقط یه بار تنظیمش کنیم و فراموشش کنیم. باید یه استراتژی کش هوشمند داشته باشیم که همیشه بهینه بمونه.

@DevTwitter | <Hamed Farzanefar/>

تو تلگرام برای گرفتن api_id و api_hash مشکل داریم و فقط پیام ERROR رو نشون میده

اگر کسی میدونه مسئله کجاست پیام بده لطفا

ویرایش:
راه حل‌های زیادی ارائه شد و اکثرشون رو تست کردم و جواب نگرفتم، اما یکی از دوستان گفتن با warp امتحان کن مشکلت حل میشه.
و همین مشکلم رو حل کرد.

(توضیح فنی هم این بود که شماره با آی پی یکی نباشه ارور میده)

گفتم شاید شما هم بخواید استفاده کنید.

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

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

پشتیبانی از چندین دیتابیس – در این نسخه، ساختار مدل بازطراحی شده تا امکان پشتیبانی از چندین دیتابیس فراهم شود. در حال حاضر از PostgreSQL پشتیبانی می‌کند و نسخه‌ای برای MySQL و MariaDB نیز به زودی منتشر خواهد شد.

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

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

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

نسخه جدید در گیت‌هاب منتشر شده است و نسخه‌ای که از MySQL و MariaDB پشتیبانی کند، به زودی در دسترس خواهد بود.

لینک پروژه:
https://github.com/navidb/metabase-persian-calendar

https://github.com/navidb/metabase-persian-calendar/blob/main/CHANGELOG.md

@DevTwitter | <Navid Behrangi/>

اگه دنبال یه نمونه عملی و کاربردی برای یادگیری Vue 3، Tailwind 4 و کار با API هستی، این پروژه می‌تونه برات مفید باشه.

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

توی این پروژه از چی استفاده کردم؟

- Vue 3 & Composition API برای ساختار بهتر و قابل نگهداری
- Tailwind 4 برای طراحی سبک، مدرن و سریع
- اتصال به Unsplash API برای دریافت تصاویر
- Pinia برای مدیریت تاریخچه جستجو
- اسکرول بی‌نهایت برای بارگذاری تصاویر به شکل بهینه

https://github.com/esmaeilbahrani/unsplash-gallery

@DevTwitter | <Esmaeil Bahrani Fard/>

یه برنامه نوشتم برای مدیریت اکانت‌های تلگرام. اگر اکانت‌های زیادی دارید و میخواید مثلاً توی برنامه دیگه nodejs یا python استفاده کنید یا به شخص دیگری دسترسی بدید. اکانتها رو اضافه میکنید و فایل JSON تولید شده قابل انتقاله.
اوپن‌سورس با مجوز GPL3 اینجاست:
https://github.com/NabiKAZ/telegram-login-manager

@DevTwitter | <Nabi/>

آیا معماری Serverless رو میشناسید؟

فرض کنید که برنامه ها رو بدون دغدغه ای در مورد سرور ها اجرا کنید و درگیر نگه‌داری، مقیاس پذیری و تامین منابع نشوید.

در معماری Serverless تامین کننده ابری مثلا AWS Lambda زیرساخت را مدیریت می کند و ما بر روی نوشتن کد تمرکز می کنید.

چه مزایایی دارد؟
۱. مقیاس پذیری خودکار - با افزایش ترافیک منابع بیشتری استفاده می‌کند.

۲. پرداخت به ازای مصرف - به جای هزینه سرور کامل فقط هزینه زمان اجرا را می‌دهیم.

۳. سریع تر deploy می‌شود.

۴. رویداد محور: با تغییرات دیتابیس یا رویداد ها مثلا ثبت نام کاربر توابع اجرا می‌شوند.

۵. منابع بیکار نیستند: نیازی نیست که سرور با ظرفیت بالا از قبل بیکار و منتظر درخواست کاربر باشند.


مثال واقعی:
ما در شرکتمان برای پردازش ویدیوهایی که کاربر آپلود می‌کرد و اضافه کردن watermark از AWS Lambda استفاده کردیم.

قبل از این نیاز به یک CPU قوی داشتیم که در اکثر اوقات بیکار بود اما با AWS Lambda فقط در زمانی که کاربر ویدیو رو آپلود می کند تابع اجرا می‌شود و خروجی را در S3 ذخیره می‌کند.

با AWS Lambda هم هزینه سرور کاهش پیدا کرد و هم هیچ منبعی بیکار نماند.

اما همیشه Serverless بهترین انتخاب نیست
معایبی هم دارد
۱. شروع سرد: اگر تابع چند وقت است که اجرا نشده است مدتی طول میکشد تا اجرا شود.

۲. زمان اجرای محدود: در AWS هر تابع بیشتر از ۱۵ دقیقه نمی تواند اجرا شود.

۳. محدود شدن به شرکت خاص: کد AWS با Azure و GCP فرق دارد و اگر مهاجرت کنیم نیاز است کد ها رو از نو بنویسیم.

۴. نداشتن State: اگر نیاز به فضای ذخیره سازی in-memory مانا داریم، این معماری بهترین انتخاب نیست.

برای پروسه های long running و high performance computing و persistent connections معماری های سنتی یا معماری های کانتینرایز شده مناسب تر هستند.

برای کارهای رویداد محور و بهینه سازی هزینه و برنامه های مقیاس پذیر AWS Lambda بسیار مناسب است.


@DevTwitter | <Pouria Jahandideh/>

سلام به همگی
بفرموده داداشم سباستین متد at توی PHPUnit ورژن 9 منسوخ شده و توی ورژن 10 کاملا حذف شد.
اگه توی تست هاتون از این متد استفاده کردین، میتونین با Rule جدیدی که برای rector-phpunit نوشتم، به صورت اتوماتیک این ریفکتور رو انجام بدین

لینک مشارکت:
https://github.com/rectorphp/rector-phpunit/pull/454
لینک منسوخ شدن متد at:
https://github.com/sebastianbergmann/phpunit/issues/4297

@DevTwitter | <Mohammad Mortazavi/>

بالاخره deepseek باعث شد بشینم پای این پروژه‌م و به جایی برسونم که قابل انتشار باشه.
به زودی منتشرش میکنم. یه رابط کاربری ساده و سبک برای کار با ollama برای اونا که میخوان مدل زبانی روی کامپیوتر خودشون و آفلاین اجرا کنن :)
البته سورسش الان روی گیت‌هاب هست:
https://github.com/Aseman-Land/qllm

@DevTwitter | <Bardia/>

توی این ریپازیتوری یک دیتا ست درباره NBA رو تحلیل کردم و سورس اش رو توی گیت هاب براتون گذاشتم، اگر تحلیل گر داده / دارید یاد میگیرید، میتونید از سورس اش استفاده کنید

https://github.com/MisaghMomeniB/NBA-Games-Analysis

@DevTwitter | <Misagh Momeni Bashusqeh/>

یه ابزار خیلی خفن پیدا کردم واسه داکیومنت کردن API توی لاراول به اسم scramble
فقط پکیج رو نصب کردم و دیدم خودش تمام اندپوینت ها٫ ریکوئست ها و ریسپانس ها رو از توی ماژول ها شناخت و توی یه ui شیک واسم آماده قرار داد
https://github.com/dedoc/scramble

@DevTwitter | <Amir Vahedi/>

خبر خوب برای علاقه‌مندان به Go و ستاره‌شناسی و نجوم! کتابخانه jpleph را معرفی می‌کنم - یک کتابخانه Go خالص برای کار با فایل‌های باینری JPL DE ephemerides!

https://github.com/mshafiee/jpleph

پکیج jpleph به شما اجازه می‌ده تا به سادگی موقعیت و سرعت اجرام منظومه شمسی رو با دقت بالا از فایل‌های JPL DE بخونید و محاسبه کنید. مهم نیست سیستم عاملتون چیه، این کتابخانه به صورت خودکار endianness رو تشخیص میده و کار میکنه!

چرا JPL DE؟ چون برای محاسبات نجومی دقیق، ماموریت‌های فضایی و تحقیقات علمی بی‌نظیره! دقتش از سری‌های تحلیلی خیلی بیشتره و با آخرین داده‌های رصدی JPL آپدیت میشه. jpleph این دقت رو به پروژه‌های Go شما میاره!
ویژگی‌های کلیدی jpleph:

پیاده‌سازی. کامل با Go
عملکرد عالی (هم‌سطح C/C++)
سازگاری با پلتفرم‌های مختلف (کراس-پلتفرم)
یکپارچگی آسان با پروژه‌های Go
مدیریت خطای قوی

اگر به astronomy، space و Go علاقه دارید، حتماً به jpleph یه نگاهی بندازید!
به توسعه کتابخانه کمک کنید، issue گزارش بدید یا در پروژه‌هاتون ازش استفاده کنید. GPLv2 متن‌باز و رایگان!


@DevTwitter | <Mohammad Shafiee/>

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

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

برای حل این مشکلات، در پروژه اخیرم تصمیم گرفتیم فرانت‌اند رو هم به‌صورت Micro Frontend پیاده‌سازی کنیم. برای این کار از Module Federation در Vite استفاده کردیم تا هر بخش از سیستم مالی (مثل حسابداری، انبارداری، فروش و ...) به‌صورت مستقل توسعه داده بشه، اما همچنان تجربه کاربری یکپارچه‌ای داشته باشیم.

تقسیم‌بندی سرویس‌ها بر اساس ماهیت
یکی از نکات کلیدی در معماری Micro Frontend این بود که سرویس‌ها رو بر اساس ماهیت کارکردی تقسیم کردیم:
- هر ماژول یا سرویس فقط شامل منطق تجاری و کامپوننت‌های مخصوص خودش بود
- یک سرویس پایه (Base Service) ایجاد کردیم که شامل تمام وابستگی‌های مشترک مثل کتابخانه‌های UI، مدیریت وضعیت، درخواست‌های API و ... بود
- سایر سرویس‌ها از Base Service استفاده می‌کردن و نیازی به نصب مجدد پکیج‌های مشترک نداشتن

مزایای این روش؟
حجم بیلد به‌شدت کاهش پیدا کرد چون وابستگی‌های مشترک فقط یک‌بار لود می‌شدن
لود صفحات سریع‌تر شد چون هر سرویس فقط ماژول‌های موردنیاز خودش رو داشت
مقیاس‌پذیری افزایش یافت چون هر بخش می‌تونست جداگانه توسعه و استقرار پیدا کنه

مدیریت صحیح Dynamic Import و Caching
یکی از چالش‌های Module Federation، مدیریت کش و Dynamic Import هست. اگر این بخش درست پیاده‌سازی نشه، ممکنه باعث لود غیرضروری و افت عملکرد بشه. برای بهینه‌سازی این فرآیند:

- ماژول‌ها رو به‌صورت Remote بارگذاری کردیم تا فقط زمانی که لازم هست، دریافت بشن
- کشینگ هوشمند رو پیاده‌سازی کردیم تا ماژول‌های یک‌بار دانلود شده، دوباره بارگیری نشن
- و Preloading و Lazy Loading رو بهینه‌سازی کردیم تا تجربه کاربری بهتری ایجاد بشه


پیاده‌سازی یک کانتینر مرکزی برای مدیریت سرویس‌ها
برای مدیریت ماژول‌های مختلف، یک Container نوشتیم که وظیفه داره:
- تمام سرویس‌های Remote رو دریافت و مدیریت کنه
- هر سرویس رو در مسیر مشخص خودش رندر کنه
- روتینگ بین ماژول‌ها رو بهینه کنه تا ناوبری بدون مشکل انجام بشه

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


نتیجه نهایی؟
- بیلد سبک‌تر و زمان دیپلوی کوتاه‌تر
- عملکرد سریع‌تر و تجربه کاربری بهتر
- مقیاس‌پذیری بالا و توسعه ماژولار
- امتیاز بهتر در Lighthouse و کاهش چشمگیر زمان بارگذاری

@DevTwitter | <Sajad Shojaie/>

انویدیا یک پروژهٔ open-source ارائه داده که فایل‌های PDF را به پادکست‌های صوتی تبدیل می‌کند. برای دسترسی به این ابزار، به لینک گیت‌هاب زیر بروید:
https://github.com/NVIDIA-AI-Blueprints/pdf-to-podcast

@DevTwitter | <Diss Obedience/>

دیروز یه شبکه عصبی خیلی خیلی جمع و جور ۱۰۰ خطی با ++C (مثال طور) برای اهداف آموزشی به کمک هوش‌مصنوعی ساختم، خروجیش جالب شد واقعا.
گفتم بذارم تو gist شاید شما بدرد شما هم خورد:
https://gist.github.com/realbardia/7a68f6e8114488866baaf021c0daa72f

@DevTwitter | <Bardia/>