مثال دزد توی کتاب Grokking Algorithms به دو روش حل شده: توی فصل هشتم به روش حریصانه (greedy) حل شده، و توی فصل نهم با برنامه‌نویسی پویا (dynamic programming). روش اول جواب بهینه‌ای بهمون نداد و از ظرفیت کیفِ دزد به شکل خوبی استفاده نکرد، برعکس روش دوم.

روش حریصانه اینطوره که دزده نگاه می‌کنه که ببینه گرون‌ترین چیزی که می‌تونه برداره چیه، بعد از اون دوباره دنبال گرون‌ترین می‌گرده.
برای مثال ظرفیت کیف، سه کیلوگرمه و نگاهی به اجناس می‌ندازه:
- لپ‌تاپ: 3KG (بیست میلیون تومن)
- مانیتور: 1KG (پونزده میلیون تومن)
- موبایل: 300G (ده میلیون تومن)
- دسته‌بیل با امضای محمود احمدی‌نژاد: 3.5K (دویست هزار تومن)
باارزش‌ترین محصول لپ‌تاپه، و وقتی اون رو توی کیفش می‌ذاره، می‌بینه که دیگه جا برای چیز دیگه‌ای نداره!

اما این جواب بهینه نیست، چون می‌تونست مانیتور و موبایل رو برداره و به جای بیست میلیون تومن، بیست و پنج میلیون تومن دزدیده باشه! جواب بهینه رو چی بهمون می‌ده؟ آره، dynamic programming!

الآن که فکر می‌کنم، این الگوریتم به درد آدم‌های شکمو هم می‌خوره؛ اینکه وقتی می‌رن مهمونی، چی بخورن که بیشترین مواد مغذی رو به بدن رسونده باشن. حداقل از مثال دزد و کیفش بهتره! 😁
#GA

A DTO:
- Declares and enforces a schema for data: names and types.
- Offers no guarantees about correctness of values.

A value object:
- Wraps one or more values or value objects.
- Provides evidence of the correctness of these values.

فیچر جدید: حالت آفلاین!
فرض کنید مشکلی براتون پیش اومده و نمی‌تونید تا چند هفته سوالات یا پیام‌های دیگران رو دریافت کنید. کافیه که یه پیام تنظیم کنید و اگه کسی به ربات پیام بده، عذرخواهی شما رو دریافت کنه و بدونه که فعلاً نمی‌تونه بهتون پیام بده.

!offline / !online

جدیداً دانشمندان متوجه شدند که ⭐️ دادن به این ریپازیتوری، فرد رو به ایدز، سیفلیس یا سرطان مبتلا نمی‌کنه؛ پس با خیال راحت از پروژه حمایت کنید!

https://github.com/WebPajooh/MediumBot/commit/ae3924f7e7c7fc879e435d12df0270d547c753c9

از Sam Newman دربارۀ دوتا کتابی که راجع به مایکروسرویس‌ها نوشته پرسیدم، و اینکه پیشنهاد خودت شروع با کدومشونه؟
جوابی که نوشت:
I’d suggest starting with Building Microservices, 2nd Edition. Monolith To Microservices is a deep dive on how to break apart an existing system - if you’re looking for a broad coverage of topics, it leaves that to Building Microservices!
#microservices

کدی رو عجالتاً ریفکتور کردم:
https://github.com/HazNet/SalavatiRefactor/pull/1
نکاتی رو بعدش گفتم که شاید براتون مضر نباشه. 👇

یکی از مشکلات شدید کد شما، مشکل style ــه که بهتره حداقل ابزاری مثل Pint رو داشته باشید. بعضی جاها نیولاین‌های اضافی داشتید، بعضی جاها که نیولاین می‌تونست خوانایی رو بالا ببره، استفاده نکرده بودید. آرایه‌ها هم توی یه سطر نباشه مگر اینکه کوتاه باشه (آرایه‌ای با یک کلید، مثلاً).

یه مورد مهم دیگه هم استفاده از resourceها برای بالابردن consistency توی پروژه‌ست. این‌طوری اگه فردا بهتون بگن که باید ساختار پیام‌های خطا تغییر کنه، چون از exception handler و بقیۀ چیزها خوب استفاده کردید، تغییردادن ریسپانس‌ها خیلی ساده می‌شه.

یه مشکل دیگه که باز هم مربوط به انسجام و یک‌دستی کدهاتون می‌شه و احتمالاً در سراسر پروژه وجود داره، اینه که گاهی از snake_case استفاده کردید و گاهی از camelCase و این رو به وضوح می‌شه توی routeهای پروژه‌تون دید:
/register_complete
/resetPassword
توی REST، چیزی که رایجه، استفاده از kebab-case ـــه؛ برای همین خبری از underscore و اینها نیست.

همچنین ترجیح بر اینه که کنترلرهامون بزرگ نباشند، خصوصاً وقتی که خواسته باشیم REST API توسعه بدیم؛ چون در این صورت، API ما resource محوره و اینجا باید الگوی CRUD رو ترجیحاً همه‌جا پیاده کنیم و در نتیجه استفاده از یه دونه کنترلر برای هندل‌کردن کل این قصۀ کرد شبستری کافی نیست. کاری که باید بکنید اینه که یه ResetPasswordController بسازید و متدهای مربوط بهش رو همونجا قرار بدید.

این یه سری از نکاتیه که الآن به ذهنم رسید بنویسم و بقیۀ دوستان هم می‌تونند نکات مفیدشون رو رو کنند.

