✅ از Linkedin آقای arash hosseini #مهندسی_سیستم لینک در نظرات پست
مهندسی سیستم بخش چهارم:

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

پیش نیاز ها :
پایداری، یکپارچگی و ثبات کارکردی نیازمند تبدیل و انتقالی بدون ابهام و انشعاب در میان فازها، عملیات ها و کارهای سیستم است. بنابراین از نظر طراحان سیستم فرض براین است که شرایط یا معیارهای پیش نیاز یا اولیه باید قبل از ورود به فاز، عملیات یا کار بعدی محقق شوند. بر اساس تعریف، از آنجایی که یک سیستم از اجزایی یکپارچه تشکیل شده است، این مهم است که اجزا همزمانی و هماهنگی داشته باشند.
وضعیت و شرایط اولیه عملیات :
شرایط اولیه عملیات شامل وضعیت های فیزیکی، عملیاتی و محیط اطراف در شروع فاز ماموریت، عملیات یا کار می باشد. از آنجایی که آنالیز، نیازمند استقرار مفروضات اولیه جنبه های گوناگون فازها، عملیات ها یا کارهای سیستم است. شرایط اولیه به عنوان یک تصویر یا نقطه شروعی است که مفروضات را دربر می گیرد. برای تشریح این مفهوم مثال ذیل را در نظر بگیرید :
مثال : هواپیما در شرایط باد مقابل با سرعت 35گره از زمین برخاست، ساعت پرترافیک صبح با کولاکی به سرعت باد 30 مایل در ساعت که از سمت دریا می وزید آغاز گردید.
استاتیک :
زمانی که ما یک سیستم را آنالیز می کنیم، بعضا وضعیت فیزیکی کلید پایه ای برای آنالیز سیستم در یک لحظه از زمان می باشد. ایستایی برای مشخص کردن جهت سیستم در لحظه حال، مانند یک وضعیت برداری یا چرخش در درون یک سیستم بزرگ تر است . از زاویه دید کلان به سیستم، هواپیمایی که در آشیانه قرار دارد، اتومبیلی که درون یک راهرو قرار گرفته یا شبکه ای بدون ترافیک پیام ها و یا سیستمی روشنایی با 2 وضعیت روشن و خاموش همگی ارائه کننده یک سیستم در وضعیت ایستا هستند. در مقابل اجزای لایه های درونی سیستم مانند کامپوننت ها ممکن است در شرایط ایستا باشند در حالیکه مجموعه سیستم در یک دینامیک قرار دارد.
دینامیک ماموریت :
هر سیستمی چه طبیعی و چه دست ساخته انسان، ماموریت خود را در محیط عملیاتش در فرمی از دینامیک، وضعیت فیزیکی انجام می دهد. دینامیک ها مشخصه های ایستای سیستم در فریم مشخصی از گذر زمان در محیط عملیاتی هستند . دینامیک ها می توانند همانند طیف از حرکت آهسته صخره ای در دامنه یک تپه، تغییرات متوسط مانند تغییرات دما و در نهایت تغییرات ناگهانی مانند زمین لرزه باشد.
دینامیک ها در ناسازگاری‌ها، آشفتگی‌ها و بی ثباتی ها در "تعادل قدرت" با محیط داخلی یا بیرونی اتفاق می افتند. نوع بشر همواره علاقمند به بررسی دینامیک ها و تاثیرآنها بر الگوهای رفتاری زمین، آب و هوا، اقیانوس ها، بازار سهام ومردم، بخصوص زمانی که اثر ویرانگر اقتصادی یا امنیتی داشته، بوده است. بنابر این پیش بینی پیشرفت در رویه های معمول کسب وکارها و تکنولوژی، خود کسب وکاری بسیار بزرگ است . چون ما نیاز داریم که با اطمینان رفتار و عملکرد یک سیستم را در شرایط دینامیک عملیاتی پیش بینی کنیم.
ادامه در کامنت

🥸 آموزش ساخت گالری تصاویر با anydesk

