محاصره در تراکنش ها

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

شاید بگید "خب چطور می‌شه فهمید؟ ما که تراکنشی شروع نکردیم!". ولی یه خورده صبر کنید... می‌تونیم یه دستوری اجرا کنیم که برامون نشون بده الان داخل کدوم تراکنشیم. بفرما:

SELECT txid_current();

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

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

شاید بپرسید چرا انقدر ریزه‌کاری؟ خب، اینجوری PostgreSQL، خیالش راحته که هر تغییری که انجام می‌شه، یا کاملاً انجام می‌شه، یا اصلاً انجام نمی‌شه. اگه توی یه دستور مشکلی پیش بیاد، کل تراکنش باطل می‌شه و هیچ تغییری اعمال نمی‌شه.

پس یادتون باشه، توی PostgreSQL، همیشه تو یه تراکنش هستید، چه بخواهید، چه نخواهید! این یه جور مراقبت اضافه‌ست که داده‌هاتون رو سالم نگه می‌داره.

#postgresql
@Code_Crafters

“… Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. “ —Joe Armstrong, creator of Erlang progamming language

وقتی به یک موز نیاز دارین تو یک تابعی , یک گوریلا با موز ندین به اون تابع! 😁 مقاله مدیوم:
https://medium.com/codemonday/banana-gorilla-jungle-oop-5052b2e4d588

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

