شما تو سایت 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

تو گروه واقعا بحث های جالبی میشه دم همه گرم که فعالن 🙌 بحث کد فانکشنال و OOP شد دیشب که بحثش به امروزم رسید. من همیشه فانکشنال رو ترجیح میدم به OOP مگه طبق ویدیویی که گذاشتم چند روز پیش بخوام یا
۱. استیت ذخیره کنم
۲. بخوام abstraction انجام بدم
و من کاملا با این موافقم! ویدیو مربوطه:
https://www.youtube.com/shorts/oIyq0q5Q7eo

فانشکنال کد زدن به این معنی نیست که شما صرفا فانکشن بنویسی. وقتی فانکشنال دارین کد میزنید حتما باید declarative باشه نه imperative. و این موضوع باعث میشه
۱. فانکشن خیلی راحت تر reusable باشه
۲. دیباگش راحت تر شه
۳. تستش راحت تر شه
۴. قابل پیشبینی تر باشه
۵. باگ کمتری داره

حالا میخوام بحث declarative و imperative رو یکم باز کنم براتون که متوجه شین. یک کد basic رو میبینم با OOP
تو declarative شما کد میزنی باید هدفت رو این باشه که به چی میرسی نه اینکه چطور میرسی.
مثلا

class NumberProcessor:
    def __init__(self, numbers):
        self.numbers = numbers

    def filter_even(self):
        self.numbers = [n for n in self.numbers if n % 2 == 0]

    def square(self):
        self.numbers = [n ** 2 for n in self.numbers]

    def process(self):
        self.filter_even()
        self.square()
        return self.numbers

همینو میتونی با ۳ تا فانکشن هم بنویسی درسته؟ اسمش فانکشنال هست؟ ‌قطعا نه. چون این Imperative هست. تستش هم سخته. یعنی اینطوری نباید بشه:

def process_numbers(numbers):
    even_numbers = []
    for number in numbers:
        if number % 2 == 0:
            even_numbers.append(number)

    squared_numbers = []
    for number in even_numbers:
        squared_numbers.append(number ** 2)

    return squared_numbers

به جاش باید اینطوری شه:

def filter_even(numbers):
    return filter(lambda x: x % 2 == 0, numbers)

def square(numbers):
    return map(lambda x: x ** 2, numbers)

بازم شاید مثال خیلی خوبی نباشه چون نمیشه تو یک پیام تلگرامی کامل باز کرد موضوعو. بخوام خیلی خلاصه بگم بزرگ ترین pros و cons کد imperative اینه که ساید افتکت داره. ایا تستی که مینویسید همه اینا رو تست میکنه؟ ایا ۱۰۰درصد خیالتون راحته این وسط ساید افکتی به وجود نمیاد که باعث شه یک باگی تو برنامتون درست شه؟

do_this()
do_that()
then_this()
then_that()

در آخر اشتباه برداشت نکنید من دشمن OOP نیستم. 😁 منتهی ترجیح میدم هرچیزیو به جای خودش استفاده کنم با دونستن drawback هاش.

یک ویدیو کوتاه مربوطه از Arjan که نظرشو راجب فانکشنال و OOP گفته:
https://www.youtube.com/shorts/lEVu7_v2pbk

و یک مقاله خیلی خیلی خوب راجب functional که توصیه میکنم حتما بخونید:
https://medium.com/@olxc/switching-from-oop-to-functional-programming-4187698d4d3


@ManiFoldsPython

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

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


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

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

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

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


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

@ManIFoldsPython

برای اینکه این پستو بهتر درک کنید میخوام ۲ مثال بزنم که overengieering یعنی چی

۱. فرض کنید دارین برنامه چت تحت وب مینویسید که notification نداره. میخواین schedule message بسازین. مثل تلگرام.

۲. فرض کنید میخواین مورد یک رو پیاده کنید ولی این بار رو گوشی باشه و notification هم داشته باشه.

چیکار میکنید؟

@ManiFoldsPython

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