وقتی سوال دارید یکم صبر و حوصله داشته باشید. سعی می کنم تا جایی که بتونم کمک کنم.

✅ از Linkedin آقای arash hosseini #مهندسی_سیستم لینک در نظرات پست
مهندسی سیستم بخش پنجم:

فصلی جدید :
نقش های سیستم و ذی نفعان
هر سیستمی در جهان هستی دارای مقصود و ماموریتی می باشد. به بیان دیگر، هر سیستمی یک دلیل وجودی برای هستیش در ارتباط با دیگر سیستم ها دارد . بیشتر سیستم های دست ساخته بشر به سمت مشارکت و دریافت نقش ها، ماموریت ها و اهداف سازمان مالک خود هدایت می شوند. هر سیستم نقش و بازی در مجموعه سیستم های مالک خود می پذیرد. مسیر موفقیت سیستم های دست ساخته در رسیدن به موفقیت در سازمان به اینکه چقدر خوب مشخص، طراحی، توسعه، یکپارچه، تائید، بررسی، عمل و پشتیبانی شده اند. در این مورد نیاز به منافع مقرری است که به صورت مستقیم یا غیر مستقیم از طریق اثربخشی عملیاتی نتایج ماموریت، کارایی دریافت شده و خروجی اهداف سیستم انسان هایی را متاثر نماید. ما به این افراد به عنوان ذی نفعان سیستم اشاره می کنیم. ابتدا به تعاریف پایه بپردازیم :
کاربر نهایی : فرد یا سازمانی که به صورت مستقیم از منافع خروجی یا نتیجه یک سیستم، محصول یا خدمت بهره مند می گردد.
ذی نفع : فرد یا سازمانی که منافع از پیش تعیین شده ای (دوستانه، رقابتی، یا متخاصم) در خروجی تولید شده از یک سیستم در انجام ماموریت تعیین شده اش دارد.
کاربر سیستم : فرد یا سازمانی که یک سیستم، محصول یا خدمت یا لوازمش را در جهت انجام دادن یک کار یا ماموریت هدفمند بکار می گیرد. برای مثال یک سیستم حمل و نقل شهری رانندگان و اتوبوس ها را برای جابجایی افراد از نقطه ای به نقطه دیگر به کار می گیرد. راننده اتوبوس و مسافران در دسته بندی کاربر قرار می گیرند.
نقش های سیستم سازمانی : سیستم های سازمانی نقش هایی را بازی می کنند که نمایان گر جایگاه آنها در چارت ماموریت ها و اهداف دامنه کسب وکاریشان می باشد. به عنوان مثال سیستم های قضایی که وظیفه و نقش داوری افراد، سازمان های کوچک و بزرگ در انطباق با قوانین، اساسنامه ها، آئین نامه ها، احکام و سیاست ها را بازی می کنند یا سیستم حمل و نقل که مشتریان و کالاها را قادر به جابجایی در امنیت از یک نقطه به یک نقطه دیگر در روی زمین، دریا، آسمان و فضا یا ترکیبی از آنها می نماید یا سیسم آموزش که امکانات آموزشی برای افزایش دانش و مهارت افراد را برای ایفای نقش مفیدتر در جامعه، مهیا می سازد
زمینه نقش سیستم :
هر سیستم دست ساخته ای، عملیات ها و کارهایی در جهت ماموریت خود برای دستیابی به اهداف و نتایج خاص مبتنی بر عملکرد برای حمایت از مشتریان، کاربران و ذینفعان خود انجام می دهد. اگر این سیستم ها را بررسی کنید شما به دو نقش همزمان و زمینه ای سیستم می رسید یک نقش ماموریتی سیستم و یک نقش پشتیبانی سیستم .
ادامه در کامنت

✅ مطلبی از کانال @TorhamDevCH در مورد DRF

https://testdriven.io/blog/drf-serializers/

