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

۱. این دوره بهتون مایندست. software engineer میده تو context دیزاین برنامتون.
۲. دوستان دیزاین صفر تا صد نظر شخصیه. مثل فلسفه. چیزی نیست که absolute باشه. بگید یا یکه یا صفر. نظرات زیاده. آدم بهتره هرچیزی که با ذهنش جور درمیاد رو رعایت کنه

مثال میگم من دیروز داشتم با یکی از دوستام بحث میکردم که settings.py نباید یک کلس باشه و lazy گرفته شه. چون IDE نمیتونه بخونه. چون من نمیتونم سریع از تو IDE برم تو کد لایبری و ببینم چه چیزایی داره و باید حتما داک لایبریو بخونم.

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

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

من مطلبی تو کانالم میگم ممکنه اشتباه باشه. این کانال دفترچه یادداشت منه. طرز فکر منه. بنابراین ممکنه با طرز فکر شما یکی نباشه و هیچ ایرادی نداره و خوشحال میشم اتفاقا روش بحثم بکنیم که با طرز فکر شمام آشنا شم.

@ManiFoldsPython

این دوره رو خیلی وقت پیش گذاشتم تو گروه
و واقعا توصیه میکنم هر پایتون کاری ببینه اینو 👌
مخصوصا از فصل ۸ تازه شروع میشه.

کسایی که کامل دیدن هم نظرشون رو کامنت کنند بقیه هم استفاده کنن 😁
@ManiFoldsPython

✔️ در ویدیو جدید یوتوب به سراغ این مبحث میریم که یک برنامه نویس چقدر لازمه از ابزارهای دوآپس بدونه؟
و با ذکر مثال هایی در زمینه‌های زیر راجع بهش گپ میزنیم:

- CI/CD
- Automation
- Containerization & Orchestration
- Monitoring & Logging
- Security
- Scalability
- Disaster Recovery
- etc.

🖥 مشاهده در یوتوب
👉 Link: https://youtu.be/RdE-SM3x-a0?si=eWfySBth6y3mK8i5

〰️〰️〰️〰️〰️〰️
@BobyDotCloud

Talk and think about problem, before coding the solution
@ManiFoldsPython

شما تو سایت roadmap.sh رو هر آیتم کلیک کنید اینطوری چند تا suggestion میاره. برای شروع و آشنایی باهاش ریسورس های خیلی خوبین.

@ManiFoldsPython

این روزا برای distributed tracing خیلی OpenTelemetry محبوب شده. میخوام تو این پست OpenTelemetry رو معرفی کنم و بگم کاربردش چیه و چرا محبوب شده؟

دلیل محبوبیت زیادش چیه؟‌
چون خیلی قابلیت کاستومایز داره و درواقع یک سری کانوشنه که همه رعایتش میکنن و شما باید بدونی این مواردو.

اصلا distributed tracing یعنی چی؟
Distributed tracing is a method of tracking application requests as they flow from frontend devices to backend services and databases. Developers can use distributed tracing to troubleshoot requests that exhibit high latency or errors.

حالا خود opentelemetry چیه؟
یعنی مجموعه از قوانین و api و sdk و ابزار مختلف که instrument میکنن پروداکتتون رو, و در نهایت خروجی بهتون داده های تله متری میدن.
در واقع شرکتای بزرگ به این نتیجه رسیدن که یک سری کانوشن بذارن و طبق اون observability رو انجام بدن به جای اینکه هر کدوم ساز خودشونو بزنن.

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

حالا چند تا سوال پیش میاد. داده های تله متری چیه؟
از سه بخش تشکیل شده:
۱. متریک ها:‌متریک ها معمولا تایم سریز هستند مثل مموری که اپلیکیشن شما مصرف کرده
۲. لاگ:‌لاگ هایی که برنامتون انداخته
۳. تریس‌(trace):‌تریس به ما میگه که تو یک event داخل اپلیکیشنمون چه اتفاقی افتاد. مثلا فکر کنید سفارشی اضافه شده به سایت شما. در واقع اون سفارش یک trace داره. از فرانت شروع میشه میاد api بک اند. میره داخل kafka و تو ۱۰ تا سرویس میچرخه. و وضعیتش تغییر میکنه. همیشه base trace درواقع باید base event تون باشه.
تریس به ما خیلی کمک میکنه چون مثلا متوجه میشیم که تو فلان سفارش یک باگی اتفاق افتاده. با دیدن trace اش دقیقا متوجه میشیم چه مسیری رفته که بتونیم باگ رو پیدا کنیم و reproduceاش کنیم

