مقایسه GitHub و GitLab

1. مالکیت:
- GitHub: متعلق به شرکت مایکروسافت.
- GitLab: متعلق به شرکت GitLab Inc.

2. جامعه (Community & Publicity):
- GitHub: بیش از 100 میلیون کاربر و سطح تبلیغات و شناخت عمومی بالا.
- GitLab: حدود 30 میلیون کاربر (تخمین زده‌شده) و سطح شناخت عمومی کمتر از GitHub.

3. فضای ذخیره‌سازی مخازن عمومی:
- GitHub: فضای ذخیره‌سازی نامحدود.
- GitLab: پنج گیگابایت (تخمینی).

4. فضای ذخیره‌سازی مخازن خصوصی:
- GitHub: پانصد مگابایت
-GitLab: پنج گیگابایت

5. دقیقه‌های محاسباتی CI برای پروژه‌های عمومی:
- GitHub: نامحدود.
- GitLab: چهارصد دقیقه (اگرچه در مستندات رسمی 50,000 دقیقه ذکر شده است، اما معمولاً 400 دقیقه ارائه می‌شود)

6. دقیقه‌های محاسباتی CI برای پروژه‌های خصوصی در ماه:
- GitHub: دوهزار دقیقه
- GitLab: چهارصد دقیقه

7. حداکثر تعداد همکاران برای مخازن عمومی:
- GitHub: نامحدود.
- GitLab: نامحدود.

8. حداکثر تعداد همکاران برای مخازن خصوصی:
- GitHub: نامحدود.
- GitLab: محدود به 5 نفر.

#github #gitlab

@Syntax_fa

تاریخچه کوبرنتیز

کوبرنتیز (Kubernetes) یکی از پیشروترین ابزارهای مدیریت کانتینرها در دنیای فناوری امروز است. اما برای درک بهتر تاریخچه کوبرنتیز، لازم است ابتدا نگاهی به ریشه‌های آن و پیشرفت‌هایی که به خلق این ابزار انجامید بیندازیم.

2006: آغاز راه در گوگل با cgroup

در سال 2006، گوگل به‌دنبال بهینه‌سازی منابع خود بود، چرا که نیاز داشت حجم عظیمی از داده‌ها و اپلیکیشن‌ها را در مقیاس بالا مدیریت کند. در این راستا، پروژه‌ای را با هدف ایجاد ابزارهایی برای جداسازی و تخصیص منابع سیستم آغاز کرد. این پروژه که ابتدا با نام "Process Container" شناخته می‌شد، بعدها به cgroup (Control Groups) تغییر نام یافت. cgroup قابلیتی بود که اجازه می‌داد منابع مختلف سیستم (CPU، حافظه، دیسک و ...) به صورت کنترل‌شده و محدود بین فرآیندها تقسیم شوند.

سال 2007: cgroup وارد هسته لینوکس می‌شود

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

معرفی Namespaces توسط Red Hat

همزمان با توسعه cgroup، مفهوم دیگری به نام Namespaces توسط شرکت Red Hat معرفی شد. Namespaces امکان ایزوله‌سازی بخش‌های مختلف سیستم (مانند شبکه، فایل‌سیستم و موارد دیگر) را فراهم کرد. ترکیب cgroup و Namespaces، اساس فناوری کانتینرها را شکل داد و بستر لازم برای مدیریت اپلیکیشن‌ها در محیط‌های ایزوله را فراهم کرد.

سال 2013: معرفی Docker

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

سال 2014: تولد کوبرنتیز در گوگل

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

نکته:
کوبرنتیز (Kubernetes) در ابتدا با زبان C توسعه داده شده بود. اما در سال 2014 تیم گوگل تصمیم گرفت آن را با زبان Go بازنویسی کند. دلیل این تغییر، توانایی‌های Go در مدیریت هم‌زمانی (Concurrency)، عملکرد بالا، و سهولت توسعه و نگهداری بود که برای یک سیستم توزیع‌شده مدرن مانند Kubernetes بسیار ضروری است.

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


2015: کوبرنتیز و CNCF

