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

سلوشنت چیه؟ 😁

چرا شرکت‌های بزرگ از Object Storage استفاده می‌کنند؟ (در 14 دقیقه)

در این ویدیو به زبون ساده توضیح میدم چرا Object Storageهایی مثل S3 و MinIO ساخته شدن و چطور شرکت‌های بزرگی مثل دیجی‌کالا، اسنپ و آمازون ازش استفاده می‌کنن.
اگر تا حالا برات سوال بوده S3 دقیقا چیه یا چطور MinIO باهاش سازگاره، این ویدیو رو ببین.

00:00 مشکل چی‌بود ObjectStorage خلق شد
04:32 نحوه ارتباط سرویس ها روی Diagram
06:20 کاربرد AWS S3 یا MinIO بیشتر است؟
07:14 ارسال یک آبجکت به AWS S3
10:39 سازگاری MinIO با S3
13:23 معرفی SDK اختصاصی MinIO

برای مشاهده ویدیو بیاید یوتیوب 🤫
پلی لیست: Cloud & Architecture Series
مدت زمان ویدیو: 14 دقیقه

مسیر طولانی با یه قدم شروع میشه. روز خوبی داشته باشید 🫂

خوبین بچها؟ کسیو از دست ندادین؟ 😢

رفقای عزیزم نوروز مبارکتون باشه 🖤

#ابزار | Jwtkit؛ جایگزین داخلی و سبک jwt.io

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

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

✅ ویژگی‌ها:
🔹 سرعت بالا و بسیار سبک
🔹 دسترسی در شرایط iran access
🔹 کاملاً رایگان و متن‌باز

🌐 مشاهده سایت:
🔗 https://jwtkit.ir

⭐️ حمایت از پروژه در گیت‌هاب:
(با استار دادن به این ریپازیتوری از توسعه‌دهنده حمایت کنید)
🔗 https://github.com/mhshahmoradi/Jwtkit

روایت شبی که ماه کامل شد 🌝
امروز می‌خوام باهاتون درباره یک حقیقت تلخ… یا شاید شیرین حرف بزنم.

من حدود ۳–۴ ماهه که تقریباً تمام تسک‌هام رو با Vibe Coding جلو می‌برم؛
به زبان ساده‌تر: تو این مدت حتی یک خط کد دستی هم ننوشتم.

و راستش بخوام صادق باشم، برای دوستانی که هنوز کاملاً سنتی کد می‌زنن یا فکر می‌کنن «AI هنوز خیلی چیزها رو نمی‌فهمه»، واقعاً نگرانم چون از نظر من امسال سال تعدیل اونهایی هست که سنتی کد می‌زنن، چون ندانستن علم اینکه چطوری یک چیز رو به AI یاد بدن رو دارن به پای نفهمی AI میزنن.
تعدیل خواهیم شد نه چون‌که ما ضعیف هستیم، اتفاقاً شاید خیلی هم حرفه‌ای باشیم، بلکه چون AI ارزون‌تره، سریع‌تره، کمتر توقع داره و کمتر هم غر می‌زنه ممکنه تعدیل بشیم!!.

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

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

ولی من یه نگاه دیگه دارم:
اگر واقعاً بفهمیم AI بزرگ‌ترین ابزار کنارمونه، برای وصل شدن بهش راه پیدا می‌کنیم
فهمیدن یعنی زیستن من (شما) با AI هست بدون اون نمیتونم زندگی کنم مثل نبودن آب!! اگر آب نباشه چیکار می‌کنید؟
برای من نبود AI هم همین بود؛ پس نداشتن اینترنت تقریباً مساوی بود با نداشتن کار پس من باید اینترنت می‌داشتم، تاکید می‌کنم باید.

همین باعث شد توی روزهای قطعی هم، با روش‌هایی که خیلی‌هاش پابلیک بود، با AI کار کردم و خروجی گرفتم.
این خروجی اتفاقا بزرگ ترین خروجی من بود 🤯.

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

حالا تصور کنید ۵ نیروی سنیور، هر کدوم با حقوق ماهانه n میلیون تومان می‌شه 5n میلیون تومان،
اون هم برای کاری که استیمیتش ۲ تا ۳ ماه بود و معلوم نبود قطعاً جواب بده یا نه.