این روزا open telemtry خیلی استفاده میشه. مثل از نسخه ۶ دات نت به صورت دیفالت اضافه شده بهش. یا از august امسال داخل cloud watch aws اضافه شده. همینطور sdk های open telemtetry برای همه زبونا موجوده برای لایبری های مختلف و یوزکیس های مختلف. مثل سلری جنگو فست wsgi asgi یا حتی orm های مختلف مثل sqlalchemy

یک نکته جالب, اینکه sdk هایی که تو زبون های مختلف داره همه توسط شرکتای بزرگ مثل گوگل و aws و Cisco و datadog و microsoft کاملا maintain میشه و میتینگ دارن و تو میتینگ هاشون میتونید شرکت کنید.

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

سایت رسمی opentelemtry
- https://opentelemetry.io/

ریپازیتوری گیتهاب sdk های پایتونی
- https://github.com/open-telemetry/opentelemetry-python

تمام ریپازیتوری ها
- https://github.com/open-telemetry

داک ریپازیتوری پایتونی:
- https://opentelemetry-python.readthedocs.io/

کانوشن های opentelemtry و تمام specification:
- https://github.com/open-telemetry/opentelemetry-specification

@ManiFoldsPython

تو کامنتا به موضوع مهمی اشاره شد, اشتباه نکنید Open Standard نیومده جای prometheus یا grafana رو بگیره. اینا کاربرادشون باهم مختلفن. الان یکم توضیح میدم:

Open standard
تمرکزش روی observability اپلیکیشن هست. که تو پست بالا کامل توضیح دادم. حتی sentry هم بر پایه open standard داره میشه. زمانی که sentry محصول خودشو شروع کرد هنوز اوپن استاندارد رو فاز بتا بود برای همین باعث شد تفاوت های جزيیی بین sentry و open standard به وجود بیاد که الان چند ماهه sentry کامل از open standard پ شتیبانی میکنه ولی در کل هدف جفتشون observability هست.

راجب grafana
گرافانا برای visualize کردن دیتا هست از دیتاسورس های مختلف. میتونه گوگل شیت باشه. میتونه دیتابیس خودتون باشه. میتونه Prometheus هم باشه. صرفا برای نمایش دیتاست. همین. کنارش alert manager و اینا هم داره که خب میتونید استفاده کنید.

اما Prometheus
برای جمع آوری دیتا تایم سریز به صورت real time طراحی شده. بیشتر برای بحث مانیتورینگ به کار میره و کلی ماژول مختلف داره برای مانیتور postgresql مثلا یا ردیس یا بروکر هاتون یا هرچیز دیگه ای. خودش یک زبون query کاملا جدا به نام PromQL داره.

پس خلاصه بخوام بگم open standard برای مانیتورینگ نیست. برای Observability هست. تفاوت monitoring و Observability:
Monitoring tells you that something is wrong. Observability uses data collection to tell you what is wrong and why it happened


برای visualize کردن دیتا open standard معمولا از ‍ui های مختلف میتونه استفاده شه مثل:
signoz
jaeger ui
Zipkin


پس اینارو باهم قاطی نکنید.
من به نظرم تو سال ۲۰۲۴ دیگه open standard جزو چیزاییه که یک برنامه نویس باید باهاش آشنا باشه و بدونه چطور کار کنه. (چه فرانت چه بک) چون هر روز داره محبوب تر میشه و به زودی تبدیل به job requirement ها میشه. پس وقت بذارین به نظرم و یادش بگیرین.

من متاسفانه چون درگیر مهاجرت و اینا شدم دیگه نتونستم مدتی فیلم ظبط کنم. ایشالا وقتی stable شدم اینجا و سیستممو حاضر کردم دوباره ریکورد میکنم و یکی از برنامه هام هم دوره ای برای open standard هست.

@ManiFoldsPython

پست امروز رو با دو سوال سطح سخت SQL شروع میکنم:

شما فرض کنید مقداری تراکنش یا سفارشات داخل یک دیتابیس روزانه دارین, به همراه قیمتی که فروخته شدن و مقدارشون و زمان فروخته شدنشون, مثلا:

id product_id product_amount total_price created_at
1 1 20 100,000 ...


۱. یک query بزنید که تغییر قیمت رو به صورت روزانه به ازای تمام record ها دربیاره. و البته میانگین قیمت اون روز 🙂 با فرض اینکه فقط برای یک product id رو میخواین در بیارین (product_id = 1). تغییرات قیمت یعنی مثلا امروز پروداکت id=1 به ازای هر یک دونه اش ۱۰۰ تومن بوده میانگینش, فردا شده ۹۹ تومن, پس ۱ تومن کم شده. اینو باید تو query اول به دست بیارین. که میشه -۱ مثلا. یا میتونه مثبت هم باشه. یعنی نسبت به روز قبلش باید حساب کنید ارزون شده یا گرون و چقدر؟.

۲. تیمی که سفارشات رو حاضر میکنه سفارشات رو export میگیره. همچنین داخل مغازه هم سفارشاتی میرسه. سپس مجددا دیتا رو ایمپورت میکنه. حالا تیم میخواد یک import به برنامه بده که اگه سفارش وجود داشت با مقادیر جدیدی که داخل اکسل داده آپدیتش کنه و اگه وجود نداشت بسازش. و در آخر بعد از ایمپورت متوجه شه چه سفارشاتی آپدیت شده و چه سفارشاتی ساخته شده. این رو با 1 query بنویسید.

راهنمایی:‌ دیتابیسمون PostgreSQL هست.وقتی تو رزومتون میزنید PostgreSQL بلدین یعنی دقیقا همچین Query هایی رو باید باهاشون آشنا باشین!
راهنمایی دوم:‌این دو query خیلی کوتاه و خوانا هستند!

@ManiFoldsPython

سید جواب سوال یک رو داد. اما چطوری جواب سوالا رو بدیم؟‌بحث میزان آشنایی با SQL و PostgreSQL هست. با توابع و window function ها اشنایی داشته باشیم. چیزایی که میتونه PostgreSQL رو خاص کنه.

اولین سوال چیه؟‌سوال راجب Financial analysis هست. اگه با LAG آشنا باشین دقیقا کاربرد اساسیش همینه. هرجایی که comparision و analysis بر اساس دیتا های قبلی و بعدی باشه میتونیم از lag استفاده کنیم. برای Performance Metric هم خیلی به درد میخوره! یا برای آنالیز Sequence ای از دیتا ها. مثلا آنالیز کن کاربر هایی که ۵ تا سفارش دادن ایا هر سفارششون بزرگ تر از سفارش قبل هست یا نه؟‌ (مثلا سفارش پنجیمشون بزرگ تر از چهارمیه؟) کل این با یک queryبدست میاد. معمولا هم خیلی خوانایی بالایی داره. یک نکته دیگه این سوال استفاده از cte هست چون اول باید دیتا رو batch کنیم (سفارشات هر روز رو)‌و بعد آنالیزشون کنیم. طبق جواب سید:

WITH DailyPrices AS (
    SELECT  DATE(created_at) AS date,  AVG(total_price / product_amount) AS average_price
    FROM orders WHERE product_id = 1 GROUP BY DATE(created_at)
)
SELECT 
    date,
    average_price,
    average_price - LAG(average_price) OVER (ORDER BY date) AS price_change
FROM 
    DailyPrices;

سوال دوم. خب مشخصه از ما mass operation میخواد. مثل mass insert. اگه نمیگفت آپدیت شدن یا ساخته شدن رو نشون بده اونوقت از upsert استفاده میکردیم. upsert یعنی اگه وجود داره update کن اگه نه insert. پس باید upsert رو به نوعی خودمون بسازیم. upsert چیکار میکنه دقیقا؟‌اول سعی میکنه insert کنه بعد اگه conflict به وجود اومد update میکنه. همینو کافیه خودمون بنویسیم و در نهایت بگیم که ایا اپسرت شده یا ایسنرت. نکته خیلی مهم تر هم اینه که RETURNING داشته باشیم. خیلی مفیده این. به شما میگه چه دیتایی رو آپدیت کردین

