دستورات مهم uv, چون درموردش ازم پرسیدید.

تمام پروژه‌های خودم رو بردم روی این مورد؛ و اکثر پروژه‌های شرکت که مسئولیت تیم نگهداری و توسعه‌اش با من هست.

برای دپلوی‌ها هم، از uv تو مرحله build روی Docker استفاده می‌کنم

تا همین ماه پیش هم اگر از من راجب کتاب داکر می‌پرسید، نسخه اول کتاب
Docker in a month of lunches
رو معرفی می‌کردم؛ نوشتار فوق‌العاده و جزئیات به اندازه کافی و البته تصاویر خوب برای انقال نکات مهم.

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

حالا نسخه دوم کتاب معرفی شده (برای اونایی که بهونه‌اشون تغییر دستورات بود)

شخصاً هنوز فرصت نکردم بخونم، اما یک مرور سریع کردم و بنظرم ازین به بعد باید این نسخه رو دنبال کرد.

(راستی قابلیت استوری گذاشتن کانال رو از دست دادیم، اگر کتاب‌هایی که قبلتر معرفی شدند رو خواستید روی اسم کانال بزنید و وارد بخش posts بشید)

#Book@pyHints

Bruno
نسخه vscode-extension رو هم منتشر کرد.

توی معماری سیستم یک اصطلاحی داریم به اسم؛
distributed monolithic
که خب یک anti-pattern هست برای معماری micro-service اول هفته با یک شرکتی برای مشاوره صحبت کردیم (کارشون رو قبول نکردم ولی یک قرارداد کوچک بستم برای اینکه بگم مشکل فعلی سیستم کجاس)

معماری سیستم مثلاً قرار بوده micro-service باشه؛ در نگاه اول هم هست و حتی از تمام ابزارهای لازم هم داره استفاده می‌شه اما به اشتباه.

کل سیستم رو امروز کنار هم چیدم و روی یک سرور بالا آوردم (بجای چندتا سرور) و تبدیلش کردم به multi app monolithic اولش خیلی ناراحت و نگران بودند که پرفورمنس خراب میشه و ازین حرفا ولی بعد توی تست‌ها دیدند که حداقل ۲ برابر سرعت پاسخ و تعداد درخواست‌هایی که هندل میشه بیشتره.

البته من مطمئن بودم که اینطوری می‌شه به سه دلیل :
۱- به وضوح anti pattern رو می‌دیدم
۲- تعداد درخواست‌های بین سرویس‌ها زیاد بود
۳- خیلی از زمان پروفایلنگ، برای درخواست بین سرویس‌ها هدر می‌رفت روی نتورک. (که خب حتی async هم نبود که حداقل cpu هدر نره)

این موضوع دلیلی شد؛ بیام چندتا تعریف اشتباه که دائم می‌شنوم رو انتقال بدم:

۱- توی ماکروسرویس هر سرویس باید دیتابیس جدا داشته باشه.

این تعریف درسته، اما تفسیر غلط ازش زیاده؛ مثلاً ۹۹٪ فکر می‌کنند این یعنی برای هر سرویس باید یک سرور Postgres جدا داشته باشند، نه لزوماً مفهوم این تعریف اینه که:
مثلاً سرویس auth شما نره دیتای سرویس payment رو بخونه حتی اگر جفتشون روی یک دیتابیس هستند (فقط دوتا تیبل جداشده) و برای گرفتن دیتای مورد نیازش به سرویس payment درخواست بده

۲- هر تابع، متد یا ... باید single responsibility داشته باشه.

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

اینو دیدم که میگم، به طرف میگم، خب عالی توابع اینکارها رو بذار یک‌جا داخل یک تابع و درخواست بده اگر مشکلی توی پرداخت پیش اومد همه باهم باید rollback بخوره (توجه به بحث قبل شما حق نداری، تیبل سرویس‌های دیگه رو دستکاری کنی)؛ برگشته می‌گه پس Single Responsiblity چی می‌شه ؟