این مقاله از اوناست که همیشه دوباره بهش سر میزنی :).
اگه مقدماتی DRF رو بلدید برای عمیق تر شدن این مقاله گزینه خیلی خوبیه. باهاش چندتا از متدها مفید سریالایزرها رو یادمیگرید و میفهمید چطوری میشه overrideشون کرد. 🤝

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

مثلا شما یک متد دارید داخل سریالایزر save این متد خودش متد update صدا میزنه و در آپدیت در نهایت شما میایید متد save خود مدل جنگو رو صدا میزنید و اینطور میشه که اگر شما یک instance و دیتا به سریالایزر پاس بدید وقتی save میکنید در اصل اپدیت هم خواهید کرد.

اگر شما می‌خواستین stackoverflow رو طراحی کنید چه کار میکردید؟ احتمالا جواب خیلیا با اون حجم کاربر microservice باشه.
ولی جواب اینه که خیر. یه monolith روی چند تا سروره و تمام!

توی یه قسمت از خبرنامه‌ی bytebytego می‌تونید در موردش بخونید:
https://blog.bytebytego.com/p/ep27-stack-overflow-architecture

در مورد اینکه چطوری به این performance می‌رسن، این صفحه از stack exchange هم جالبه:
https://stackexchange.com/performance

✅ خلاصه کتاب - 97 نکته که هر معمار/مهندس نرم افزار باید بداند
از لینکدین Hamed Banaei

لینک مطلب:
https://www.linkedin.com/pulse/%25D8%25AE%25D9%2584%25D8%25A7%25D8%25B5%25D9%2587-%25DA%25A9%25D8%25AA%25D8%25A7%25D8%25A8-97-%25D9%2586%25DA%25A9%25D8%25AA%25D9%2587-%25DA%25A9%25D9%2587-%25D9%2587%25D8%25B1-%25D9%2585%25D9%2587%25D9%2586%25D8%25AF%25D8%25B3-%25D9%2586%25D8%25B1%25D9%2585-%25D8%25A7%25D9%2581%25D8%25B2%25D8%25A7%25D8%25B1-%25D8%25A8%25D8%25A7%25DB%258C%25D8%25AF-%25D8%25A8%25D8%25AF%25D8%25A7%25D9%2586%25D8%25AF1-hamed-banaei/?trackingId=zTwpUdT5RRWeppZRBoLYnw%3D%3D

✔️ متن مقاله در نظرات

✅ مطلبی در مورد index ها در PostgreSQL از کانال @djangoex

در پستگرس (PostgreSQL) چند نوع مختلف شاخص یا ایندکس (Index) وجود دارد که هر کدام برای کاربردهای خاصی طراحی شده اند. در زیر به معرفی و بررسی آنها می‌پردازم:

یک. B-tree: این نوع شاخص، پیش فرض برای هر نوع داده‌ها می‌باشد. سریعترین ایندکس برای عملیات مقایسه‌ای مانند =, <, <=, >, >= می‌باشد.

دو. Hash: این نوع از شاخص فقط برای عملیات مساوی (=) سریع است و برای سایر عملیات‌های مقایسه‌ای کارآیی مناسبی ندارد.

سه. GiST (Generalized Search Tree): این شاخص پشتیبانی می کند از و نسخه سازگاری بسیار پذیر است که از حوزه های داده و عملیات مقایسه متنوعی پشتیبانی می کند.

چهار. SP-GiST (Space-Partitioned Generalized Search Tree): این نوع شاخص فراهم می کند برای انواع مختلفی از بازیابی های داده، به خصوص زمانی که داده ها یک ساختار فضایی شیر نمی کند.

پنج. GIN (Generalized Inverted Index): این شاخص مناسب برای داده‌هایی است که مقادیر چندگانه در یک سطر دارند، مانند آرایه‌ها و JSON.

شش. BRIN (Block Range INdex): این شاخص مناسب برای جداول بزرگ است که سطرهای آنها به طور فیزیکی بر اساس برخی مقادیر مرتب شده‌اند.

