گراف در پایتون
از بچه‌های گروه منتوری

@code_crafters

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

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

فرقش اینه به داشتن جنم هستش، اینکه اون بچه جنمش رو داشته ولی شما نه، یه جمله جالب هست که میگه خود کرده را تدبیر نیست

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

بعضی وقت‌ها حمایت کردن و کمک کردن بهتون اشتباه هستش واقعا من با همین بچه میبستم الان سایتش هم بالا اومده بود با همه موضوعاتش

اخیرا تحریم شکن‌ها از کار افتادن و کارشون تموم شده (زندگی با دیوانه‌ها چالش های خودش رو داره)

امروز هم من درگیرش بودم و یکی از بچه‌ها (جا داره اینجا ازش تشکر کنم) یه راه حل کارآمدتر از راهکار دیونه‌ها بهم داد که بهتون میگم

ابتدا برید تو سرور و ماشینتون و پکیج زیر رو نصب کنید

sudo apt install proxychains tor

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

بعد از اتمام نصب خودش بصورت پیش فرض آماده کار هستش و نحوه استفاده ازش اینجوری هست که ابتدای اون دستوری که میخواید بزنید proxychains رو اضافه میکنید

sudo proxychains apt update

sudo proxychains apt install <package-name>

خوبیش این هست که کل سیستم رو درگیر نمیکنه براتون و هرجا که از این دستور استفاده کنید میاد وسط

از مسیر زیر هم میتونید پروکسی مدنظر خودتون رو قرار بدید

sudo nano /etc/proxychains.conf

همون جور که می‌بینید می‌تونید از انواع پروکسی http, socks4, socks5 استفاده کنید و در انتهای فایل که برید پروکسی پیش فرض خودش رو می بینید که ست شده

<Type> <ip> <port> <name> <paswword>

socks5 127.0.0.1 9050

بالاتر هم یدونه example براتون گذاشته

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

sudo systemctl status tor
.
.
.

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


#free

@code_crafters

آموزش زبان c
از بچه‌های گروه منتوری
#c

@code_crafters

از مزایای شی گرایی (oop) چیه؟؟

اینکه بیشتر از ۵۰۰ خط کد رو به کمتر از ۱۵۰ خط کد تبدیل میکنی و بعدش میشنی چاییت رو میخوری (و میای کانال پست میزاری)


چرا این اتفاق افتاد؟
دو عامل مهم داریم
دانش فنی
بدهی فنی

وقتی بهتون یک فرایند سپرده میشه، یک داستان کاربری یا یک بخش از یک اپیک (epic)


شما هیچ درکی از موضوع و مسئله ندارید، پس تو مرحله اول میشینید به قدری کد میزنید که فقط اون تسک رو پاس کنید بره، یعنی به سرانجام برسه، اینجا شما دانش فنی کسب کردید منتها دچار بدهی فنی شدید و بعد می‌شینید در چندبار بررسی کد اون رو بهبود می‌دید و تمیز سازی هم انجام میدید

خروجی هم میشه اینکه کد شما رو هرکسی ببین، میگه اینکه کاری نکرده اصلا، این کدها خیلی راحته که

@code_crafters

آموزش کتابخانه seaborn

از بچه‌های گروه منتوری

@code_crafters

داکیومنت معرفی و کار با pylint بصورت ساده و مختصر
از بچه‌های گروه منتوری

یکی از مباحثی که داخل مصاحبه فنی ازتون میپرسن

@code_crafters

الگوریتم حریصانه و تقریبی

فایل تهیه شده از بچه‌های گروه منتوری

@code_crafters

☁️ سرورهای ابری (IaaS) به کوبار کلاد اضافه شد! 🚀


⏰ پرداخت ساعتی(PAYG)
🐧 سیستم‌عامل‌های متنوع
🌐 شبکه خصوصی(Private Network)
💾 دیسک اضافی (Volume)
🔑 پشتیبانی از کلید عمومی(SSH Key)
🖥 دسترسی به کنسول
📊 مانیتورینگ

🎁 اعتبار اولیه رایگان برای شروع سریع و بدون دغدغه

همین حالا سرور ابری خودتون رو با ۳ کلیک بسازید!

🌐 KubarCloud.com
🆔 @KubarCloud

هفته دوم یادگیری زبان سی برای شما
از بچه‌های گروه منتوری

#c

@code_crafters

استاد کاکایی

میگن هیچ نوازنده‌ای نمیتونه اندازه سازنده ساز، ساز رو به رقص خودش در بیاره

شعرهای استاد رو هم کسی جز خودش نمیتونه انقدر زیبا بیان کنه