INSERT INTO product_order (id, user_id, product_id, product_amount, total_price, status)
VALUES 
    (UUID..., 'txn1001', 1, 1.5, 15000, "DONE"),
    (UUID..., 'txn1002', 1, 2.0, 20000, "DONE"),
    (UUID..., 'txn1003', 1, 0.75, 7500, "DONE")
ON CONFLICT (id)
DO UPDATE SET
    status = EXCLUDED.status,
RETURNING id, user_id, product_id, product_amount, total_price, status
CASE WHEN xmax::text::int > 0 THEN 'Update' ELSE 'Insert' END AS operation_type;

که طبق تابعی که نوشتم میتونید متوجه شین update بوده یا insert.
نکته مهم سوال اینه که
۱. با upsert آشنا باشین
۲. با returning آشنا باشین
۳. با on conflict آشنا باشین

@ManiFoldsPython

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

۱. با وجود اینکه میدونید من چقدر sqlalchemy رو بخاطر تایپینگ خفنش دوست دارم و نزدیک بودن به SQL ولی متاسفانه ساپورت LAG رو نداره که اتفاقا خیلی مهمه. مثلا فکر کنید صورت حساب میخواین بنویسید. جوابی که با lag درمیاد خیلی بهینه تره تا اینکه سعی کنید از روش های دیگه برین جلو. ولی این query رو خیلی راحت میتونستین با orm django بنویسید.

۲. اما query دوم رو هم با جنگو نمیتونستین بنویسید. با sqlalchemy میشد.

پس مهم نیست از چه ‍orm ای استفاده میکنید. اینو دیدم چون دیدم دیشب دو نفر سره اینکه orm خوبه یا بده دارن دعوا میکنن, قبلا هم دیدم که فردی میگفت sqlalchemy بهترین orm عه یا django orm بهترینه. بنظرم اصلا منطقی نیست. سولوشنی وجود نداره فقط drawback هست. من میتونم بگم هر orm ای یک جایی drawback داره و یک جایی نداره. تو هر پروداکت اگه orm بتونه queryهای خوب و بهینه به اندازه مورد نیاز جنریت کنه تو کمترین زمان انتخاب مناسبیه با کمترین raw query نوشتن ممکن چون maintain اونا سخت تره تا maintainشون با orm. حالا ممکنه برای یک پروژه django orm این موضوع صدق کنه و یک پروژه sqlalchemy. پس خیلی حساس نباشید رو این قضیه. واقع بین باشین رو drawback هایی که وجود داره و قبولش کنید. بهتون کاپ افتخار نمیدن اگه تکنولوژی که استفاده میکنید drawback نداشته باشه, بلکه کم سواد هم میگن چون نتونستین drawback هایی که داره رو شناسایی کنید و قبولش کنید.

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


@ManiFoldsPython

کامنت حق حامد تو کامنتا به نقل قول از Greg Young:

میگن یکی از بزرگترین چیزایی که یه فرد C لول تو یه شرکت یاد میگیره اینه که در جواب هر سوالی بگه It depends

@ManiFoldsPython

دوستانی که میپرسن چطور من sql یاد گرفتم:

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

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

۳. همین query هایی که طی روز مینویسید تلاش کنید بهینه و با ۱ هیت بنویسید. با ۱ هیت نوشتن دلیل بر این نمیشه که query بهینه شد. explain و analyze رو بزنید ببینید چه اتفاقی داره میفته. با مفاهیم داخل دیتابیس آشنا باشین. بدونید cost estimate و execution plan وactual time و rows and width و buffers چیه. صرفا سریع ران شدن هم دلیل بر آپتیمایز بودن یک query نیست. ممکنه مموری خیلی زیادی مصرف کنه. پس متریک های دیتابیس رو یاد بگیرین. و کار کردن باهاش رو. مثل یک زمین بازی میمونه هرچی بیشتر توش بازی کنید بیشتر یاد میگیرین.

آیا مهمه؟
صد در صد 🙂 اخیرا دیدم تو community پایتون خیلی مانور میرن رو اینکه پایتون رو بشدت دیپ شن. بد نیستا ولی اولویت بندی کنید از بقیه چیزا غافل نشید. خیلیا که با orm کار میکنن اگه ۵ تا سوال sql ازشون بپرسن بلد نیستن چون تو عمرشون زیاد تو دیتابیس نچرخیدن و سرو کله نزدن.

@ManiFoldsPython

