یک چیزه خیلی مهم تو دنیای برنامه نویسی:
https://www.youtube.com/watch?v=U7A12dQgFqI

به شدت Idempotency تو کد مهمه. صرفا به API ختم نمیشه و تو سطح کد هم میتونه رعایت شه. توابعی بنویسید که در برابر arguement ای که بهش میدین همیشه Idempotent هستن! یکی از مزایا بزرگ type state بودن هم Idempotency عه.

ویدیو تایپ استیت که قبلا تو کانال فرستاده بودم:
https://youtu.be/DwAQ6dm-Vn8


@PyBackEndHub

یک نکته امروز یاد گرفتم که کاش زودتر یاد میگرفتم
تو پایتون هیچوقت از Any استفاده نکنید. اگه تایپ یک آبجکتی رو نمیدونید اونوقت از object استفاده کنید.
چرا؟
چون مجبور میشین حالا تایپ رو چک کنید و شرط بنویسید.

یعنی اگه بنویسی:

def foo(bar: Any): 
   bar.not_valid

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

def foo(bar: object): 
   bar.not_valid

استتیک تایپ چکر بهتون ایراد میگیره. پس مجبور میشین به صورت explicit تایپشو چک کنید. جاهایی که نمیدونید چه تایپی به این تابع پاس داده میشه عالیه.


@PyBackEndHub

کاربرد گروهو میخوام تغییر بدم
به گروهی برای رفع مشکل و بحث در خصوص Backend Engineering و پایتون

مرجعی هم بشه که بتونید کلا سوالات flask یا kafka یا rabbitmq یا FastAPI یا ORM هرچیز دیگه ای که ممکنه براش community پیدا نکنید. لینک:

https://news.1rj.ru/str/PythonFellow

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

@PyBackEndHub

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

@PyBackEndHub

توصیه میکنم حتما یک سری به warp بزنید.
هم برای مک هست. هم برای لینوکس منتشر شده. (ویندوزیا یک چرخ بزنن بعدا بیان :))‌ ) قابلیتاش که زیاده چیزایی که ترمینال های دیگه هم دارن. ولی چیزایی که ترمینال های دیگه ندارن:

۱. مثل ide هست. یعنی میتونید با کلیک برید وسط تکست. یا خیلی کار هایی که تو IDE میتونید انجام بدید اینجام میتونید.

۲. با راست نوشته شده و چیزی که با rust نوشته شده اکثر مواقع هم سریعه هم امن 😂 سرعت و پرفومنس رو قشنگ حس میکنید. هیچوقت قفل نمیکنه یا کند نمیشه.

۳. یک AI داره که من استفاده نکردم نمیدونم چیکار میکنه

۴. میتونید کامند هایی که در دسترسه رو ببینید. تو این کیس دیدین آپشن های Poetry lock رو قشنگ توضیح داده یک به یک. یا مثلا موقع checkout کردن بهتون inline support میده که دارین رو کدوم گیت برنچ checkout میکنید.


warp.dev

چند ماهه میخواستم تستش کنم. یک waiting list مسخره داشت که برداشته شد.

@PyBackendHub

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

هر روز دری جدید از sqlalchemy برام باز میشه :))

میدونستین sqlalchemy میتونه با یک کلس سشن همزمان به چند دیتابیس وصل شه؟ یعنی خودش هندل میکنه. و خودش میفهمه که الان کانکشن رو باید کجا بزنه و رو کدوم دیتابیس اجرا کنه. ولی چیزی که نظرمو جلب کرد این نیست. چیزی که نظرمو جلب کرد اینه که وقتی transaction بزنید و از دو دیتابیس استفاده کنید، خودش خودکار two phase commit میزنه به صورت implicit. البته به صورت explicit هم ممکنه این. ولی برام خیلی جالب بود یک فریم ورک چقدر میتونه اون پشت مجیک و باهوش باشه که همچین کاریو بتونه انجام بده 😅. ساپورتش برای two phase commit خیلی زیاده ولی تاحالا تو هیچ orm ای همچین چیزی ندیده بودم که به صورت smart بیاد two phase بزنه خودش!