هر اندیشه‌ای که منتهی به عمل نشود، مرض است


این جمله ناب رو گوته گفته
شاید بگید خب من اندیشه قتل دارم الان برم عملیش کنم؟؟؟

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

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

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



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

ولی موضوع گوته فراتر از بوکوفسکی هستش، بوکوفسکی از لذت حرف میزنه، گوته از شادی و حس خوب نسبت به خودمون، بحث اصلا تموم کردن یا نکردنش نیست(بقول بوکوفسکی)، بحث سر عملی کردن و انجام دادن هستش (بقول گوته)

خیلی وقت‌ها بابت اینکه نمیتونیم یکاری رو انجام بدیم ناراحتیم، مثلا اینکه چرا شاغل نیستم چرا شغل مورد علاقه خودم رو ندارم

گوته تو این یک جمله ساده میگه چقدر عملیش کردی، اصلا مهم نیست به شغل رسیدی یا نه، چه برسه مورد علاقه‌ت باشه

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


در واقع حس خوب و رضایت از خودمون به همین مسئله بستگی داره، اگه بابتش اقدام جدی نکنی به عملی کردنش، درگیر سرخوردگی و یاس میشی

میخوای مهندس نرم افزار بشی؟؟
عملیش کن
میخوای برنامه نویس بشی؟؟
عملیش کن
میخوای از تخصصت شغل داشته باشی؟؟
عملیش کن
میخوای مستقل بشی؟؟
عملیش کن


حرف آخر بابت حس رضایت درونی، اقدام برای اندیشه‌هامون هستش همین رو شما گوشه ذهنت نگهدار و انجام بده ببین چجوری به حس رضایت از خودت میرسی

#free

@code_crafters

در این مجموعه پست‌ها، می‌خواهیم کتاب http guideline را مطالعه کنیم و نکات آن را خلاصه نویسی کرده و به اشتراک بگذاریم.
این کتاب به شما دید خوبی درمورد http می‌دهد و با خواندن این کتاب میتوانید درک خوبی از مسائل مربوط به این پروتکل و اپلیکیشن‌های تحت وب به دست آورید.
این مجموعه پست ها را با هشتگ
#http_guideline
می‌توانید در کانال دنبال کنید.


کتاب در ابتدا خیلی ساده و کوتاه شروع شده و در فصل‌های بعدی هر بخش از فصل قبل را بازتر کرده و به جزئیات موارد می پردازد

در این پیام می‌خواهیم درمورد ssl certificate صحبت کنیم.
چگونه سرور‌ها هویت خود را ثابت می‌کنند؟

در پروتکل HTTP اطلاعات رمزگذاری نمی‌شوند.
درواقع یک connection به پورت ۸۰ سرور ایجاد می‌شود و یک request message از سمت کاربر ارسال می‌شود و یک response message از سوی سرور دریافت می‌شود و در نهایت این کانکشن بسته می‌شود.

این flow برای انتقال اطلاعات حساس همچون اطلاعات بانکی اصلأ مناسب نیست، چرا که هرکسی می‌تواند message ها را باز کند و اطلاعات آن را استخراج کند.

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

اکنون flow مقداری پیچیده می‌شود!
کاربر یک connection به پورت ۴۴۳ ایجاد می‌کند. هنگامی که سرور کانکشن را قبول کرد، ssl initialization انجام می‌شود.
در این مرحله پارامتر های رمزنگاری توسط client و server جابجا می‌شود. هنگامی که این handshake انجام شد، اطلاعات ابتدا به لایهٔ ssl ارسال و رمزنگاری می‌شود و سپس به سمت کلاینت/سرور ارسال می‌شود.

در مرحله ssl handshake اطلاعات زیر توسط کلاینت و سرور جابجا می‌شود:
- ورژن پروتوکل http
- یک کلید برای رمزنگاری
- یک session key موقت برای رمزنگاری شبکه
- اطلاعات هویتی سرور (certificate)

بیاید و یکم certificate رو باز کنیم!
درواقع certificate یک فایلی است که سرور برای اثبات هویت خود، به کلاینت ارسال می‌کند. این سرتیفیکیت برای اینکه اعتبار خود را نشان دهد، از پیش توسط یک Certificate authority امضا شده است.

این فایل شامل اطلاعات زیر می‌باشد:
- Public key
- Hostname of website
- Name of signing authority
- Signature of signing authority

