خداحافظ گیت‌هاب، سلام کدبرگ: کوچ بزرگ ریپازیتوری اصلی زیگ

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

انتقال شامل ریپازیتوری اصلی زیگ (ziglang/zig) و همچنین سایر ریپازیتوری‌های مرتبط با اکوسیستم زیگ است. این اقدام با هدف تقویت کنترل جامعه بر توسعه زیگ و کاهش خطرات ناشی از تغییرات سیاستی یا مالکیت گیت‌هاب انجام شده است. اندرو کلی، رهبر پروژه زیگ، در بیانیه‌ای اعلام کرد که این انتقال گامی حیاتی برای تضمین آینده‌ای پایدار و مستقل برای زیگ است.

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

فرآیند انتقال به تدریج انجام شده و شامل انتقال کد، تاریخچه، مسائل (issues) و درخواست‌های ادغام (pull requests) است. تیم زیگ ابزارهایی را برای تسهیل انتقال برای توسعه‌دهندگانی که در این پروژه مشارکت دارند، ارائه کرده است. این انتقال ممکن است در کوتاه‌مدت باعث ایجاد اختلالاتی شود، اما انتظار می‌رود در بلندمدت به نفع پایداری و استقلال زیگ باشد.

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

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

مطلب در ویرگول:
https://vrgl.ir/2aNZB

@DevTwitter | <Alireza DavoodiNia/>

تجربه ی آشنایی با Gateway و معماری Microservices :
توی چند روز اخیر موقعیتی پیش اومد که با گیت وی و معماری میکرو سرویس آشنا شدم و با خودم گفتم یه خلاصه ای ازش رو اینجا بذارم.

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

گیت وی چیه؟
گیت وی نقطه ورودی تمام درخواست‌های کلاینت به سمت سرویس‌هاست.
یعنی به‌جای اینکه مستقیماً به چند سرویس مختلف API بزنیم، همه‌چیز از یک “دروازه” عبور می‌کنه.

++ گیت وی مسئول کارهایی مثل:
- روت کردن درخواست‌ها به سرویس درست
- مدیریت احراز هویت و توکن
- محدودیت سرعت، لاگ‌گیری و امنیت
- ساده‌سازی ارتباط فرانت با پشت‌صحنه

مزایای Gateway :
- یک ورودی مشترک برای همه سرویس‌ها => ساده‌تر شدن ارتباط
- مدیریت یکپارچه امنیت، توکن‌ها و قوانین
- امکان ورژن‌بندی و روتینگ هوشمند
- جمع شدن لاگ‌ها و مانیتورینگ در یک نقطه

️ معایب / چالش‌ها:
- اگر Gateway مشکل داشته باشه، کل سیستم تحت‌تأثیره
- دیباگ سخت‌تره چون درخواست‌ها قبل از رسیدن به سرویس تغییر می‌کنن
- پیچیدگی در تنظیم و قوانین روتینگ (با تمام وجودم این موضوع رو درک کردم (: )
- وابستگی زیاد سیستم به این نقطه‌ی مرکزی

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

@DevTwitter | <Ali Joshany/>

کمپانی OpenAi یک دایکیومنت بسیار ارزنده معرفی کرده به عنوان Building an AI-native engineering team

در این سند، راهکارهای قابل اجرا ارائه شده است تا رهبران مهندسی بتوانند از همین امروز فرایند ساخت تیم‌ها و فرآیندهای بومی هوش مصنوعی (AI-native) را آغاز کنند

نسخه فارسی :
https://xpoury4.github.io/ai-native-engineering-persian/
نسخه اصلی :
https://cdn.openai.com/business-guides-and-resources/building-an-ai-native-engineering-team.pdf

لینک گیتهاب برای دانلود :
https://github.com/xPOURY4/ai-native-engineering-persian

@DevTwitter | <POURYA/>

نسخه جدید Docker Engine 29 منتشر شد!
حالا containerd به‌صورت پیش‌فرض نقش «image store» داره
و پشتیبانی آزمایشی از nftables برای فایروال/شبکه لینوکس اضافه شده
یک گام بزرگ به سمت مدرنیته!

@DevTwitter | <MehrdadLinux/>

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

https://github.com/Mazafard/TermForge

@DevTwitter | <Maza/>

#میم_شبانگاهی

تیپیکال مشکلات فنی دوستام

@DevTwitter | <Mahdi Hazrati/>

چهار استراتژی کلیدی برای مقیاس‌پذیری مؤثر پایگاه داده

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

۱) استراتژی Vertical Scaling (افزایش ظرفیت سخت‌افزاری)
ساده‌ترین روش برای افزایش توان پردازشی پایگاه داده، ارتقای منابع سخت‌افزاری نظیر CPU، RAM و فضای ذخیره‌سازی است.
این رویکرد بدون نیاز به تغییرات ساختاری در نرم‌افزار انجام می‌شود و در بسیاری از سیستم‌ها، اولین گام منطقی برای افزایش ظرفیت به شمار می‌آید.
با این حال، Vertical Scaling دارای محدودیت ذاتی است و نهایتاً تا سقف مشخصی قابل افزایش است.