اینجا بود که من دانش مهندسی نرم‌افزار رو با AI و تجربه تیم فرانت ترکیب کردم…
و فقط تو ۱۲ ساعت پرفورمنس رو زیر و رو کردیم.
یادم نمی‌ره ۵ صبح به بچها پیام دادم: «امشب کولاک کردم!»
نسخه اولیه حدود ۲۵۰ فایل کلیدی رو تغییر داده بود و در نهایت با 350 تا چنج بردیمش بالا.
با EM و VP و مدیران ارشد تست کردیم، همه واقعاً شگفت‌زده بودیم.
هرکسی نتیجه رو می‌دید، می‌گفت: «با اپ دقیقاً چی کار کردید؟!»

کاری که شاید نزدیک ۱ میلیارد تومان هزینه برمی‌داشت،
با ترکیب من و فقط ۴۰ دلار اشتراک Copilot Pro حل شد.

دنیا عوض شده رفقا.
به‌نظرم وقتشه کت «Front-end Developer» یا «Back-end Developer» یا هر عنوان محدود دیگه‌ای رو کنار بذاریم و کت «مهندس نرم‌افزار» رو بپوشیم یاد بگیرین مهندس نرم افزار باشید نه کد نویس.
چون در نهایت، کسی می‌مونه که بتونه مسئله حل کنه، با هر ابزاری که ارزون تره و دقت بالاتری داره.

شاید نظرم نامحبوب باشه، ولی فکر می‌کنم خیلی از نقش‌ها در شکل فعلی‌شون دیر یا زود حذف می‌شن.
من از AI با یک پرامپت که اولش می‌نوشتم "به عنوان یک QA ..." به عنوان یک "پروداکت منیجر ..." به عنوان یک "سنیور فرانت اند دولوپر ..."
هر خروجی می‌خوام رو میتونم بگیرم پس من همه ام؟ 🤷🏻‍♂️

جالبه بدونید من تو این ۳ ماه حتی یک ریال هم برای Copilot ندادم
و نسخه اولیه رو با Copilot for Student بالا آوردم در حالی که دانشجو هم نبودم! بله چون زیستن من با AI هست من هر راهی رو پیدا می‌کنم.

من واقعاً مشتاقم توی این مسیر کنارتون باشم و مشاوره بدم.
هدف این کانال از روز اول این بوده:
کمک کنم «سنیور واقعی» بشید.
توی توضیحات کانالم هست.

و به‌نظرم این هم بخشی از مسیر سنیوریتیه. و به زودی عوض می‌کنم به "کمک می‌کنم مهندس نرم افزار باشید"

پیروز و سلامت باشید ❤️
حسن عرب‌برزو

خیلی‌ها سوال کردن چطوری GitHub for Student رو تهیه کنیم؟
قبلاً هرکی حوصله نداشت سریع reply می‌زد:

Before asking a question, search first

خداروشکر دوران اون جمله تقریباً تموم شده 😁
الانم خیلی کار نمی‌کنه، چون دیگه کسی سرچ نمی‌کنه… همه Prompt می‌دن! جمله جدیدی اگه داره من بلد نیستم هنوز.

بین جواب دادن به سوال‌هاتون، از ته انباری ذهنم یادم اومد اون زمانی که ویرگول بین کامیونیتی برنامه‌نویسی ایران خیلی ترند بود، منم دستی به آتش داشتم و دوتا مقاله خوب نوشتم؛ که یکیش دقیقاً همین موضوع بود:
چطوری GitHub for Student بگیریم؟
اون زمان مثل الان نبود؛
اگر جزو مشتری‌های اولیه Copilot بوده باشید، یادتونه تبلیغش این بود که داخل کدت فقط یک کامنت بنویس که قراره زیرش چه اتفاقی بیفته، بعد Copilot خودش ادامه‌اش رو کامل می‌کرد 🤯
مثلاً:

// send a message to telegram channel with bot token

فقط Enter می‌زدی، شروع می‌کرد کد تولید کردن! الان اسمش شده Inline Suggestion
اون زمان هنوز کسی نمی‌دونست اسم این کار چیه؛ الان براش اسم پیدا شده: Prompt 🙂‍↔️
من هر بار اینو برای کسی تعریف می‌کردم باورش نمی‌شد، و وقتی فعالش کردم واقعاً ذوق داشتم 😚