برای مطالعه بیشتر حول این موضوع میتوانید به مستندات PostgreSQL مراجعه نمایید.

قسمت اول: قراردادهای پایتون

در یک مجموعه از پست‌ها، قراردادهایی که در هنگام کدنویسی پایتون باید رعایت شوند معرفی می‌شوند. این قراردادها از پروژه‌های مشهور و کتابخانه‌های استاندارد پایتون گرفته شده‌اند و در طول زمان تکامل پیدا می‌کنند.

In a series of posts, the conventions that must be followed when coding in Python are introduced. These conventions are taken from popular Python projects and standard libraries and evolve over time.

این قراردادها خوانایی کد را بالا می‌برند. خوانایی کد، مهم‌تر از نوشتن کد است. هر برنامه‌نویسی که کار توسعه نرم‌افزار را انجام می‌دهد باید با این قراردادها آشنایی کامل داشته باشد. در پست بعد در مورد Hanging indent ها صحبت می‌کنیم.

These conventions improve code readability. Code readability is more important than code writing. Every programmer who does software development should be familiar with these contracts. we will talk about hanging indents in the next post.

#آموزش_پایتون
#قراردادهای_پایتون

آدرس کانال:
@Programmingschool2
سایت آموزشی:
http://programmingschool.ir

قسمت دوم: قراردادهای پایتون
تورفتگی‌های Hanging Indent

خطوطی که بیش از ۷۹ کاراکتر دارند باید به صورت عمودی نوشته شوند. در هنگام نوشتن عمودی، باید پیوستگی خط حفظ شود. یکی از راه‌های حفظ پیوستگی، استفاده از پرانتز یا براکت است. تراز شدن خطوط با استفاده از Hanging indent انجام می‌شود. تورفتگی‌ Hanging یک سبک نوشتاری است که در آن تمام خطوط یک پاراگراف به جز خط اول تورفتگی دارند. در پایتون، این اصطلاح برای توصیف سبکی استفاده می‌شود که در آن پرانتز آغازین یک عبارت پرانتزدار، آخرین کاراکتر خط اول است و خطوط بعدی تا پرانتز بسته، تورفتگی دارند.

Lines longer than 79 characters must be written vertically. Line continuity must be maintained when writing vertically. One of the ways to maintain continuity is to use parentheses or brucet. Alignment of lines is done using Hanging indent. Hanging indentation is a writing style in which all lines of a paragraph are indented except for the first line. In Python, this term is used to describe a style in which the opening parenthesis of a parenthesized expression is the last character of the first line, and subsequent lines are indented up to the closing parenthesis.


هنگام استفاده از تورفتگی‌های Hanging باید در نظر گرفت که خط اول نباید هیچ آرگومانی داشته باشد. همچنین می‌توان از تورفتگی‌های بیشتر برای تشخیص واضح خطوط مذکور استفاده شود.

When using hanging indents, note that the first line should not have any arguments. Also, more indentations can be used to clearly distinguish the mentioned lines.

#آموزش_پایتون
#قراردادهای_پایتون

آدرس کانال:
@Programmingschool2
سایت آموزشی:
http://programmingschool.ir
گروه پرسش و پاسخ:
https://t.me/programmingschool_group

✅ از Linkedin آقای arash hosseini #مهندسی_سیستم لینک در نظرات پست
مهندسی سیستم بخش ششم:

پذیرش سیستم :
میزان موفقیت هر سیستم دست ساخته بشر و ماموریتش در شاخص های پذیرش ذیل نهفته است :
· آیا بازار برای پذیرش سیستم جدید آمادگی دارد ؟ یک نیاز عملیاتی به پنجره ای از موقعیت های جدید
· درک کاربر از ابزارهای عملیاتی، سازگاری و در دسترس بودن
· توانایی سیستم در انجام و به ثمر رساندن اهداف کاربر – اثر بخشی سیستم
· بازگشت سرمایه برای منابع وابسته به عملیات و نگهداری سیستم – به صرفه بودن
بیشتر افراد پذیرش سیستم را از دریچه رضایت زمینه کاری مشتری می بینند. مهندسین غالبا اندازه گیری این موضوع را به بعد از ارائه و توزیع سیستم در بازار محول می کنند. بر اساس چیزی که سازمان از نظرسنجی های پس از تحویل می آموزد، مهندسین ممکن است سیستم یا محصول را اصلاح کنند اگر :
· کاربر موقعیتی جدید برای رفع کمبودها، طی یک قرارداد توسعه به آنها ارائه نماید. البته کمبودهایی که در قرارداد اولیه در نظر گرفته نشده باشد.
· پیش بینی های سود بلندمدت سرمایه گذاری داخلی را ارزشمندتر نماید.
شما به عنوان یک مهندس سیستم باید نیازهای عملیاتی کاربر را قبل از توسعه و نظر سنجی درک نمائید، شما باید درک کنید که :
· کاربر قرار است چگونه از سیستم یا محصول شما استفاده نماید ؟
· چه معیارهایی برای موفقیت باید اعمال شود ؟
· پیامد شکست کاربر و بوجود آمدن شاخه های جدید از درجاتی از موفقیت چیست ؟
اگر توسعه دهندگان سیستم شاخص موفقیت برای پذیرش سیستم از طرف کاربر را درک ننمایند، بهترین طراحی نیز بیهوده خواهد بود، در نتیجه این موضوع یکی از مفاهیم پایه در مهندسی سیستم خواهد بود. شاخص های پذیرش یاد شده اگر چه از نظر روانی برابر به نظر می رسند، بندرت به صورت همزمان در حالت مطلوب قرار می گیرند. معیارهای ذهنی - یعنی درک از ابزارهای عملیاتی، مناسب بودن و دسترس پذیری، اغلب معیارهای عینی موفقیت سیستم (اثربخشی . به صرفه بودن) را مبهم می نماید.
· فاکتورهای نگاه ذهنی ، حس و درک در جامعه همتایان سیستم یا منبع سرمایه گذاری قالبا پذیرش موفقیت سیستم از دید کاربر را تا اندازه ای تیره تار می نماید.
· در مقابل، کاربر برای همان دلایل ذهنی ممکن است موفقیت عینی یک سیستم را زیر سوال ببرد.
در نهایت، برخی از رویدادها بررسی واقعیت را ممکن می سازد. یک تصمیم برای ادامه کار با یک سیستم ممکن است منجر به ایجاد نیاز به یک بروزرسانی برای تصحیح کمبودها، حذف تدریجی یک سیستم یا جایگزینی آن با یک سیستم جدید گردد. یک آن
ابزار عملیاتی، مناسب، در دسترس و موثر پیش ران اطمینان از وجود مهندسی سیستم به عنوان یکی از اجزای اصلی توسعه کلان از ایده تا ارائه نهایی می‌باشد. این فاکتورها به مانند شعار در میان بازاریاب ها مرسوم هستند و اغلب اندازه گیری آنها برای پیاده سازی بسیار دشوار می باشد. به طور معمول پیاده سازی سیستم نیاز به متخصصینی دارد که میزان قابل توجهی از تمرکز عمر کاری خود را بر اندازه گیری و ارائه این اطلاعات به نحوی که واقعی و قابل فهم برای تصمیم گیران کلیدی باشد، صرف کرده اند.
چالش های کلیدی توسعه سیستم های قابل پذیرش از طرف کاربران :
موفقیت و درجه پذیرش سیستم، محصول یا خدمت غالبا به کمک پاسخ به مجموعه ای سوالات که با آنالیز قبل از توسعه و با بازخورد و دریافت نتایج بعد از توسعه اندازه گیری می شود، اندازه گیری می شود. سوالاتی شامل موارد ذیل :
ادامه در کامنت

✅ بجای کد نویس بودن، برنامه نویس باشید!

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