۲) استراتژی Replication (توزیع بار خواندن)
در Replication با ایجاد نسخه‌های متعدد از داده، امکان توزیع بار خواندن بین چندین نود را فراهم می‌سازد.
در این مدل:
عملیات نوشتن تنها به یک نود Leader ارسال می‌شود، Leader تغییرات را به نودهای Follower منتقل می‌کند، عملیات خواندن می‌تواند توسط هر یک از نودهای Leader یا Follower انجام شود.
هدف اصلی این روش افزایش ظرفیت Read و بهبود کارایی سامانه در مواجهه با تعداد زیاد درخواست‌های خواندن است.

۳) استراتژی Caching (افزایش سرعت با ذخیره‌سازی موقت)
استفاده از Cache، از تکرار درخواست‌های غیرضروری به پایگاه داده جلوگیری می‌کند.
در این رویکرد، نخستین درخواست داده را از پایگاه داده دریافت کرده و نتیجه آن در Cache ذخیره می‌شود.
درخواست‌های بعدی، در صورت وجود داده در Cache، به‌سرعت پاسخ داده می‌شوند.
این روش علاوه بر کاهش بار پایگاه داده، به‌طور چشمگیری سرعت پاسخ‌گویی را نیز افزایش می‌دهد.

۴) استراتژی Partitioning / Sharding (مقیاس‌پذیری افقی برای مدیریت بار نوشتن)
استراتژی Sharding با تقسیم داده به بخش‌های مستقل (Partitions یا Shards) و توزیع آن‌ها در چندین سرور، امکان افزایش ظرفیت‌پذیری عملیات نوشتن را فراهم می‌کند.
در این مدل:
هر شارد بخشی از داده را مدیریت می‌کند،
هر درخواست نوشتن تنها به شارد مربوطه ارسال می‌شود،
بار نوشتن میان چندین ماشین تقسیم می‌گردد.
این رویکرد برای سامانه‌هایی که حجم عملیات نوشتن آن‌ها بالا است، روشی پایدار و قابل اعتماد به حساب می‌آید.

ارتباط Replication و Sharding
در معماری‌های بزرگ، Sharding و Replication معمولاً به‌صورت ترکیبی مورد استفاده قرار می‌گیرند.
هر شارد روی چندین نود Replicate می‌شود تا در صورت خرابی یک نود، دسترس‌پذیری داده حفظ گردد.

جمع‌بندی
چهار روش Vertical Scaling، Replication، Caching و Sharding، ستون‌های اصلی مقیاس‌پذیری پایگاه داده در معماری‌های مدرن محسوب می‌شوند.
انتخاب مناسب میان این روش‌ها به نیازهای عملکردی، حجم داده، الگوی دسترسی و محدودیت‌های معماری هر سیستم بستگی دارد.
به‌کارگیری درست و ترکیبی این استراتژی‌ها، امکان ساخت سامانه‌هایی پایدار، سریع و قابل‌اتکا را فراهم می‌کند.

@DevTwitter | <Amir Rahimi Nejad/>

چرا هنوز وردپرس باید اینقدر “دکمه‌محور” و “فرم‌محور” باشه؟
چرا کاربر نتونه مثل حرف زدن با یه آدم، با سایت حرف بزنه و سایت هم واقعا بفهمه چی میگه؟

خب با NLWeb میشه ولی باید مفهوم عمیقتری رو بررسی کنیم اون هم پایه این دانش یا بهتره بگم مادرش یعنی NLU (Natural Language Understanding) ، میشه وردپرس رو از یه CMS معمولی تبدیل کرد به یه موجود فهمنده ( البته درنظر بگیرید منظورمون استفاده از یک چت بات chatbot هوشمند یا متصل به یک هوش مصنوعی نیست ) در حقیقت باید یک لایه ای در خود وردپرس ایجاد کنیم که بتونه نیت کاربر رو برداشت کنه و کاری که باید رو انجام بده؟

