ی اپلیکیشن خوب آندرویدی برای آپدیت بودن و در دسترس داشتن مقالات جدید:

https://play.google.com/store/apps/details?id=com.substack.app

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

https://play.google.com/store/apps/details?id=com.burockgames.timeclocker

@osmanmakhtoomdev

پست جدید من تو لینکداین در خصوص RabbitMQ
خوشحال میشم حمایت کنید و کمک کنید به دست بقیه هم برسه.

https://www.linkedin.com/posts/osman-makhtoom_rabbitmq-messaging-techtalk-activity-7226960744251043840-Eq0u?utm_source=share&utm_medium=member_android

@osmanmakhtoomdev

اینم پست جدید لینکداین:

https://www.linkedin.com/posts/osman-makhtoom_%D8%B3%D9%84%D8%A7%D9%85-%D8%A8%D9%87-%D9%87%D9%85%DA%AF%DB%8C-%D9%85%D9%86-%D8%AF%D9%86%D8%A8%D8%A7%D9%84-%D9%87%D8%B1-%DA%A9%D8%B3%DB%8C-%D9%87%D8%B3%D8%AA%D9%85-%DA%A9%D9%87-%D8%AF%D9%86%D8%A8%D8%A7%D9%84-activity-7229070417586458624-b3Om?utm_source=share&utm_medium=member_android

Depends on doesn't mean imports or calls, necessarily, but rather a more general idea that one module knows about or needs another module.

Architecture patterns with Python. xxii introduction

نکته مهمی که اینجا بیان شده خیلی جالبه:
میخاد بگه که منظور از وابستگی الزاما این نیست که ماژول B بیاد ماژول A رو import یا call کنه، بلکه مسئله یکم کلی تره و به این معنیه که اصلا ماژول B درمورد ماژول A چیزی میدونه یا بهش نیاز داره.

خب این توضیح همون اصل پنجم SOLID که میشه D یعنی Dependency inversion هست.

اما من میخام اینو بیارم تو بحث communication روزانه با تیم بیزینس که خودم اون اوایل خیلی مشکل داشتم روش.

اول ی توضیح کلی درمورد این اصل:
میگه که ما دو لایه داریم، یکی لایه سطح بالا و اون یکی لایه سطح پایین.

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

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

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

حالا برای اینکه ما بتونیم این دو لایه رو جوری بچینیم که بتونن اطلاعات رو با هم رد و بدل کنن بدون اینکه لایه سطح بالا به لایه سطح پایین وابستگی داشته باشه(بدونه که چکار داره میکنه یا مجبور باشه فقط از همون جزییات استفاده کنه) نیاز به ی واسط داریم که بهشون میگیم interface این لایه میانی در واقع کاملا انتزاعیه و به هیچکدوم از دو لایه سطح بالا و پایین وابستگی نداره.

حالا بیایم ببینیم تو مکالمات روزمره با بیزینس چجوریه:
ما ی دولوپر داریم
ی پروداکت داریم

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

از کامنت‌های شما استقبال میکنم.

@osmanmakhtoomdev

سعی کن تو کدت پنجره شکسته‌ای بجا نذاری

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

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

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

@osmanmakhtoomdev

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

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

روش دوم اینه که اینجوری فکر کنی که من باید زبان انگلیسی رو یاد بگیرم و بتونم صحبت کنم و شروع کنی و هر روزت رو با روز قبلت و هر هفته رو با هفته قبل مقایسه کنی و پیش بری 🤓

تو روش اول چون نگاهت به هدفه و باهاش فاصله داری جا میزنی، اما تو روش دوم چون مسافتی که طی کردی رو میبینی به خودت انگیزه میدی و میری جلو( گرچه داری خودتو گول میزنی 😁 و کلی با هدف فاصله داری، ولی مجبوری )

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

پس یادت باشه ی پلن داشته باش و نقطه شروع و نقطه پایان رو تو ذهنت داشته باش اما قدم‌های کوچیک بردار و مسافتی که رفتی رو با نقطه شروع مقایسه کن نه نقطه پایان!

@osmanmakhtoomdev

بخون بیا تا پایین ی چیزی بهت بگم

