اقا 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

نکنید اینکارو :))))
@PyBackendHub

یک پکیج نوشتم, که۹ ماه پیش شبیهشو نوشته بودم.
این پکیج کاملا type stated هست. کاری که این پکیج میکنه اینه که به شما یک interface خیلی عالی میده برای هندل کردن exchange پول های مختلف رو میده. مثلا یورو به دلار. یا بالعکس. همینطور همینکارو برای crypto ها هم انجام میده. بلاکچین هم inspect میکنه. و همه اینکار هارو با داشتن یک تایپ عالی و یک تجربه توسعه عالی بهتون میده و جلوی illegal state هارو میگیره (مثل مقایسه کردن مقدار دلار و یورو بدون exchange کردنشون)

در حال حاضر فقط دلار و یورو و USDT Trc20 ساپورت میشن. اگه دوست داشتین میتونید کامیت بزنید. سورس کدش براتون احتمالا جالب باشه. برای حمایت خیلی ممنون میشم استار و یا contribute بدید 🙏

لینک گیتهاب لایبری:
https://github.com/ManiMozaffar/fastexchange

@PyBackEndHub

تو پست قبلی interface لایبری خیلی واضح نشد, برای همین عکس میدم ازش. اگه ایده ای داشتین حتما بهم بگید. تومن و بقیه کریپتو ها ساپورت شن میتونه game changer خوبی باشه.
(پ.ن‌:‌ تایپ ها یک جورین که میتونید راحت تیبلشون کنید 😅.)

برای حمایت خیلی ممنون میشم استار و یا contribute بدید 🙏

لینک گیتهاب لایبری:
https://github.com/ManiMozaffar/fastexchange


@PyBackEndHub

یک مقاله خیلی خوب بازم راجب type state که ben (بنیامین فکر کنم؟ 😁) تو گروه به اشتراک گذاشت:
Writing python like rust

همه چیزه این مقاله درست نیست قطعا ولی ایده کلیش رو اگه بگیرین خیلی بهتر کد میزنید.
اگه نمیدونید type state چیه توصیه میکنم حتما ویدیو زیر رو ببینید:
آموزش پترن type state به زبان فارسی

و یا مقاله های زیر هم خیلی بهتون میتونه کمک کنه:
Parse, don't validate in Python
Rust, for type state!

سمپل کدش هم که اخیرا ‍share کردم. یک لایبری که type state هست برای بحث کریپتو و پول. اینترفیس خیلی آسون تری میده و تجربه توسعه عالی بهتون میده. همین که استتیک تایپ چکر رو ران کنید و ایرادی بهتون نگیره احتمال خیلی قوی کدتون مشکلی نداره.
FastExchange

تایپ استیت کد زدن میتونه خیلی نحوه و سبک کد زنیتون رو تغییر بده.
@PyBackEndHub

Writing python like rust
مقاله ای که پست قبل شیر کردم بهترین مقاله ای بود که تو پایتون خوندم سمت typing

چیزی که خودم خیلی رعایت میکنم استفاده مناسب از NewType هست.
دقت کنید نیازی نیست حتما از pydantic استفاده کنید و overhead داشته باشین. فقط وقتی باید از pydantic استفاده کنید که دیتاتون ازبیرون اومده باشه. مثل بروکر یا response ای از یک api.

تو مقاله اصلا از pydantic استفاده نکرده (از serde کرده که لایبری مشابه serde راست هست. ولی فقط برای لایه بیرون لازمه. نه داخل خوده کد)

تو لایبری FastExchange علتی که استفاده کردم از Discriminated union بوده. که تو این مقاله خودش با پایتون دستی نوشته همین Discriminated union. برای نوشتن Discriminated union میتونید از pydantic استفاده کنید.

@PyBackendHub

یک چیز جالب دیدم؛
https://leetcode.com/zcgzcgzcg/
رنک ۹۴ دنیا هستن، تو لیت کد.

اما ایشون اصلا حرفه اش برنامه نویسی نیست. دارنده ۳ مدال طلا المپیک و یکی از بهترین بازیکن های پینگ پونگ تو دوران خودش بوده 😂

@PyBackendHub

یک سافت اسکیل خیلی مهم که نداشتنش میتونه محیط کاری رو تبدیل به محیط سمی کنه:
Disagree and commit
کالچری هست که تو آمازون و خیلی شرکت های خوب دنیا هست. رفرنس

At Amazon, you may know, we have a set of leadership principles that we take very seriously. I’m a big fan of the one that says “Have Backbone: Disagree and Commit.” It means that if you disagree with something, it’s your responsibility to argue. It’s meant to be applied even if it’s your boss’s idea. Disagreeing doesn’t mean acting like a jerk. It means making a cogent case, using data where possible to support your arguments. The second part of the principle, “Commit,” is important as well. At some point, you may have to give in, or compromise. If you do, then you’re committed to the decision. You can’t be passive-aggressive or later say “I told you so.” You own the final decision, even if it’s not what you originally wanted.

"دیدی بهت گفتم؟". بدترین جمله ای هست که یک نفر میتونه بگه تو یک تیم بنظرم.

تو این فیلمم jeff خودش توضیح میده
https://www.youtube.com/watch?v=Afoh23PHVP0


@PyBackendHub

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

یک دلیلی که نباید از تم دیفالت pycharm استفاده کنید. چون همه چیزو سفید نشون میده. تو این مثال baz.bar هم رنگ foo.bar میشد.
و شما نمیتونی متوجه شی چیزی که بهش دسترسی داری واقعا type داره یا نه.

پی نوشت:‌نگفتم تغییر بدین IDEرو. گفتم فقط مهمه که رنگا متفاوت باشه. که شما متوجه شین به attr درستی دسترسی پیدا کردین یا نه. دیفالتشو ظاهرا میتونید تغییر بدید...

@PyBackendHub

استفاده از privilege های pg خیلی میتونه مفید باشه. داکش زیره میتونید بخونید:
https://www.postgresql.org/docs/current/ddl-priv.html

یوزکیس هاش:
۱. اولا نیازی نیست برنامه نویسا write access داشته باشن. یک read کافیه اکثر مواقع. یا اگه write میخواین بدین دو یوزر بسازین یکی read باشه فقط یکی هم read هم write

۲. میتونید کنترل کنید که یک نفر GRANT خاصی رو نگیره. مثلا یوزر mani قابلیت دیلیت رو هیچ تیبلی نداشته باشه. یا قابلیت select رو تیبل اطلاعات شخصی کاربرا نداشته باشه و ... .


میتونید لاگ pg هم فعال کنید. که متوجه شین چه کسی چه query ای زده. از کجا رو کدوم تیبل. و کلی متا دیتا دیگه. از لینک زیر میتونید راجب لاگ pg هم بخونید.
https://www.postgresql.org/docs/current/runtime-config-logging.html

یک نکته فقط داره اونم اینه که postgresql لاگ قدیمی رو پاک نمیکنه. فقط rotate میکنه. پاک کردن لاگ قدیمی رو توصیه میکنم با logrotate انجام بدید. نه فقط لاگ pg بلکه خیلی جاها به درد بخوره.
https://linux.die.net/man/8/logrotate

@PyBackendHub

برای پسا social engineeringا هم خیلی روش دفاعی خوبیه. مثلا organization ها data breach داشتن ولی نفهمیدن از کجا خوردن :))‌ ولی لاگتون فعال کنید و هر سرویس یوزر و هر کاربر یوزر خودشو داشته باشه و لاگ انداخته شه کاملا مشخص میشه که چه اتفاقی افتاده اگه یک درصد data breach بود.

@PyBackendHub