برای گسترش و پذیرش بیشتر کوبرنتیز در جامعه متن‌باز، گوگل تصمیم گرفت این پروژه را به بنیاد جدیدی به نام Cloud Native Computing Foundation (CNCF) اهدا کند. CNCF که یک زیرمجموعه از بنیاد Linux Foundation است، وظیفه داشت تا به توسعه و گسترش اکوسیستم ابزارهای مدرن ابری کمک کند. این حرکت باعث شد کوبرنتیز از زیر چتر گوگل خارج شود و به یک پروژه مستقل و جهانی تبدیل شود که توسط جامعه متن‌باز هدایت می‌شود.

رشد و محبوبیت کوبرنتیز

پس از اهدا به CNCF، کوبرنتیز به سرعت به استانداردی برای مدیریت کانتینرها تبدیل شد. ابزارهای بسیاری برای تکمیل اکوسیستم کوبرنتیز توسعه یافتند و شرکت‌های بزرگی مانند
Red Hat، IBM، Microsoft💩, AWS
از آن پشتیبانی کردند. کوبرنتیز به دلیل انعطاف‌پذیری، مقیاس‌پذیری، و قابلیت اتوماسیون، به یکی از محبوب‌ترین ابزارها برای مدیریت زیرساخت‌های ابری تبدیل شده است.

#kubernetes

@Syntax_fa

استراتژی Deployment در Kubernetes چیست؟

برای درک مفهوم استراتژی Deployment در Kubernetes، ابتدا باید دو معنای ممکن "deployment" در محیط Kubernetes را توضیح دهیم:

1. deployment
به فرآیند نصب یک نسخه جدید از یک اپلیکیشن یا workload روی pods در Kubernetes اشاره دارد.
2. Deployment
(با D بزرگ)، یک Kubernetes object است که دارای فایل تنظیمات YAML مخصوص به خود می‌باشد و به شما این امکان را می‌دهد که تعیین کنید:
- فرآیند deployment چگونه باید انجام شود،
- دقیقاً چه چیزی باید deploy شود،
- و همچنین چگونه درخواست‌ها به اپلیکیشن جدید هدایت شوند.

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

1. Recreate Deployment
این روش یک فرآیند همه یا هیچ است که اپلیکیشن را فوراً به‌روزرسانی می‌کند، اما با مقداری downtime همراه است.

- در این استراتژی، pods موجود حذف می‌شوند و نسخه جدید جایگزین آن‌ها می‌شود.
- این روش باعث می‌شود که از زمان خاموش شدن نسخه قدیمی تا شروع به کار نسخه جدید، اپلیکیشن downtime داشته باشد.
- موارد استفاده مناسب:
- محیط‌های توسعه (development environments).
- زمانی که کاربران ترجیح می‌دهند یک دوره کوتاه downtime به جای کاهش عملکرد یا خطاهای طولانی‌مدت (در rolling deployment) داشته باشند.
- زمانی که دلایل فنی اجازه اجرای دو نسخه همزمان از یک اپلیکیشن را نمی‌دهند(برای مثال statefull بودن برنامه).

2. Rolling Deployment
در این استراتژی، نسخه جدید اپلیکیشن به‌صورت تدریجی روی pods مستقر می‌شود.

- مزایا:
- امکان بازگشت (rollback) آسان‌تر.
- ریسک کمتری نسبت به روش Recreate دارد.
- نسبتا راحت پیاده‌سازی می‌شود.
- معایب:
- ممکن است کند باشد.
- در صورت بروز مشکل، بازگشت به نسخه قبلی دشوارتر است.
- اجرای همزمان چند نسخه از اپلیکیشن ممکن است برای اپلیکیشن‌های قدیمی مشکل‌ساز باشد.

3. Blue/Green Deployment (Red/Black Deployment)
این استراتژی به شما امکان می‌دهد که نسخه جدید اپلیکیشن را بدون downtime مستقر کنید.

- در این روش، نسخه فعلی (آبی) فعال است و نسخه جدید (سبز) در کنار آن اجرا می‌شود.
- پس از آزمایش نسخه سبز، ترافیک به آن سویچ می‌شود.
- مزایا:
- حذف کامل downtime.
- ریسک کمتر (به‌دلیل امکان بازگشت فوری به نسخه قبلی).
- عدم وجود مشکلات نسخه‌بندی، زیرا کل اپلیکیشن در یک حالت تغییر می‌کند.
- معایب:
- نیاز به منابع دوبرابر برای نسخه‌های آبی و سبز.
- نیاز به مکانیزمی برای تغییر سریع ترافیک.

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

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


5. A/B Testing