دیروز درگیر ی پروژه بودم که باید بیسش رو میاوردم بالا با داکر.
خب من همیشه عادت داشتم فقط بکند رو داکرایز کنم و اونم تمام نیازمندیاش مثل nginx, elk, postgres, redis, rabbit و... رو همه رو داخل همون docker-compose پروژه میذاشتم و ی نتورک بریج هم میزدم و تمام.
اما این بار گفتم بیام و اینکارو نکنم.
بجاش اومدم ردیس و ربیت و انجین ایکس و پستگرس رو جدا بالا آوردم تو داکر و تو فایل داکر کمپوز فقط بکند و فرانت و ورکر سلری رو کانفیگ کردم.
حتی ساخت دیتابیس و یوزر رو تو پستگرس و grant permission رو رفتم اول تو شل کانتینر پستگرس دستی انجام دادم قبل ران کردن بکند.
و تو شل ربیت هم رفتم یوزر و vhost رو دستی ایجاد کردم و دسترسیا رو ست کردم.
بعد دیدم انجین ایکس نه بکند رو میشناسه نه فرانت رو و دوباره ی نتورک ایجاد کردم و همه سرویسا رو وصل کردم بهش.
حالا سر سرو کردن استتیک فایل‌های بکند دوباره مشکل داشت انجین ایکس و درگیر اون بودم 😢
و الی آخر....

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

@osmanmakhtoomdev

حیفم اومد نذارمش

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

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

خود بحث نوستر اینجا کمی مبهم خواهد بود چون ازش حرف نزدم و بعدا بیشتر می زنم ولی سبک کار و ترکیب کردن چیزها و دیدن اینکه انگلیسی چقدر قابل فهم و استفاده است مثبت ترین نکته ماجراست (:

https://youtu.be/-BLqBYtSh28

#ویدئو #انگلیسی

امروز کتاب Designing data-intensive applications رو شروع کردم.
سعی میکنم از این به بعد هر روز چکیده و ی سری توضیحات درمورد هر مطلبش رو تو کانال قرار بدم.

@osmanmakhtoomdev

سلام 😊
بالاخره تونستم به این کمالگرایی غلبه کنم و قدرت شروع ناقص رو تو خودم تقویت کنم
اولین ویس رو تونستم ضبط کنم و براتون میذارمش.

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

ویس اول بخشی از مقدمه کتاب designing data-intensive applications

#ddia

@osmanmakhtoomdev

سلام به همگی عزیزان
امیدوارم حالتون خوب باشه

ی خبر خوب براتون دارم:

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

در ادامه قراره صفحات وبلاگ، آموزش‌ها و پروژه‌ها هم بهش اضافه کنم.

فرانت رو با انگولار بصورت SSR و بک رو با جنگوی عزیز نوشتم که البته فعلا فرانت و بک هیچ ارتباطی با هم ندارن.

ممنون میشم بررسی کنین و نظرات و پیشنهاداتتون رو بگین.

دوره هم قراره ادامه داشته باشه، نگران نباشید 😁👊

@osmanmakhtoomdev

ویس دوم بخش دوم و پایانی مقدمه کتاب designing data-intensive applications

#ddia

@osmanmakhtoomdev

ویس سوم، مقدمه بخش اول کتاب designing data-intensive applications

#ddia

@osmanmakhtoomdev

ی خبر خوب براتون دارم
اما شنبه میگم 😅

دیدین شنبه من شد یکشنبه؟
درسته عزیزانم

اما هنوز قطعی نشده، بذارین ۱۶ مهر ماه بیاد و قطعی بشه خبر بعد بذارم.

بجاش امشب ی ویس کتاب رو میذارم 🤝

ویس چهارم، بخش اول کتاب
designing data-intensive applications

اصطلاحات مهم:

Reliability = قابلیت اعتماد
*Scalability = مقیاس پذیری
Maintainability = قابلیت نگهداری

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

ممنون از مهدی عزیز که این ایراد رو مطرح کردن

#ddia

@osmanmakhtoomdev

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

آمار هم میده بصورت روزانه و هفتگی و ماهانه و...
همچنین مقایسه میکنه که بدونی کدوم سمتی داری میری

خلاصه که همه جوره میتونید روش حساب کنید

@osmanmakhtoomdev

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

✅بصورت موضوعی ویدیو ضبط میکنیم.
✅ویس کتاب‌ها رو پیش می‌بریم.
✅ مقاله و بلاگ هم می‌نویسیم.

در حال حاضر لیست کتابها به این صورت هست:
۱- Designing data-intensive applications در حال ضبط
۲- Domain driven design کتاب آبی
۳- Architectural patterns with Python
۴- Building microservices
۵- System design interview
۶- Distributed systems

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

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

ممکنه این روند در ادامه با گرفتن بازخوردها و کسب تجربه‌ها تغییراتی داشته باشه.

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

ممنون که باهام همراهی می‌کنید

@osmanmakhtoomdev