هنگامی که این فایل توسط کلاینت دریافت می‌شود، مرورگر به صورت اتوماتیک ولیدیشن هایی را روی این فایل انجام می‌دهد. برای مثال:
۱- ابتدا تاریخ certificate بررسی می‌شود که منقضی نشده باشد
۲- امضای signature مورد بررسی قرار می‌گیرد تا مطمئن شویم authority قابل اعتمادی این certificate را امضا کرده.
۳- در این مرحله با authorities public key سیگنیچر را مقایسه می‌کنند تا مطمئن شوند CA واقعاً این certificate را امضا کرده.
۴- برای اطمینان از اینکه این certificate تنها برای این سرور است، domain سرور را با دامین سرتیفیکیت مقایسه می‌کنیم.


کاری از بچه‌های گروه منتوری

@code_crafters

یک اتصال امن با HTTPS

پیش‌تر آموختیم که ssl یک لایه رمزگذاری است که با رمزنگاری کردن پیام‌ها، امنیت اطلاعاتمان را در شبکه تضمین می‌کند.

تا زمانی که شما تبدیل به یک متخصص در زمینه ارز ها نشدید، نیاز نیست بدانید چگونه می‌توانید با raw ssl پیام‌های خود را جابجا کنید؛ چرا که کتابخانه‌های مختلفی وجود دارد تا بتوانید ssl program های خود را توسعه دهید!

برای مثال یکی از معروف‌ترین آن‌ها، OpenSsl است.

بیایید و ببینیم چگونه می‌توانیم به کمک ssl, پیام‌های خود را رمزنگاری و ارسال کنیم.

تصور کنید می‌خواهید یک پیام از کامپیوتر خود به یک سرور در آمریکا ارسال کنید.

۱- کامپیوتر شما یک local context می‌سازد و تمام اطلاعات handshake را با فراخوانی SSL_CTX آماده می‌کند.
۲- دامنهٔ سرور مقصد را به ip تبدیل می‌کند
۳- یک اتصال به پورت ۴۴۳ مقصد ایجاد می‌کند که نیازمند ساخت یک local socket است.
۴- هنگامی که اتصال برقرار شد، می‌توانیم لایهٔ ssl را به اتصال TCP خود وصل کنیم..
۵- سرور certificate خود را ارسال می‌کند و با کامپیوتر شما یک کلید رمزنگاری ارسال می‌کند
۶- تمامی اطلاعات با کلیدی که در مرحله ۵ ارسال شده بود، رمزنگاری و رمزگشایی می‌شود!

اما آیا این تنها راه است؟ جواب به این سوال، خیر است.

ما میتوانیم به واسطهٔ یک proxy server نیز، به صورت امن اطلاعات خود را جابجا کنیم.

به صورت ساده، این ارتباط به صورت زیر است:

«لوکال -> سرور پروکسی -> مقصد»

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

اینجا باید به گونه‌ای با سرور پروکسی صحبت کنیم که بداند می‌خواهیم از آن به عنوان یک middle man استفاده کنیم.

برای این‌کار از پروتکل HTTPS SSL TUNNELING استفاده می‌کنیم!

ابتدا به سرور پروکسی، یک درخواست با پروتکل مخصوص CONNECT می‌زنیم.
در payload آدرس سرور مقصد را می‌دهیم.

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

#http_guideline
@code_crafters

انتیتی (entity) و انکدینگ (encoding)

می‌دانیم که http روزانه میلیارد‌ها آبجکت از هر نوع اطلاعاتی (مانند عکس، فیلم، متن و...) را جابجا می‌کند؛
اما ارسال پیام برای ما کافی نیست!
ما باید مطمئن شویم که این پیام‌ها کاملا ارسال شده‌اند، identify شده‌اند، استخراج و پراسس شده اند.

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

قبل از اینکه بدانیم هدر ها کجا ست می‌شوند، بیایید یک نگاهی مختصر به ساختار http message داشته باشیم:

هر http message می‌تواند یا برای request باشد و یا برای response.
این پیام‌ها از سه بخش تشکیل شده‌اند:

۱- در این بخش ما ریسورس خود را مشخص می‌کنیم.
برای ریکوئست: url و host را به همراه method در این بخش ست میکنیم.
مثال:
GET google.com/random/path

برای ریسپانس: تنها جواب از سوی سرور را در اینجا ست می‌کنیم
404 google.com/random/path

۲- در این بخش هدرهای خود را ست میکنیم. هدر ها برای ریکوئست و ریسپانس گاهی متفاوت است.
برای ریکوئست، می‌گوییم: «من انتظار یک ایمیج را دارم» اما برای ریسپانس می‌گوییم «در این پیام برایت یک ایمیج را فرستادم».

۳- این بخش، بخش بدنه است. تنها در ریسپانس، در این بخش اطلاعات را می‌گذاریم.