# BAD
def activate_user(user: User, session) -> None 
     session.execute(sa.update(User).where(User.id==user.id).values(is_active=True) 

# GOOD
def activate_user(user_id: UserId, session) -> None
     session.execute(sa.update(User).where(User.id==user_id).values(is_active=True)

به این قانون law of demeter هم میگن. هدفشم چیزی جز بهتر شدن reusability کدتون و راحت تر تست نوشتن نیست.

@ManiFoldsPython

کسب اولین مدال برنز django از سایت stackoverflow را به خودم تبریک میگم. 😂

✅منیجرها در جنگو
از لینکدین Hamze Qaempanah
به کمک منیجر‌ها، می‌تونیم منطق‌های مرتبط با یک حوزه رو یکجا کپسوله کنیم و این توی پیاده سازی DDD هم به ما کمک می‌کنه.

سه تا از پرکاربردترین کارهای منیجرها که توی ویدئو بهشون اشاره کردم ایناست:
۱- کاستوم کردن منیجر با اضافه کردن متد کاستوم بهش
۲- تغییر دادن کوئری‌ست اولیه منیجر
۳- تعریف چندین کوئری ست و صدا زدنشون از طریق منیجر

پ.ن: تو ویدئو تپق دارم چون نمی‌تونم تایم زیادی برای رکورد و ادیت‌شون بذارم و همینطور دان ایز بتر دن پرفکت :)

⭕️ اگر در حوزه RedTeam فعالیت کرده باشید، مطمئناً با Evilginx آشنا هستید. Evilginx یک ابزار است که برای دور زدن 2FA و انجام مهندسی اجتماعی و فیشینگ مورد استفاده قرار می‌گیرد. با این حال، این نوع ابزارها پس از یک مدت زمان قابل شناسایی می‌شوند و سرویس دهنده‌ها می‌توانند آن‌ها را مسدود کنند.
حال به چند تکنیک برای جلوگیری از این اتفاق می‌پردازیم.

در ابتدا، برای انجام این روش، نیاز به دو دامنه و سرور، و همچنین یک حساب Cloudflare داریم. Evilginx را روی Apache نصب کرده و از Let's Encrypt برای فعال سازی SSL استفاده می‌کنیم. سپس سایت را به Cloudflare اضافه می‌کنیم.

با فعال کردن ویژگی Temporary Protections و تنظیم شدت آن به حالت Under Attack ، می‌توانیم سایت خود را در برابر حملات مخرب محافظت کنیم. همچنین با فعال کردن ویژگی Geo-blocking، قادر خواهیم بود دسترسی ابزارهای اسکنر و scraper را قطع کنیم. همچنین، با فعال کردن ویژگی Botfight نیز می‌توانیم در برابر حملات رباتیکی که به سایت انجام می‌شوند، محافظت کنیم.

با استفاده از ویژگی Meta Refresh، دو دامنه را در اختیار داریم. یکی Evilginx و دیگری Apache. با استفاده از این روش، می‌توانیم در صورت بازدید از Evilginx، کاربر را به Apache منتقل کنیم و Meta Data را نشان دهیم. با این کار، اسکنر ها با Apache برخورد خواهند کرد.

و در نهایت، از Obfuscation برای مخفی‌سازی کدهای HTML و JS استفاده کنید تا خوانایی آن‌ها به سادگی امکان‌پذیر نباشد.

#RedTeam #OpSec
@securation

🔹دورکینگ چیست؟

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

مثال:
برای پیدا کردن وب سرورهای ناامن و ضعیف:

intitle:"Welcome to Windows 2000 Internet Services"

پیدا کردن سایت‌هایی که امکان SQL Injection دارند:

inurl:index.php?id=

پیدا کردن صفحه‌های لوگین:

inurl:admin/login

پیدا کردن سرورهای FTP باز:

intitle:"index of" inurl:ftp

دورکینگ با تمام موتور‌های جستجو می‌تونه انجام بشه و هر موتور تکنیک‌های خودشو داره.

سرچ‌های خیلی پیچیده‌تری هم می‌شه با تکنیک‌های دورکینگ انجام داد. دو تا لیست از منابع دورکینگ آخر پست می‌ذارم.

👉🔗 Dorks Collection List
👉🔗 Dorking DB

#آموزش

سری مهندسی نرم‌افزار: پست 6
از لینکدین Saeed Shahrivari Joghan
زوج طلایی طراحی: سادگی + تفکیک دغدغه‌ها

اگه پست ۵ رو خونده باشید به اینجا رسیدیم که برای طراحی و تولید یه نرم‌افزار (باز هم تاکید می‌کنم دامنه نرم‌افزار شامل کد، داده و مستنداته🙂) که قابلیت تغییر، نگهداری و حتی تعمیر ساده‌تری داشته باشه رعایت دو اصل تا حد زیادی کافیه: «سادگی» و «تفکیک دغدغه‌ها». بیاید دقیق‌تر به این دو موضوع بپردازیم:

1️⃣سادگی: سادگی در طراحی نرم‌فزار یعنی درست کردن سیستمی که فهم، استفاده، نگهداری و تغییر اون ساده باشه. به نظرم سادگی چیزیه که برای همه تا حد زیادی ملموسه!
2️⃣تفکیک دغدغه‌ها (SoC): یعنی نرم‌افزار رو به بخش‌های متمایزی تفکیک کنیم به نحوی که هر بخش درگیر یک عملکرد (functionality) یا به عبارتی دغدغه (concern) خاص باشه و تا حد خوبی بخش‌ها ایزوله باشند. آیا این اصل یعنی هر ماژول فقط باید یه کار بکنه؟ جواب منفیه! کار با دغدغه متفاوته.

یه سوال جالب: این دو اصل چه نسبتی با هم دارند؟ میشه گفت معمولاً این دو اصل همراستا هستند ولی در موارد نادری ممکنه هم‌جهت نباشند. اگه مجبور بشیم بینشون اولویت داشته باشیم، از دید من همیشه سادگی به هر چیزی اولویت داره. حالا اگه این دو اصل رو در طراحی نرم‌افزار رعایت کنیم چه مزایایی داره؟
1️⃣فهم ساده‌تر: خوانایی و ساختارمند بودن نرم‌افزار خیلی مهمه. آقا مارتین فاولر میگه: ‌«هر احمقی قادره کدی بنویسه که ماشین بفهمتش، برنامه‌نویس خوب کسیه که کدی می‌نویسه که آدمها هم به راحتی درکش می‌کنند.»
2️⃣نگهداشت ساده‌تر: اگه این دو اصل رو رعایت کرده باشیم توسعه، نگهداری و حتی تعمیر نرم‌افزار به مراتب هزینه کمتری داره.
3️⃣قابلیت استفاده مجدد: وقتی نرم‌افزار از اجزای ساده و تر و تمیز تشکیل شده باشه میشه با تلاش کمی مولفه‌های موجود رو در جاهای دیگه هم استفاده کرد.
4️⃣آزمون‌پذیری بهتر: مولفه‌های ساده و تر و تمیز رو خیلی راحتتر میشه تست کرد.

مزایای خیلی زیادی میشه نوشت ولی من به همین ۴تا بسنده کردم. باز هم تاکید می‌کنم از دید من اصول همین دو اصله و حداقل ۵۰ ساله که در نرم‌افزار مطرح و استفاده می‌شه. دنبال هر فرقه یا اصول جدیدتر مثل SOLID یا DDD یا TDD و غیره هم برید بر پایه همین دو اصل هستند و من همیشه ترجیح دادم دید خودم رو باز نگه دارم و اصول دین رو صرفاً به این دو اصل محدود کنم و از هر رویکردی مثلاً DDD یا TDD در جای مناسب خودشون استفاده کنم چون تنها چیزی که در هر زمینه نرم‌افزاری به درد می‌خورند همین دو اصل هستند. در پست بعدی ایشالا به چابکی و تغییر می‌پردازیم.

پانوشت: مرحوم آقا دایکسترا خیلی در این زمینه زحمت کشیده!

چرا conda استفاده کنیم؟؟؟


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

conda create -n MyENV python=3.8

دوم اینکه محیطی که براتون میسازه رو داخل home شما و در دایرکتوری مخصوص خودش میسازه و نه در مسیر جاری شما خب این مزیتش این هست که شما راحت هرجا باشید میتونید ۱-سریع فعال و ۲-غیرفعال و یا محیط خودتون رو تغییر بدید و یا بدون دغدغه نسبت به محل قرارگیریش محیط جدید بسازید و ۳-حذف هم کنید و بین محیط‌های مختلف راحت سویچ کنید

1- conda activate my_env

2- conda deactivate

3- conda env remove -n MyENV

مورد بعدی هم اینکه:
۱-نصب پکیج هم داخلش راحته
۲-و علاوه بر خودش میتونید از pip هم استفاده کنید
۳- همچنین بروز رسانی پکیج

1- conda install PackName

2- pip install PackName

3- conda update PackName

۱-لیست پکیج‌های نصب شده رو هم میتونید ببینید
۲-و یا یک فایل حاوی ادرس‌های آن جهت نصب بسازید
۳-و یا بصورت yaml براتون قرار میده که از دو بخش تشکیل شده پکیج‌هایی که خودش نصب کرده و پکیج‌هایی که با pip نصب شده

1- conda list

2- conda list --explicit

3- conda env --export  > requirements.yml

که بالطبع میتونید اون رو هم در یک محیط دیگه نصب کنید

conda create -f requirements.yml

conda create -n MyENV -f requirements.yml

گفتیم همه محیط‌ها رو در یک مسیر قرار میده که با دستور زیر هم میتونید لیست همه محیط هاتون رو ببینید

conda env list

۱- اگه بخواید یک‌محیط رو‌حذف کنید ۲-یا یک پکیج رو حذف کنید

1- conda env remove -n MyENV --all

2- conda remove PackName

برای دیدن اطلاعات مربوط به محیط تون

conda info

جهت تست و بررسی سلامت محیط

conda doctor

جهت تغییر نام محیط با شرط فعال نبودن محیط تون(فراموش نکنید conda یک محیط base داره که با دستور اولی فعال میشه)

conda activate

conda rename -n OldName NewName

۱-جستجوی پکیج با نمایش تاریخچه تگ آن
۲-مشاهده وابستگی های آن
۳-مشاهده پکیج‌ها استفاده کننده آن

1- conda search PackName

2- conda repoquery depends PackName

3- conda repoquery whoneeds PackName

ادغام محیط شل با conda

conda init bash

پاک کردن پکیج‌های نا استفاده

conda clean

برای کانفیگ از قبیل محیط نصب، پکیج‌ها محدودیت دانلود و ...

conda config

conda config --help

موضوع جالب اینکه هنگام نصب پکیج تمام وابستگی‌ها رو اجرایی میکنه و نصب و حتی اگه نیاز به نسخه دیگری از پایتون باشه اون رو downgraid میکنه که منجر میشه تا حد ممکن براتون خطایی رخ نده و دردسر نکشید


داخل کامنت ها هم نحوه نصبش رو در اوبونتو میزارم


@code_crafters

📣 تبلیغ رایگان

کانال تلگرامی @pythonlearnme خیلی از مفاهیم رو بدون حاشیه توضیح داده و سریع رفته سر اصل مطلب

Nerwork&security
The Good, Bad and the Ugly

توی این کانال فقط قرار هست در مورد برنامه نویسی به زبان پایتون حوزه های شبکه و امنیت صحبت میکنیم

این کانال یک بلاگ شخصی هست و پیرامون نظرات و چیزهایی که توی بیش از 5سال کد زدن یاد گرفتم (فقط برای کمک به دوستان تازه‌کار)
👨‍💻📚Chief Information Security Officer/Red Hat/Network Administrator Useful Network Sensor/Security Consultant📚👨‍💻

Admin: @Antoone2024
Github:https://github.com/ChiefInformationSecurityOfficer
Linkedin: https://www.linkedin.com/in/amirsamrozveltr-rezvani-80653a291/

* چجوری توی پایتون نمودار بکشیم؟

خیلی وقتا پیش میاد که بخواین یه دیتایی رو ببرین روی نمودار، به دلایل مختلف:

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

چه ابزاری برای نمودار کشیدن ساده‌تر و کارآمد تره؟
من چندتا ابزار رو تست کردم، حتی ابزارهای گرافیکی، ولی به عقیده من بهترین و ساده‌ترین ابزار کتابخونه matplotlib بود.
فکر کنم این کتابخونه بصورت یه ماژول بیلت-این توی همه ورژنهای پایتون امبد شده باشه و وجود داره، تنها هزینه‌ش یه ایمپورته:)