در Kubernetes، A/B Testing نوعی از canary deployment است که ترافیک را بر اساس پارامترهای خاص (مانند کوکی‌ها یا user agents) بین نسخه‌های مختلف اپلیکیشن توزیع می‌کند.

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

6. Shadow Deployment
در این روش، نسخه جدید اپلیکیشن روی production workloads آزمایش می‌شود، اما بدون اینکه کاربران نهایی متوجه شوند.

- ترافیک بین نسخه فعلی و نسخه جدید تقسیم می‌شود.
- مزایا:
- امکان آزمایش جنبه‌های غیرفنی (مانند عملکرد و پایداری) نسخه جدید.
- معایب:
- پیچیدگی مدیریت بالا.
- نیاز به منابع دوبرابر برای اجرای همزمان نسخه‌های مختلف

نکته:
توجه داشته باشید که فقط دو استراتژی Recreate و Rolling به‌صورت پیش‌فرض توسط Kubernetes Deployment object پشتیبانی می‌شوند. سایر استراتژی‌ها نیازمند سفارشی‌سازی یا استفاده از ابزارهای تخصصی هستند.

source

#deployment_strategy

@Syntax_fa

انحصارطلبی غول‌های فناوری: «ما حامی هستیم، اما فقط وقتی مال خودمون باشی!»

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

کافیه یه پروژه اوپن‌سورس یا یه استارت‌آپ کوچیک یه ذره رشد کنه و توجه‌ها رو به خودش جلب کنه. سریع یکی از این غول‌ها میاد، قربون‌صدقه میره و یه قلب بزرگ (❤️) پای پروژه می‌ذاره. اما این قلب زدن فقط یه راه مودبانه برای گفتن این جمله‌ست: "ما این رو می‌خریم!" و اگه نتونن بخرنش، وارد یه فاز تهاجمی‌تر میشن: نابودش کن!

فاز اول: قلب بزن، قربون‌صدقه برو
وقتی یه استارت‌آپ یا یه پروژه اوپن‌سورس داره رشد می‌کنه، اول از همه غول‌های فناوری میان و با لبخند ازش تعریف می‌کنن. مثلاً توییت می‌زنن:
"این پروژه واقعاً الهام‌بخشه. ما عاشق نوآوری هستیم و از این پروژه حمایت می‌کنیم!"
اما پشت این تعریف‌ها، مدیرای اجرایی و تیم‌های حقوقی شرکت دارن بررسی می‌کنن که چطور این پروژه رو تصاحب کنن. چون تو دنیای غول‌ها، کلمه «حمایت» معمولاً به معنی «ادغام در امپراتوری ما» است.

فاز دوم: چند ماه بعد، خبر میاد که:
"مایکروسافت/گوگل/آمازون این استارت‌آپ را با مبلغ X میلیون دلار خریداری کرد."
ظاهرش خیلی جذابه: استارت‌آپ حالا منابع بیشتری داره و می‌تونه سریع‌تر رشد کنه. ولی در واقعیت، این خرید بیشتر شبیه یه «عملیات خفه کردن» برای کنترل یا حذف رقابت در بازار هست.

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

@Syntax_fa

مثال‌هایی از شکار و انحصارطلبی

1. مایکروسافت و نوآوری‌های Netscape: پایان مرورگر مستقل
در دهه ۹۰ میلادی، Netscape یکی از محبوب‌ترین مرورگرهای وب بود. این شرکت به نوعی پیشگام اینترنت مدرن به حساب می‌اومد و مایکروسافت که از محبوبیت و رشد سریع Netscape ترسیده بود، استراتژی تهاجمی خودش رو شروع کرد. 
مایکروسافت تصمیم گرفت مرورگر خودش به نام Internet Explorer رو به صورت رایگان همراه با ویندوز عرضه کنه. این حرکت باعث شد که کاربران به طور پیش‌فرض از Internet Explorer استفاده کنن و سهم بازار Netscape به شدت کاهش پیدا کنه. 
در نهایت، Netscape نتونست با این انحصارطلبی مبارزه کنه و ورشکست شد. این پرونده حتی به دادگاه ضدانحصار ایالات متحده کشیده شد، جایی که مشخص شد مایکروسافت عمداً از قدرت انحصاری ویندوز برای حذف رقبای مرورگر استفاده کرده. 

