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

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

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

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

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

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

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

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

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

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

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

داشتم 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 ها میمونید تا نظرشون رو راجع به این تغییر بگن.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<<------>>

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

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

به تازگی کتاب
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

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

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

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

بهتره قبل از خوندن کتاب، در حد مقدمات کانکارنسی رو بدونید و تمرین کرده باشید، آموزش های من برای قبلش کافیه:
https://news.1rj.ru/str/ArshamTM/18

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

کتاب 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 میکنه و...

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

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

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

🤝 در این سری جلسات کتاب 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.

The devil is in the details
شیطان در جزئیات خفته

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

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

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

|-×-×-×-|

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

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

ولی خودمونیما، چه دلیلی وجود داره که کد فرمت نشه؟
اونم با وجود کلی ابزار برای اتومات شدن این فرآیند؟
چیزی جز مایندست "بزن بره"؟
و چه تضمینی هست کسی که رو فرمت کردن کدش تنبلی کرده، بقیه جاها مثل ساعت کوارتز، دقیق باشه؟

|-×-×-×-|

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

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

دیر رسیدن، بهتر از رو پروداکشن ترکیدن!

|-×-×-×-|

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

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

|-×-×-×-|

از این موارد و عدم توجه به جزئیاتی که باعث فاجعه شدن زیاد توی تاریخ دنیای نرم افزار وجود داره،
ولی مایندست "بزن بره" هم همچنان به قوت خودش باقیه 🔥😂

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

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

|-×-×-×-|

نظر شما چیه؟ چه مثال ها و نکاتی رو دوست دارید در مورد مطالب گفته شده مطرح کنید؟

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

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

<--×-->

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

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

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

<--×-->

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

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

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

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

نظر شما چیه؟

چشامو بستم و باز کردم، دیدم دو ساله که تو اسنپم...
<<--×-->>
بعد از بیرون اومدن از شرکت قبلی،
به تنها چیزی که فکر میکردم مهاجرت بود،
اون موقع با حمایت شما کانکشن های عزیزم شرکتای زیادی بهم پیام دادن، ولی خب چون هدفم مهاجرت بود، همه ایرانی هاش رو ریجکت کردم... به جز اسنپ.

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

سه تا نکتشو یادمه:
اول که خیلی خودمونی شروع کرد و یخ من آدم خجالتی رو شکوند،

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

و سوم رو توضیحات من راجع به پروژه هام خیلی فلسفی شد، جوری که من مطالعه راجع به "هنر پرسشگری و تفکر نقادانه" رو تو برنامه هام گذاشتم و همینم خیلی تو مسیر شغلیم کمکم کرد.
<<--×-->>
نهایتا موفق شدم و وارد شدم،
خیلی خوشحالم که این اتفاق برام افتاد،
کسایی که از نزدیک یا از پست هام منو میشناسن میدونن که چقدر تو زندگیم تلاش کردم، له شدم، مچاله شدم، اما هیچوقت تسلیم نشدم، تا نهایتا به نقطه ای رسیدم که میگم "آها، این همون نقطه شروعیه که لایقش بودم".

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

از چیزای خوبی که تو اسنپ دیدم باید پست های زیادی بزارم که بقیه سازمان ها یاد بگیرن، یاد بگیرن که "توجه به نیرو ها، هزینه نیست، سرمایه گذاریه!"، دقیقا کاری که اسنپ میکنه و رشدش رو هم مدیون همینه.

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

ممبر جدید زیاد داشتیم،
که ممکنه از وجود این دوره آگاه نباشن،
خوشحال میشم این دوره بتونه به خودتون یا دوستاتون کمک کنه.
هر کی استفاده کرده و راضی بوده معرفی کنه به بقیه 🙌🏼
دمتون گرم. ❤️

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

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

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

ولی خب، تو یه سری مدل تست ها مثل e2e و load test هم مجددا سناریو رو میدونیم، با اینحال ممکنه قسمتی از فلو (flow)، مطابق انتظار پیش نره، لود تست که کلا داستان خاص خودشو داره،
ولی تو e2e هم مجددا اگه ایراد پیش‌بینی نشده ای پیدا بشه، احتمالا در نقاط اتصال هست، و e2e هم تو پیدا کردن باگ لاجیکی غیرمنتظره، کمکی به ما نمیکنه.

<--×-->

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

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

<--×-->

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

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

<--×-->

از خوبی های جانبی تست هم میشه به "مثال بودن" اش اشاره کرد. با فرض دنیای ایده آل، خوندن تست های یه پروژه خیلی ساده تر از خوندن کد خود پروژست، و از رو تست هاش میشه به سادگی فهمید که چیکار میکنه و ورودی و خروجی مورد انتظار سیستم چی هست.
البته خب تو دنیای واقعی و غیر ایده آل، ممکنه یه دولوپر تازه کار مدعی سینیوریتی همین تست هارو فراپیچیده (over complex) کنه.

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

<--×-->

ولی خب در کل نظر شما راجع به تست چیه؟
مزایا؟ معایب؟ پیشنهاد؟ انتقاد؟ به من، به پست، به کانال و... 🙂🙌🏼

رفقا شب مهندس مبارک! 🥳
ببخشید دیر شد سرم تو کد بود متوجه گذر عمر نشدم 😂

i’m accepting 3–5 students for my private mentorship program.

the goal is to help motivated people build strong fundamentals and a clear path toward becoming a competent developer.

the mentorship includes:
- a personalized roadmap based on your interests and mindset (frontend, backend, data, ai, etc.)
- weekly calls on google meet
- practical assignments and follow-ups via telegram
- monthly assessments with feedback based on your progress

your age, country, or current level doesn’t matter.

what does matter:
- you are willing to study and practice every day
- you can commit to a consistent plan for several months
- you are comfortable being challenged and receiving direct feedback

if this sounds like a good fit, fill out the form below:
https://docs.google.com/forms/d/e/1FAIpQLScfvxtTpEmVkYqeoVY4wTWhFxC4IywuINxNqK7f4fiFZDrizg/viewform?usp=publish-editor

(only a small number of applicants will be selected)