و نکته عجیب تر اینه که این لایبری یک جورایی یک maintainer فقط داره که از ۲۰۰۶ داره رو این پروژه کامیت میزنه!😁

@PyBackendHub

🫡 Commitment
به این میگن… خیلیم معروف نیست نسبت به بزرگی کاری که کرده که خدایی در حقش خیلی کم لطفی شده😅 پکیجش یکی از پردانلود ترین پکیج های پایتونه، با اختلاف خیلی بیشتری نسبت به بقیه ORM های پایتونی.

اینجام hachyderm عشه. سوال های جالبی میکنه. جالبه با community اش در حال ارتباطه دائم و ازشون سوال میپرسه😁 پیرو پست قبلیم، ایشون با این حجم سواد میاد تو پابلیک سوالشو میپرسه که نشون میده سنیور بودن به نپرسیدن و جواب اشتباه دادن نیست، بلکه به پرسیدن و جواب غلط ندادنه!

https://hachyderm.io/@zzzeek

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

یک ایونت داشتیم، که هرکسی باید ۲۰ عکس به صورت اسلاید از یک تیکه با ارزش زندگیش درست میکرد و تو هر اسلاید ۲۰ ثانیه حرف میزد. میتونست خاطره باشه، یک عادت (hobby) باشه، یا هرچیزی. خلاصه کل افراد تیم پرزنت کردن تا اخر سر نوبت رسید به CEO. وقتی پرزنتش شروع شد عکسای ایرانو دیدم! خاطره سفرش از سال ۲۰۱۷ داخل ایرانو گفت و اینکه چقدر مردم باهاش مهربون بودن، مهمون نواز بودن، غذا مهمونش میکردن و چقدر جو صمیمی بود. از تهران و اصفهان و شیراز و چند شهر ایران دیدن کرده بود، و اخرش گفت با وجود اینکه خیلی کشور ها رفته و مسافرت کرده ولی بهترین تجربه زندگیش تو ایران بوده.

همینطور که اسلایدا رو داشت میبرد به اسلاید بعدی، خیلی حس غرور منو گرفت :)) ۷ ساله ایران نیومدم و کاش میتونستم بیام یک سر مسافرت.😁

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

@PyBackendHub

یکی از بهترین روش های پیاده سازی retry mechanism استفاده از کانتکس منیجر و generator هست. علتش؟ چون شما میتونید یک try except ای داشته باشین که کاملا reusable هست و base اش درواقع اکسپشن هایی هست که catch میکنید.
مثالش, به جای اینکار:

def fn(): 
    try:
        foo(bar)
    except FooBarException: 
        ... # handler 1
    except BazException: 
        ... # handler 2

میتونید اینکارو انجام بدید

@contextmanager
def flow_manager(): 
    try:
        yield
    except FooBarException: 
        ... # handler 1
    except BazException: 
        ... # handler 2

with flow_manager(): 
     foo(bar)

خوبیش چیه؟ هیچی try except بلاکتون کاملا reusable میشه. خیلیا برای اینکه همچین چیزی داشته باشن ۲ لایه کلس مینویسن که نیازی نیست واقعا. اینطوری خیلی ساده تره و راحت تره. بخش زیادی از سورس کد httpx اینطوریه.
چیزی نیاز داشته باشین تو try except میتونید به کانتکس منیجر بدید. تو این مثال ساده بود من چیزی نذاشتم. ولی این شیوه کاملا داینامیکه و خیلی میتونه خوب باشه برای retry mechanism مخصوصا برای لایبریا چون نیازی نیست دیگه ارث بری انجام شه فلان متود رو اورراید کنی فلان کارو کنی فلان اتفاق میفته. نه flow کاملا دسته خودتونه.
همیشه توصیه کردم سورس کد لایبری هارو بخونید خیلی چیزا برای الهام داره. مثلا تو httpx مثالی که زدم خیلی استفاده شده و باعث شده کد یک دست و خیلی خوبی داشته باشه.