نکته: من چرخ خیاطی ندارم ولی کیبوردم رو به اون‌هایی اهدا می‌کنم که اینترنت رو مختل کردند. :)

من خیلی‌ها را دیده‌ام که واژۀ monolith را مترادف legacy می‌دانند و این یک مشکل بزرگ است! معماری monolithic یک انتخاب معتبر است و حتی پا را فراتر گذاشته و می‌گویم: به عقیدۀ من، معماری monolithic یک انتخاب و پیشفرض منطقی است.
#BuildingMicroservices

تا زمانی که واقعاً لازم نشده، دیتابیس را بین سرویس‌ها به اشتراک نگذارید و هر کاری از دستتان بر می‌آید انجام دهید تا از چنین چیزی پیشگیری کنید. به نظرم در صورتی که به دنبال امکان دیپلوی مستقل (independent deployability) باشید، به اشتراک گذاشتن دیتابیس‌ها یکی از بدترین چیزهایی است که می‌شود انجام داد!
#BuildingMicroservices

یکی از مواردی که می‌تونیم به عنوان معایب مایکروسرویس‌ها ذکر کنیم، بحث هزینه‌ست.
وقتی معماری مایکروسرویس داریم، یعنی باید چیزهای زیادی رو run کنیم.
فرضاً هر کدوم از سرویس‌ها به صورت ایزوله‌شده می‌ره بالا؛ یه سری از ابزارها به جای یک‌بار نصب‌شدن، بارها نصب می‌شن و این یعنی منابع بیشتری مصرف می‌شه و فضای آزاد کمتری خواهیم داشت.

آقای Sam Newman به این نکته هم اشاره کرده که مجبور می‌شیم برای ابزارهای غیر رایگان، به جای هزینۀ یک لایسنس، هزینۀ چند لایسنس رو پرداخت کنیم چون انگار روی چند ماشین مستقل نصب شدند!

حالا به معماری monolithic فکر کنید و اینکه قراره یک کپه کد بزرگ رو یک‌جا دیپلوی کنیم...

وقتی از معماری مایکروسرویس استفاده می‌کنیم، سرویس‌های مختلفی داریم که با هم دیگه حرف می‌زنند و ممکنه که برای جواب‌دادن یک درخواست کاربر (مثلاً گرفتن توئیت‌های اخیر) از ده‌تا مایکروسرویس مختلف تقاضا کنیم که بهمون دیتای لازم رو ارائه کنند؛ دیتاها توی هر سرویس serialize شدند و بعد unserialize و اتفاقات از این دست.

همین باعث می‌شه که latency سیستم بالا بره و کاربر زمان بیشتری رو معطل ریسپانس بمونه.

اوایل کارتون، وقتی شروع می‌کنید، همه‌چیز سحرآمیز و خفن به نظر میاد. تکنولوژی‌های براق، هوش از سرتون می‌بَره و هِی ذوق می‌کنید. اما جذابیت تکنولوژی‌ها هم مثل هر جذابیت دیگه‌ای که توی دنیا هست، بعد از مدتی از بین می‌ره و دیگه خبری از حال عجیبی که داشتید نیست. وقتی با Laravel آشنا شدم، احساس می‌کردم یه تسلای مدل Y خریدم و حس خوبی داشتم ولی وقتی جلوتر رفتم، دیگه این حس رو از دست دادم. (الآن این حس رو با محبوبان جدیدم یعنی Nest.js و Docker و ElasticSearch و RabbitMQ دارم)

وقتی از این مرحله عبور می‌کنید، می‌فهمید که تکنولوژی نهایتاً یه ابزاره که باید در جای خودش به کار بره. اگه بشه یه تکنولوژی رو به چکش تشبیه کرد، همۀ مشکلات ما میخ نیستند که راه‌حلشون چکش باشه! بعدش به Clean Code اهمیت می‌دید، بعدش ممکنه توی شیءگرایی سُر بخورید، بعدش با Design Patternها آشنا بشید، بعدش برسید به مباحث معماری سیستم و الی آخر.

در نهایت می‌فهمیم که همۀ اینها قرار بوده به درد یه چیز بخوره: حل مشکلات بیزنس!
اینکه دامین رو خوب بشناسیم و قوانین و محدودیت‌ها رو توی سیستم پیاده کنیم که مشتری خوشحال باشه و درآمد بیزنس بالا بره! اگه بشه این هدف رو به دست آورد، دیگه اهمیتی نداره که از فلان تکنولوژی خفن استفاده کردید یا با PHP7 پیش رفتید!

- I smell a rat!
- Yeah! It should be too problematic and weird...
- No, I mean it! I can smell a dead rat that is died under your bed!
- What? Wait! God! No! Here's a dead rat! What should I do with this?
- Why don't you dance with HER?
- Because I know you want to make a steak out of HER!
- I give up! You're so mean!
#english

راجع به پروژه‌ای که قرار بود معماری مایکروسرویس داشته باشه صحبت کرده بودیم و بعضی‌هاتون شوق نشون دادید؛ یه سیستم شبیه Google Calendar که بتونه جلسه‌ها و کارهای مهممون رو بهمون یادآوری کنه.

ریپازیتوری رو اینجا ساختم:
https://github.com/WebPajooh/calendar-microservice

کار خودم رو هم با سرویسی که مربوط به جمع‌آوری روزهای تعطیله شروع می‌کنم؛ از Typenoscript برای این سرویس استفاده می‌کنیم و فعلاً روزهای تعطیل ایران رو تشخیص می‌دیم. راه ارتباط سرویس‌های دیگه با این سرویس، REST API خواهد بود.

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