مطلب زیر رو بخونید. تفاوت کد نویسی و برنامه نویسی رو تقریبا گفته:
https://roocket.ir/articles/programming-or-coding

✅ شروع دوره طراحی الگوریتم از کانال @BenDevelop
توصیه میکنم پیگیر این دوره باشید. نه به خاطر مدرسش (که البته واقعا کارش درسته) به خاطر اینکه یاد گرفتن طراحی الگوریتم میتونه مارو به سمت حرفه ای شدن توی برنامه نویسی سوق بده.
وقتی طراحی الگوریتم و ساختمان داده بلدی. خیلی بهتر میتونی کد بهینه بنویسی که سرعت اجرای بالایی هم داشته باشه و منابع زیادی هم مصرف نکنه.

اینم اولین ویدیو معرفی دوره الگوریتم و ساختمان داده که صحبتش رو کرده بودیم
تو این ویدیو دوره رو معرفی می‌کنم و توضیح می‌دم که دوره برای چه کسایی هستش و به چه ترتیبی باید ببینیدش

https://youtu.be/kclXvoKsEEY

@BenDevelop

قسمت سوم: تورفتگی‌های بخش شرطی if

زمانی که بخش شرطی یک عبارت if طولانی باشد لازم است در چند خط نوشته شود. در این حالت، نوشتن کلمه کلیدی و پرانتز باز در خط اول و بقیه شروط در سایر خطوط ایده جالبی نیست(مشابه Hanging Indent). زیرا باعث تداخل کدهای شرط if با کدهای بلوک آن شود.

When the conditional part of an if-statement is long, it requires to be written on multiple lines. In this case, it isn't an interesting idea to write the keyword if and open parenthesis in the first line and the rest of the conditions in the other lines (similar to Hanging Indent). Because it makes the code less readable.

در این حالت PEP هیچ ایده صریحی ندارد. برخی از شکل های نوشتاری قابل قبول عبارتند از:

In this case, PEP has no clear idea. Some acceptable written forms are:

۱- سایر خطوط مربوط به بخش شرطی، به صورت همتراز با خطوط بلاک if نوشته شود.

1- Other lines related to the conditional section should be alignment to the lines of the if block.

۲- بین خطوط بخش شرطی و دستورهای بلوک if یک خط کامنت قرار می‌دهند.

2- A comment line is placed between the lines of the conditional section and the if block commands

۳- تورفتگی های بخش شرطی، بیشتر از دستورات بلوک if است.

3- The indents of the conditional section are more than the if block commands.

#آموزش_پایتون
#قراردادهای_پایتون

آدرس کانال:
@Programmingschool2
سایت آموزشی:
http://programmingschool.ir
گروه پرسش و پاسخ:
https://t.me/programmingschool_group

قسمت سوم: تورفتگی‌های بخش شرطی if

در مثال بالا، سه فرم صحیح عبارت if با شرط طولانی را مشاهده می‌کنید.

In the example above, you see the three correct forms of the if statement with a long condition.

Please write clean code.🙏🙏

#آموزش_پایتون
#قراردادهای_پایتون

آدرس کانال:
@Programmingschool2
سایت آموزشی:
http://programmingschool.ir
گروه پرسش و پاسخ:
https://t.me/programmingschool_group

✅ یه پلی لیست خوب و رایگان با موضوع نتورک پلاس

دونستن network+ و مفاهیم پایه شبکه، میتونه به درد برنامه نویس ها بخوره
این مفاهیم به هیچ استک خاص و زبان برنامه نویسی خاصی مربوط نیست

https://www.aparat.com/playlist/1641292

✅ پیاده سازی logging در جنگو

توی جنگو، logging یک ابزاره که بهتون کمک می‌کنه تا پیام‌های مختلف رو ثبت و مدیریت کنید.
این پیام‌ها می‌تونن شامل پیام‌های عملیاتی، اطلاعاتی و خطاها باشن. با استفاده از logging می‌تونید اطلاعات مربوط به برنامه‌تون رو به صورت منظم ثبت و بررسی کنید.