import matplotlib.pyplot as plt

اگر نصب نبود که، آقای پیپ در خدمت شماست:

pip install matplotlib

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

هیستوریش هم خیلی باحاله،
آقای جان هانتر، که یه نوروبیولوژیست بود (نمیدونم ترجمه فارسیش چی میشه: عصب-زیست‌شناس یا همچین چیزی) میخواسته یه EEG رو روی نمودار نشون بده، نشسته این برنامه رو اون قدیما - سال 2002 شاید - نوشته، که بعدا بقیه هم دیدن گوگوله و استفاده کردن ... الان تیم matplotlib توسعه‌ش میده... اگه میخواین مشارکت کنین:

https://github.com/matplotlib/matplotlib
https://matplotlib.org/

نکته علمی هم EEG هست که مخفف Electroencephalography هست، به معنی "نوار مغزی"... یه بار کلمه‌ش هم بخونین، الکترو-انسِفالو-گرافی (uh·lek·trow·en·seh·fuh·lo·gruh·fee)

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

✅پستی از لینکدین Mohammad Amin Amjadi فعلا فقط تصمیم گرفته. اما از همین تصمیم اش خیلی چیزارو میشه یاد گرفت 🤣 لینک

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

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

- ساختار پیشنهادی پروژه

- نحوه داشتن یک setting زیبا (داشتن base و develop و ... اصلا خوب و مناسب نیست خصوصا برای پروژه های بزرگ)