دیدم نه فقط میشه، بلکه ترکیب وردپرس با NLU دقیقا همون جهتیه که وب باید بره.
همه چیز از همین سؤال ساده شروع شد:

اگه کاربر به جای پر کردن فرم پیچیده پشتیبانی، فقط بگه «می‌خوام اشتراک سایتم رو تمدید کنم»، چرا سایت نفهمه؟

اینجا بیشتر بخونید در موردش دو منبع نسبتا خوب و کاربردی :
https://fastbots.ai/blog/nlu-for-beginners-a-step-by-step-guide
https://botpenguin.com/glossary/natural-language-understanding

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

از همینجا به بعد، ایده تبدیل شد به یک مسیر جدی:
وردپرس + NLU

یعنی اضافه کردن یک مغز فهمنده که بتونه Intent کاربر رو انتخاب کنه، Entityها رو دربیاره و در نهایت، یک ACTION واقعی سمت وردپرس اجرا کنه.

به نظرم این، همون نقطه تحولیه که وردپرس چند ساله کم داشته: رفتن از “کلیک کردن” به “درک کردن”.

دارم روی یک معماری کار می‌کنم که این دو دنیا رو به هم قفل کنه:
1- پشت‌صحنه پایتون برای پردازش زبان طبیعی
2- جلوی صحنه وردپرس
3- یک لایه میانی که این‌ها رو مثل یک سیستم عصبی واقعی به هم وصل کنه.

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

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

این فقط یه آموزش نیست…
این شروع یک تحول و تغییر جهته.

@DevTwitter | <amin diba/>

چند وقت پیش وسط یه پروژه معمولی بودم. یه سایت ساده که فقط باید اطلاعات رو درست و تمیز نشون بده. همون موقع یه سؤال تو ذهنم چرخید:
اصلاً چرا وب هنوز اینقدر یک‌طرفه‌س؟
چرا سایت فقط نشون می‌ده ولی نمی‌فهمه چی می‌خوای؟
از همین سؤال رسیدم به چیزی که این روزا داره یه لایه جدید به وب اضافه می‌کنه: NLWeb

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

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

خروجی چی میشه؟
کاربر که وارد سایت میشه، دیگه مجبور نیست تو منوها یا PDFهای سنگین دنبال جواب بگرده.
فقط سؤالش رو می‌نویسه و پشت‌صحنه، NLWeb کل محتوای سایت رو می‌فهمه، تحلیل می‌کنه و یه جواب دقیق و تمیز می‌ده.
https://github.com/nlweb-ai/NLWeb

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

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

@DevTwitter | <amin diba/>

گاهی تو دنیای فرانت‌اند یه چیزهایی هست که همیشه فقط موقع مصاحبه سر و کله‌شون پیدا میشه…
«خب بگو ببینم Closure چیه؟»
ولی واقعیت اینه که Closure یکی از بنیادی‌ترین مفاهیمی هست که خیلی از طراحی‌ها و معماری‌های مدرن جاوااسکریپت، و حتی خود React، روی اون سوار شده‌اند.
توی این مقاله‌، سعی کردم خیلی ساده و مرحله‌به‌مرحله نشون بدم:
کلوژر واقعاً چیه و چرا مهمه
کجاها تو طراحی نرم‌افزار ازش استفاده می‌کنیم
چه معضلاتی میتونه به همراه داشته باشه
و مهم‌تر از همه: چطور React با استفاده خلاقانه از Closure، هوک‌هایی مثل useState و useEffect رو ممکن می‌کنه
برای اینکه مفهوم واقعاً جا بیفته، خودمون هم یک نسخه‌ی مینیمال و واقعی از useState و useEffect رو با Closure ساختیم تا ببینیم پشت‌پرده چه خبره!
اگه Closure همیشه برات یک چیز مبهم، ترسناک یا فقط یک سؤال مصاحبه‌ای بوده، این مقاله نگاهت رو بهش کامل عوض می‌کنه.
لینک مقاله
https://medium.com/@ajblog7070/how-javanoscript-closures-power-react-re-creating-usestate-and-useeffect-from-scratch-16a7ee0a0757

@DevTwitter | <Ali Jafarian/>

آیا هوش مصنوعی جای همه شغل هارو میگیره؟
نه

