Arsham's Tech Mastery

یکی از مشکلات اساسی سازمان ها (مخصوصا تو ایران)،
مدام بریده شدن زنجیره انتقال دانش هست!
و متاسفانه توجه زیادی هم به این موضوع نمیشه.

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

<--×-->

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

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

حالا چند تا چالش این وسط وجود داره:
- سازمان برای دانش به دست اومده ارزشی قائل نیست، و فقط به محصول بدست اومده از اون دانش اهمیت میده، بنابراین ظرفیت درستی به این موضوع اختصاص داده نمیشه.
- فرهنگ سازمان، انتقال دانش رو به درستی نهادینه نکرده، بنابراین نیرو های ارشد تمایلی به ارتباط در این زمینه ندارن (مگر با تمایل شخصی خودشون)
- تو ایران، چالش مهاجرت، که نیرو ها وقتی که تجربشون به حد خوبی میرسه و زمان میوه دهیشون میرسه، میرن... (حق هم دارن، نیرو ها تو ایران سازمان رو ترک نمیکنن، کل سیستم و کشور رو ترک میکنن)
و...

<--×-->

راه حل؟
- به توانایی نوشتن و انتقال دانش، به چشم یه مهارت ضروری نگاه کنیم، نه یه مهارتی که هعییی، میتونه امتیاز باشه!
این باعث میشه نیرو هامون به سمت یاد گرفتن "انتقال دانش" برن و مشتاق باشن انجامش بدن و نه تنها سازمان بهره ببره، بلکه نیرو تو کل مسیر شغلی اش از داشتن این مهارت لذت ببره! و حتی این کالچر رو به سازمان های بعدی اش هم منتقل کنه.

- به عنوان سازمان، ظرفیت کافی برای انتقال دانش در نظر بگیریم، مثل تیز کردن اره میمونه.

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

- برای حل چالش مهاجرت نیرو ها،
سازمان های بزرگ میتونن کمیته های داکیومنت نویسی با ظرفیت اختصاصی برای شفاف سازی و مکتوب کردن دانش ها و فرآیند ها داشته باشن.

نظر شما چیه؟

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

🤝 در این سری جلسات کتاب Designing Data-Intensive Applications (THE BIG IDEAS BEHIND RELIABLE, SCALABLE, AND MAINTAINABLE SYSTEMS) از نشر o'reilly را بررسی خواهیم کرد. آرشام در این پست بیشتر در مورد این کتاب توضیح داده.

🧠 در جلسات قصد هست همانطور که کتاب هم تاکید داره تبیین درستی از کلمه Data در حوزه #توسعه #نرم_افزار برای خودمون ایجاد کنیم. هر چند همین ابتدا تاکید می کنیم، این کلمه Data محدود به حوزه توسعه نرم افزار قطعا نیست.

✨در انتها یک جلمه از هم پیش گفتار کتاب اینجا بیاریم و یادآوری کنیم که یکی از اهداف از سلسه جلسات قبل یعنی بررسی #فلسفه_علم دقیقا فهم چرایی جمله زیر هست که در اونجا با #یادگیری و جداسازی #علم از #ابزار می تونیم با درک عمیق پرسش ها، #تصمیم_سازی های با کیفیت تری داشته باشه.
Software keeps changing, but the fundamental principles remain the same.

کتاب آوردم براتون قویییی 🔥✌️🏼😃
کتابی که میخوام معرفی کنم رو خودم حدود ۷۰ درصدشو خوندم، بقیشم دارم میخونم (همزمان البته با چند کتاب دیگه) و سنگین هم هست و بنابراین کند پیش میرم یکم.

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

کتاب Designing data-intensive applications نوشته آقای مارتین کلپمن (که ایشون استاد دانشگاه کمبریج هستن و از مهندس های ارشد لینکداین بودن) کتابیه که تمرکزش روی طراحی بهینه نرم افزار هاییه که مسئولیت نگهداری و جا به جایی اطلاعات رو دارن (نرم افزار های statefull، دیتابیس ها، بروکر ها و...)