_ نحوه مدیریت env ها و اینکه چه چیزهایی داخل env باشن

- شیوه‌های مناسب مدیریت پکیج‌ها و نکاتی که در پروژه‌های بزرگ با تعداد پکیج زیاد به وجود میاد

- ساختار و نحوه کدنویسی هر اپ

- شیوه‌های پیاده سازی ارتباط بین اپ‌های مختلف تا decouple نگه‌شون داریم

- شیوه‌های مدیریت dependency injection برای وابستگی‌های داخلی و بیرون هر اپ

_نحوه نگه‌داری کد و وابستگی‌ها تا در آینده با چالش‌های کمتری بتونیم در صورت نیاز به سمت میکروسرویس بریم یا بخش‌هایی از سورس کد رو به سرویسی مجزا منتقل کنیم

- دیدگاه‌ و معیارهای لازم برای شکوندن اپ‌ها

- نکات تست نویسی، چطور تست بنویسیم و برای چیا تست بنویسیم

- روش های ماژولاریتی خصوصا روش های Modular By Layer و Modular By Feature و پترن Vertical Slice Architecture و ...

- معماری Clean Architecture

- پترن MVC برای لایه Presentation و استفاده از اون برای توسعه وب سرویس های مبتنی بر DRF

- ملاحظات و نکات مدلسازی خصوصا وقتیکه تیم دیتا داریم، قراره Data warehouse بسازیم یا در آینده کارهای تحلیلی و دیتاساینس انجام بدیم و ...