پی پست open telemetry که پریروز گذاشتم و معرفیش کردم, یک نفر ممکنه بگه چرا من بیام این همه داک بخونم و ازش استفاده کنم؟ خودم میرم یک چیزی مینویسم با یک میدلور کارو در میام. Keep it simple و don't overengineer.

خب تو جواب این کار باید بگم که keep it simple با shitty way خیلی فرق میکنه. این open standard که من معرفی کردم specificationاش توسط system designer هایی تهیه شده که سال ها با این چالشا درگیر بودن و پشت هر تصمیم دیزاینی که وجود داره کوله باری از تجربه هست. از شرکت های بزرگی هستن و رو پروداکت های بزرگی کار کردن مثل datadog یا aws cloudwatch.

نیازه سیستم مانیتورینگ و یا observability اینه که اگه خوده بک اند یا بقیه سرویسا پایین بیان نباید این سرویس پایین بیاد. مثلا بیاین فرض کنیم از همون دیتابیسی که برای monitoring استفاده کردیم برای بک اند و جنگومون هم بکنیم. خب اگه داون شه جفتش باهم داون میشن. و وقتی جفتش باهم داون شن سیستم سایلنت میشه یعنی دیگه نمیفهمیم اکسپشن رخ داده. خب این دلیل وجود خوده سیستمی که دیزاینش کردیم رو زیرسوال میبره نه؟

پس همیشه مرز بین shitty way رو بدونید با کار استاندارد. keep it simple یعنی شما تو نسخه اول استفادتون بیاین از همون sdk و لایبری هایی که خودش داره استفاده کنید که سریع خروجی رو ببینید و ایا ببینید به دردتون میخوره و بیزنستون در حدی بزرگ شده که بخواد این مفید باشه براتون؟ ‌بعد برین دورش کد بنویسید و لایبری های instrumentationاش رو کاستومایز کنید.

@ManiFoldsPython

یه جمله خیلی بامسما در کتاب Clean Code in Python هست که میگه:

Having maintainable software is not about anticipating future requirements (do not do futurology!)

ترجمه: داشتن یه نرم‌افزار قابل‌نگهداری به معنی پیش‌بینی نیازمندی‌های آینده نیست. (آینده‌پژوهی نکنید!)

اینجا "پیش‌بینی" به معنی تخصیص انرژی و زمان واسه ساخت یه بستر برای توسعه ساده‌تر در آینده با توجه به نیازمندی‌هایی هست که بعدها ممکنه بوجود بیان.

منظور اینه که بجای اینکه بیایم ذهنیت، معماری و دیزاین رو محدود به آینده کنیم، سعی کنیم نیازمندی‌های فعلی رو برطرف کنیم.

یه مثال کاربردی می‌زنم تا درک این قضیه ساده‌تر شه. فرض کنید شما یه Shop طراحی کردید و فقط یه متد پرداخت دارید و اونم PayPal هست. درحالی که دارید کلاس PayPal رو طراحی می‌کنید، این فکر به ذهنتون خطور می‌کنه که شاید بعدها متد پرداخت Stripe هم به سیستم اضافه شد. اونوقت من باید یه کلاس عین PayPal واسه Stripe درست کنم.. چرا از همین الان یه Base Class درست نکنم و PayPal و Stripe از اون بیس‌کلس ارثبری نکنن؟

موضوع اینه که هنوز نه به باره.. نه به داره.. استرایپ کو؟! داری عملا از دیزاین‌پترنی استفاده می‌کنی که اصلا نیازی بهش نداری. بله. درسته. این یه دیزاین OOP پرفکت هست و بهتره که همچین حرکتی رو بزنی ولی آیا الان؟!

اینجاست که Over-engineering کار دست آدم می‌ده. بنظرم این دو موضوع Overengineering و Overthinking در کنار هم میان. تمرکزتون رو بذارید روی نیازمندی‌های فعلی و سعی کنید سلوشن خوب برای الان بدید.. بعدا با تغییر نیازمندی‌ها، می‌تونید سراغ دیزاین‌پترن‌ها و متدلوژی‌ها و معماری‌های پیچیده‌تر هم برید!

میم امشب 😂
@ManiFoldsPython

میخواستم تشکر کنم بابت حمایتتون این چند روزه ویدیو ها خیلی سین خوردن تو یوتیوب 🥲🙌

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

@ManiFoldsPython