یک ساعت داشتم براش توضیح میدم؛ که این تابع SRP رو رعایت می‌کنه چون تو فقط داری میگی من پول رو پرداخت کردم موفق بود یا نه.


۳- ماکروسرویس بهتره ...

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


چندتا برداشت اشتباه دیگه هم بود که متأسفانه یادم نیست دیگه،‌ ولی تبدیل سیستم به یک monolithic واقعی توی این پروژه نتایج خیلی بهتری داشت.
حتی برای مرحله بعدی هم پیشنهاد کردم اول سراغ
Load balance
و بالا آوردن چندتا instance از همین monolithic برند، بعد برای تبدیل به micro-sercive از یکی که معماری رو واقعاً بلد هست کمک بگیرند نه کسی که پوشه پوشه کردن فایلای پایتونش رو فقط یاد گرفته.


نهایتاً؛ البته من می‌دونم خیلی از این برداشت‌های اشتباه از کجا میاد.
منابع ترجمه شده به فارسی.

ترجمه اشتباه لغوی یک کلمه، باعث میشه معنی یک جمله بطور کامل عوض بشه.

#توضیح

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

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

تست کنید 👆

داستان گیر دادن من هم همین هست؛ کسی که آموزش میده لزومی نداره تمام موارد و جزئیات رو به یک تازه‌کار بگه اما همین که توی آموزشش اشتباه نگه و از حالات درست استفاده کنه باعث میشه ذهن نیرویی که تربیت می‌کنه آماده باشه.

در نهایت:
همونطوری که خروجی همه‌ی کلاس‌های آموزش زبان انگلیسی، مترجم‌های برتر ادبیات کلاسیک انگلیسی نیست و حتی ممکنه فقط
I am a blackboard
ازش در بیاد؛ قرار هم نیست خروجی همه شاگردهای شما Dennis Ritchie باشه، اتفاقاً خیلی‌هاشون قراره خیلی زود متوجه بشوند اصلا علاقه‌ای به برنامه‌نویسی ندارند فقط لایک شدن پستای اینستاگرامشون و ویدئو دادن توی یوتیوب براشون مهمه

خلاصه؛ اگر حتی مقدمات یک چیزی رو درس میدی، باید اصول و قواعد رو رعایت کنی وگرنه خیانت داری می‌کنی

4: It is appalling. Please, please don't do this.

source: Architecture Patterns with Python page 14

من یک پستی روی لینکدین گذاشتم؛ چندروزه برای ارتباط گرفتن با maintainer های یک پروژه‌ای فعالیتم زیاد شده اونجا و کامنت گذاشتن زیر پست‌ها و ... ازم راجب منبع زیاد سوال شد.

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

این کتاب‌ها حداقل‌هایی هست که باید بخونید تا به خودتون بگید مهندس نرم‌افزار پایتون!

و کامنتی که هیچوقت جواب داده نشد؛ چندنفر سوال کردند گفتم بازم توضیح بدم:

اول نگاهی به کتاب‌ها بندازیم و دسته‌بندی کنیم اونارو ؟
من کتاب هوش مصنوعی رو توی لینکدین نذاشتم.

کل کتاب‌هایی که معرفی کردم به ۴ دسته تقسیم می‌شه:
۱- پایتون مقدماتی تا کمی پیشرفته.
مگه میشه شما زبان برنامه‌نویسی که کد می‌زنی رو درست نشناسی ؟
۲- برنامه‌نویسی async و کمی optimization برای پایتون.
واجب هست؛ چون باعث میشه نسبت به رقبای بازار بهتر باشید
۳- ساختمان داده و الگوریتم؛
هرجای استانداردی که برید مصاحبه فنی حداقل چیزی هست که پرسیده میشه
۴- طراحی و معماری نرم‌افزار و سیستم
امکان نداره یک سوال هرچند کوچیک و ساده راجب این موضوع ازتون نشه.