مخاطب های زیادی میتونه داشته باشه، ولی برای backed engineer ها، data engineer ها، منیجر های تیم های فنی به شدت پیشنهاد میشه. (خودشم مثل اکثر کتابای خوب، تو صفحات اولش کامل توضیح داده برا چه افرادی مناسبه)

کتاب از سه بخش (part) اصلی تشکیل شده:
- foundation of data systems
- distributed data (replication, partitioning, etc.)
- derived data (streaming and batch processing)

بخش اول یه کلیتی از سیستم های اطلاعاتی میگه، و اینکه چه چیزایی تو کار کردن با نرم افزار هایی که با اطلاعات سر و کار دارن مهمه.
خب این یعنی کجا ها؟ همه جا!

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

اینجوری بگم که به عنوان یه مهندس نرم افزار، در روز به روز کارمون با دیتا درگیریم و این کتاب دید خوبی نسبت به دیتا بهمون میده.

بخش دوم میاد میگه اکثر مفاهیمی که راجع به دیتابیس ها (و فراتر البته) گفتیم، برای وقتی بود که روی یه سرور (نود) هستیم، اگه بخوایم همینو رو چندین نود داشته باشیم چه چلنج هایی خواهیم داشت و راه حلشون چیه؟
این بخش سوالات و راه حل های زیادی داره اما تازه شروع کاره، یعنی بعد مطالعه این بخش، کلی سوال دوباره تو ذهنتون ایجاد میشه، اگرچه کتاب به بهترین شکل توضیح داده، ولی خب موضوعش اساسا پیچیده است و به مطالعه و تمرین خیلی زیاد نیاز داره.
این نکته هم بگم که اگر بخش partitioning براتون پیچیده بود و اسکیپ کردید،
همچنان بخش transaction (و پارت سوم تا حد خوبی) میتونه مستقلا خونده بشه و خیلی مفید واقع بشه.

پارت سوم هم راجع به derived data (اطلاعات مشتق شده) هست و فصل هایی مثل batch processing و stream processing رو شامل میشه که به ترتیب بهشون offline و near real-time هم میگن.
این دسته از اطلاعات میشه گفت دیتای دسته اول یا source of truth ما نیستن و ما برای یوزکیس های زیادی که مطرح میشه میسازیمشون (مثلا analytics).
فصل اولش (۱۰ ام کتاب) با یه مثال از فلسفه یونیکس شروع میشه و به طور جذابی با همین مثال کوچیک میره جلو و distribute میکنه و...

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

#کتاب #معرفی_کتاب

تا حالا شده به یه مشکلی بخورید، ولی هیچ سر نخی از مشکل ندارید، بنابراین اصلا نمیدونید راجع به چی باید سرچ کنید؟ یا هر چی سرچ میکنید به نتیجه نمیرسید. (مثلا یه بار سر مموری لیک تو نود جی اس اینجوری شدم، و نمیدونستم حتی مشکلی که خوردم اسمش مموری لیک هست، مدعیان سینیوریتی هم که... باید براشون میخوندم ای به فدای چشم تو این چه نگاه کردن است!)

یا مثلا یه چیزی رو ندونید، اما ندونید چی باید سرچ کنید که یادش بگیرید؟ مثلا تو مکالمه همکارات بشنوی "p99 اش چنده؟" قبلنا که یادمه گوگل نتایج قابل قبولی برای این نمیداد، ولی ساده است، میگمش بعدا. (کلیت سوالم رو دریابید فارق از مثال)

یه حالت بدتر هم وجود داره، که مشکل خوردن، اما اصلا نمیدونن مشکل خوردن! (مثلا چندتا گوروتین اون گوشه نشستن نون و پنیرشونو میخورن به کسی هم کار ندارن (dangling goroutines))

یا میدونن مشکل خوردن اما بهش بی توجهی میکنن مثلا سرور هفته ای یه بار کرش میکنه، ری استارت میکنن و درست میشه و روز از نو روزی از نو! Availability هم که... کشک! 😂