_ ملاحظات فیلد‌های کاستوم در مدل و سریلایزر و ...

- کوئری‌هامون رو کجا بنویسیم؟

- چطوری کوئری‌هامون رو آپتیمایز کنیم؟

- این همه میگن Fat Model، Fat Model چه نکاتی و ملاحظات و باید و نبایدهایی داره و اینکه چرا باز این روش اصلا خوب نیست خصوصا برای تیم و پروژه‌های بزرگ و روش‌های جایگزینش چیه؟

- در کل بیزینس لاجیک رو کجا و چطور پیاده کنیم؟ کمی با DDD آشنا بشیم و دست به کد بشیم تا کدی مناسب برای پروژه و شرکت‌های بزرگ و استارتاپ‌هایی که اجایل بودن براشون مهمه بزنیم

_ ملاحظات ماگریشن‌ها و اینکه چطور ماگریشن دستی بنویسیم و اگر حجم دیتای زیادی داخل دیتابیس داشته باشیم چکار کنیم؟

_ مزیت Connection Pool چیه و چرا باید داشته باشیم و چطور؟

- چرا باید از Repository Pattern استفاده کنیم و چی هست اصلا؟ کی ازش استفاده کنیم؟

- اگر دو یا چندتا دیتابیس روی چندتا دیتاسنتر که بصورت failover کانفیگ شده باشن داشته باشیم چکار کنیم؟

- اگر بخواهیم per app یا per model تصمیم بگیریم از دیتابیسی مجزا استفاده بشه چکار کنیم؟

- اگر بخواهیم برای محیط local دولوپرها دیتابیسی داشته باشیم که اتوماتیک برای هر فرد دیتابیسی مجزا در نظر گرفته بشه چکار کنیم؟

- ملاحظات توسعه api با DRF و نکات کلاس‌های Serializers، Permissions, Relations و Fields، Renders و ...

- نکات مربوط به Dockerfile و اقدامات لازم جهت افزایش سرعت بیلد

- تنظیمات مناسب Gitlab-Ci

- کاربرد PreCommit و نقشش در بهبود فرآیند توسعه کد و code review و شیوه توسعه PreCommit کاستوم

- کار با ابزارهای Tracking، Profiling و monitoring

و ....

تو جواب ها اشاره کردن به بخش اول سوال. یک راه حل نسبتا کارگشا.
یک چیزی هست به اسم two phase commit. یعنی شما قبل اینکه بخوای یک transaction رو کامیت کنی میتونی یک اوکی بگیری از دیتابیس. دیتابیس بهت میگه این transaction تو اون لحظه ای که داری ازش میپرسی قابلیت کامیت شدن رو داره بدون مشکل یا نه. پس اون سرویس دوم باید two phase commit بزنه وقتی با سرویس اول داره حرف میزنه. و اگه اوکی بود ببره رو سرویس اول.

حالا مشکلی که وجود داره اینه که ممکنه اختلاف زمانی که تو two phase commit رخ میده ممکنه خودش باعث fail شدن transaction شه. یعنی state دیتابیس تو این چند ثانیه تغییر کرده باشه. ممکنه براتون سوال پیش بیاد باید چیکار کرد؟‌
هیچی باید تسلیم شد!