پست بعدی

یک نگاهی به مصاحبه‌های software engineering بندازید
یا حتی mock interview هایی که موجود هست!

تمام این موارد حداقل‌ای ها هست ولی در سطوح مختلف از شما پرسیده میشه.

در نهایت؛ فکر می‌کنم از پست‌هایی که تا به امروز گذاشته شده همه درک کردید!
من پست‌هام برای
software engineer

شدن هست و کسایی که شاید بودنشون توی این کانال هم اشتباه باشه؛ اما قطعاً خوشحالیم از اینکه هستند:

۱- انواع و اقسام وایب کدر
۲- بطور‌کلی تر؛ کدر‌‌ها
۳- هرکسی که نیازی به درک داشتن از کاری که می‌کنه نداره و فقط می‌خواد ی چیزی دمو کنه

درنهایت برای سه مورد خاص هم هیچکدوم از مطالب کتاب‌های بالا نیاز نیست :

۱- دانشجویی که می‌خواد از شر تسک‌های استاد زودتر راحت بشه.

۲- کارمند دولتی که ۱/۳ شرکت خصوصی حقوق میگیره و مدیرانش هم هیچ درکی از هیچی ندارند.

۳- کسی که ایده خوبی داره و کمتر از ۱-۲ هفته وقت داره برای ارائه ایده‌اش MVP داشته باشه که کار کنه

اگر توی این ۲ دسته بندی و ۶ مورد نیستید؛ شرمنده‌ام باور کنید یا نه تأکید می‌کنم!

کتاب‌هایی که گفتم حداقل‌هایی هست که باید یاد بگیرید تا بهتون بگن Software Engineer

پرسیدید چرا نویسنده می‌گه این مورد appalling هست؟ با اینکه بنظر رفتار خیلی خوبی میاد.

من یک نمونه کد زدم که نشون بدم چرا بد هست این رفتار؛ توی این حالت من بیش از حد سخت گرفتم و همه چیز NewType هست (یا یک رفتاری رو نباید دنبال کنید یا کل کد باید یک استاندارد رو رعایت کنه)

اولین و مهمترین نکته :
توجه کنید نویسنده همین رفتار یعنی تعریف مداوم تایپ جدید برای نوع داده‌های اصلی رو بد می‌دونه!
اینکه بجای str, bool, int تایپ جدید تعریف کنید که پارامتر ورودی شما بهتر بنظر برسه!

حالا بررسی کنیم خود ایرادات وارده رو:

۱- تعریف نوع داده‌ای جدید هیچ عملکرد بهتری برای runtime بهم نمیده!
خیلی از افرادی که اینکار رو می‌کنند برای فرار از تست کردن کدها؛ فرار از نوشتن ولیدیشن؛ فرار از چک کردن پارامتر‌های ورودی و ... اینکار رو می‌کنند! این چیزی هست که شخصا بسیار توی این مدل کد زدن دیدم (قطعا هستند افرادی که اینطوری عمل نمی‌کنند ولی خب من ندیدم)

۲- خط ۹۱ کد رو ببینید؛ هرجایی از کدم که بخوام یک str یا ... رو برای این توابع استفاده کنم حتما باید توی NewType ایی که تعریف کردم بذارمش!

ادامه پست بعدی:

چیزایی که شخصا خیلی باهاشون مشکل دارم :

۳- وقتی این NewType هیچ runtime چکی نمیده؛ چه فرقی بین

email: Email
email: str 

هست؟ استفاده از اسم متغییر درست به توسعه دهنده بعدی به درستی می‌فهمونه که باید ایمیل استفاده کنه و نه چیز دیگری

اینجا باید ترجیح بدید که Email رو تبدیل به یک کلاس کنید که validation های مختلف خودش رو هم حتما داشته باشه!