یه جورایی اون زمان مایکروسافت MVP خودش رو، رو کرده بود؛ ولی به‌نظر من Time to Market رو از دست داد و OpenAI اومد و مثل بمب ترکید.
درصورتی‌که مایکروسافت خیلی جلوتر بود و بازار رو از دست داد. البته همون‌طور که مشخصه، توی بحث کدنویسی Copilot هنوزم خیلی حرف برای گفتن داره؛ هرچند OpenAI فعلاً با ChatGPT خیلی خوب عمل کرده.
از عقاید و سلیقه‌های من که بگذریم، می‌رسیم به پستی که ۴ سال پیش توی ویرگول گذاشته بودم.
اگر دانشجو هستید که عالیه؛ اگر نیستید، یه دانشجو پیدا کنید و این ابزار خفن رو تو جیبتون داشته باشید 😄
https://vrgl.ir/Id1UR

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

خواهیم دید چه خواهد شد...
پیروز و سلامت باشید ❤️
حسن عرب‌برزو

یکی یه LLM Gateway درست کرده که باهاش میتونید به پلن‌های رایگان ۱۴ تا سرویس مختلف وصل بشید و در مجموع ۱ میلیارد توکن در ماه بگیرید!

خوبیش اینه که خروجی OpenAI-compatible میده با قابلیت fail-over که اگه یکی از providerها جواب نداد اتوماتیک سوییچ بشه رو بعدی و...

طبق انتظار opensource و self-hosted هست و تنها زحمتش ساخت اکانت برای هر کدوم از این سرویس‌هاست! بعضی‌هاشون هم مثل CloudFlare و... کردیت کارت میخواد! امیدوارم به کارتون بیاد :)

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

[ SOURCE X ] | [ Github freellmapi ] | 3.3K ⭐️

بعضیا میگن AI کداش خوب نیست خوب کد نمیزنه، راستم میگن چون AI روی کد انسانها ترین شده نه کد آدم فضایی‌ها. 😁

باید درباره چندتا موضوع دیگه هم صحبت کنیم

۱. حالا که AI هست چطوری کد ریویو کنیم؟
۲. بعد از مرحله همیشه وایب کدینگ کردن، AI خوابمم بهم ریخته هفته ای ۲-۳ شب تا صبح بیدارم باید براتون بگم …

کلادفلرم آزاد شده دیگه همه هستین خوش برگشتید ❤️

من به‌عنوان یک مهندس نرم‌افزار، در دنیای AIها چطور باید کد را ریویو کنم؟
راستش من اصلاً کد را به آن شکلِ مرسوم ریویو نمی‌کنم 🤠

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

سؤال جالبی است؛ الان خودم هم وقتی دارم این را می‌نویسم، این سؤال در ذهنم می‌آید که:
«پس دقیقاً چه چیزی را ریویو می‌کنم؟»

قبل از شروع، خیلی‌ها را دیده‌ام که موقع ریویو کد می‌گویند:
1. براش چند تا کامنت توپ گذاشتم، بره با برف سال بعد بیاد پایین.
2. کدش اصلاً به درد نمی‌خوره، پرفورمنسش خوب نیست.
3. کدش با فرمت پروژه‌ی ما خیلی سینک نیست، باید بره ریفکتور کنه.
4. حاجی، این اصلاً DDD بلد نیست!

دوستای عزیزم، دنبال «قاتل بروس‌لی» هستید وقتی کد یک نفر را ریویو می‌کنید؟ 😅

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

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

قانون اول
من به‌عنوان ریویور باید تست را ریویو کنم!
اصلاً مهم نیست تغییرات داخل پروژه دقیقاً چه هستند؛ مهم این است که آیا به‌اندازه‌ی کافی تست دارند؟
آیا چیزی که می‌خواهیم به محصول اضافه کنیم، همه‌ی حالت‌هایش تست دارد؟ اگر نه، از نظر من Approve نیست.
چیزی که تست ندارد، امروز شما می‌دانید چیست؛
اما وقتی از شرکت بروید یا چند ماه بعد دوباره به همان کد برگردید، فقط خدا می‌داند چیست!
این تفکرِ «من آچارفرانسه‌ام و هیچ‌کس نباید بیزینس بخش من را بفهمد» را هم از ذهنتان دور کنید.
دورانی که دانش را انحصاری نگه می‌داشتیم گذشته است. AI روی کد شما آنبورد می‌شود و شرکت فقط به یک AI Engineer نیاز دارد که بتواند آن را هدایت کند.
پس فضا را برای بقیه باز کنید، دانشتان را قابل‌انتقال کنید و اجازه بدهید سیستم بدون وابستگی به افراد رشد کند.
شل کن مهندس 🌚