این بحث تو ریاضی بهش میگن Two Generals' Problem که هیچوقت حل نشده و ثابت شده حل نشدنیه.
یعنی چی؟‌ یعنی فکر کنید دو ژنرال میخوان به یک شهر حمله کنن با ۲ ارتش مختلف از ۲ نقطه مختلف. ژنرال اول به دوم میگه دو شنبه صبح حمله میکنیم. ژنرال اول نمیدونه ژنرال دوم پیامش رو دریافت کرد یا نه. برای همین باید صبر کنه که ژنرال دوم جواب بده. ژنرال دوم میگه باشه شنیدم. حالا ژنرال دوم نمیدونه که ژنرال اول پیامشو دریافت کرد یا نه. حالا باید صبر کنه دوباره ژنرال اول بگه شنیدم. و این loop تا انتها میتونه بره.

بنابر این قضیه, شما حتی میتونی درخواست HTTP بزنی که duplicate شه یعنی دو بار ارسال شه! چون acknowledge نشده.
واسه همین fault tolerancy همیشه تا یک حدی معقوله. از یک جا به بعد دیگه میشه مرز جنون :)) خوبه بهش فکر کنیم ولی یادمون نره وارد جنون نشیم 😁
@PyBackEndHub

توی شرکت روی پروژه شرکت مثال زدم؛ عذر میخوام اگر توی تصویر بالا مثال خیلی کاربردی نیست
جایی رو ندیدم مثال خوب / واقعی بزنه یا زده باشه سعی کردم ی مورد مشابه رو مثال بزنم

فرض کنید ما ۳ نوع فایل داریم که خیلی برامون مهم هست :
1- لاگ‌ها ؛ خطاهای سرویس‌ها - دیتابیس و ... توی این فایل‌ها نوشته میشه و وجودش برای پروژه بسیار بسیار مهم هست
پس اگر فایل لاگ وجود نداشت پروژه به هیچ وجه نباید روی پروداکشن بره

2- فایل‌های کمکی؛ وجودشون مهم هست اما نه اونقدری که نذاریم پروژه بره روی پروداکشن
بعنوان مثال تصویر لوگوی شرکت

3- یک سری گذارشات روزانه مثلا و.ضعیت پرداخت‌ها و ...
که بصورت اتوماتیک انتهای ساعت کاری هر روز درست میشه؛ اما اگر یکی از ادمین‌ها یا مشتری‌ها وسط روز بخواد خروجی بگیره ممکنه نداشته باشم.

توی مثال بالا بصورت دیفالت هر ۳ فایل یک ارور رو بر میگردونه :
FileNotFoundError
که اگر بخوایم exception handler بنویسیم باید حتما توی داخلی ترین تابع پردازش نوشته بشه و حتما باید بررسی کنیم که توی یک تابع یا متد بصورت همزمان وجود بیش از ۱ مورد از فایل‌های بالا بررسی نشه چون در اون صورت نمی‌دونیم ارور مربوط به عدم وجود کدوم فایل بوده و نمی‌تونیم تصمیم بگیریم آیا ابزار باید روی پروداکشن بره یا خیر یا ...

اهمیت custom exception نوشتن همینجا مشخص می‌شه؛
شما می‌تونید هرجایی که دلتون خواست و هر نوع فایلی که دلتون خواست رو بررسی کنید.
برنامه‌نویس‌های تیم شما آزادی عمل بیشتری دارند و این یعنی تصمیمات بهتری می‌تونند بگیرند
دیباگ کردن بسیار راحت تر خواهد بود؛ چرا که به لطف خطاهای مشخص می‌تونید درجا سروقت تابع یا متدی برید که وظیفه بررسی اون خطا رو داره
جداسازی مفاهیم مختلف؛ مثل بررسی لاگ و اعمالش یا بررسی و برخورد با گزارشات روزانه و ... باعث میشه شما بتونید کد رو به راحتی به افراد مختلف بسپارید و این یعنی کار کردن به صورت پارالل به راحتی قابل انجام هست پس سرعت توسعه کد قطعا بیشتر خواهد بود.
و ...


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

ولی در نظر بگیرید:
هیچ کس از رعایت best practice ها متضرر نشده و نمی‌شه.

سلام به همه. درسته که بعضی پست هایی که فوروارد میکنم به یک یا چند پست دیگه وابسته هستن (مثل همین دو پست آخر).
ولی نکاتی که توی این پست ها هست، مد نظر منه و به نظرم آموزنده هستن.
مثلا یکی به Two Generals' Problem اشاره کرده.
یکی دیگه هم به custom exception اشاره کرده.