آیا توسعه ی نرم افزار از همیشه سخت تر میشه؟
آره

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

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

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

چون هنوز صنعت به نیروی خوب نیاز داره.

به کسی که توانایی فکر کردن و فهمیدن داره.

تجربه ارزش داره، حل کردن مشکل ارزش داره، اینکه یک سیستم چگونه کار می کنه و نه چرا، ارزش داره.

در نهایت برنامه نویس های ضعیف حذف میشن، برنامه نویس های متوسط باید پیشرفت کنن و برنامه نویس های قوی جاشون امنه.
https://www.youtube.com/watch?v=JPuP7SLs44g

@DevTwitter | <Yusof Sadat Fakhr/>

سلام رفقا
چند روزی درگیر طراحی یه اپلیکیشن Shop بودم که داخلش مدیریت نماینده‌ها هم به‌صورت کامل هندل بشه. راستش تو مسیر کلی چالش داشتم و یه‌سری سؤال‌ بی‌جواب ذهنمو درگیر کرده بود.
تا اینکه به یه داکیومنت خیلی خفن رسیدم که حتی چندتا از مدیرهای FAANG (Meta(Facebook), Amazon, Apple, Netflix, Google) هم نظر دادن و واقعاً محتوای کامل و کاربردی‌ای داره.
اگه دوست دارید مطالعه‌اش کنید، از این لینک می‌تونید برید
https://www.systemdesignhandbook.com/guides/design-inventory-management-system/

@DevTwitter | <rasol kalantari/>

اگر میخواهید کاری با واتس اپ بکنید برای اتوماسیون
https://github.com/tulir/whatsmeow

متاسفانه این اپ منفور هرچی لینک داره رو demote می‌کنه

@DevTwitter | <Fred/>

اگر قدرت AI در دستان همه است، مدیون تلاش‌های بی‌وقفه پیشگامانی چون یان لکان هستیم.
این ویدئو سفری ست به سال 1989 (1368)؛روزگاری که جاده‌ها آسفالت نبود و بسیاری از نفت برای گرم کردن استفاده میکردند، پژوهشگران در آمریکا در حال آموزش مدل های AI بینایی ماشین مبتنی بر شبکه عصبی بودند.

@DevTwitter | <Gratomic AI Bot/>

#کوته_نیوز

دیجیاتو/ گوگل دسترسی رایگان به جمینای 3 پرو و Nano Banana Pro را محدود کرد و گفت باید پول بپاشید رو سر و صورتم.

@DevTwitter

توی vibe coding مرحله planning رو جدی بگیرید تا خروجیتون چند برابر بهتر بهشه.
به صورت خلاصه باید سه مرحله رو طی کنید
۱. تهیه کردن کانتکست خلاصه و درست
از AI توقع نداشته باشید کل پروژه رو تو ذهنش داشته باشه برای هر تسک بهش بگید به کجاها باید توجه کنه و به کجاها توجه نکنه.

کانتکست هم باید کوچیک باشه و هم باید جامع باشه
۲. پلن
هیچقوت از AI نخواید مستقیم کد رو بزنه چون بعدش refine کردنش خیلی سخت میشه. اول بخواید plan کنه اگه plan اون طوری که شما میخواستید نبود ازش بخواید plan رو refine کنه

۳. اجرا و راستی آزمایی.
مرحله آخرم اجراست. اگه اجراش خیلی پرت بود بهتره کل کد رو پاک کنید و برگردید به مرحله ۲ یا حتی مرحله ۱ اینکه هی با پرامپت های بعدی سعی کنید مشکل رو فیکس کنید خیلی جواب نمیده

مثلا فرض کنید شما یه پروژه دارید که تست نداره و با vibe coding میخواید براش تست بنویسید. راه اول اینه که سعی کنید توی یه پرامپت بلند یا کوتاه از AI بخواید برای شما تست بنویسه.
ولی راه پیشنهادی من اینه:
۱. از AI بخواید ماژول های پروژه رو برای شما شناسایی کنه و همراه با جزئیات لازمه نوشته بشه بده و توی یه فایل به هر اسمی مثل TASK1_PLAN.md بریز حالا بررسی نهایی رو روی این فایل بکنید مطمئن بشید best practice هایی که میخواید رعایت بشه توی PLAN نوشته شده اینکه چیا باید ماک بشه چیا نباید بشه اونجا هست و ۳. در قدم نهایی بخواید PLAN رو اجرا کنه

@DevTwitter | <brdia/>