قانون دوم
فرقی نمی‌کند Tech Lead هستم، EM هستم، یا هر چیز دیگری.
کد ریویو باید یک فرهنگ درونی باشد. هر چه هم که هستم، نباید بدون ریویوی شخص دیگری، کدم را مستقیم ببرم پروداکشن.
وقتی وارد این فضا شوید، باید مطمئن باشید فردی که با او کار می‌کنید حتی اگر junior باشد، وقت می‌گذارد و ریویو می‌کند. این داستانِ رئیس‌بازی‌ها را از ذهنتان دور کنید.
سنیوری که یک‌درمیان پابلیش‌هایش incident می‌خورد، به‌نظر من اصلاً سنیور نیست! چون هنوز مفهوم تیم را احتمالا به درستی نمی‌داند.

قانون سوم
پرفورمنس، اگر بیزینس را تحت‌تأثیر قرار دهد، مهم است!
زمانی که کد را می‌خوانید، ممکن است با کوئری‌هایی مواجه شوید یا جاهایی که به هر دلیلی از نظر پرفورمنسی مشکل دارند.
برای اینکه بتوانید یک مرز دقیق بین micro-optimization و optimization بکشید، همیشه این‌طور فکر کنید:
«اگر این برود بالا، آیا باعث می‌شود سرویس موردنظر حدود ۱۰۰ تا ۲۰۰ میلی‌ثانیه کندتر شود؟»
برای خودتان و برای بیزینسی که دارید، معیار و مرزی بین micro-optimization و optimization تعیین کنید تا به‌خاطر چیزهای جزئی بی‌جهت گیر ندهید و بحث الکی درست نشود.
وقتی مسئله‌ی شما با کد کسی بیزینسی باشد نه شخصی، احتمالاً او هم بهتر درک می‌کند.

قانون چهارم
مطلقاً هیچ باگی بدون تست نباید منتشر شود!
یعنی اگر به هر دلیلی اجازه دادید بعضی تغییرات بدون تست منتشر شوند، اشکالی ندارد...
اما باگ بدون تست که تضمین نمی‌کند دیگر تکرار نشود، مطلقاً نباید approve شود.

و قانون آخر
یادتان باشد بالاخره یک روزی AI کد را می‌زند؛ مهم این است که ما بتوانیم با هم کار کنیم. و امیدوارم آنجا حسرت این همه گیر های الکی و سفت و سخت خودتان را نخورید.

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

حالا سؤال پیش می‌آید: چطور تست بنویسیم؟ باید در پست دیگری درباره‌اش صحبت کنیم.
من قبلا یک ویدیو درباره تست نویسی داشتم که ساختار درستش رو گفته بودم ولی بیشتر باید درباره اینکه با AI چطور تست بنویسیم صحبت کنیم.
ویدیو کد نویسی | پلی لیست تست

دوست داشتم تا اینجا که اومدید چهار نکته روهم بهتون بگم:
نکته اول
به‌عنوان یک contributor یادتان باشد باید این فرهنگ را داشته باشید که ساختار پروژه‌ی کسی را به‌هم نزنید.
جدا از اینکه آن فرد می‌خواهد با شما کار کند و همکاری مؤثری داشته باشد، تغییر فرمت کد یا تغییر ساختار پروژه‌ها زیاد مطلوب نیست؛ چون ممکن است حتی ریویو کد را سخت کند حتی اگر از بنیاین پروژه اشتباه نوشته شده جای درست شدنش در MR/PR شما نیست.
من تا جای ممکن سعی می‌کنم این مورد را نادیده بگیرم یا این فرهنگ را به contributorها یاد بدهم تا وارد چالش با آن‌ها نشوم.

نکته دوم
یادتان باشد از نظر من زیاد کامنت گذاشتن برای کسی، بیشتر ضعف و عقده‌های شما را نشان می‌دهد.
یک ریویوی خوب، اگر مشکلات زیادی داشته باشد، وارد مرحله‌ی تعامل حضوری یا جلسه می‌شود 🤷🏻‍♂️

نکته سوم
اگر شما معمولاً contributor هستید، سعی کنید این فرهنگ را به ریویوکننده‌های خودتان منتقل کنید؛ شاید آن‌ها هم رشد کردند. 😊

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

ارادتمند
حسن عرب‌برزو

هم‌اکنون Copilot با قیمت‌گذاری جدیدش قلبم رو شکست 💔

بعد از فقط یک روز استفاده از Copilot Pro Plus، تقریباً ۴۰٪ از سهمیه‌ام مصرف شد.

دیگه به درد نمی‌خوره این دنیا...
شما چه اشتراکی دارید؟