قسمت سختش وقتیه که میخواید یه سیستم جدید دیزاین کنید،
- نمیدونید از کجا شروع کنید
- نمیدونید چه تصمیمی درست یا غلط، چون پارامتر های مقایسه اش رو نمیدونید
- یا جوانب مختلفش رو بدونید که هست اما نتونید ببینید

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

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

یا تو همین موقعیتی که هستم نواقصی رو خواهم دید که قبلا نمیدیدم (مطمئنم این اتفاقا میوفته چون چندین بار تجربش کردم)

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

داستان یه پروژه شخصی (پادکرایب)
من پروژه های شخصی زیادی دارم،
بعضیاشو دارم همچنان پیش میرم،
بعضیاشو رها کردم،
بعضیاشم هنوز شروع نکردم،
خلاصه مثل خیلی دیگه از برنامه نویسا 😅😂

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

خواستم متن پادکست هارو پیدا کنم، چیزی پیدا نشد،
یه سری ابزار هم برای ویس به متن بودن که همه پولی و پرداخت دلاری،
تا اینکه با پروژه ویسپر آشنا شدم،
اول از همه فلو رو دستی اجرا کردم،
ویسپر mp3 ساپورت نمیکرد و باید wav بهش میدادم،
پس فلو میشه این:
- کراول پادکست
- دانلودش به صورت کانکارنت
- تبدیلش به کمک ffmpeg
- بیلد و ست آپ ویسپر لوکال
- تبدیل ویس به متن

حالا نوبت چسبوندن این قطعات به هم بود،
- یه فایل باینری ffmpeg که کار تبدیل (mp3->wav) رو انجام میده،
- پروژه ویسپر که به زبان C نوشته شده و ست آپ خاص داره،
- یه سری کد گولنگی برای مدیریت برنامه و مدیریت دانلود

دوست عزیزم محمد جهانی اینجا کمکم کرد بهم گفت که اینجور پروژه ها معمولا یه چیزی دارن به اسم bindings (کلمه جدیدی بود برام)
و بایندینگ های ویسپر و ffmpeg رو پیدا کردیم (اتفاقا رو بایندینگ ffmpeg بعدا که کانتریبیوت هم زدم)

همون موقع ها بود که دوستم مبینا هم بهم پیام داد که میخواد رو یه پروژه اپن سورس کار کنه (پادکرایب رو اولش قرار بود به صورت یه ابزار cli و یه بات تلگرامی رایگان و اپن سورس ارائه بدم) و خیلی کمکم کرد (فیچر دانلودر و کراول کست باکس رو زد، یه سری ایده سر تسک ها داد و...)،

منتها بایندینگ های ویسپر خیلی مشکل داشت،
به این شکل که باید خود ویسپر رو کلون میکردیم،
و go get اش هم باید میکردیم،
و اینا version mismatch میخوردن گاهی الکی،
و باید یه ریپلیس هم تو گو مود میزدیم.

و از یه جایی به بعد هم، ایمیج ما رو پایپ لاین بیلد میشد اما دیگه روی لپتاپ من بیلد نمیشد (به خاطر ناسازگاری Apple M1)

یه ایشو باز کردم رو ویسپر و آقای josharian از خفنای اپن سورس گولنگ، با نیم خط کامنت فیکسش کرد 😁

هیچی خوب پیش نمیرفت تا اینکه گوگل اومد اعلامیه داد گوگل پادکست رو میخواد با گوگل موزیک مرج کنه 😂
ما کست باکس هم داشتیم،
کراول اپل پادکست رو البته گذاشته بودیم برا بعدا،
ولی خب بعد این خبر رفتیم رو هوا 😂

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

اما من تسلیم میشم؟
نه پیوت میکنم 😂

عوض کردم همه چیزو،
- کامند لاین کنسل (فعلا فقط بات تلگرام)
- استفاده از OpenAI API به جای ران کردن مدل توسط خودم
- اولویت دادن ترنسکرایب هر نوع صدا، نسبت به صرفا پادکست
- و برای هزینه خدمات بالا، باید فیچر های پرداخت هم بزارم.