2. مایکروسافت و Skype: تصاحب و سقوط یک نوآوری
مایکروسافت در سال ۲۰۱۱ با مبلغ ۸.۵ میلیارد دلار Skype رو خریداری کرد. اسکایپ تا قبل از خرید یکی از محبوب‌ترین ابزارهای تماس ویدیویی و صوتی در جهان بود و به عنوان یک نوآوری مستقل می‌درخشید. اما بعد از خرید توسط مایکروسافت، مشکلات شروع شد: 
- مایکروسافت به جای توسعه و بهبود اسکایپ، تمرکز رو روی ادغام اون با محصولات خودش مثل ویندوز و Office گذاشت. 
- اسکایپ به مرور زمان از کارایی افتاد؛ مشکلات مربوط به کیفیت تماس و رابط کاربری گیج‌کننده باعث شد که بسیاری از کاربران به سرویس‌های رقیب مثل Zoom، WhatsApp، و Google Meet مهاجرت کنن. 
- نهایتاً، اسکایپ که یک‌زمانی یکه‌تاز بازار تماس‌های ویدیویی بود، به حاشیه رانده شد و تقریباً از فضای رقابت حذف شد. 

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

3. مایکروسافت و Nokia: شکست برنامه‌ریزی‌شده؟
یکی از جنجالی‌ترین تصاحب‌های مایکروسافت، خرید بخش موبایل شرکت نوکیا در سال ۲۰۱۳ بود. نوکیا که زمانی بزرگترین تولیدکننده گوشی‌های موبایل در دنیا بود، به خاطر رقابت با سیستم‌عامل‌های اندروید و iOS دچار افت شد. مایکروسافت با وعده همکاری و توسعه، بخش موبایل نوکیا رو خرید و ادعا کرد که این خرید به زنده‌کردن نوکیا کمک می‌کنه. اما در واقعیت، این اتفاق به سقوط کامل نوکیا منجر شد:
- مایکروسافت تصمیم گرفت که گوشی‌های نوکیا فقط با سیستم‌عامل Windows Phone عرضه بشن، که سهم بسیار کوچکی از بازار موبایل داشت. این تصمیم، نوکیا رو از رقابت با اندروید و iOS دور کرد.
- سرمایه‌گذاری روی ویندوزفون شکست خورد و مایکروسافت خیلی زود این پروژه رو رها کرد.
- در نهایت، بخش موبایل نوکیا تعطیل شد و هزاران نفر از کارکنانش بیکار شدن.

4. گوگل و DeepMind 
گوگل وقتی DeepMind رو خرید، قول داد که این شرکت مستقل و متمرکز روی «هوش مصنوعی اخلاقی» باقی می‌مونه. اما حالا بیشتر کارای DeepMind روی پروژه‌هایی متمرکزه که به تبلیغات گوگل و سرویس‌های پول‌ساز این شرکت کمک می‌کنه. مثلاً پروژه‌های سلامت DeepMind به Google Health منتقل شدن، و حالا بیشتر از اینکه به اخلاق فکر کنن، به سوددهی فکر می‌کنن. 

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

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

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

@Syntax_fa

شما بزرگ ترین دشمنان و خلافکاران در علیه شرکت های تولید نرم افزار در جهان رو در تصویر میبینید!

رئیس سایت سافت ۹۸ و پی سی دانلود در یک قاب

#fun

@Syntax_fa

وب‌سایت سینتکس‌فا لانچ شد!

تقریبا اوایل سال 1403 تصمیم گرفتیم یه تیمی رو دور هم جمع کنیم تا با هم کار های خفن و جذاب انجام بدیم همچنین باعث پیشرفت همدیگه بشیم.

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

وب‌سایت سینتکس اتمامش تقریبا یسال طول کشید! سه بار طراحی ui ux ریدیزاین شد. فرانت اتدش هم دوبار ریدیزاین شد!

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

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

https://syntaxfa.com

@Syntax_fa

راستی یادم رفت
تشکر از:
امیرحسین فرانت اند پروژه با فلاتر
@Awmirsn
طراحی خفن UI/UX توسط محمد
@FalahiDevPV
همچنین سحر هم تو UI/UX کمک زیادی کرده
@shariws
بک اند جنگو با اون یکی امیرحسین و خودم
@the_aech

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

https://github.com/actions/starter-workflows/