* درواقع http headers یک plain text از هدر ها هستند که در لایه دوم http message قرار می‌گیرند.

در این بخش به مرور چند هدر معروف می‌پردازیم:

1- Content-type:
این هدر، نشان میدهد که شما در بخش body، انتظار چه اطلاعاتی را خواهید داشت.
برای مثال، هنگامی که شما یک متن را باز می‌کنید، content-type از سمت سرور مقصد به مقدار text/plain ست می‌شود.

2- content length
پیش از اینکه body را از یک http message استخراج کنیم، می‌بایستی بدانیم که چه انتظاری از بدنه خواهیم داشت.
برای مثال انتظار یک عکس با حجم ۲ مگابایت را داریم. پس در این هدر، ما حجم content را ست می‌کنیم.

3- content encoding
گاهی برای امنیت بیشتر و یا کم کردن حجم، ما اطلاعات یک پیام را encode می‌کنیم. در این هدر، به مقصد می‌فهمانیم که پیام از قبل با این الگوریتم encode شده، پس برای خواندن آن، آن را decode کنید.

#http_guideline
@code_crafters

Http Internationalization

روزانه میلیاردها انسان در جهان document هایی را به زبان‌های مختلفی در اینترنت به اشتراک می‌گذارند. همانطور که از اسم world-wide web مشخص است, این شبکه برای تمام افراد جهان با هر زبانی است. پس باید راهی باشد که بتوانیم به نوعی تمامی این اطلاعات را منتقل کنیم

هرگاه یک درخواستی ارسال می‌شود, یک هدر accept-language نیز با آن ارسال می‌شود. با این هدر کلاینت به سرور می‌گوید که من انتظار دارم پیامی که دریافت می‌کنم, زبانش این باشد.

پس از اینکه سرور با توجه به این هدر ریسپانس را فراهم و ارسال کرد, در آن یک هدر به نام content-language ارسال می‌کند. اینگونه کلاینت می‌تواند با استفاده از آن محتوای پیام را باز کرده و از ان استفاده کند.

اما چگونه این اطلاعات باینری تبدیل به متون قابل خواندن می‌شود؟ برای درک این موضوع ابتدا باید به مفهوم Charset ها بپردازیم.

درواقع این charset ها هستند که می‌گویند این مقدار باینری را به کدام یک از کاراکتر های کدام زبان وصل کنیم.

هنگامی که ریسپانس را دریافت می‌کنیم, در هدر content-type یک charset نیز ثبت شده است.
مثال:
Content-Type: text/html; charset=iso-8859-6

این به این معنی است که داده ما به صورت ۸ بیتی map می‌شود (که احتمالا یا لاتین است یا عربی!)

حالا کار این character set ها چیست؟
کرکتر ست ها درواقع دو کار را انجام می‌دهند.
۱- تبدیل باینری به کد کاراکتر
۲- تبدیل کد کاراکتر به کلمه

برای مثال ما می‌خواهیم به کمک کرکتر ست ها مقدار زیر را به کاراکتر تبدیل کنیم.

11100001
ابتدا این را به کاراکتر کد ۲۲۵ تبدیل می‌‌کنیم و سپس کد ۲۲۵ را به کلمه اصلی خود مپ می‌کنیم که درواقع کاراکتر «ف» است.
پس:
11100001 -> 225 -> ف

حالا که متوجه شدیم تمامی این کارها را کرکتر ست ها انجام می‌دهند, پس چرا هدر content-language ارسال می‌کنیم؟

کاراکتر ست ها صرفا الگوریتم هایی هستند که صرفا بر اساس زبان, می‌توانند کد ها را به کلمات مپ کنند.
برای مثال کرکتر کد ۲۲۵ در زبان‌های مختلف شکل های مختلفی دارد.
در زبان لاتین a و در زبان عربی «ف» است و در زبان یونانی «الفا».

به عنوان نکته پایانی باید درنظر داشت که کاراکتر‌ها می‌توانند فرم‌های گوناگونی داشته باشند.
برای مثال کاراکتر «ع» می‌تواند گاهی «عـ» نیز باشد.
اینجا نیاز است که مفهوم glyph را درک کنیم.

هنگامی که کاراکتر کد به یک کاراکتر مپ می‌شود, نوع نشان دادن آن مشخص نمی‌شود. ما صرفا می‌دانیم که 225 عدد کاراکتر «ف» است. حال نمایش دادن این عبارات بر عهده glyph است.
اگر بخواهیم موشکافانه تر به قضیه نگاه کنیم, فرایند تبدیل بصورت زیر خواهد بود:

11100001 -> 225 -> "ARABIT LETTER FEH" -> glyph shows «ف»

#http_guideline
@code_crafters

رمان گرگ بیابان از هرمان هسه

سالهاست میگذره که یادم نمیاد کی بوده که رمانی خونده باشم و چنان جذاب باشه که خوابش رو ببینم

یه رمان فلسفی بشدت سنگین هستش که درک کردن خط به خط اون واقعا سخته


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

شخصیت داستان بهش میگه تیغ اصلاح صورت منتظرمه تا پیش از موعود کارم رو باهاش انجام بدم (رگ گردنش رو بزنه)


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

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

حضور و وجود تسک‌های ناهمگام و زمان بندی و برنامه ریزی شده هستش

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

فریمورک fastapi چون پیش فرض و در دل خودش asyncio هستش این مورد هندل میکنه اما برای django ما از ترکیب celery با (rabbitmq ، redis) استفاده میکردیم اما این خودش یکمقدار افزونه و کار بیشتر اضافه میکرد


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

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

میتونید باهاش در پس زمینه یا برنامه ریزی شده ارسال ایمیل و پیامک داشته باشین، تصاویر و فایل‌هارو ذخیره کنید (حتی بصورت chunk) و علاوه بر این می‌تونید لایه‌کوئری رو هم باهاش به صورت ناهمگام با orm اجرا کنید


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


#django

@code_crafters

Content Negotiation

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

به این موضوع Content Negotiation می‌گوییم.
در این پیام به نحوه تصمیم‌گیری برای انتخاب یک زبان می‌پردازیم.
به طور کلی ما دو روش برای انتخاب زبان داریم:
- Client-driven negotiation
- Server-driven negotiation


اکنون به Client-driven negotiation می‌پردازیم.
در این مکانیزم هنکامی که کاربر به سایت codecrafters.ir درخواست می‌زنند, سرور کد کرفرترز برای کلاینت لیستی از زبان‌‌ها را ارسال می‌کند. اکنون مرورگر می‌تواند تصمیم بگیرد که کدام یک از url ها را باز کرده و به کاربر نشان دهد.
همانطور که متوجه شدید, این روش اصلا مناسب نیست! چرا که باید ۲ برابر ریکوئست ارسال شود و این موضوع latency را به شدت افزایش می‌دهد. پس بهتر است به فکر یک روش دیگری باشیم تا دیگر کلاینت این‌همه درگیر انتخاب زبان نباشد.

برای حل این موضوع Server-side negotiation بوجود آمد.
وب‌سرور به ۲ روش تصمیم می‌گیرد که کدام یک از زبان‌ها را انتخاب کند.
۱- استفاده از header هایی مانند Accept-language و Accept-charset.
۲- استفاده از User-agent کاربر.

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

گاهی Http اجازه می‌دهد که کاربران یک لیست از انتظارات خود ارسال کنند.
تصور کنید ما می‌خواهیم به سایت codecrafters.ir درخواست بزنیم اما نمی‌دانیم که آیا زبان المانی پشتیبانی می‌شود یا خیر.
پس ما در هدر Accept-language مقدار زیر را ارسال می‌کنیم:

Accept-language: en;q=0.5, fr;q=0.0., du;1.0.

هنگامی که سرور این پیام را دریافت می‌کند, اینگونه برداشت می‌‌کند که محتوا باید المانی باشد, اگر چنین چیزی موجود نبود, انگلیسی نیز می‌پذیرد. اما باید توجه داشته باشد که هیچگاه محتوای فرانسوی ارسال نکند.

گاهی نیز این تصمیمات را بر عهده proxy می‌سپاریم.
این proxy server است که تصمیم می‌گیرد به کدام resource درخواست بزند و اطلاعات لازم را به کاربر ارسال کند.


#http_guideline
@code_crafters

پروژه وقتی به مرحله پروداکشن میرسه، یه گام خیلی مهم داره که انجام اون الزام آوره

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

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

مهمترین نوع لاگ در دنیای برنامه نویسی audit log (لاگ میمیزی) هستش که در سطح امنیتی و رهگیری تمامی رفتارهای کاربر در سیستم انجام میشه که با جزئیات کامل صورت میگیره

در جنگو کتابخونه django-auditlog با نصب و کانفیگ (تنظیماتش خیلی راحت هستش) کردنش لاگ ممیزی رو در سیستم شما پیاده سازی میکنه و فیچرهای کنترلی زیادی رو هم بهتون میده

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

#monitoring
#django
#log
#audit_log

@code_crafters