@PyBackendHub

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

ببین فکر کن یک مدل داری با ۳ تا فیلد

MyModel
- id
- first_name
- last_name

که دو تای پایینی nullable هستن. رکورد ایدی اول تو دیتابیس هم first name اش null هست هم last name اش. من ۲ درخواست همزمان میدم. درخواست اول first name رو مانی میکنم. درخواست دوم last name رو مظفر.
اتفاقی که میفته اینه که اول از دیتابیس MyModel رو میخونه جفت درخواستا. برای جفتشون first_name=None و last_name=None هست. بعد هرکدومشون همچین query ای میزنن:

درخواست اول:

// model.first_name = "Mani"
// model.save()
UPDATE MyModel
SET first_name = 'Mani', last_name = NULL
WHERE MyModel.id = 1

درخواست دوم:

// model.last_name = "Mozaffar"
// model.save()
UPDATE MyModel
SET first_name = NULL, last_name = 'Mozaffar'
WHERE MyModel.id = 1

دیدی چی شد؟ جفتشون یک NULL هم فرستادن سمت دیتابیس. چرا؟ چون تو مموری یکی از نام و نام خانوادگی null بود و وقتی .save رو میزنی همونو میفرسته به دیتابیس.
بنابراین یا first name نال میمونه یا last name. در صورتی که درستش اینه:

// req 2
UPDATE MyModel
SET last_name = 'Mozaffar'
WHERE MyModel.id = 1

// req 1
UPDATE MyModel
SET first_name = 'Mani'
WHERE MyModel.id = 1

معادل orm اش چی میشه؟

# req 1
MyModel.object.filter(id=instance.id).update(last_name="Mani")

# req 2
MyModel.object.filter(id=instance.id).update(last_name="Mozaffar")

# OR...
mymodel.save(update_fields=['first_name'])

@PyBackendHub

اما sqlalchemy یک فیچر داره که بهش میگن dirty tracking

Dirty means that field in-memory and database values are different.

یعنی دقیقا استیت دیتابیس و مموری رو track کنه. پس متوجه میشین چه فیلد هایی override شدن.
یعنی تو sqlalchemy میتونید بنویسید

mymodel.first_name = "Mani"

و موقعه flush فقط first name رو فلاش میکنه.
تو جنگو هم یک پکیج هست برای اینکار که میتونید استفاده کنید:
https://github.com/romgar/django-dirtyfields

ولی من به سلیقم نمیخوره و ترجیح میدم بنویسم که چه فیلدی رو میخوام اپدیت کنم.

@PyBackendHub

چطور issue رو به صورت حرفه ای تو یک community مطرح کنیم و به جواب برسیم؟

اولین مشکلی که من خیلی میبینم مشکل xy هست.

https://en.wikipedia.org/wiki/XY_problem
مشکل xy چیه؟ به جای اینکه راجب صورت سوال, سوال بپرسن راجب مشکلی میپرسن که در طی پاسخ به اون سوال از اون روش بهش برخوردن. مثلا یک مثال ساده:‌ من چطور تو پایتون میتونم سه کاراکتر اخر از یک string که میاد رو بگیرم؟‌
حالا سوال و چالش واقعی:‌من چطور میتونم ببینم فایلی که کلاینت برام فرستاده همون فایلیه که ادعا میکنه؟ جوابش: مقایسه مجیک بایت و تطابقش با file extension که بعد آخرین نقطه میاد.
پس همیشه سوالتون رو بپرسید. میتونید راهکاری هم که داشتین در کنارش معرفی کنید.

دومین مشکل همون مشکل dont ask to ask هست که احتمال پاسخ گرفتنتون رو به شدت کاهش میدین.
https://dontasktoask.com