دوست دارید در خصوص گیتهاب اکشن پست های بیشتری بذاریم؟ تو پروژه هاتون از گیتهاب اکشن استفاده می کنید؟

#github #workflow

@Syntax_fa

چه کسایی سمت گیتهاب اکشن نسخه رایگانش نرن؟

بنظرم خیلی از موارد گزینه مناسبیه ولی اگه:
ریپازیتوری پرایوت شما بیشتر از 2000 دقیقه در ماه قراره روش جاب های مختلف ورکفلو هاتون اجرا بشه.
ریپازیتوری پابلیک ->‌بیشتر از 16 گیگ رم و 14 گیگ فضا و 4 تا پردازنده نیاز دارید.
ریپازیتوری پرایوت -> بیشتر از 7 گیگ رم و 14 گیگ فضا و 2 پردازنده نیاز دارید.

در غیر اینصورت گزینه خیلی خوبیه مخصوصا برای استفاده شخصی

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

#github #workflow

@syntax_fa

مشارکت تو پروژه اپن سورس

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

برای چه کسایی مناسبه؟
- پایتون رو بلد باشه
- به کراولر نویسی و web scraping علاقه داشته باشه
- تجربه کار با جنگو رو داشته باشه

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

همچنین یکی از افراد با تجربه که خیلی قبولش دارم، پروژه رو مدیریت میکنه.
بنظر من برای لول آپ، فرصت خوبیه

اگه دوست دارید مشارکت کنید، پیویم پیام بدید:
@ayeef

سه تا وب سایت با طراحی فضایی
وب سایت اولی و دومی تو یه لیگ دیگن

https://gapsystudio.com/

https://boredapeyachtclub.com/

https://amie.so/

@Syntax_fa

چندتا از بچه‌ها پیوی پیام دادن و راجب یه موضوع صحبت کردن

اینکه بیکاری اذیتشون میکنه، منجر به تنبلی و کاهش اعتماد بنفس درونشون شده و ...

بچه‌ها درکتون میکنم و این مسئله کاملا طبیعی هستش

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

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

این قضیه رو جدی بگیرید و ازش استفاده کنید

Source

@Syntax_fa

📌 معرفی KeePassX؛ ابزار مدیریت رمز عبور امن و کاربردی 

🔒 KeePassX یک نرم‌افزار مدیریت رمز عبور رایگان و متن‌باز است که به شما کمک می‌کند تمامی رمزهای عبور خود را به‌صورت امن ذخیره کنید و تنها با به خاطر سپردن یک رمز اصلی (Master Password) به تمامی آن‌ها دسترسی داشته باشید. 


✅ ویژگی‌های اصلی KeePassX: 
1. امنیت بالا: 
   با استفاده از الگوریتم‌های رمزنگاری قدرتمند (AES و Twofish)، KeePassX اطلاعات شما را در برابر دسترسی‌های غیرمجاز محافظت می‌کند. 

2. متن‌باز بودن: 
   به دلیل متن‌باز بودن، می‌توانید از امنیت و شفافیت آن مطمئن شوید. جامعه برنامه‌نویسان همواره آن را بررسی می‌کنند و بهبود می‌دهند. 

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

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

5. بدون نیاز به اینترنت: 
   KeePassX روی سیستم شما اجرا می‌شود و نیازی به اتصال به اینترنت ندارد، بنابراین خطرات ناشی از هک شدن سرویس‌های ابری را کاهش می‌دهد. 


🔰 کی برای KeePassX مناسب است؟ 
- افرادی که رمزهای زیادی دارند و حفظ آن‌ها دشوار است. 
- کسانی که به امنیت اطلاعات و حریم خصوصی خود اهمیت می‌دهند. 
- کاربرانی که ترجیح می‌دهند داده‌های خود را به‌صورت آفلاین و بدون نیاز به سرورهای ابری ذخیره کنند. 


💡 چرا KeePassX؟ 
در دنیایی که اطلاعات دیجیتال ما هدف اصلی هکرهاست، استفاده از یک ابزار مدیریت رمز عبور امن، ضروری است. KeePassX یک گزینه عالی برای محافظت از اطلاعات شخصی شماست. 

📥 دانلود KeePassX: 
برای دانلود و اطلاعات بیشتر به وب‌سایت رسمی آن مراجعه کنید: 
https://www.keepassx.org

🌐 با KeePassX، امنیت رمزهای عبور خود را تضمین کنید!