۱. خب من چیکار میکردم؟ تو سناریو اول کلا schedule نمیکردم! به جاش همون لحظه ای که schedule کرده پیام رو داخل دیتابیس میساختم ولی یک فیلد میذاشتم با display_at به زمان آینده که توسط یوزر تعیین شده. و وقتی بقیه کلاینت ها (تو همون گروه تلگرامی) درخواست میفرستن که محتوا رو ببینن فقط محتوایی که display_atشون کمتر مساوی زمان حال بود رو نشون میدادم.
that's it!
نه بروکر نیازه. نه استریم. نه event driven architecture
من تونستم به همون هدفی که requirement ام بوده برسم. که بقیه یوزر ها ببینن پیامو. همیشه وقتی requirement مینوسید رو how تمرکز نکنید. رو what تمرکز کنید. اگه requirement این بود که طرف schedule کنه اونوقت اون requirement احتمالا احمقانه هست چون داره رو نحوه پیاده سازی دخالت میکنه.


@ManiFoldsPython

و در نهایت همین سناریو ساده میتونه پیچیده تر شه...
مثلا تو این مثال میتونیم یک ورکر بذاریم پیام هایی که زمان displayAtشون رسیده و فرانت قراره نشون بده به کلاینت, رو با یک ورکر به صورت periodically بگیریم.

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

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

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

این over engineering رو خیلی زیاد دیدم .. بنظرم فقط تو مصاحبه خوبه که یکم نشون بدین بلدین(پز بدین) 😁

@ManiFoldsPython

تو گروه بحث خوبی شد راجب ساید افکت. مهدی سورس خوبی رو گفت که میتونید ساید افکت رو مطالعه کنید و متوجه شین چیه دقیقا. لاگ انداختن ساید افکت نیست.
https://en.m.wikipedia.org/wiki/Side_effect_(computer_science)

من همونطور که اشاره کردم فقط functional نمیزنم. فانکشنال خالی و pure نوشتن اصلا اونقدر ساپورت خوبی نداره تو پایتون. پس بازم OOP هم نیازتون میشه. من خودم ترکیبی مینویسم ولی بیشتر اخیرا سعی میکنم فانکشنال کد بزنم چون ساید افکت نداره و تستش راحت تره. مثال قبلی بد بود. شاید با این مثال بهتر درک کنید:

یک مثال تمیز از داشتن و نداشتن ساید افکت:

class Order
   def deliver(self): ...

def deliver(order: StartedOrder) -> DeliveredOrder:
    .

..


استیت اوردر بعد از اجرای فانکشن دلیور تغییر میکنه. ولی فانکشن دلیور تو مثال دوم یک آبجکت جدید میسازه که میدونیم چیه و side effect نداره و راحت تست میشه.
برای تست کردنش:

result = deliver(order)
assert isinstance(

result

, DeliveredOrder)

# OOP
order.deliver()
assert ... # assert all the side effects now if you dare

@ManiFoldsPython

✔️ در طی چند سال گذشته از فعالیت کانال، محتواهای رایگان زیادی تولید شده و هدف کانال هم از ابتدا اشتراک دانش رایگان و عام المنفعه بوده، برای همین تصمیم گرفتیم یک بار دیگه تمام این محتواهارو در یک پیام قرار بدیم تا به راحتی قابل دسترسی برای افراد علاقمند به یادگیری باشه:

✅🎥 کانال یوتوب سیلیسیم مهران تعریف (آموزش پایتون و جاوااسکریپت و...)
https://www.youtube.com/@Silicium7

✅🎥 کانال یوتوب میکروفرانت اند (آموزش پایتون و جاواسکریپت و ...)
https://www.youtube.com/@MicroFrontend

✅🎥 کانال یوتوب بابی کلاد (آموزش پایتون، کلاد، دوآپس و ...)
https://www.youtube.com/@bobycloud

✅🎥 کانال یوتوب امیر مطهری (آموزش پایتون، میکروپایتون و ...)
https://www.youtube.com/@AmirMotahari

✅🎥 کانال یوتوب گیت اور هیر مانی (آموزش پایتون، دیزاین پترن و ...)
https://www.youtube.com/@GitOverHere

✅🎥 کانال یوتوب تورهام (آموزش پایتون، فست ای پی آی و ...)
https://www.youtube.com/@techwithtori

✅🎥 کانال یوتوب شهریار شریعتی (آموزش سلری، جنگو چنلز، وب فریمورک ها و ...)
https://www.youtube.com/@ShahriarShariati