و آخرین مشکل نحوه و کالچر مطرح کردن مشکلتون هست. لایبری های اوپن سورس اگه ایشو زده باشین حتما با کالچر مطرح issue آشنا هستین, این موارد شامل:
۱. جدایی لاجیک از کدتون. هرچقدر لاجیک لای کدتون بیشتر باشه خواناییش کمتر میشه برای کسی که مسلط نیست به اون لاجیک.
۲. نوشتن یک failing test. خیلی وقتا همه مشکلشونو میگن ولی واقعا نمیفهمم کجاش مشکل بوده 😁
۳. اگه مورد دو رو انجام ندادین, میتونید یک قطعه کد کوتاهی بذارین که مشکلتون رو reproduce کنه! expected result مشخص باشه.
۴. محیطتون رو کامل شرح بدید. سیستم عاملتون, چه نسخه ای از لایبری و پایتون رو دارین استفاده میکنید‍.
۵. اسکرین شات با ‍سایت هایی مشابه ray.so بنویسید یا از قابلیت جدید تلگرام استفاده کنید برای ارسال کد.


@PyBackendHub

برای یک پروژه یک سری چیزا ضروریه. تو اولین پست میرم سمت IDE یعنی vscode. یک پروژه به چیا نیاز داره تو vscode ؟

۱. مهم ترینش که قطعا دارین pylance هست. pylance یک language server هست برای پایتون که static type check هم انجام میده (برخلاف pycharm که نداره). استتیک تایپ چکش بر اساسه pyright هست, درواقع superset ای هست از pyright یعنی کمی فرق میکنه ولی احتمالا متوجه نخواهید شد. نکته خیلی مهم اینه که حتما static type check پایتونتون رو فعال کنید و رو حالت basic بذارین حداقل. به طور دیفالت خاموشه. چطوری؟‌وارد user setting داخل vscode تون بشین و سرچ کنید type checking mode و اونو بذارین رو حالت basic.

۲. لینتر ruff. داشتن یک لینتر خیلی مهمه. ruff هم خیلی سریعه و هم خیلی سبک و هم خیلی عالی. با rust نوشته شده و هم کاره black و isort رو انجام میده. یعنی ایمپورت هایی که استفاده نکردین هم پاک میکنه.توصیه میشه حتی تنظیمات راف رو داخل pyproject بذارین که بین همه یوزرا یکسان باشه. تو پست بعدی که راجب استراکچر خوده پروژه هست بیشتر صحبت میکنم.

۳. اکستنشن دیباگر تست. خیلی وقتا باگایی که داریم رو با یک تست reproduce میکنیم (یا بهتره بگم همیشه باید اینکارو کنیم). اون موقع ران کردن یک تست خاص با دیباگر خیلی میتونه مفید باشه. میتونید اینکارو بدون extension هم انجام بدید ولی مدام باید یک کانفیگی رو عوض کنید که یکم اذیت کننده میتونه باشه. این extension خودش تستا رو پیدا میکنه و میتونید ران کنید با دیباگر یا به صورت معمولی:
https://marketplace.visualstudio.com/items?itemName=LittleFoxTeam.vscode-python-test-adapter

۴. داشتن یک .vsocde/settings.json که کمک میکنه یک ستینگ واحد داشته باشین بین همه کسایی که تو پروداکت دارن با vscode کار میکنن. خیلیا اینو میذارن تو ‍gitignore ولی من دلیلی نمیبینم. میتونه خیلی مفید باشه.

۵. استفاده از built in extension خوده git وی اس کد. اینطوری سریع تر میتونید کامیت بزنید و بهتر میتونید متوجه شین چیو دارین کامیت میکنید.

۶. استفاده از vscode/launhc.json که اپ هاتون رو با دیباگر بتونید ران کنید. مثلا جنگو یا فست دارین بتونید با لانچر تو حالت دیباگ رانش کنید. داکیومنت کاملش این زیر هست.
https://code.visualstudio.com/docs/editor/debugging


حالا تو پست های بعدی میپردازم به بخش پایتونی و غیر از IDE
@PyBackendHub

