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

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

#حریم_خصوصی
#رمز_نگاری
#پسورد
#hash
#salt
#password
#privacypolicy

@easymicroservice
@easymicroservices
@csharptips

سریال this is us درباره یه خواهر و دو تا برادر همسن هست که یکی شون به فرزند خواندگی گرفته شده و سر همین از اون دو تا خیلی باهوش تر و برای درامای سریال حتی سیاه پوست هم هست. (دو تا سفید و مو بلوند)
یه جای سریال پدر خوانده از رندال (برادر سیاه پوست) سوال های ریاضی طور می‌پرسه و پسر با اینکه جواب ها رو میدونه اما نمیگه
پدر عصبانی میشه و پسر رو دعوا می‌کنه که تو که باهوشی چرا انقدر نمره هات بده و چرا تلاش نمیکنی؟
پسر در دفاع از خودش میگه که دوس نداره جواب درست بده چون باعث میشه فقط خودش جایزه بستنی بگیره و خواهر برادرش جایزه نگیرن و این جوری خواهر برادرش از رندال بدشون میاد و نمیخواد که متفاوت باشه

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

تاپیک #موقعیت_سخت

✅ پارامتر on_delete که توی تعریف یک رابطه (relationship) در مدل ها استفاده میشه، نحوه رفتار سیستم در مواقع حذف یک شی مرتبط با شی دیگه رو مشخص می‌کنه.

⚠️قرارداد: توی این متن به جدول اصلی میگم پدر. به جدول خارجی میگم فرزند.

احتمالا با مقدار on_delete=models.CASCADE آشنا هستید. وقتی که CASCADE باشه. اگر پدر رو حذف کنیم همه فرزندانش هم حذف میشن.

✔️اما مقدار on_delete = protected (توی جنگو) به معنای اینه: در صورتی که پدر بخواد حذف بشه و فرزندی داشته باشه، یک خطای ProtectedError ایجاد میشه. در واقع این حالت اجازه نمیده پدری که فرزند حذف نشده داره، حذف بشه.

کمی حرف حساب..

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

مهندس نرم افزار حالا واقعا کیه؟
به طور کلی اون شخصی که یک نرم افزار از صفر تا صد رو تحویل مشتری میده میشه مهندس نرم افزار‌.
مهندسی نرم افزار خیلیییییی فراتر از کد زنی هست
اصولا دید کد زنی و برنامه نویسی با دید مهندسی تفاوت زیادی داره ( اینو اگر تو ایران بگین احتمالا کتک بخورین ولی حقیقته) چون اکثرا ( حدود ۹۹ درصد) اسیر پدیده golden hammer هستن.
یه زبان بلدن و فکر میکنن ختم عالمن :)

یه مهندس نرم افزار بسته به این که تو چه زمینه ای فعالیت میکنه باید بتونه سیستم رو تحلیل و طراحی کنه، ریسک ها رو بسنجه، پروژه رو مدیریت کنه و هر مرحله ای که لازمه برای ساخت یه نرم افزار رو در نظر بگیره که داستانش خیلی خیلی مفصله و تقریبا خیلی از این مسائل به کد مربوط نیست!
حرف حساب من بیشتر روی شرکتای معتبره که رو پروژه های خاص دارن کار میکنن وگرنه متاسفانه تو ایران دید مناسبی از مهندسی نرم افزار وجود نداره.
برای مثال شرکتای بزرگ مهندس متدلوژی دارن! که البته فیلد تحقیقاتی خودم هم همین مهندسی متد هست.
و کارش چیه؟ میان بسته به یه پروژه که تعریف میشه یه متدلوژی رو مهندسی میکنه
در واقع میاد یه process line برای ایجاد نرم افزار تعریف میکنه و این کاملا سفارشی شدست و بسته به پروژه و ریسک هاش میتونه متفاوت باشه
تو این زمینه مقالاتی هم هست که میتونید بخونید.
و این در حالیه که تو ایران فقط مدیران پروژه اسکرام رو بلدن و برای هر پروژه ای از اسکرام استفاده میکنن و طبعا نتیجش رو هم میبینن.
حتی خود سازندگان اسکرام اون رو برای هر پروژه ای توصیه نمیکنن!
این مشکلات متاسفانه ناشی از نبود سواد کافی و البته پدیده golden hammer هست که خیلی خیلی زیاده این روزا
حرف آخر من به هر کسی که به شکل حرفه ای میخواد مهندسی نرم افزار رو ادامه بده اینه که inertie رو تا حد امکان کاهش بدن. دنبال یادگیری چیزای جدید باشن. فک نکنن یه چیز بلد باشن دیگه ختم عالمن و یاد بگیرن چیزای بد و اشتباه رو با دونستن پاد الگو ها تغییر بدن

✅ یک ویدئوی خیلی مفید از @BenDevelop
✔️ توی این ویدئو امیربهادر سه تا نکته در مورد مرتبه زمانی (پیچیدگی زمانی) میگه که من خودم تا امروز برداشتم اشتباه بود.
✔️ یه مثال پادشاه و شطرنج هم اشاره کرد، که بهراد قبلا توی لینک های زیر توضیح داده:
رشد نمایی:
https://www.tgoop.com/TadavomnisT_channel/92
داستان تا کردن کاغذ:
https://www.tgoop.com/TadavomnisT_channel/93
داستان شطرنج:
https://www.tgoop.com/TadavomnisT_channel/95


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

https://www.youtube.com/watch?v=2L-9QV0Nqgo&t=1295s

@BenDevelop

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

یه چیزی هست که شاید خیلی‌هاتون متوجهش نشده باشید. اونم اینه که توی 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 به خاطر مطالب آموزنده شون تشکر میکنم.