Python BackendHub
بنظرم دانش تو زمینه بک اند به ۳ قسمت تقسیم میشه، که خیلی مهمه سه تاشو داشته باشیم. مثلا فکر کنید میخواین یک rest api بنویسید به همراه تست. قسمت اول بلد بودن فریم ورکی برای اینکاره. مثل پای تست و فست. ولی بلد بودن اینا کافی نیست فقط قسمت دوم، فلسفه پشت اون…
توصیه شخصی, دیدم بعضیا میخوان یک فریم ورک یا زبون جدید یاد بگیرن خیلی سریع میرن سراغ یک پروژه خیلی خوب. (از جمله خودم تا چند وقت پیش). ولی حقیقتا خیلی کمکتون نمیکنه.مثلا من برم یک پروژه خفن FastAPI ببینم و سعی کنم همون پترن رو تکرار کنم. چه مشکلی ایجاد میکنه؟ دید منو به شدت کور و محدود میکنه. یعنی چی؟ فرض کنید شما کاناله منو دارین دنبال میکنید, یک پروژه فست دارین میخواین تصمیم بگیرین چطور با دیتابیس کانکت شید. خب راه های مختلفی هست, مثل استفاده از orm و چه orm ای هم مهمه. یک راه حل اینه که شما صرفا چیزی که من نوشتم رو دنبال کنید, که اصلا ممکنه حرف من درست نباشه یا دیدم bias باشه.
خب چیکار باید کنیم؟ نظره من اینه که شما باید بتونید سبک سنگین کنید. ببینید کسی که از orm django استفاده کرده چی گفته (تو اینترنت مقاله پیدا کنید). درک کنید چرا یک نفر از orm django خوشش میاد و یک نفر بدش میاد. همینکارو برای بقیه orm های پایتونی هم انجام بدید. و البته یک قدم خارج تر شید. فلسفه استفاده orm چیه؟ چه فلسفه ای پشت orm django هست؟ چه فلسفه ای پشت sqlalchemy هست؟ query builder چیه؟ فرقش چیه با orm؟ یعنی خیلی فلسفه ها صرفا تو طرز استفاده از ابزاره, نه تنوع یا فیچر های مختلف یک ابزار.
@PyBackendHub
خب چیکار باید کنیم؟ نظره من اینه که شما باید بتونید سبک سنگین کنید. ببینید کسی که از orm django استفاده کرده چی گفته (تو اینترنت مقاله پیدا کنید). درک کنید چرا یک نفر از orm django خوشش میاد و یک نفر بدش میاد. همینکارو برای بقیه orm های پایتونی هم انجام بدید. و البته یک قدم خارج تر شید. فلسفه استفاده orm چیه؟ چه فلسفه ای پشت orm django هست؟ چه فلسفه ای پشت sqlalchemy هست؟ query builder چیه؟ فرقش چیه با orm؟ یعنی خیلی فلسفه ها صرفا تو طرز استفاده از ابزاره, نه تنوع یا فیچر های مختلف یک ابزار.
@PyBackendHub
👍38👎3👏2
Python BackendHub
#otel سوال پرسیدن که این پکیج چیه اصلا و کارش چیه. اولا باید بگم اگه onboarding guide اش رو بخونید خیلی راحته استفاده ازش. تو ۱ دقیقه میتونید بالا بیارین و شروع به استفاده کنید. بدون اینکه چیزی رو بخواین هاست کنید. اول بذارین توضیح بدم observation یعنی…
#otel
تو پست قبلی که ریپلای زدم به زبون خیلی ساده توضیح دادم opentelemetry یا همون otel چیه. در ادامه سری پست های opentelemetry (که مخففش میشه otel) میپردازیم به ۴ تا component بسیار مهم که بدنه otel رو تشکیل میدن. همونطور که گفتم otel صرفا یک specification ای هست برای observation. پس خیلی مهمه که بدونید. این component ها چی هستن و چرا وجود دارن.
اولی که حتما آشنایی دارین باهاش لاگه. که زیادی به توضیح نمیخواد. لاگ قدیمی ترین شکل observation در یک نرم افزار بود. دومی event هست. event هم لاگه ولی با این تفاوت که event کاملا structure مشخصی داره. تو otel لاگ قابل قبول نیست و همیشه باید event بسازین. معمولا پکیج های otel خودکار لاگ شما رو تبدیل به event میکنن پس نیازی نیست نگرانش باشی. یک نمونه ساده از event اینطوریه:
{"event":"Failed to connect to DB","level":"warning","timestamp":"2024-02-15T12:45:32.681868Z","logger":"foo_module"}
ایونت به عبارت ساده تر لاگیه که تایم استمپ داره و راحت تر query میشه.
قسمت سوم otel میشه span. چیه دقیقا و فرقش با لاگ (یا ایونت چیه)؟ span یک نقطه استارت و یک نقطه انتها دارن تو زمان. یعنی تو یک بازه زمانی هستن. و هر span کلی event میتونه داشته باشه.
یعنی به عبارت ساده تر لاگ یا event درواقع یک عکسی هست از یک لحظه از execution در نرم افزار شما. ولی span یک فیلم ۳ بعدیه از یک کاری که در نرم افزار شما انجام شده. و نکته جالب تر اینه که span میتونه key attribute داشته باشه. مثلا من یک span دارم که وقتی کاربر محصولی اضافه کرد, یک مدل train شده باید اطلاعات رو از اون عکس محصول extract کنه و به محصول اضافه کنه (مثل رنگ و اینا).
تو این کیس منطقیه که اسم span من باشه "extracting metadata from product" . و attribute ای داشته باشم به اسم image_id که بدونم داره رو چه عکسی این اتفاق میفته. user_id هم مناسبه چون میدونم عکس برای چه یوزریه. تعداد تگ هایی که مثلا extract شده هم میتونم key value کنم. "extracted_tags". این شد یک span خیلی با ارزش. این مثالو تا اینجا داشته باشین.
و در آخر trace رو داریم. که مجموعه ای از span ها میشن یک trace. هر کدوم از این اسپن ها میتونن تو یک سرویس و یک جای مختلف سیستمتون اتفاق افتاده باشن. لزوما نیازی نیست این اسپن ها به ترتیب باشن. میتونن همزمان اتفاق افتاده باشن که میشه end-to-end view از سیستمتون. بخوام ساده تر بگم trace در نهایت میشه یک سریالی که چند فیلم 3d کنار هم گذاشتین و همه اینا به هم مربوطن و باهم معنی پیدا میکنن.
حالا به چه دردی میخوره؟ فکر کنید تو facebook marketplace دارین کار میکنید. و همون flow ای که بالا تر توضیح دادم هست. یوزر عکس یک محصولی رو آپلود میکنه به یک api ای. و بعد متا دیتا اون عکس extract میشه و در نهایت به عده ای از کاربران که علاقه دارن به اون category از اون محصول ایمیل ارسال میشه که مثلا همچین محصولی تو مارکت فیسبوک اومده.
به شما تیکت میدن که چرا فلان یوزر عکسش هیچ تگی نداشته؟ شما بلافاصله داشبوردتون رو query میکنید
تمام. حالا شما همه span هایی که مربوط به اون یوزره و هیچی extract نکرده رو میبینید. حالا رو یک span مورد نظرتون کلیک میکنید. و trace رو میبینید. trace اش چی میشه؟میشه از اون نقطه ای یوزر عکسو از فرانت آپلود کرد تا اون موقعی که ایمیل فرستاده شد به یوزر های دیگه. کل این میشه trace. و لاگ هر span ای که تو هر جای سیستمتون داشتین رو اینطوری میتونید بخونید و راحت دیباگ کنید.
یا لزوما reactive نیست.یک سیستمی که خوب instrument شده (observability خوبی داره) میتونه کاره مانیتورینگ هم تا حدی انجام بده. شما دیتا خیلی راحت تو این case میتونید پرفونس مدل هاتون رو graph کنید که روزانه چند در صد عکس ها تگ میشن. چقدر تگ میشن. با percentile نشون بدید اینو.
ولی صبر کنید تموم نشده! یک سیستمی که خوب instrument شده خیلی راحت میتونه دیتا برای business analytics هم داشته باشه. سوال اینجاست که من ایمیل فرستادم به یوزر های دیگه. آیا اونا رو ایمیل کلیک کردن و محصول رو خریداری کردن؟ چند درصد اینکارو کردن؟ ادامه همین مسیر هم میتونست تو همون trace باشه!
خلاصه اینکه opentelemetry رو دست کم نگیرین😁 باهاش میشه جادو کرد. به شرطی که درک کنید برای چی ساخته شده.
@PyBackendHub
تو پست قبلی که ریپلای زدم به زبون خیلی ساده توضیح دادم opentelemetry یا همون otel چیه. در ادامه سری پست های opentelemetry (که مخففش میشه otel) میپردازیم به ۴ تا component بسیار مهم که بدنه otel رو تشکیل میدن. همونطور که گفتم otel صرفا یک specification ای هست برای observation. پس خیلی مهمه که بدونید. این component ها چی هستن و چرا وجود دارن.
اولی که حتما آشنایی دارین باهاش لاگه. که زیادی به توضیح نمیخواد. لاگ قدیمی ترین شکل observation در یک نرم افزار بود. دومی event هست. event هم لاگه ولی با این تفاوت که event کاملا structure مشخصی داره. تو otel لاگ قابل قبول نیست و همیشه باید event بسازین. معمولا پکیج های otel خودکار لاگ شما رو تبدیل به event میکنن پس نیازی نیست نگرانش باشی. یک نمونه ساده از event اینطوریه:
{"event":"Failed to connect to DB","level":"warning","timestamp":"2024-02-15T12:45:32.681868Z","logger":"foo_module"}
ایونت به عبارت ساده تر لاگیه که تایم استمپ داره و راحت تر query میشه.
قسمت سوم otel میشه span. چیه دقیقا و فرقش با لاگ (یا ایونت چیه)؟ span یک نقطه استارت و یک نقطه انتها دارن تو زمان. یعنی تو یک بازه زمانی هستن. و هر span کلی event میتونه داشته باشه.
یعنی به عبارت ساده تر لاگ یا event درواقع یک عکسی هست از یک لحظه از execution در نرم افزار شما. ولی span یک فیلم ۳ بعدیه از یک کاری که در نرم افزار شما انجام شده. و نکته جالب تر اینه که span میتونه key attribute داشته باشه. مثلا من یک span دارم که وقتی کاربر محصولی اضافه کرد, یک مدل train شده باید اطلاعات رو از اون عکس محصول extract کنه و به محصول اضافه کنه (مثل رنگ و اینا).
تو این کیس منطقیه که اسم span من باشه "extracting metadata from product" . و attribute ای داشته باشم به اسم image_id که بدونم داره رو چه عکسی این اتفاق میفته. user_id هم مناسبه چون میدونم عکس برای چه یوزریه. تعداد تگ هایی که مثلا extract شده هم میتونم key value کنم. "extracted_tags". این شد یک span خیلی با ارزش. این مثالو تا اینجا داشته باشین.
و در آخر trace رو داریم. که مجموعه ای از span ها میشن یک trace. هر کدوم از این اسپن ها میتونن تو یک سرویس و یک جای مختلف سیستمتون اتفاق افتاده باشن. لزوما نیازی نیست این اسپن ها به ترتیب باشن. میتونن همزمان اتفاق افتاده باشن که میشه end-to-end view از سیستمتون. بخوام ساده تر بگم trace در نهایت میشه یک سریالی که چند فیلم 3d کنار هم گذاشتین و همه اینا به هم مربوطن و باهم معنی پیدا میکنن.
حالا به چه دردی میخوره؟ فکر کنید تو facebook marketplace دارین کار میکنید. و همون flow ای که بالا تر توضیح دادم هست. یوزر عکس یک محصولی رو آپلود میکنه به یک api ای. و بعد متا دیتا اون عکس extract میشه و در نهایت به عده ای از کاربران که علاقه دارن به اون category از اون محصول ایمیل ارسال میشه که مثلا همچین محصولی تو مارکت فیسبوک اومده.
به شما تیکت میدن که چرا فلان یوزر عکسش هیچ تگی نداشته؟ شما بلافاصله داشبوردتون رو query میکنید
name = 'extracting metadata from product' AND user_id='x' AND extracted_tags=0
تمام. حالا شما همه span هایی که مربوط به اون یوزره و هیچی extract نکرده رو میبینید. حالا رو یک span مورد نظرتون کلیک میکنید. و trace رو میبینید. trace اش چی میشه؟میشه از اون نقطه ای یوزر عکسو از فرانت آپلود کرد تا اون موقعی که ایمیل فرستاده شد به یوزر های دیگه. کل این میشه trace. و لاگ هر span ای که تو هر جای سیستمتون داشتین رو اینطوری میتونید بخونید و راحت دیباگ کنید.
یا لزوما reactive نیست.یک سیستمی که خوب instrument شده (observability خوبی داره) میتونه کاره مانیتورینگ هم تا حدی انجام بده. شما دیتا خیلی راحت تو این case میتونید پرفونس مدل هاتون رو graph کنید که روزانه چند در صد عکس ها تگ میشن. چقدر تگ میشن. با percentile نشون بدید اینو.
ولی صبر کنید تموم نشده! یک سیستمی که خوب instrument شده خیلی راحت میتونه دیتا برای business analytics هم داشته باشه. سوال اینجاست که من ایمیل فرستادم به یوزر های دیگه. آیا اونا رو ایمیل کلیک کردن و محصول رو خریداری کردن؟ چند درصد اینکارو کردن؟ ادامه همین مسیر هم میتونست تو همون trace باشه!
خلاصه اینکه opentelemetry رو دست کم نگیرین😁 باهاش میشه جادو کرد. به شرطی که درک کنید برای چی ساخته شده.
@PyBackendHub
❤12🙏4👍2
#otel
نمونه مثال دیروز رو یادتونه؟ پیاده سازیش همچین حالتی میشه. که البته کدشم پوش کردم اینجا که ببینید
وقتی مفاهمیشو بلد باشین خیلی سادست. مثل این میمونه SQL بلد باشین و بخواین از orm فقط برین ببینید چطوری میتونید اون query رو بنویسید. ولی اگه مفاهیم یا specification رو بلد نباشین به شدت گیج کنندست.
برای مثالمون ۳ تا راهکار هست:
۱. وقتی تو یک سرویس هستن, اگه همون کانتکس منیجری که من باز کردم رو دو بار زیر هم باز کنید اسپن دوم میشه child اسپن اول. وقتی مناسبه که تو یک سرویس نیاز دارین به چند اسپن.(دارین چند تا کار میکنید)
۲. وقتی تو دو سرویس جدا هستین, میتونید لینک کنید. برای لینک کردن باید trace id و span id رو داشته باشین. میتونید تو هدر بفرستین و بعد بگیرین.
۳. روش سوم و از همه بهتر Context Propagation هست. که اینجا مثالشو گذاشته که با ۲ تا api فلسک اینکارو انجام داده. وقتی به درد میخوره که شما یک event ای دارین تو چند تا سرویس. و میخواین همه باهم کنار هم بیان. یک وقتا حتی ممکنه sequential هم نباشن. ولی پیچیده تره این حالت. برای همین تو مثال نیاوردمش. تو کیس ما این روش از بهترین بود.
@PyBackendHub
نمونه مثال دیروز رو یادتونه؟ پیاده سازیش همچین حالتی میشه. که البته کدشم پوش کردم اینجا که ببینید
وقتی مفاهمیشو بلد باشین خیلی سادست. مثل این میمونه SQL بلد باشین و بخواین از orm فقط برین ببینید چطوری میتونید اون query رو بنویسید. ولی اگه مفاهیم یا specification رو بلد نباشین به شدت گیج کنندست.
برای مثالمون ۳ تا راهکار هست:
۱. وقتی تو یک سرویس هستن, اگه همون کانتکس منیجری که من باز کردم رو دو بار زیر هم باز کنید اسپن دوم میشه child اسپن اول. وقتی مناسبه که تو یک سرویس نیاز دارین به چند اسپن.(دارین چند تا کار میکنید)
۲. وقتی تو دو سرویس جدا هستین, میتونید لینک کنید. برای لینک کردن باید trace id و span id رو داشته باشین. میتونید تو هدر بفرستین و بعد بگیرین.
۳. روش سوم و از همه بهتر Context Propagation هست. که اینجا مثالشو گذاشته که با ۲ تا api فلسک اینکارو انجام داده. وقتی به درد میخوره که شما یک event ای دارین تو چند تا سرویس. و میخواین همه باهم کنار هم بیان. یک وقتا حتی ممکنه sequential هم نباشن. ولی پیچیده تره این حالت. برای همین تو مثال نیاوردمش. تو کیس ما این روش از بهترین بود.
@PyBackendHub
👍4
یادتونه دیشب مثال زدم که میتونید query بزنید؟به این شکل الان میشه زد. خیلی راحت.
و شما میتونید به این شکل خیلی راحت observability رو داشته باشین
پی نوشت: از لاگ فایر استفاده نکردم چون هنوز نه span link داره نه Context Propagation
@PyBackendHub
و شما میتونید به این شکل خیلی راحت observability رو داشته باشین
پی نوشت: از لاگ فایر استفاده نکردم چون هنوز نه span link داره نه Context Propagation
@PyBackendHub
یک پستی دیدم تو لینکدین و یک چیزیه که حقیقتا خیلی مخالفشم. نظره شما چیه؟ مصاحبه کننده میاد از قبل یک سوالی آماده میکنه, و یک جوابی تو ذهنش داره. اگه شما دقیقا همون جواب تو ذهن مصاحبه کننده رو بدی قبولی. و اگه ندی قبول نیستی.
بنظرم این مدل مصاحبه بدترین مصاحبه هست. اصلا شبیه دنیای واقعی نیست. هدف مصاحبه این نیست که شما به جواب درست برسی. هدف اینه که یک نفر بیاد و بتونیم باهم یک مشکلی رو حل کنیم با هم فکری. سوالی که فقط ۱ جواب داره سوال خوبی نیست. تو دنیای واقعی یک سولوشن نداریم بلکه ترید آف داریم.
@PyBackendHub
بنظرم این مدل مصاحبه بدترین مصاحبه هست. اصلا شبیه دنیای واقعی نیست. هدف مصاحبه این نیست که شما به جواب درست برسی. هدف اینه که یک نفر بیاد و بتونیم باهم یک مشکلی رو حل کنیم با هم فکری. سوالی که فقط ۱ جواب داره سوال خوبی نیست. تو دنیای واقعی یک سولوشن نداریم بلکه ترید آف داریم.
@PyBackendHub
👍32❤1🙏1👌1
Python BackendHub
یک پستی دیدم تو لینکدین و یک چیزیه که حقیقتا خیلی مخالفشم. نظره شما چیه؟ مصاحبه کننده میاد از قبل یک سوالی آماده میکنه, و یک جوابی تو ذهنش داره. اگه شما دقیقا همون جواب تو ذهن مصاحبه کننده رو بدی قبولی. و اگه ندی قبول نیستی. بنظرم این مدل مصاحبه بدترین مصاحبه…
یک نکته بگم که احساس میکنم اکثرا که سوال اینطوری طرح میکنن به دنبال تقلید از شرکت های بزرگ و Faang هستن. من خودم حقیقتا به یک شرکت نسبتا بزرگ پارسال مصاحبه داشتم و تو مصاحبه سوال الگوریتمی رو به کند ترین روش ممکن حل کردم ولی پاس داده شدم مرحله بعد و فیدبکی که گرفتم این بود که مهم نیست اگه اینو به صورت آپتیمایز ترین حالت ممکن حل کنی. مهم ارتباط گرفتن موقع حل سواله و اینکه آگاه باشی از ترید آف. کلا دنبال این هستن که طرز فکر شما رو ببینن. و یک سوال الگوریتمی لایو کدینگ کم هزینه ترین کار برای این موضوع هست (که شاید بهترین عملکرد رو نداشته باشه ولی خب شرکت Faang کلی کاندید داره....)
تو کیس بالا خیلیا به روشی حل کرده بودن که حالت <ایده آل>از دیده مصاحبه کننده نبود و تقلب بود. ولی بنظره من اتفاقا خیلی با ارزش تره. وقتی من سولوشنی میدم که کلا out of box بوده و داره نیاز بیزنس من رو پوشش میده چرا که نه؟
@PyBackendHub
تو کیس بالا خیلیا به روشی حل کرده بودن که حالت <ایده آل>از دیده مصاحبه کننده نبود و تقلب بود. ولی بنظره من اتفاقا خیلی با ارزش تره. وقتی من سولوشنی میدم که کلا out of box بوده و داره نیاز بیزنس من رو پوشش میده چرا که نه؟
@PyBackendHub
👍15❤2
zoxide is a smarter cd command, inspired by z and autojump.It remembers which directories you use most frequently, so you can "jump" to them in just a few keystrokes. zoxide works on all major shells.
https://github.com/ajeetdsouza/zoxide
این خیلی چیزه تمیزیه👌 یک سالی میشه تقریبا دارمش رو سیستمم. مخصوصا الان خیلی بدرد بخوره. مثلا یک پروژه داشتم اسمش helicopter بود. نمیتونستم پیداش کنم. میخواستم cd کنم تو دایرکتوریش.
خلاصه اینکه rust چیکار ها که نمیکنه😁
@PyBackendHub
https://github.com/ajeetdsouza/zoxide
این خیلی چیزه تمیزیه👌 یک سالی میشه تقریبا دارمش رو سیستمم. مخصوصا الان خیلی بدرد بخوره. مثلا یک پروژه داشتم اسمش helicopter بود. نمیتونستم پیداش کنم. میخواستم cd کنم تو دایرکتوریش.
z helicopter
خلاصه اینکه rust چیکار ها که نمیکنه😁
@PyBackendHub
GitHub
GitHub - ajeetdsouza/zoxide: A smarter cd command. Supports all major shells.
A smarter cd command. Supports all major shells. Contribute to ajeetdsouza/zoxide development by creating an account on GitHub.
😁19👍2👎2🆒2🔥1
من mkdocs تاحالا کار نکرده بودم
ولی وقتی کار کردم فهمیدم چقدر راحت میتونید داک جنریت کنید. مستقیم از کد. یک عالمه پلاگین مفید داره و پلاگین نوشتن براش هم خیلی سادست.
نمونه پروژه aioclock رو میتونید ببینید که از داک استرینگ خوده سورس داکیومنت نوشتم:
خوده پروژه
داک پروژه
برای پروژه ای که مونولیتیک هست خیلی چیزه خوبی میتونه باشه حتی تو کیس بیزنس (نه لزوما اوپن سورس) چون همیشه این مشکل رو داشتم که داکیومنت وقتی تو نوشن نگه میداری خیلی زود outdate میشه و خیلی غیر منطقی هست که داکیومنت مربوط به کد رو بخوای تو نوشن بذاری.
از طرفی داک استرینگ بنویسی ممکنه تو نگاه اول مشخص نباشه و طرف باید بدونه بره سراغ چی. و سرچ کردن و اینا یکم سخت تره.
@PyBackendHub
ولی وقتی کار کردم فهمیدم چقدر راحت میتونید داک جنریت کنید. مستقیم از کد. یک عالمه پلاگین مفید داره و پلاگین نوشتن براش هم خیلی سادست.
نمونه پروژه aioclock رو میتونید ببینید که از داک استرینگ خوده سورس داکیومنت نوشتم:
خوده پروژه
داک پروژه
برای پروژه ای که مونولیتیک هست خیلی چیزه خوبی میتونه باشه حتی تو کیس بیزنس (نه لزوما اوپن سورس) چون همیشه این مشکل رو داشتم که داکیومنت وقتی تو نوشن نگه میداری خیلی زود outdate میشه و خیلی غیر منطقی هست که داکیومنت مربوط به کد رو بخوای تو نوشن بذاری.
از طرفی داک استرینگ بنویسی ممکنه تو نگاه اول مشخص نباشه و طرف باید بدونه بره سراغ چی. و سرچ کردن و اینا یکم سخت تره.
@PyBackendHub
GitHub
GitHub - ManiMozaffar/aioclock: A modern python scheduling framework with dependency injection and modular integration support.…
A modern python scheduling framework with dependency injection and modular integration support. Alternative for Rocketry or apscheduler - ManiMozaffar/aioclock
👍11❤3
Forwarded from Sadra Codes
در این کنفرانس، دو آزمایش انجام شد. در آزمایش اول، یک تفنگ پینتبال روی یک شاسی روبهروی یک تابلو قرار داده شد و در هر لحظه، یک توپ پینتبال به سمت تابلو پرتاب میشد و در نهایت تصویر یک آدمک مصور شد.
آزمایش دوم تقریبا شبیه به آزمایش اول بود با این تفاوت که اینبار بجای یک تفنگ پینتبال، ۱،۱۰۰ مازل پینتبال با فشار هوای موجود در چهار محفظه به حجم کلی ۸،۰۰۰ لیتر به سمت تابلو پرتاب میشدن.
آزمایش اول نمایانگر شیوه عملکرد CPU و آزمایش دوم شبیهساز شیوه عملکرد GPU بود. اگه به آزمایش اول دقت کنید، میبینید که مجری صحنه با دستکاری تفنگ، سرعت پرتاب توپ رو تغییر میده. طی کنفرانس به این عمل مجری هیچ اشارهای نمیشه اما این پارامتر در CPU، کلاک (Clock) پردازنده نامیده میشه که با یکای هرتز اندازهگیری و مشخص میشه که به معنی سرعت CPU در پردازش هر تسک طی یک ثانیه (سیکل زمانی) هست.
مثلا یک پردازنده ۳ گیگاهرتزی (3GHz) نمایانگر اینه که این پردازنده این قابلیت رو داره که در هر ثانیه، ۳ میلیارد بار بین هر تسک پردازشی سوییچ کنه! تسک پردازشی میتونه خواندن از مموری، نوشتن در IO، باز کردن یک سشن وب یا هرچیزی باشه.
وظیفه پردازش در پردازنده بر عهده هسته (Core) هست. یک خصیصه بد هستهها، Lazy بودنشونه. خیلی زود به خواب میرن. فرض کنید شما دوتا تسک دارید.
تسک اول: بررسی تعداد اعداد اول بین عدد ۱ میلیارد تا ۲ میلیارد.
تسک دوم: ۲۰ بار پرینت کردن Hello world.
از اونجا که ترتیب انجام این تسکها مهم نیستن، پس اهمیتی هم نداره که کدوم زودتر انجام شه. مسلما تسک دوم در کسری از ثانیه اجرا میشه اما تسک اول خیلی زمانبره ولی شما برنامه رو طوری مینویسید که ابتدا تسک اول و سپس تسک دوم اجرا شه. یک هسته شروع میکنه تعداد اعداد اول بین یک میلیارد و دو میلیارد رو میشماره و شما تا الان تقریبا چند دقیقهای هست که منتظرید تا یکی از این دو تسک تموم شه.
این درحالیه که میتونستید برای پردازنده مشخص کنید که برنامه شما از دو تسک تشکیل شده که کاملا مستقل و مجزا هستن نسبت به هم تا هسته میتونست برنامه رو به نحو بهتری اجرا کنه. این عمل اجرای موازی نام داره. درواقع شما دارید برنامه رو به دو بخش (ترد) تقسیم میکنید و دست Core رو واسه سوییچ کردن بین هریک از این تسکها باز میذارید.
درسته که گفتیم تسک دوم خیلی سادهتر و سریعتر اجرا میشه، ولی این یکم ناعادلانه هست اگه هسته، زمان بیشتری رو اختصاص بده به اجرای تسک اول تا تسک دوم. توی پایتون، این زمان بصورت پیشفرض بر روی ۰.۰۰۵ تنظیم شده. یعنی هسته فقط میتونه ۵ هزارم ثانیه به هر تسک اجازه اجرا شدن بده. اگه فکر میکنید این عدد خیلی کوچیکه، سرعت سوییچ کردن پردازنده در ثانیه رو فراموش نکنید.
پردازش موازی به طور کلی به دو صورت انجام میشه. واقعا موازی (Parallel) شبهموازی (Concurrent). خیلی خلاصه بگم، در حالت موازی، واقعا چند تعداد هسته اجیر اجرای چند تسک میشن و در لحظه همشون درحال پردازشن اما در حالت شبهموازی، یک یا چند هسته روی چند تسک سوییچ میکنن. به قدری این سوییچ سریع اتفاق مییوفته (۰.۰۰۵ ثانیه در پایتون) که شما فکر میکنید واقعا دانلود منجر شما movie1.mp4 و movie2.mp4 رو داره همزمان دانلود میکنه!
الان تا حدودی با CPUها آشنا شدیم. این وسط GPUها چطوری کار میکنن؟!
برخلاف محدودیت CPU ها در تعداد هستهها، GPUها میتونن تعداد بسیار زیادی هسته داشته باشن. در یک پردازنده معمولی امروزی، شما نهایتا ۸ هسته در اختیار دارید. این در حالیه که در یک GPU میانرده، حداقل ۱۰۰۰ هسته وجود داره. مشخصا انجام یک تسک بصورت Parallel خیلی سریعتره تا Concurrent و نقطه قوت GPU ها در پردازش موازیشونه!
در یک تسک رندر کردن یک جسم سهبعدی، ممکنه هزاران هسته در لحظه روی پردازش ابعاد مختلف اون شی کار کنن. با حجم فضای مموری (VRAM) که در سخت افزار GPU تعبیه شده، مسلما سرعت و حجم، خیلی بیشتر از ریجستری CPU و RAM هست. این در حالیه که یک CPU در حالتی Efficient هست که کلاک بالایی داشته باشه و با سرعت زیادی سوییچ کنه.
حالا میدونید دیوایسی که در دست دارید یا تلگرامی که درحال استفاده ازش هستید چطور کار میکنه! امیدوارم لذت برده باشید! :) ❤️
Join for more: @lnxpylnxpy
آزمایش دوم تقریبا شبیه به آزمایش اول بود با این تفاوت که اینبار بجای یک تفنگ پینتبال، ۱،۱۰۰ مازل پینتبال با فشار هوای موجود در چهار محفظه به حجم کلی ۸،۰۰۰ لیتر به سمت تابلو پرتاب میشدن.
آزمایش اول نمایانگر شیوه عملکرد CPU و آزمایش دوم شبیهساز شیوه عملکرد GPU بود. اگه به آزمایش اول دقت کنید، میبینید که مجری صحنه با دستکاری تفنگ، سرعت پرتاب توپ رو تغییر میده. طی کنفرانس به این عمل مجری هیچ اشارهای نمیشه اما این پارامتر در CPU، کلاک (Clock) پردازنده نامیده میشه که با یکای هرتز اندازهگیری و مشخص میشه که به معنی سرعت CPU در پردازش هر تسک طی یک ثانیه (سیکل زمانی) هست.
مثلا یک پردازنده ۳ گیگاهرتزی (3GHz) نمایانگر اینه که این پردازنده این قابلیت رو داره که در هر ثانیه، ۳ میلیارد بار بین هر تسک پردازشی سوییچ کنه! تسک پردازشی میتونه خواندن از مموری، نوشتن در IO، باز کردن یک سشن وب یا هرچیزی باشه.
وظیفه پردازش در پردازنده بر عهده هسته (Core) هست. یک خصیصه بد هستهها، Lazy بودنشونه. خیلی زود به خواب میرن. فرض کنید شما دوتا تسک دارید.
تسک اول: بررسی تعداد اعداد اول بین عدد ۱ میلیارد تا ۲ میلیارد.
تسک دوم: ۲۰ بار پرینت کردن Hello world.
از اونجا که ترتیب انجام این تسکها مهم نیستن، پس اهمیتی هم نداره که کدوم زودتر انجام شه. مسلما تسک دوم در کسری از ثانیه اجرا میشه اما تسک اول خیلی زمانبره ولی شما برنامه رو طوری مینویسید که ابتدا تسک اول و سپس تسک دوم اجرا شه. یک هسته شروع میکنه تعداد اعداد اول بین یک میلیارد و دو میلیارد رو میشماره و شما تا الان تقریبا چند دقیقهای هست که منتظرید تا یکی از این دو تسک تموم شه.
این درحالیه که میتونستید برای پردازنده مشخص کنید که برنامه شما از دو تسک تشکیل شده که کاملا مستقل و مجزا هستن نسبت به هم تا هسته میتونست برنامه رو به نحو بهتری اجرا کنه. این عمل اجرای موازی نام داره. درواقع شما دارید برنامه رو به دو بخش (ترد) تقسیم میکنید و دست Core رو واسه سوییچ کردن بین هریک از این تسکها باز میذارید.
درسته که گفتیم تسک دوم خیلی سادهتر و سریعتر اجرا میشه، ولی این یکم ناعادلانه هست اگه هسته، زمان بیشتری رو اختصاص بده به اجرای تسک اول تا تسک دوم. توی پایتون، این زمان بصورت پیشفرض بر روی ۰.۰۰۵ تنظیم شده. یعنی هسته فقط میتونه ۵ هزارم ثانیه به هر تسک اجازه اجرا شدن بده. اگه فکر میکنید این عدد خیلی کوچیکه، سرعت سوییچ کردن پردازنده در ثانیه رو فراموش نکنید.
python -c "import sys; print(sys.getswitchinterval())"
0.005
پردازش موازی به طور کلی به دو صورت انجام میشه. واقعا موازی (Parallel) شبهموازی (Concurrent). خیلی خلاصه بگم، در حالت موازی، واقعا چند تعداد هسته اجیر اجرای چند تسک میشن و در لحظه همشون درحال پردازشن اما در حالت شبهموازی، یک یا چند هسته روی چند تسک سوییچ میکنن. به قدری این سوییچ سریع اتفاق مییوفته (۰.۰۰۵ ثانیه در پایتون) که شما فکر میکنید واقعا دانلود منجر شما movie1.mp4 و movie2.mp4 رو داره همزمان دانلود میکنه!
الان تا حدودی با CPUها آشنا شدیم. این وسط GPUها چطوری کار میکنن؟!
برخلاف محدودیت CPU ها در تعداد هستهها، GPUها میتونن تعداد بسیار زیادی هسته داشته باشن. در یک پردازنده معمولی امروزی، شما نهایتا ۸ هسته در اختیار دارید. این در حالیه که در یک GPU میانرده، حداقل ۱۰۰۰ هسته وجود داره. مشخصا انجام یک تسک بصورت Parallel خیلی سریعتره تا Concurrent و نقطه قوت GPU ها در پردازش موازیشونه!
در یک تسک رندر کردن یک جسم سهبعدی، ممکنه هزاران هسته در لحظه روی پردازش ابعاد مختلف اون شی کار کنن. با حجم فضای مموری (VRAM) که در سخت افزار GPU تعبیه شده، مسلما سرعت و حجم، خیلی بیشتر از ریجستری CPU و RAM هست. این در حالیه که یک CPU در حالتی Efficient هست که کلاک بالایی داشته باشه و با سرعت زیادی سوییچ کنه.
حالا میدونید دیوایسی که در دست دارید یا تلگرامی که درحال استفاده ازش هستید چطور کار میکنه! امیدوارم لذت برده باشید! :) ❤️
Join for more: @lnxpylnxpy
👍21🔥1
نسخه ۰.۱.۰ فریم ورک AioClock منتشر شد 🔥🔥
آیوکلاک یک فریم ورک برای scheduling هست که کاملا Async عه و هر چیزی که یک فریم ورک نیاز داره رو داخلش داره, مثل دپندسی اینجکشن و startup/stop ایونت و ...
تغییرات نسخه جدید:
- بهبود داکیومنت و خوانایی بسیار بالا
- اضافه شدن پلاگین FastAPI - تو لایه HTTP میتونید ببینید چه تسک هایی دارین, که قراره ران بشن و اگه لازم بود یک تسک با درخواست POST همون لحظه ران کنید!
- اضافه شدن API Internal - برای کنترل لایبری, و نوشتن پلاگین FastAPI که میتونید ابزار CLI باهاش بنویسید یا مثل پلاگین فست رو برای فریم ورک های وب دیگه استفاده کنید.
Github
Documentation
برای حمایت خوشحال میشم استار بدید یا contribute کنید.
@PyBackendHub
آیوکلاک یک فریم ورک برای scheduling هست که کاملا Async عه و هر چیزی که یک فریم ورک نیاز داره رو داخلش داره, مثل دپندسی اینجکشن و startup/stop ایونت و ...
تغییرات نسخه جدید:
- بهبود داکیومنت و خوانایی بسیار بالا
- اضافه شدن پلاگین FastAPI - تو لایه HTTP میتونید ببینید چه تسک هایی دارین, که قراره ران بشن و اگه لازم بود یک تسک با درخواست POST همون لحظه ران کنید!
- اضافه شدن API Internal - برای کنترل لایبری, و نوشتن پلاگین FastAPI که میتونید ابزار CLI باهاش بنویسید یا مثل پلاگین فست رو برای فریم ورک های وب دیگه استفاده کنید.
Github
Documentation
برای حمایت خوشحال میشم استار بدید یا contribute کنید.
@PyBackendHub
🔥13👍3
ریسپانس API وقتی tasks رو صدا میزنید.
از همین ID هم میتونید استفاده کنید برای اینکه تسک رو بلافاصله اجرا کنید و دیگه منتظر اون trigger بعدیش نباشین (مثلا اگه قراره فردا ساعت ۹ اجرا شه دوباره)
@PyBackendHub
از همین ID هم میتونید استفاده کنید برای اینکه تسک رو بلافاصله اجرا کنید و دیگه منتظر اون trigger بعدیش نباشین (مثلا اگه قراره فردا ساعت ۹ اجرا شه دوباره)
@PyBackendHub
👍6
ما یک git flow داریم، که شاید اسمشو نشنیده باشین ولی حتما احتمال زیاد همینو رعایت میکنید. تو عکس توضیح داده. تو پروژه واقعی main میشه پروداکشن، و جای release branches میشه staging و develop هم که میشه نسخه dev که معمولا خیلی استیبل نیست.
معمولا وقتی هاتفیکس انجام میدین رو پروداکشن، رو برنچ staging و dev باید rebase کنید.
حالا سوال دارم ازتون، فکر کنید هات فیکس انجام دادید، ولیبخاطر اون هاتفیکس برنچ develop کانفلیکت خورد موقع ریبیس که حل کردین. ولی شما ۱۰۰ تا برنچ فیچر دیگه دارین از develop، که حالا همشون دقیقا همون کانفلیکت رو خوردن. بنظرتون راهکارش چیه؟
@PyBackendHub
معمولا وقتی هاتفیکس انجام میدین رو پروداکشن، رو برنچ staging و dev باید rebase کنید.
حالا سوال دارم ازتون، فکر کنید هات فیکس انجام دادید، ولیبخاطر اون هاتفیکس برنچ develop کانفلیکت خورد موقع ریبیس که حل کردین. ولی شما ۱۰۰ تا برنچ فیچر دیگه دارین از develop، که حالا همشون دقیقا همون کانفلیکت رو خوردن. بنظرتون راهکارش چیه؟
@PyBackendHub
👍8😱6
Python BackendHub
ما یک git flow داریم، که شاید اسمشو نشنیده باشین ولی حتما احتمال زیاد همینو رعایت میکنید. تو عکس توضیح داده. تو پروژه واقعی main میشه پروداکشن، و جای release branches میشه staging و develop هم که میشه نسخه dev که معمولا خیلی استیبل نیست. معمولا وقتی هاتفیکس…
سید تو کامنت اشاره کرد, چند تا راه حل داره.
یک راه حلی که من قبلا استفاده میکردم و خیلی بهینه نیست اینه که شما برنچ فیچرت رو ریست کنی رو آخرین کامیتی که رو برنچ پروداکشنم هست. و بهت هاتفیکس رو cherry pick کنی و همه کامیت های بعدیشم هم چری پیک کنید (میتونید یک رنجی از کامیت هارو چری پیک کنید نیازی نیست دونه دونه انجام بدید). و بعد کامیت هایی که زده بودید هم چری پیک کنید.برای هر برنچ ۵-۱۰ دقیقه طول میکشه و خیلی بهینه نیست.
راه حل خیلی منطقی تر استفاده از git rerere هست. این قابلیت رو میده که اگه کانفلیکت مشابهی رو یک بار حل کردین دیگه دفعات بعدی هم حل شه. این اسم مخفف Reuse Recorded Resolution هست, که خیلی معنی قشنگی داره. جوری که حلش میکنی اینه که شما وقتی یک کانفلیکت رو حل میکنی گیت راهکار شما رو ذخیره میکنه و یادش میمونه و دفعه بعدی که بخواین دقیقا همون کانفلیکت رو حل کنید git براتون حل میکنه.
یک یوزکیسش دیگش اینه که شما رو یک برنچی زمان زیادی کار کردی و الان اون برنچ خیلی کانفلیکت خورده. اصلا نیازی نیست کانفلیکت هارو حل کنید چون احتمالا قبلا حل کردیشون.
لینک یک مقاله که کامل توضیحش داده
لینک خود داکیومنتش
@PyBackendHub
یک راه حلی که من قبلا استفاده میکردم و خیلی بهینه نیست اینه که شما برنچ فیچرت رو ریست کنی رو آخرین کامیتی که رو برنچ پروداکشنم هست. و بهت هاتفیکس رو cherry pick کنی و همه کامیت های بعدیشم هم چری پیک کنید (میتونید یک رنجی از کامیت هارو چری پیک کنید نیازی نیست دونه دونه انجام بدید). و بعد کامیت هایی که زده بودید هم چری پیک کنید.برای هر برنچ ۵-۱۰ دقیقه طول میکشه و خیلی بهینه نیست.
راه حل خیلی منطقی تر استفاده از git rerere هست. این قابلیت رو میده که اگه کانفلیکت مشابهی رو یک بار حل کردین دیگه دفعات بعدی هم حل شه. این اسم مخفف Reuse Recorded Resolution هست, که خیلی معنی قشنگی داره. جوری که حلش میکنی اینه که شما وقتی یک کانفلیکت رو حل میکنی گیت راهکار شما رو ذخیره میکنه و یادش میمونه و دفعه بعدی که بخواین دقیقا همون کانفلیکت رو حل کنید git براتون حل میکنه.
یک یوزکیسش دیگش اینه که شما رو یک برنچی زمان زیادی کار کردی و الان اون برنچ خیلی کانفلیکت خورده. اصلا نیازی نیست کانفلیکت هارو حل کنید چون احتمالا قبلا حل کردیشون.
لینک یک مقاله که کامل توضیحش داده
لینک خود داکیومنتش
@PyBackendHub
Medium
Fix conflicts only once with git rerere
Fixing conflicts is chore enough not to do the same ones over and over again. See how rerere makes Git remember your conflict fixes!
👍13❤2
Forwarded from BenDev
درود دوستان
مصاحبه سطح جونیور با آقا بهداد عزیز
سری جدید ماک اینترویو رو داریم شروع میکنیم و لطفا در این فرآیند هرگونه نظر مثبت و منفی دارین برام بنویسین که توی مصاحبه های بعد تغییر بدیم
@BenDevelop
https://www.youtube.com/watch?v=DJ6lHSp7gUo
مصاحبه سطح جونیور با آقا بهداد عزیز
سری جدید ماک اینترویو رو داریم شروع میکنیم و لطفا در این فرآیند هرگونه نظر مثبت و منفی دارین برام بنویسین که توی مصاحبه های بعد تغییر بدیم
@BenDevelop
https://www.youtube.com/watch?v=DJ6lHSp7gUo
YouTube
Mock Interview - مصاحبه فنی جونیور با بهداد به همراه تحلیل و بررسی
مصاحبه فنی جونیور با بهداد
Mock interview Junior
+ تحلیل و بررسی
▬ محتوای ویدیو ▬▬▬▬▬▬▬▬▬▬
ما تو این ویدیو قصد داریم که با دوست عزیزمون بهداد مصاحبه کنیم
و با هم اشتباهاتش رو دربیاریم و ازش درس بگیریم
▬ بخش های ویدیو ▬▬▬▬▬▬▬▬▬▬
0:00 مقدمه
0:40…
Mock interview Junior
+ تحلیل و بررسی
▬ محتوای ویدیو ▬▬▬▬▬▬▬▬▬▬
ما تو این ویدیو قصد داریم که با دوست عزیزمون بهداد مصاحبه کنیم
و با هم اشتباهاتش رو دربیاریم و ازش درس بگیریم
▬ بخش های ویدیو ▬▬▬▬▬▬▬▬▬▬
0:00 مقدمه
0:40…
👍4
BenDev
درود دوستان مصاحبه سطح جونیور با آقا بهداد عزیز سری جدید ماک اینترویو رو داریم شروع میکنیم و لطفا در این فرآیند هرگونه نظر مثبت و منفی دارین برام بنویسین که توی مصاحبه های بعد تغییر بدیم @BenDevelop https://www.youtube.com/watch?v=DJ6lHSp7gUo
یک پلی لیست عالی از امیربهادر 👌
دیدن ماک یکی از بهترین روش های یادگیریه.
مصاحبه انجام دادن مثل رزومه نوشتن یک اسکیله. لزوما کسی که دانش تکنیکال خوبی داره خوب مصاحبه نمیکنه. بخش خیلی زیادی از مصاحبه اسکیل communication هست که خیلی مهمه. لزوما کسی که بره تو یک مصاحبه ۳ تا سوال الگوریتمی حل کنه استخدام نمیشه و FAANG و شرکت های بزرگ تر برای اینکه فرصت چک کردن assignment ندارن و هزینه زیادی براشون میبره و لایو هم نیست رو به پرسیدن سوال های الگوریتمی آوردن, که البته هدفشون استخدام یک leet coder نیست(ولی سولوشن بهتری براشون وجود نداره یا هنوز پیدا نشده که بتونن یک سوالی رو طرح کنند و طرف بتونه با کد زدن حلش کنه و اسکیل communication اش هم نشون بده و عمق دانشش هم نشون بده)
و البته سوالای system design ای که میپرسن هم دوباره یک مکانیزمه که leet coder ای استخدام نکنن که communication خوبی هم داره.
من میخواستم خیلی وقت پیش یک repo بنویسم برای مصاحبه دادن (مثل رزومه نویسی)
ولی بعدش فهمیدم که اونقدر مصاحبه objective نیست و تا کسی مصاحبه ماک خوب نبینه چند تا مصاحبه نده قلقش دستش نمیاد. ولی نوشتن resume خیلی آبجکتیو هست که یک ریپو دارم در خصوص تکنیک های نوشتن رزومه.
یک نکته که اخیرا کشف کردم برای اپلای, اگه سطح زبانتون خوبه حتما درج کنید (مثلا اگه c1 هستین بنویسید که c1 هستین) چون واقعا خیلیا (حتی اروپایی و خارجی ها) خیلی خوب حرف نمیزنن. البته دروغ ننویسید چون قطعا باعث ریجکتتون میشه اگه بنویسید c1 بلدید ولی تو مصاحبه اول نتونید در حد c1 حرف بزنید.
@PyBackendHub
دیدن ماک یکی از بهترین روش های یادگیریه.
مصاحبه انجام دادن مثل رزومه نوشتن یک اسکیله. لزوما کسی که دانش تکنیکال خوبی داره خوب مصاحبه نمیکنه. بخش خیلی زیادی از مصاحبه اسکیل communication هست که خیلی مهمه. لزوما کسی که بره تو یک مصاحبه ۳ تا سوال الگوریتمی حل کنه استخدام نمیشه و FAANG و شرکت های بزرگ تر برای اینکه فرصت چک کردن assignment ندارن و هزینه زیادی براشون میبره و لایو هم نیست رو به پرسیدن سوال های الگوریتمی آوردن, که البته هدفشون استخدام یک leet coder نیست(ولی سولوشن بهتری براشون وجود نداره یا هنوز پیدا نشده که بتونن یک سوالی رو طرح کنند و طرف بتونه با کد زدن حلش کنه و اسکیل communication اش هم نشون بده و عمق دانشش هم نشون بده)
و البته سوالای system design ای که میپرسن هم دوباره یک مکانیزمه که leet coder ای استخدام نکنن که communication خوبی هم داره.
من میخواستم خیلی وقت پیش یک repo بنویسم برای مصاحبه دادن (مثل رزومه نویسی)
ولی بعدش فهمیدم که اونقدر مصاحبه objective نیست و تا کسی مصاحبه ماک خوب نبینه چند تا مصاحبه نده قلقش دستش نمیاد. ولی نوشتن resume خیلی آبجکتیو هست که یک ریپو دارم در خصوص تکنیک های نوشتن رزومه.
یک نکته که اخیرا کشف کردم برای اپلای, اگه سطح زبانتون خوبه حتما درج کنید (مثلا اگه c1 هستین بنویسید که c1 هستین) چون واقعا خیلیا (حتی اروپایی و خارجی ها) خیلی خوب حرف نمیزنن. البته دروغ ننویسید چون قطعا باعث ریجکتتون میشه اگه بنویسید c1 بلدید ولی تو مصاحبه اول نتونید در حد c1 حرف بزنید.
@PyBackendHub
GitHub
GitHub - ManiMozaffar/awesome-resumes: Create resumes and CV with awesome-resumes. Practical tips, guidelines, guide, examples…
Create resumes and CV with awesome-resumes. Practical tips, guidelines, guide, examples and documentation for all IT fields - ManiMozaffar/awesome-resumes
👍12❤2
چقدر یک architecture میتونه پیچیده باشه؟
Sentry: YES
احساس میکنم این پیچیدگی از قصده که نخوای خودت maintain کنی اینو 😂 چون هزینه maintain کردنش به صورت self host از هزینه اینکه از نسخه کلادش استفاده کنی بیشتره :))
هنوز متوجه نمیشم چرا هم memcached هست هم ردیس. 😁
@PyBackendHub
Sentry: YES
احساس میکنم این پیچیدگی از قصده که نخوای خودت maintain کنی اینو 😂 چون هزینه maintain کردنش به صورت self host از هزینه اینکه از نسخه کلادش استفاده کنی بیشتره :))
هنوز متوجه نمیشم چرا هم memcached هست هم ردیس. 😁
@PyBackendHub
😁9🤣7👍4🤔2👎1
اگه ری اکت کار میکنید یک سری بزنید به این پروژه:
https://www.locatorjs.com/
کارش اینه که شما رو component ای که تو صفحه مرورگرت میبینی کلیک میکنی و میبرتت تو کد دقیقا قسمت مربوط بهش.😅👌
@PyBackendHub
https://www.locatorjs.com/
کارش اینه که شما رو component ای که تو صفحه مرورگرت میبینی کلیک میکنی و میبرتت تو کد دقیقا قسمت مربوط بهش.😅👌
@PyBackendHub
Locatorjs
LocatorJS - click on any component to go to code.
Click on any component and go from your app to component's code.
👍6👎1
یک پارادیم که خیلی قشنگه بدونید راجبش CoC هست.
Convention over configuration
این پارادیم core خیلی از فریم ورک هایی هست که شما استفاده میکنی. و خیلی خوبه که خودت هم استفاده کنی.
حالا این پارادیم چیه؟
این پارادیم خیلی سادست. میگه تعداد تصمیم هایی که یک برنامه نویس قراره بگیره وقتی داره از یک component شما استفاده میکنه باید تو کمترین حالت ممکن باشه. یعنی چی؟
یعنی من دارم لایبری pydantic مینویسم. دیدین احتمالا که یک Field داره که شما توضیح میدی تو Field یک سری متا دیتا میدی راجب اون فیلد تو اون دیتا کلس. این فیلد کلی پارامتر میگیره. ولی همه این پارامتر ها آپشناله. و این دقیقا CoC هست. یعنی به شما این flexibility خیلی زیاد رو میده که رفتار یک component رو هرچقدر میخواین تغییر بدید, در عین حال کلی مقدار دیفالت میذاره براتون که لازم نباشه خیلی فکر کنید و تصمیم های زیادی بگیرین.
این اصل رو شما هرجایی میتونید استفاده کنید. چه تو backend چه فرانت چه devops چه هر جای دیگه ای.
@PyBackendHub
Convention over configuration
این پارادیم core خیلی از فریم ورک هایی هست که شما استفاده میکنی. و خیلی خوبه که خودت هم استفاده کنی.
حالا این پارادیم چیه؟
این پارادیم خیلی سادست. میگه تعداد تصمیم هایی که یک برنامه نویس قراره بگیره وقتی داره از یک component شما استفاده میکنه باید تو کمترین حالت ممکن باشه. یعنی چی؟
یعنی من دارم لایبری pydantic مینویسم. دیدین احتمالا که یک Field داره که شما توضیح میدی تو Field یک سری متا دیتا میدی راجب اون فیلد تو اون دیتا کلس. این فیلد کلی پارامتر میگیره. ولی همه این پارامتر ها آپشناله. و این دقیقا CoC هست. یعنی به شما این flexibility خیلی زیاد رو میده که رفتار یک component رو هرچقدر میخواین تغییر بدید, در عین حال کلی مقدار دیفالت میذاره براتون که لازم نباشه خیلی فکر کنید و تصمیم های زیادی بگیرین.
این اصل رو شما هرجایی میتونید استفاده کنید. چه تو backend چه فرانت چه devops چه هر جای دیگه ای.
@PyBackendHub
👍35