لکن از @Abbasi_ai و @mani_nikou به خاطر مطالب آموزنده شون تشکر میکنم.

کامنت @Sepehr_e
سلام و درود. من برای این یه راه حلی دیدم از ریپو یکی از دوستان بنظر اومد مربوطه
کاری که کردن اومدن و از models.CASCADE استفاده کردن و یه SOFT_CASCADE نوشتن که همه مدلای مربوطه رو سافت دلیت میکنه

from django.db import connections
from django.utils import timezone
from collections import defaultdict


def SOFT_CASCADE(collector, field, sub_objs, using):
    collector.data = defaultdict(set)

    collector.collect(
        sub_objs,
        source=field.remote_field.model,
        source_attr=field.name,
        nullable=field.null,
        fail_on_restricted=False,
    )

    collector.data = defaultdict(set)

    for item in sub_objs:
        item.is_deleted = True
        item.delete_date = timezone.now()
        item.save()

    if field.null and not connections[using].features.can_defer_constraint_checks:
        collector.add_field_update(field, None, sub_objs)

https://github.com/mejomba/django_shop_m89_final/blob/main/core/models_on_delete.py

✅اولین پست از Mohammad Amin Amjadi
لینک
بریم سراغ اشتباهات پروژه جنگو! و اولین پستی که قولش رو داده بودم.
سعی کردم بر اساس کدهای گیت‌هاب و تجربیاتی که داشتم یکسری اشتباهات و مطالب رو باهاتون در میون بذارم.
فرض کنین که بک اند یک فروشگاه اینترنتی به این شکل پیاده شده.
از اونجایی که زودتر شروع کردن رو به یک شروع بی نقص ترجیح می‌دم قطعا اشتباهات و ایرادات زیادی بهم وارد هست.
ممنون میشم با دقت مطالعه کنین و هر نظر و سوالی داشتین باهام در میون بذارین.
امیدارم که مفید باشه و حمایت فراموش نشه.

✅یه دوره رایگان در مکتب خونه با عنوان تحلیل و طراحی سیستم

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

درس تحلیل و طراحی سیستم یا همان مهندسی نرم افزار 1 اساسی‌ترین درس برای شروع یادگیری مراحل توسعه سیستم‌های نرم افزاری است و مهمترین پیشنیاز آن درس برنامه‌نویسی شئ‌گرا می‌باشد.
در این دوره آموزشی، مفاهیم اساسی و اصول اولیه تحلیل و طراحی سیستم‌های نرم افزاری با رویکرد شئ گرا و بر مبنای متدولوژی RUP تشرح شده است. در جلسات اول مفاهیم اساسی تحلیل و طراحی سیستم‌ها بیان شده است. در ادامه مراحل توسعه نرم‌افزارها بر اساس متدولوژی RUP تدریس شده و برای تسلط کامل دانشجو بر مفاهیم طراحی، ابتدا ابتکارات طراحی شئ‌گرا و در ادامه اصول اساسی SOLID و در نهایت الگوهای طراحی به تفصیل بیان شده است و در نهایت قسمت‌هایی از مراحل تحلیل و طراحی یک سیستم نمونه آورده شده است.
لینک

معرفی چند دوره‌ی جامع با لود بالا خاص کسانی که میخواهند در زمینه مهندسی نرم افزار به شکل حرفه ای چه در صنعت و چه به شکل پژوهشی کار کنند:

۱. متدولوژی‌های ایجاد نرم افزار :
https://ocw.sharif.edu/course/id/336


۲. الگوها در مهندسی نرم افزار :
https://ocw.sharif.edu/course/id/443


۳. طراحی شی گرای سیستم ها :
https://ocw.sharif.edu/course/id/38


۴. ایجاد چابک نرم افزار:
https://ocw.sharif.edu/course/id/448


پ ن: این دوره ها رو با حواس جمع ببینید و از نکات بسیار خوبی که گفته میشه نهایت استفاده رو ببرید.

✅آموزش پیاده سازی جنگو در پلتفرم های مختلف لیارا، هم روش و وی پی اس
از علی بیگدلی