تنظیمات logging توی settings.py قرار میگیره. این تنظیمات شامل مواردی مثل جایی که پیام‌های لاگ ذخیره بشن و چطور برچسب‌گذاری بشن، هستن.

توی کدهای جنگو می‌تونید از logging استفاده کنید. اول باید یه logger با یه نام دلخواه ایجاد کنید. بعد می‌تونید با استفاده از اون logger پیام‌های مختلف رو ثبت کنید. مثلا:

import logging

logger = logging.getLogger('my_logger')

logger.debug('DEBUG')
logger.info('INFORMATION')
logger.warning('WARNING')
logger.error('ERROR')
logger.critical('CRITICAL')

لینک داکیومنت جنگو:
https://docs.djangoproject.com/en/4.2/topics/logging/

✅ ترکیب Middleware های جنگو با logging

✔️ میتونیم با استفاده از میدلور ها و logging اطلاعات مفیدی رو لاگ کنیم. مثلا همه request و response هارو لاگ کنیم.
این مثال:
https://zeroes.dev/p/django-middleware-to-log-requests/

✔️ یا همه Exception هایی که رخ میده رو لاگ کنیم.
این مثال:
https://gist.github.com/Alexx-G/2a2986f2e8d93f554fb8

✅ لاگ کردن چه استفاده ای میتونه داشته باشه؟

یکی از استفاده هاش که میتونه دیباگ کردن باشه.
اما استفاده مهم ترش میتونه مونیتورینگ باشه.

ریپو زیر رو ببینید عنوانش گویای ماجراست
Monitoring Django applications with Grafana and Kibana using Prometheus and Elasticsearch


https://github.com/gonzalo123/django-logs

✅ پست مفیدی از کانال @ManiFoldsPython در مورد جاب آفر گرفتن از شرکت های خارجی
بقیه نکات در کامنت ها

مواردی که به نظر من یک بک اند کار برای کار تو شرکت های مدرن خارجی و گرفتن جاب آفر داخلشون باید بلد باشه, طبق تجربه این چند وقتم داخل مصاحبه ها و جاب هایی که دیدم:

1. آشنایی با گیت
2. تست نویسی
3. آشنایی با github action برای نوشتن فایل work flow yaml
4. درک عمیق تر از پایتون (خوندن کتابی مثل fluent python یا python cook book)
تسلط به پترن دیزاین ها
5. آشنایی با paradigms های مختلف برنامه نویسی
6. الگوریتم
7. تسلط روی SQL
8. آشنایی با MySQL یا PostgreSQL.
9. آشنایی با داکر و داکر کامپوز
10. آشنایی با مفاهیم Event driven architecture, SOA, microservice و Monolithic
11. تسلط رو یک فریم ورک microservice friendly مثل FastAPI یا Flask
12. آشنایی با یک فریم ورک Monolithic مثل جنگو میتونه مزیت خوبی باشه.
13. آشنایی با یک سرویس کلاد (AWS/Azure/GCP) در حد نیاز بک اند. معمولا certificate های مشخصی دارن که میتونید راجبشون تحقیق کنید و تو اون مسیری که مربوط به بک اند دولوپر میشه برین.
14. آشنایی با دیتابیس های کلاد مثل amazon rds
15. آشنایی با serverless و نمونش داخل کلاد مثل AWS Lambda
16. آشنایی با k8s در حد نوشتن فایل yaml سرویستون
17. آشنایی با یک ابزار IAC مثل terraform
(از بین ترافورم یا k8s و داکر, معمولا رو یکیش تمرکز میکنن شرکتا. و تو اغلب آگهی ها هم دیدم وزن بیشتر سمت داکر و k8s بوده تا ترافورم)


@ManiFoldsPython

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

هرگونه بی احترامی باعث ریمو‌میشه.
پروژه درسی سفارش ندید و نگیرید باعث ریمو‌ شدنتان میشود.

با تشکر.

لینک گروه:
https://t.me/researcher_people