#keepassx

@syntax_fa

تایپ اسکریپت هم به راه راست هدایت شد و فهمید جی اس خرابه.

بازنویسی TypeScript با Go و افزایش سرعت ۱۰ برابری 🚀

مایکروسافت اعلام کرده TypeScript در حال بازنویسی مجدد به زبان Go می باشد. این تغییر باعث افزایش ۱۰ برابری سرعت نسبت به نسخه قبلی خواهد شد. در حال حاضر، TypeScript بر پایه JavaScript و TypeScript خودش نوشته شده است، اما این رویکرد جدید به طور چشمگیری عملکرد را بهبود می‌بخشد.

چرا Go انتخاب شد؟ 🤔
مایکروسافت که در دوراهی سی هشتگ و گولنگ مانده بود در نهایت تصمیم قاطعانه گرفت از سی هشتگ استفاده نکند.

همچنین مایکروسافت دلایلی برای این تصمیم بازنویسی با گو ارائه داده است:

✅ بهینه‌سازی حافظه – زبان و مفسر Go نسبت به JavaScript از حافظه بهینه‌تر استفاده می‌کند.
✅ همزمانی بهتر – زبان و مفسر Go دارای مدل همزمانی پیشرفته است که باعث افزایش سرعت کامپایل می‌شود.
✅ بهره‌گیری از کامپایلر کارآمد – زبان و مفسر Go با داشتن یک باینری مستقل، نیاز به اجرای TypeScript روی Node.js را حذف می‌کند.

مزایای تغییر به Go 🔥

🔹 افزایش سرعت کامپایل – پروژه‌های بزرگ TypeScript سریع‌تر اجرا خواهند شد.
🔹 مصرف کمتر حافظه – منابع کمتری مصرف شده و پردازش‌ها سبک‌تر خواهند بود.
🔹 ادغام بهتر با محیط‌های مختلف – می توان ادعا نمود که TypeScript بدون وابستگی به Node.js روی سیستم‌های بیشتری قابل اجراست.

آیا این به معنای دردسر برای کدنویسها است؟ 🧐

به گفته تیم توسعه‌، این تغییر در بنیان TypeScript رخ می‌دهد و بر نحوه استفاده برنامه‌نویسان از آن تأثیری نخواهد گذاشت. کدهای موجود همچنان به درستی کار خواهند کرد، اما با سرعت و کارایی بیشتر.

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

📌 نتیجه‌گیری:
قرار است TypeScript به زبان Go بازنویسی شود که باعث افزایش چشمگیر سرعت و بهینه‌سازی مصرف منابع خواهد شد. این یک تغییر بنیادی است که می‌تواند تجربه توسعه‌دهندگان را بهبود ببخشد. 💡✨

#fun

Source

@syntax_fa

معرفی ابزار امنیتی Lynis 

ا🔒 Lynis چیست؟ 
ا- Lynis یک ابزار امنیتی قدرتمند برای بررسی امنیت سیستم‌های مبتنی بر Linux، macOS یا Unix است. این ابزار با انجام یک اسکن گسترده، به تقویت امنیت سیستم و تست‌های تطابق با استانداردها کمک می‌کند. Lynis یک پروژه متن‌باز است.

🎯 اهداف Lynis: 
این ابزار به دلیل انعطاف‌پذیری بالا، برای اهداف مختلفی استفاده می‌شود، از جمله: 
- بررسی امنیتی (Security Auditing) 
- تست تطابق با استانداردها (مانند PCI، HIPAA، SOx) 
- تست نفوذ (Penetration Testing) 
- شناسایی آسیب‌پذیری‌ها 
- تقویت امنیت سیستم (System Hardening) 


👥 کاربران Lynis: 
- توسعه‌دهندگان: برای تست ایمیج های Docker یا بهبود امنیت اپلیکیشن‌های وب. 
- مدیران سیستم: اسکن برای شناسایی نقاط ضعف جدید.
- تسترهای نفوذ: شناسایی نقاط ضعف امنیتی در سیستم‌های مشتریان. 

📂 سیستم‌عامل‌های پشتیبانی‌شده: 
- Linux 
- macOS 
- FreeBSD 
- OpenBSD 
- Solaris 
- و حتی دستگاه‌هایی مثل IoT. 

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