در این وبینار تلاش بر این است تا مدل های مختلف پیاده سازی را به دوستان ارائه کنیم تا بتوانند بدون ترس و با خطا های کمتر گزینه های مناسب را برای پیاده سازی انتخاب کنند. از جمله مواردی که در این وبینار بررسی خواهد شد نحوه تبدیل و تغییر layout یک پروژه برای پیاده سازی در هر متد است و در ادامه به ویژگی هایی اشاره خواهد که به شما در تصمیم گیری انتخاب خواهد کرد.

همچنین در هر مورد می توانید هزینه ها و کیفیت سرویس را بررسی کنین از جمله ، پیاده سازی ها با CICD و همچنین بکاپ گیری های مداوم.

لینک آپارات:
https://www.aparat.com/v/lRu59
لینک سایت علی بیگدلی:
لینک

✅سری مهندسی نرم‌افزار: پست 7
از لینکدین Saeed Shahrivari Joghan
توسعه چابک نرم‌افزار: سرعت یا انطباق؟

حوالی سال ۲۰۰۱ میلادی تعدادی از افراد شناخته شده حوزه نرم‌افزار طی بیانیه‌ای اعلام کردند که به راه‌های بهتری برای توسعه نرم‌افزار نسبت به دهه ۹۰ میلادی رسیدند و عنوان این بیانیه رو گذاشتند «توسعه نرم‌افزار به صورت چابک». بر خلاف روش‌های کلاسیک اجایل ارز‌ش‌های جدیدی رو تاکید می‌کرد:
۱- ارزش بیشتر افراد و تعاملات نسبت به فرآیند‌ها و ابزار
۲- ارزش بیشتر نرم‌افزاری که کار می‌کنه نسبت به مستندات مفصل
۳- ارزش بیشتر تعامل با مشتری نسبت به مذاکره قرارداد
۴- ارزش بیشتر پاسخ به تغییر نسبت به پایبندی به برنامه قبلی
زیر بیانیه هم یه نکته نوشته شده که معمولاً کسی نمی‌خونه: «آيتم‌های آخری بی‌ارزش نیستند بلکه آیتم‌های اولی ارزش بیشتری دارند.»

من همیشه اعتقاد داشتم که اجایل بودن به معنی سریع بودن نیست بلکه ذات فلسفه اجایل «پاسخ و واکنش مناسب به تغییراته». به قول فرنگیا که میگن embracing change یعنی فراتر از پذیرش تغییرات اونها رو در آغوش بکشیم. سوال مهم اینه که «چرا باید انقدر در مقابل تغییرات منعطف باشیم؟» من در پاسخش دو تا نکته دارم:
۱- در فرآیند تولید نرم‌افزار مخصوصا شناسایی دقیق نیازمندی کاربر ما درگیر یه پروسه غیر قطعی، تکاملی و اکتشافی هستیم. یعنی ما به مرور متوجه نیازمندی دقیق کاربر میشیم و خیلی مواقع این نیازمندی‌ها تغییر می‌کنند پس ما باید به جای جنگیدن با تغییر اونها رو کامل بپذیریم. یکی از راهکار اصلی چابکی برای هضم تغییرات فرآیند تکرار‌شونده و افزایشی هست.
۲- از دید من چابکی و هضم تغییرات در راستای بقای کسب‌وکار تعریف میشه. یعنی مثل روال طبیعت اگه با تغییرات بیشتر خودت رو وفق بدی، بیشتر بقا پیدا می‌کنی. در واقع مثال خوب برای چابکی یوزپلنگ نیست که با اینکه خیلی سریعه ولی همه جا در حال انقراضه بلکه مثال خوب میتونه حضرت کروکدیل باشه که ده‌ها میلیون سال روی زمین بقا داشته. پس معمولاً شرکتی که چابکتر باشه به تغییرات واکنش بهتری نشون میده و در بازار بقای بیشتری پیدا می‌کنه.

در زمینه چابکی حرف زیاده ولی تو این پست بیشتر از این اطاله کلام نمی‌کنم و در پست‌های بعدی بیشتر توضیح میدم. برای یادآوری هم که شده بد نیست نگاهی مجدد به بیانیه چابکی بندازیم:
https://agilemanifesto.org/