✅🎥 کانال یوتوب دوآپس هابیز (آموزش امیربهادر - دوره پروژه محور جنگو به همراه داکر، سی آی سی دی و ...)
https://www.youtube.com/watch?v=KtYDIJN3wmM&list=PLYrn63eEqAzY5uG5ks_OquWcojzHvhp9Z

✅🔥 سه فایل مصاحبه با آقای حسن رمضانی که از Core Developer های Django, Gunicorn, Pydantic, Urllib3 و ... هستند در کانال موجود هست که با سرچ کردن اسم آقای "حسن رمضانی" در کانال میتونید مصاحبه هارو پیدا کنید و گوش بدید.

✅📚 ریپازیتوری گیتهاب Awesome Python Resources: مجموعه ای از بهترین و کامل ترین ریسورس‌های مورد نیاز برای رشد در مسیر شغلی مهندسی نرم افزار (پایتون) به همراه تفکیک بر اساس Career Path و Advanced Topics
https://github.com/DjangoEx/awesome-python-resources

✅📚 ریپازیتوری گیتهاب Awesome Python Roadmaps: مجموعه از رودمپ‌های مورد نیاز یک مهندس نرم افزار (پایتون) در Career Path هایی نظیر Backend، Data Scientist، Software Architect و ...
https://github.com/DjangoEx/awesome-python-roadmaps

✅📚 تمام ریپازیتوری‌ها به صورت یکجا نیز در صفحه گیتهاب DjangoEx قابل دسترسی هست
https://github.com/DjangoEx

✅ تمام این موارد آموزشی رایگان هستند و میتونید ازشون استفاده کنید.
✅ موقت: اگر مطلبی رو یادم رفته بزارم و قبلا توی کانال تولید محتوا داشتند لطفا به من (@BobyCloud) پیام بدید.

#رودمپ #پایتون #جنگو #منابع #از_کجا_شروع_کنیم

〰️〰️〰️〰️〰️〰️
© @DjangoEx

اف تاپیک؛ این بار ولاگ استایل :))

۴ روزه اومدم برلین. واقعا شهر باحالیه. نکته جالبش اینه که هرجور کالچری شما اینجا میبینی… از رستوران ایرانی تو مال بگیر تا کره ای ژاپنی چینی. من حتی از رستوران اِتیوپی هم رد شدم 🤣 و هرکی تو اون رستوران کار میکنه برای اون ملت و فرهنگه. همه انگلیسی حرف میزنن و حداقل تا الان تو برخورد های اول ادمای خیلی مهربون و خوبی بودن 🫠 خیلی قشنگه واقعا مردم اینطوری باهم کنار میان و نمیبینی مثلا بگن “go back to your country” و این چیزا…

تنها چیز مزخرف برلین تا اینجا با اختلاف زیاد هواش بوده… همش سرده همش بارونی ساعت ۳-۴ هم تاریک میشه😂 و کمبود خونه برای اجاره

@ManiFoldsPython

تو این پست میخوام ثبات داده رو بهتون توضیح بدم که به ۲ نوع وجود داره:

بذارین مثال بخوام بزنم که تفاوتشو متوجه شین. مثال خیلی راحت میزنم distributed system هم نباشه. فکر کنید دو تا سیستم دارین که یکی به اون یکی وابسته هست. مثلا یک api ساختین برای جمع آوری دیتا وضعیت آب و هوای همه کشور و شهر های دنیا. و هر پایگاه آب و هوایی هم سیستم خودشو داره و با api ای که شما ساختین حرف میزنه و براتون اطلاعات میفرسته.

دو تا راه حل دارین:
۱. تو هر دقیقه براتون دما اون شهرو بفرستن که میشه strong consistency
۲. هر یک ساعت یک بار تک تک دمای یک ساعت گذشته رو براتون ارسال کنند که میشه eventually consistent. و بعد شما همرو با هم insert کنی تو دیتابیس.

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

اگه یکم بهش فکر کنید و جدول هم ببینید متوجه میشین pros و cons هر روش چیه و به جاش با آگاهی راجب ثبات داده تو اپلیکیشنتون با قاطعیت باید تصمیم بگیرین.

@ManiFoldsPython