۴- احساس امنیت کاذب؛ توی مورد ۱ به این موضوع اشاره کردم!
حالا بخش بدتر این قضیه کجاس ؟ دولوپرهای حواس‌پرت به mypy تکیه می‌کنند که دولپر دیگری از کدشون سواستفاده نکنه بجای اینکه دقیقا پارامتر ورودی رو بررسی کنند و اگر ایمیل ولید نیست ارور برگردونند.

۵- توی پایتون NewType چون قوانین نامگذاری شبیه به Class داره و البته که Syntax Highlight هم مثل کلاس می‌بینه باعث سردرگمی میشه!
کلاس بدون رفتار ؟
اینم موردی دیگه و یک anti-pattern دیگه

در نهایت :
NewType
چیز بدی نیست؛ جو گیری بده. وقتی سورس کد بزرگ هست و شما این موضوع رو بیش از حد پیش بردید اتفاقات قشنگی نخواهد افتاد.
دقت کنید این موارد حتی توی زبان‌های کامپایلری و lowlevel هم قفل هست.

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

نسخه با کیفیت تصویر

پیام دادید یک راهکار یا ... برای اینکه تست کنیم معماری که استفاده کردیم واقعاً microservice هست یا Distributed monolothic پیشنهاد می‌دید ؟

سوال جالبی بود و هیچوقت به این فکر نکرده بودم که چطوری میشه؛ یک تست سریع راه انداخت، اما بنظرم بهترین جواب هم توی خود ویژگی‌های microservice هست:

تمام سرویس‌ها اگر که باهم اجرا بشه؛ سیستم باید کار کنه!
اما اگر هر سرویس رو خاموش کنید (مثلاً برای ۵ دقیقه) باقی سرویس‌ها باید بدون مشکل کار کنند، وقتی بعد از ۵ دقیقه اون سرویس خاموش شده رو روشن کردید، سیستم باید کامل کار کنه.

مثال: فرآیند خرید محصول (انسانی)
ثبت سفارش - تایید موجودی - تایید سفارش و صدور فاکتور - پرداخت - تایید پرداخت - آماده سازی - ارسال.

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

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

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

پ.ن:
سعی کردم مثالم خیلی ساده باشه (چون خودشون ذکر کردند جونیور هستند)

سمت ما
__init__.py
لزوماً خالی نیست؛ خیلی وقتا تنظیمات خاص و راحت تر و ... داخلش هست
و یا حتی re-export برای راحتی بیشتر کاربر.

برای اولین باز :
شخصا این کتاب رو هنوز نخوندم (۲ فصل فقط)

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

این کتاب رو یکی از دوستان به من هدیه داده (که خب هنوز وقت نکردم خوندنش رو کامل کنم) توی کانال @pyrust درگیری این مدتم رو نوشتم.

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

برای اونهایی که واقعا نیاز دارند به این موضوعات درحال حاضر پیشنهادش می‌کنم. اما اگر کتاب‌های دیگه که معرفی شده رو نخوندید می‌تونید صبر کنید تا شخصا کتاب رو بخونم و بعد نظر دقیقتر بدم!

به همین دلیل این پست رو هشتگ نمیزنم که قاطی باقی کتاب‌های اصلی نشه!

#Quick
یکی از دلایل خوب استفاده از containar اینه که آپدیت ورژن‌ها ساده‌تر باشه!

پروژه‌ای رو داشتم که هنوز از Postgres 12 استفاده می‌کرد؛ ۱۴ نوامبر ۲۰۲۴ پشتیبانی این نسخه تموم شده (سرچ کردم حفظ نیستم).
بعد بنده خدا مدیر شرکت می‌خواست optimization بزنه که مشکلاتش کمتر بشه، همین که ابزارهایی که استفاده می‌کردند رو آپدیت کردم و البته معماری سیستم رو کمی بهتر (مثلاً برای دسترسی به یک سری سرویس‌های داخلی چون نتونسته بودند کانفیگ کنند، درخواست‌ها رو از اینترنت رد می‌کردند که خودش باعث میشه latency زیاد بشه) بیش از ۷۰-۸۰٪ مشکلاتشون حل شد.
بخصوص میزان مصرف منابع!

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