اقا abstract نکنید الکی 😁 خیلی وقتا میبینم بعضیا چیزای عجیبی رو abstract میکنن. نمونش بروکره. یا دیتابیس. که اگه خواستی بتونی با تغییر ۲۰ خط کد بروکرت رو تغییر بدی. یا دیتابیستو تغییر بدی.

سوالی که من برام پیش میاد همیشه اینه:
اگه شما با ۲۰ خط کد داری بروکر یا دیتابیستو تغییر میدی, ایا واقعا داری از اون بروکر یا دیتابیس به نحو احسن استفاده میکنی؟ چون قطعا فیچر هایی داشته که مخصوص خودش بوده .

البته اضافه کنم abstraction میتونه خیلی پرفکتم انجام شه. مثل orm django یا sqlalchemy که بستگی به دیتابیس رفتارش میتونه متفاوت باشه. ولی اونا لایبرین. ایا زحمت همچین abstraction پرفکتی بیشتر نیست از اینکه بشینی ۳ تا خط کدو عوض کنی؟

@PyBackendHub

در ادامه سری پست های قبلی, اینبار میپردازیم به استراکچر و نیازه اولیه یک پروژه فارغ از نوع پروژه.

۱. اولین چیزی که مهمه داشتن یک command runner هست که کامندا همه یک جا جمع باشن. برای اینکار میتونید از makefile یا justfile استفاده کنید. همه دپندسی هارو ship نکنید و تا حد ممکن کمترین دپندسی رو ship کنید.
۲. لطفا دیگه از requirements.txt استفاده نکنید :)). بهترین حالت pyproject هست چون خیلی flexible تره و requirements.txt دیگه deprecate شده. حتی بنظره من بهتره دپندسی ها لاک شن چون دیگه خیلی قابل پیش بینی میشه سرویس. برای اینکار میتونید از poetry یا حتی گزینه بهتر از uv استفاده کنید.
۳. داشتن static analyzer خیلی کمکتون میکنه. اگه خیلی restrict باشه جلوی سرعت توسعه رو میگیره و کلا استفاده از پایتونو تا حدی زیر سوال میبره (مگه برای لایبرای اوپن سورس یا پروژه هایی که خیلی scale کردن). من باشم از pyright استفاده میکنم چون مشابه vscode هست.
۴. داشتن کامیت هوک خیلی میتونه کمک کنه. دوستان پری کامیت هوک فیچری گیته! پری کامیت که یک cli tool پایتونی هست فقط برای پایتون نیست. درواقع یک پری کامیت هوکه. شما میتونید گیت هوک خودتونو بنویسید و خیلی راحته اینکار. تو این ویدیو بهتون آموزش میده. من شخصا بنظرم پری کامیت (لایبری پایتونی) خیلی لیمیت داره. پس توصیه میکنم خودتون کامیت هوکتونو بنویسید خیلی سادست بخدا :). میتونید از pre push هوک استفاده کنید که قبل از پوش کردن ران شه و dx رو ضعیف تر نکنه.
۵. هر سرویس کانتینری که میزنید باید entry point داشته باشه. لطفا هارد کد نکنید تو خوده فایل داکرتون. باعث میشه آپریشن و توسعه بیشتر دیکاپل شه.
۶. اسکریپت های یک پروژه رو تو فولدر جدا و تست هاشو هم تو یک فولدر جدا نگه دارین از خوده سرویس. نیازی نیست تست یا اسکریپت رو ship کنید به پروداکشن. فقط فایل سرویس.
۷. فایل .envrc خیلی میتونه تو توسعه کمکتون کنه. مقاله زیر رو بخونید که متوجه شین کاربردش چیه.
۸. موقعه توسعه لاگ هارو ذخیره کنید. که اگه باگی پیدا کردین و نتونستید reproduce اش کنید و لاگ کنسولتونو از دست دادین همچنان لاگ داشته باشین.

نهایتا سرویستون این شکلی میشه:

service/
   logs/
   service/
   tests/
   noscripts/
   container_entrypoint.sh
   makefile (or justfile)
   .envrc
   **.lock (اگه باشه بنظرم عالیه)
   pyproject.toml

@PyBackendHub

یک نکته اگه دوست داشتین رعایت کنید خیلی به سطح پستای کانال کمک میکنه 🙏
اگه از یک تایپ پست خوشتون میاد reaction مثبت بدین. اگه نمیاد ری اکشن منفی بدین. من بر اساس ری اکشن و تعداد forward و کامنت و سوالایی که ازم تو پیوی میپرسن معمولا تصمیم میگیرم چه پستی مناسب تره.

@ManiFoldsPython

من واقعا اینو دیدم.. خیلی هم دیدم که نیروی های ایرانی به مراتب از نظر هارد اسکیل قوی ترن و راحت میتونن استخدام شن تو خارج کشور. ۳ مورد رو اگه تقویت کنید واقعا شانس استخدام شدنتون بالا میره:

۱. اولیش زبانه. زبان انگلیسی باید خوب حرف بزنید. من دیدم بچه ها دنبال مهاجرت کارین ولی سطح زبانشون در حد b1 هست. خب خیلی سخت پیش میاد شرکتی شما رو قبول کنه چون تا بخواین به c1 برسید حداقل چنین ماه یا حتی شاید سال زمان میبره . بنابراین هزینه training شما خیلی زیاد میشه برای شرکت و خیلی راحت بیخیال میشه. پس سعی کنید حداقل تو مصاحبه خیلی روان صحبت کنید.


۲. دومیش رزومست. رزومه غیر استاندارد مینویسن. قبول نمیشه توسط ATS ها. من خیلی افراد سطح بالایی دیدم که رزومشون واقعا ضعیف بود و این باعث کمتر شدن فرصت هاشون میشه. تو هر مقطع و سطحی که هستین باید رزومه رو خوب بنویسید. چه میخواد جونیور باشه چه principal engineer.

ریپو من راجب رزومه نویسی:
https://github.com/ManiMozaffar/awesome-resumes

۳. آخریش نشون دادن مهارته. من دیدم بعضی بچه ها واقعا مهارت خوبی دارن ولی چون تو رزومه و گیت هابشون خوب نتونستن نشون بدن به چشم نمیان. موقع بولت پوینت نویسی برین PR هایی که زدین به ریپو شرکت رو ببینید و یک دور دوره کنید. همین موضوع خودش باعث میشه ۳ سطح بولت پوینت هاتون بهتر شه چون یادتون میره چه کدایی زدین.

پلی لیست من راجب پیدا کردن شغل اول و رشد مسیر شغلی:
https://www.youtube.com/playlist?list=PLEQ3RnweNGA6ccgQkiov9Q6jnQAw8H-ob


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

@PyBackendHub

دو مقاله خیلی خوب برای بیشتر آشنا شدن با Kafka

https://medium.com/swlh/apache-kafka-what-is-and-how-it-works-e176ab31fcd5
https://medium.com/@jaykreps/exactly-once-support-in-apache-kafka-55e1fdd0a35f


@PyBackendHub

این قسمت خیلی جالبه :

For example several people in comments cited the “FLP” paper which is noscriptd “The Impossibility of Consensus with One Faulty Process”. That doesn’t sounds good! Then again you might just as easily run into a paper claiming in its first sentence that failure detectors “can be used to solve Consensus in asynchronous systems with crash failures.” What to make of this? Well this is where the detail really matter in theoretical distributed systems claims: you have to be concrete about the setting and fault-model. The FLP result is proving that consensus isn’t possible in a very limited setting. Once you allow even simple things like local timers or randomization it becomes possible. You’ll notice consensus algorithms depend on these things to implement a kind of noisy but eventually correct failure detection such as “a process that doesn’t heartbeat for some time is dead”. These are the settings people refer to when they say such-and-such an algorithm “solves consensus”.

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

@PyBackendHub