خب الان چه کنیم؟
بکوبیم از نو بسازیم پروژه رو،
یه قسمتایی از پرداخت کریپتویی رو زدم،
و با OpenAI API هم ارتباط گرفتم،
چندتا کانتریبیوت هم این وسط زدم،
بعد تلگرام stars اومد 😂

وسطای پروژه هم یه جایی تلگرام پرمیوم فیچر تبدیل ویس به متن تبدیل ارائه داد.
و بعدشم متوجه شدم اپل پادکست خودش متن همه پادکست هارو داره.

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

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

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

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

نتورک بین پاد ها و خارج کلاستر، مدیریت کانفیگ ها، تقسیم کانتینر ها توی سرور های مختلف (#distribution)، ترمیم خودکار (auto-healing)، مدیریت منابع، اسکیل آپ و داون، و خیلی کارای دیگه... رو برای ما آسون میکنه.

قصد ندارم ریزشو تو این پست بگم، صرفا میخواستم یه کتاب معرفی کنم براش 😄

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

البته این کتاب راجع به اینترنال کوبر یا چلنج های کوبر توی اسکیل بزرگ نیست، ولی به عنوان
A beginners guide to Kubernetes
A touch on the surface of Kubernetes
و... میتونم بگم عالیه، مختصر اما مفید توضیح داده.

تقریبا فصل هاش بر اساس ریسورس ها هستن (ریسورس ها تو کوبر یه سری موجودیت ها هستن که کاربرد های مختلفی دارن، خود پاد یه ریسورسه) و ترتیب خوندن فصل ها اوایلش مهمه (فصل پاد مثلا، که همه جا اسمش هست)، اما فصل های بعدش رو تقریبا میشه مستقل هم خوند.

و از اون کتاباییه که بهتره لپتاپ هم کنارتون باشه و کوبرنتیز رو ست آپ کرده باشید، چون مثال زیاد داره. (با داکر دسکتاپ یا microK8s یا K3s به راحتی میتونید یه کوبر لوکال بالا بیارید)

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

نکته مهم 🔥: من میخوام یه پروژه کوبری اپن سورس استارت بزنم، که کار من تنها نیست، اگه تازه کار هستید خوندن این کتاب میتونه زمینه خوبی بهتون بده که بتونیم پروژه رو قوی تر روش کار کنیم. (البته که دانش فارق از هر راهی که بدست بیاد ارزشمنده، چه کتاب، چه آزمون و خطا و...)

#معرفی_کتاب #کتاب

کتاب Concurrency in Go رو خیلی وقت پیش خوندم ولی الانم نیازمند دوباره خوندنه،
کتاب کوچیکیه اما نصفش زیر زمینه 😂

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

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

بهتره قبل از خوندن کتاب، در حد مقدمات کانکارنسی رو بدونید و تمرین کرده باشید، آموزش های من برای قبلش کافیه:
https://t.me/ArshamTM/18

برای بعدش، کلی تمرین و تمرین...

در نهایت اگه میخواید کانکارنسی توی گولنگ (و گاها یکم فراتر از گولنگ) رو به خوبی یاد بگیرید این کتاب میتونه خیلی کمکتون کنه.

#معرفی_کتاب #کتاب #concurrency #go

به تازگی کتاب
A Common sense guide to Data Structures and Algorithms
رو از یکی از دوستای خوبم هدیه گرفتم و خوندم.

کتاب خیلی خوبیه، خیلی روان و با شکل و مثال، دیتااستراکچر هایی مثل
Arrays, Hash maps, Stack, Queue, Linked list, Tree, BST, Heap, Graph, etc.
و الگوریتم های مختلف و معروف جستجو،
و نحوه بدست آوردن و مقایسه پیچیدگی زمانی و پیچیدگی حافظه رو توضیح داده، و تکنیک هایی برای بهینه کردن الگوریتم ها گفته.

همچنین چند فصلش هم به recursion اختصاص داده و به خوبی توضیحشون داده.

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

زبان انگلیسی کتابش هم زیاد پیچیده نیست، پس اگه زبانتون زیاد خوب نیست هم به نظرم زیاد نگران این موضوع نباشید.

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

#معرفی_کتاب #کتاب #datastructure_and_algorithms

آدام گرنت (adam grant) رو احتمالا خیلی هاتون به خاطر کتاب معروفش به اسم "دوباره فکر کن" (think again) بشناسید،

توی این ویدئو فوق العاده، راجع به آدمایی که دانششون رو به اشتراک میزارن (givers) در مقابل آدمایی که فقط دنبال منفعت خودشونن (takers) صحبت میکنه.

ویدئو فوق العاده ایه و چقدر قشنگ حرف دلمو زد
https://www.youtube.com/watch?v=YyXRYgjQXX0

دیدگاه شخص خودم از giver بودن حال خوب همون لحظه اش هست، و ارتباط گرفتن با آدما،

اضافه کنم که من اعتقادی هم به چیزای متافیزیکی مثل قانون جذب و... ندارم، ولی معتقدم تاثیر کمک ما خیلی طبیعی تر از این حرفا به خودمون برمیگرده،

من اگه به دو نفر کمک کنم و اونام به دو نفر و...
در نهایت یه تاثیر نمایی رو کل جامعه (که جامعه میتونه یه دانشگاه، یه شرکت، یه کشور یا... باشه) میزاره، جامعه ای که من هم دارم توش زندگی میکنم، و بار ها این تاثیر مثبت و لذت بخش رو به چشم دیدم.

<<------>>

راجع به takers، چند ماه پیش یه پست تقریبا مرتبط براتون نوشته بودم با تایتل "مایندست جویندگان طلا!"
که متاسفانه کلی نوشتم ولی نتونستم ببندمش 😂

خلاصه اش این بود که علم مثل طلا نیست که فقط یه مقدار محدودی ازش باشه و سر مالکیتش دعوا کنیم،
علم یه ویژگی شگفت انگیز داره و اون کپی شدنه!
و جالب تر اینکه هر چقدر بیشتر کپی بشه اتفاقا ارزشمند تر هم میشه! شاید بشه یه سری علوم انحصاری خاص رو تو این تعریف نیوورد، نمیدونم، ولی مطمئنم درصد خیلی بالایی از خساست های علمی بی مورده و صرفا از روی حس های منفی دیگست (مثل حسد یا ترس) که دیگه میره تو چارچوب روانشناسی و کار من نیست 😄

به به! خیلی وقت بود منتظر این مستند بودم (هانی پات کلا مستند های خوبی میسازه و یکی دو ماه پیش اطلاع داده بود میخواد اینو بسازه)
تازه از تنور در اومده 🔥
راجع به نود جی اس هست:
https://www.youtube.com/watch?v=LB8KwiiUGy0
------
همچنین حالا که صحبتش شد پیشنهاد میکنم مستند revolution os هم حتما ببینید، فوق العاده جذابه، راجع به لینوکس + اپن سورس هست و ریچارد استالمن عزیز و بقیه دوستان توش صحبت میکنن.
------
مستند و فیلم خوب (در این حوزه) داشتید معرفی کنید تو کامنت. 🙌🏼

منابع رایج یادگیریمون:
یوتیوب، استک آورفلو، مدیوم و بلاگ های مشابه، یودمی و بقیه کورس ها، داکیومنت های رسمی.
همچین:
کتاب و پادکست
<<----->>

ولی یه سری منبع هم هستن که فوق العاده اند اما شاید از چشمتون مخفی مونده باشن از جمله:
- تِک بلاگ (Tech Blog) های پروژه های بزرگ، مثلا بلاگ گیتهاب و داکر خیلی فعالن، یا بخش case studies ها توی سایت رسمی گولنگ، هزاران تا تک بلاگ هست که پروژه های واقعی داستان های شگفت انگیزشون رو تعریف کردن.
اینجا هم یه لیست خوب ازشون گذاشتن:
https://github.com/kilimchoi/engineering-blogs

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

- ریلیز نوت ها: پر از کلید واژه های مختلف و جذاب برای آنبورد شدن روی قابلیت های پروژه و آشنایی بیشتر با مفاهیم استفاده شده در اون.

- ایشو ها: مفصله، بعدا توضیح میدم.

- مقالات تخصصی
مقالاتی مثل این
https://dl.acm.org/doi/pdf/10.1145/3593856.3595909
یا مثلا وایت پیپر پروژه ها کلا تو یه لول دیگه اند ولی به عنوان مهندس باید از این مقالات بخونیم.
و البته مقالات تخصصی تر و آکادمیک تر که در چارچوب این پست نمیگنجه.

<<----->>
بازم مثل همیشه، مشتاق شنیدن انتقادات و نکات خوبی که بلدید هستیم. 🙌🏼🔥

داشتم readme پکیج httpexpect رو میخوندم (این پکیج برای HTTP and REST API E2E testing استفاده میشه. (همش اسمه نمیشه ترجمش کرد 😅️️️️️️)

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

پکیج اش رو دیدم و اولین خط readme نوشته شده بود:
This was mostly an experiment to learn go and test using closures to interpret a JSON path. You should use https://github.com/PaesslerAG/jsonpath instead.

آخ جون فرصت کانتریبیوت!

ولی صبر کن، اول بریم پول ریکوئست هارو بخونیم ببینیم کسی قبلا انجامش نداده؟
خود کلمه jsonpath رو سرچ کردم و به این پول ریکوئست رسیدم:
https://github.com/gavv/httpexpect/pull/49

تحلیل هایی که ویکتور در جواب به این پول ریکوئست داشته رو خیلی دوست داشتم، مثلا این:
https://github.com/gavv/httpexpect/pull/49#issuecomment-408675078


و بعدش هم بلافاصله رفته سه تا ایشو روی پکیج اولی باز کرده...

ایشو ها رو پکیج اولی فیکس شدن اما رو دومی نه و ویکتور دلیلی نمیبینه این تغییر رو انجام بده، اما گفته که استقبال میکنه از کسی که تغییر بده،
مکالمه مال پنج سال پیشه، بریم ببینیم پکیج دومی درست شده؟

یه پروژه تستی میسازیم و هر دو پروژه رو امتحان میکنیم (فکر کنم لازم به توضیح نباشه که این پروژه تستی قرار نیست زیاد زنده باشه! همچنین قرار نیست بزرگ یا تمیز باشه، کد اش رو میزارم کامنت)

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

برای من راستش صرفه نداشت از این بیشتر پیش برم، ولی مسیری که رفتم نکته های آموزشی داشت که حیفیم اومد شیر نکنم.

اومدم پا لپتاپ یهو دیدم یه موش خرمای خوشگل آبی رو لپتامه 😂 خواهرم برام عروسک گوفر درست کرده بود 😍😂

<<----->>
اگه کسی دوست داشت از این گوفر های خوشگل داشته باشه میتونه بهم پیام بده یا از غرفه با سلام خواهرم بخره. ✌️🏼

https://basalam.com/shikopik576/product/856329

قبل اسنپ با یه شرکت خارجی خوبی مصاحبه داشتم، ولی متاسفانه به دلیل نداشتن تجربه کافی #observability و ابزار هاش رد شدم، بنابراین این پست رو براتون نوشتم که شما رد نشید 😁
<<----->>
به طور کلی ما سه تا پارامتر مهم تو این بحث داریم،
- لاگ (Log)
- متریک (Metric)
- تریس (Trace)

راجع‌ به لاگ قبلا یه صحبت هایی شده مخصوصا تو گروه گپمون با آقای حکایتی، هرچند که کافی نبوده و خیلی جا بحث داره هنوز.
<<----->>
الان میخوام یه نکته راجع به metric یادم افتاد بهتون بگم.
ما دو دسته اصلی از متریک ها داریم:
- متریک های بیزنسی
- متریک های نرم افزاری

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

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

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

برای خود تیم فنی هم کاربرد داره، مثلا اگه هر کدوم از این متریک ها یهو دچار افت شدید بشه، احتمالا باید یه اکشن تکنیکال داشته باشیم.

یه دسته دیگه هم که متریک های تکنیکال بود،
مثلا مصرف رم و CPU،
تعداد درخواست در ثانیه،
ریسپانس تایم،
تعداد درخواست ها با ریسپانس 4xx یا 5xx،
مثلا اگه 5xx هامون از یه حدی بیشتر بشه، قطعا مشکلی وجود داره.
تو بعضی موارد مثلا تعداد کانکشن های وب سوکت،
یا اگه اپلیکشن گولنگی بود تعداد گوروتین ها (برای مطمئن شدن از نبود گوروتین لیک)
و...
<<----->>
اینکه هر ابزار چطور این متریک هارو اندازه گیری میکنه وابسته به ابزارش متفاوته، ابزار های زیادی هم هستن (مثلا پرمتئوس، سیگنوز و...) که راستش هدف من نیست و مقاله و آموزش خوب براشون زیاد هست، ولی مفهومی همین مسئله رو بیشتر بررسی خواهیم کرد.

<<----->>
خوشحال میشم نظراتتون رو راجع به متریک برام کامنت کنید، کجاها استفاده کردید؟ و...

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

برا خیلیامون به عنوان مهندس نرم افزار، احتمالا پیش اومده که شخصی "آرزو داره" که مالک بیزنسی باشه، بیزنسی که به واسطه سالها تجربه و تلاش کلی آدم و سرمایه و شانس! و... شده "بیزنس"
مثالش میشه همون درخواست اپلیکیشن اسنپ با پنج میلیون که تو پونیشا میبینیم.

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

چی داری؟ آرزوی پول دار شدن به واسطه آشنایی با شمای مهندس نرم افزار!

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

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

منم رویاها و ایده های خودمو دارم، و دارم براشون تلاش میکنم (نتورک، مطالعه، پس انداز و...).
یه سری کامنت و منبع هم بعدا زیر این پست میزارم.✌️

میخوایم یه سیستم طراحی کنیم،
حله، بزن بریم یه دو سه تا کلاستر کافکا بزاریم و هفت هشت تا سرویس و خلاصه دیزاین سیستم رو دراریم!!!!
داداش کجا با این عجله وایسا با هم بریم 😅

<<----->>

یکی از پادکست هایی که دنبال میکنم پادکست gotime هست (فوق العادست)، که یکی از اپیزود های اخیرش راجع به کافکا بود، و یکی از مدیرای کلاودفلر (Matthew Boyle) که چندسالی هست داره با کافکا کار میکنه (ایشون همچنین نویسنده کتاب ddd in go هم هستن) راجع به یه سری سوالات صحبت میکنه، مثلا
کافکا چه مشکلاتی رو حل میکنه؟
چرا انداختن یه تکنولوژی مثل کافکا وسط مشکلات نمیتونه همه چی رو درست کنه؟
پیچیدگی های کافکا و...

<<----->>
تو این پست بیشتر از این چیزی نمیگم، مت همه چیزو گفته،
ولی راجع به پادکستش،
پادکست رو به کمک یکی از پروژه هاییم که فعلا تو وضعیت "probably failed" هست دانلود و متنش رو استخراج کردم و براتون گذاشتم تو کامنت.

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

امیدوارم این پروژه من هم درست بشه بیشتر براتون پادکست بزارم. 😅
<<----->>
https://podcasts.google.com/feed/aHR0cHM6Ly9jaGFuZ2Vsb2cuY29tL2dvdGltZS9mZWVk/episode/Y2hhbmdlbG9nLmNvbS8yLzIyOTY

اولین بار که اسم پترن circuit breaker توی مایکروسرویس رو شنیدم، فکر کردم اووو چه اسم خفنی! بعد دیدم عه، همون فیوز خودمونه 😄 (البته درستش کلید مینیاتوری هست، که با فیوز اشتباه گرفته میشه)

از اونجایی که این کلمه رو از دنیای الکترونیک قرض گرفتن، من هم اول یه خلاصه ای از کارکردش تو دنیای الکترونیک ارائه میدم.

فیوز وسیله ایه که وقتی جریانات برق ناسالمه، مدار رو قطع میکنه که به وسایل الکتریکی آسیب نرسه، بنابراین ما برای مدار دو حالت داریم
- بسته: وقتی که همه چی رو به راهه
- باز: وقتی که مدار قطعه

نکته: توی این بحث، کلمه trip معنی پریدن (قطع شدن) فیوز رو میده.

<<----->>
حالا این پترن چه کاربردی توی مایکروسرویس داره؟

فکر کنید شما یه کلاینت دارید، یه api gateway که بهش میگیم سرویس الف و یه سرویس که توسط gateway کال میشه و بهش میگیم سرویس ب

حالا اگه سرویس ب کند باشه یا بعد ۶۰ ثانیه تایم آوت بده یا سری مشکلات از این قبیل، سرویس الف هم با همین تاخیر ها جواب کاربر رو میده و کاربر تجربه بدی خواهد داشت،

شما خودتون رو به عنوان کاربر تصور کنید،
دیر جواب نگرفتن بهتره یا زود جواب نگرفتن؟ (داریم راجع به سناریویی حرف میزنیم که در هر صورت جواب نمیگیریم)

این پترن دقیقا اینجا به کار میاد (البته کاربرد های دیگه هم داره)

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

<<----->>
برای پیاده سازی این پترن توی زبان های مختلف پکیج هست و به سادگی میتونید پیداشون کنید.
برای گولنگ این پکیج هست:
https://github.com/rubyist/circuitbreaker

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

برای خوندن کدش میتونید از فایل circuitbreaker.go شروع کنید و از توابع NewXxxBreaker
در واقع انواع مختلفی از فیوز داریم و تفاوتشون هم تو نحوه قطع شدن و دوباره وصل شدنشونه،
البته میتونید هم توابع قطع و وصل رو از بیرون بنابر شرایط دلخواه خودتون صدا بزنید.

<<----->>
خیلی خلاصه کردم مطلب رو، اگر حس میکنید جایی نیاز بهبود داره یا خواستید از کاربرد هاش تو پروژه های خودتون بگید خوشحال میشم برامون کامنت بزارید.

یه سایت خفنی پیدا کردم، ایده اش واقعااا جذاب بود،
https://console.algora.io/home/projects

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

کانال یوتیوبشون هم دوست داشتم، تقریبا همون چیزیه که این کانال رو به خاطرش زدم، بررسی کد پروژه های اپن سورس (با چند تا از دوستان هم جلساتی رفتیم، ولی پابلیک نبوده، پابلیک هم تولید خواهیم کرد)

ظاهرا پلتفرمش تازه تاسیسه ولی به نظرم معروف میشه.

لینک ایشو بانتی هاشم گذاشتم تو کامنت

🔗 با همفکری و همراهی چند تن از دوستان جلساتی در باب تبیین چرایی اهمیت یادگیری #فلسفه_علم برای هر #اندیشمند و #خردمند ی ترتیب دادیم. جلسات مطابق معمول در سرور دیسکورد (زمان جلسات در بخش ایونت های سرور مشخص می باشد) برگزار میشه. در کامنت های همین پست، در صورت صلاحدید و اجازه دوستان در جلسه صوت جلسات را قرار میدم.
🤝 در این جلسات با انتخاب جمعی، کتاب فلسفه علم از سمیر اکاشا را هم بررسی خواهیم کرد.
🧠 در جلسات پاسخ خواهیم داد که چرا یادگیری فلسفه علم محدود به هیچ فرد خاصی نمیشه و هر #دانش_مند ی باید حداقل های این علم بین رشته ای را یاد بگیره تا بتونه #تصمیم_سازی های با کیفیت تری داشته باشه.