📋 مراحل اسکن Lynis: 
1. آغاز اسکن 
2. بررسی مالکیت فایل‌ها 
3. شناسایی سیستم‌عامل و ابزارها 
4. جستجوی اجزای نرم‌افزاری موجود 
5. اجرای تست‌های امنیتی 
6. ارائه گزارش وضعیت امنیتی 

🔎 نتیجه: گزارش‌های فنی در فایل‌های گزارش (مانند lynis.log و lynis-report.dat) ذخیره می‌شوند. 

🎛 قابلیت سفارشی‌سازی: 
- امکان غیرفعال کردن تست‌های سخت‌گیرانه. 
- اجرای تست‌های اختصاصی کاربر با هر زبان اسکریپتی. 

📦 نصب Lynis: 
Lynis سبک و آسان برای استفاده است. روش نصب از طریق گیت‌هاب: 
- کلون از GitHub
git clone https://github.com/CISOfy/lynis

- استفاده از فایل tarball و اجرای دستور
lynis/lynis audit system -Q


🛡 امنیت سیستم شما با Lynis تضمین می‌شود!

#lynis

@syntax_fa

این ارتش هاگوارتز و دنیای هری پاتر نیست

بلکه چهارشنبه سوری است

#Fun

@Syntax_fa

💻 Vibe Coding: برنامه‌نویسی بدون درک کد؟!

داشتم توی توییتر (اکس) می‌چرخیدم که به یه اصطلاح جدید به نام Vibe Coding برخوردم. این یعنی یه برنامه‌نویس دیگه مستقیم کد نمی‌نویسه، بلکه میره از ابزارهای AI مثل ChatGPT، Cursor AI، Copilot و این جور چیزا استفاده می‌کنه و کدی می‌سازه که شاید کار کنه، ولی نه خیلی قابل درک یا بهینه باشه!

🔹 مکانیزم این روش چجوریه؟
1️⃣ برنامه‌نویس یه ایده کلی داره.
2️⃣ می‌ره به AI می‌گه که "یه چیزی بساز که این کار رو بکنه."
3️⃣ هوش مصنوعی یه کد می‌سازه که احتمالاً درست کار کنه.
4️⃣ آخرش، بدون اینکه خیلی درک کنه چطور کار می‌کنه، برنامه اجرا میشه!

📌 نتیجه؟
✅ کد نوشته شده و بالا اومده.
❌ اما ساختار و بهینه بودنش هنوز معلوم نیست.
❌ برنامه‌نویس حتی نمی‌دونه کد چطور کار می‌کنه!
❌ عملکرد؟ شاید درست کار کنه، ولی فقط تا وقتی مشکلی پیش نیاد!
❌ مشکلات امنیتی؟ ممکنه یه سوراخ امنیتی بزرگی وجود داشته باشه که کسی متوجهش نشه تا زمانی که به مشکل برخورد کنه! 🔓

یه مثال جالب از این قضیه، "Leo" یه برنامه‌نویس بود که با استفاده از Cursor AI بدون نوشتن حتی یک خط کد یه سیستم SaaS راه انداخت و داخل توییتر (اکس) پز می‌داد که چطور موفق شده و چقدر فروخته. اما بعد از یه مدت، یه توییت زد و گفت که وب‌سایتش تحت حمله قرار گرفته و اپلیکیشنش خراب شده! بعد مشخص شد که چیزای ساده‌ای مثل authentication یا CORS رعایت نشده بود!

📌 نتیجه‌گیری:

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

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

@Syntax_fa

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

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

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

حالا چطور اینکارو انجام بدیم؟
گیتهاب اکشن یه قابلیتی داره که میتونیم تنظیم کنیم یه ورکفلو بصورت دوره تکرار همش اجرا بشه
خب پس قسمت اول مسئله حل شد بقیشم که کاری نداره یدونه smtp میخوایم اونم جیمیل در اختیارمون قرار میده و تا روزی 500 تا ایمیل هم رایگان میتونیم ارسال کنیم پس فقط نیازه یه سری ریکوئست و فیلتر ساده بزنیم تا پول ریکوئست های مدنظر رو در بیاریم و به آدرس ایمیل اشخاصی که ریویو میکنن ارسال کنیم.

در نهایت این ورکفلو رو پیادش کردم:
https://github.com/alireza-fa/github-actions/blob/main/.github/workflows/check_prs_and_send_email.yml

#github_action

@syntax_fa

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