پیام پاول دوروف به مناسبت تولد ۴۱ سالگی و البته قوانین کنترل شدید اینترنت اروپا؛

https://www.tg-me.com/durov/452

سایتای داکر دان شده؛ دست به چیزی نزنید!

یکی از دوستان توی گروه اطلاع دادند.

Issues accessing Registry, Hub, Scout, DBC, DHI - We are seeing issues accessing and using our services across many of our products. See dockerstatus.com⁠ for updates.

پینوشت:
بنظر میاد مشکل اصلی از AWS هست

#توصیه@per3onal

دقیقاً، پیشرفت بعد از درک نفهمیدم هست.

این رو به خواهر دوستم گفتم؛ رفیقم زنگ زده، که آقا خواهر من یک شرکتی وارد شده بهش یه سری منابع دادند که بخونه، تازه ۲ هفته‌اس وارد شده (این اولین تجربه کاریش هست)

ولی همش می‌گه، هیچی متوجه نمی‌شه؛ دوره آموزش یا راهکار یا چیزی داری براش ؟
راهنمایی‌اش کردم و تمام، گفتم این پست رو بنویسم ...

وقتی قراره چیزی یاد بگیری، چه دانشجو، چه کاری چه اصن سنیور

همیشه باید یک نکته‌ای رو یادت باشه؛

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

یعنی اینکه به خودت بگی؛
من چه غلطی دارم می‌کنم.
من هیچ چیزی نمی‌فهمم.
من هیچ درکی از کاری که می‌کنم ندارم.
و ....

کاملاً طبیعی هست؛ نمی‌گم درسته‌ها حرف تو دهن من نذارید بعداً، می‌گم طبیعی هست.

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

اما مهمترین بخشش هم همین هست؛ اون اوایل که هیچی ازش نمی‌فهمی نا امید نشی و ادامه بدی.

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

بنظرتون بعد از چندماه اگر ببینیدش، انگیزه‌ای براش مونده ؟
یا اینکه اگر بیاد به شما بگه چیزی نفهمیده، خنگ‌ترین آدم دنیاس ؟

حالا کنار دست همین آدم، یک راهنما بذارید یک چیزی مثل chatgpt, grok, gemini یا ...
بنظرتون حالا چطوری عمل می‌کنه ؟

احتمالاً بازهم انگیزه کمی خواهد داشت، اما دیگه مباحث زیادی رو هم می‌دونه؛
مثلاً می‌دونه که متغییر چیه؛ یا def برای تعریف تابع هست

حالا کنار دست همین آدم منابع دیگری رو هم بذارید؛ مثل یوتیوب یا ...
ممکنه کمی کند ولی راه خودش رو هم پیدا می‌کنه؛ از پایتون شروع می‌کنه تا به جنگو برسه.


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

جاهایی که همه‌ی متن رو سریع میفهمم و میرم جلو؛ بهم حس خیلی خوبی میده درصورتی که اصلاً چیز خوبی نیست؛ این یعنی من هیچی یاد نگرفتم ازین کتاب، چون چیزی نداره که به من اضافه کنه

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

من هیچی نمی‌فهمم،
من خنگم و ....

خلاصه که اگر شماهم مثل خواهر این دوست من یادتون میره درحال یادگیری هستید، یکجا بنویسید و بذارید جلو چشمتون:

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

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

در نهایت:
قدم اول برای اینکه شروع کنید به یادگیری، این هست که بفهمید اون موضوع رو یاد نگرفتید یا نفهمیدید.

#موقت

ربطی به موضوع این کانال نداره؛ ولی این روزا خیلی ازین پیام‌ها دریافت می‌کنم.
گفتم بذارم شاید به کار یک نفر دیگه هم اومد.