✅ پست قابل تاملی از @pyHints

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

اگر قرار بود از اول شروع کنی، چه مطالبی رو دنبالش میرفتی ؟

قطعاً برای برنا‌مه‌ نویسی :
بجای اون همه جابجایی فقط ۳ تا زبان رو نگه می داشتم

Assembly, Rust, Python3

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

قطعاً توی این مسیرم باز هم
Cisco CCNA, CCNP
رو میخوندم. (البته پیشنهادم برای برنامه‌نویس‌ها این روزها درحد همون CCNA هست)

قطعاً بازهم
Linux RedHat
رو آزمون‌هاش رو میدادم (مدرک lpic رو دوس ندارم چون خیلی کاغذی هست)

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

💬 کامنت یکی از دوستان درباره این مطلب:

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

✅ مطلبی از @djangoex

✔️ شاید تا الان براتون پیش اومده باشه که موقع نوشتن حلقه‌های for در پایتون، با خودتون فکرکنید که شاید راه‌های بهتری هم وجود داشته باشه.

✅ در این مقاله ۳۰ مثال پایتونیک مختلف رو بررسی میکنیم تا از نوشتن حلقه‌های for اجتناب کنیم. مثال‌هایی که با استفاده از توابع built-in پایتون به دلیل پیاده‌سازی‌های داخلی پایتون (cpython) پرفورمنس بهتری دارن تا روش های functional programming که در کامیونیتی پایتون و متدهای built-in پایتون وجود داره و ...

توضیحات بیشتر همراه با مثال‌های مختلف رو می‌تونید در این مقاله مطالعه کنید:
👉 30 Pythonic Ways To Avoid For Loops — A Decade-Long Journey Best Practices

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

#python #best_practice
〰〰〰〰〰〰〰
© @DjangoEx

✅ مطلبی از @PinkOrca
در مورد مقایسه Bootstrap و Tailwind

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

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

بوتسترپ یه فریمورک Component-based هستش و از تعداد زیادی استایل آماده برای اجزای مختلف تشکیل شده، ولی تیلویند Utility-first هستش و تک تک ویژگی‌های اجزاء رو خود شما مثل CSS عادی توش با کلاس‌ها تعریف می‌کنید.
این از طرفی به این معنیه که نه تو تیلویند برخلاف Pure CSS، کدهای شما تکرار میشن، نه مثل بوتسترپ وابسته به چهارچوب هستید و اکثر خروجی‌ها مشابه از آب در میان!🫣 پس دستتون باز تره...
ولی مشکلاتی هم داره این موضوع.
برای کسی که تو CSS مهارت خوبی نداره و صرفا هدفش ساخت سریع یه UI هستش(مثلا برای یک بک‌اند دولوپر)، بوتسترپ می‌تونه ساده‌تر باشه. از طرفی چون کلاس‌ها خیلی جزئی و متنوع هستن تو تیلویند، باعث  میشه برخلاف فایل CSS که توش از تکرار کد جلوگیری شده، این‌بار فایل HTML ما یکم شلوغ‌تر بشه.🥴

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

سوال مهم:
بهترین منبع برای یادگیری تیلویند css کجاست؟
مثل بوتسترپ، تیلویند هم داکیومنتیشن خوب و کاملی داره. بهترین کار اینه که یه روز بهش مراجعه کنید و در کمتر از یک بعد از ظهر، کار رو باهاش یاد بگیرید! البته قبلش بهتره تو CSS، سطحتون متوسط رو به بالا باشه.

به نظرم چیزی که مهم بود رو رسوندم تو این نوشته و تا همینجا کافیه، نتیجه با شما.

~> @PinkOrca

این باگ ۱ ماه تیم رو درگیر کرده بود :

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

یک بخشی از کد رو داریم که همه‌ی تست هارو به درستی پشت سر میذاره، حتی تست‌هایی که توی pipeline و CI/CD داریم

همه چیز حتی بصورت هفتگی روی سیستم ها درست کار می‌کنه
اما بمحض اینکه میره روی سرور تست‌ خصوصی یا
A/B test

سرعتش تا ۲۰ برابر کندتر می‌شه شایدم بیشتر
ولی این مشکل رو روی سیستم دولوپر‌ها نداریم.

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

مشکل چی بود:

if item in mylist:

همین خط کد، ۲ تا مسئله داشتیم،
۱- نیروی junior ایی از طرف شرکت به تیم اضافه شده
۲- توی تیم DevOps هم چون کار روتین شده بوده، سپرده‌اند به یک نیروی Mid-level نگهداری رو

و همزمان ۲ تا خطا انجام شده :
۱- نیروی تیم توسعه و استفاده از in توی پایتون
۲- نیروی تیم DevOps و تبدیل یکی از pipeline های تست، ازش پرسیدند چرا انقدر تست طول می‌کشه بنده خدا رفته چک کرده دیده یک دیتاست بزرگ داریم برای تست
اومده این رو با یک دیتای کوچیکتر جایگزین کرده

و چون نیروی junior توسعه دهنده هم سواد کافی نداشته روی
mylist
توی مثال بالا برای چک کردن اینکه آیا یک نمونه‌ای وجود داره یا نه از
in

استفاده کرده، که روی حجم بالای دیتا منبع اصلی کند بودن هست :

راهکار :
۱- چون روی دیتاهای حجیم کار می‌کنیم، DevOps نباید دیتای تست رو تغییر میداد (اینجوری باگ خیلی زودتر خودش رو نشون میداد)

۲- نیروی تیم توسعه نباید از in و list استفاده میکرد :
۲-۱ : اول به این دلیل که ما اندیس داده رو نمی‌خواهیم فقط وجود یا عدم وجودش توی کدها مهم بوده که نوع داده‌ای set بسیار اینجا کمک کننده بود, همین که بدونیم ۱ مورد وجود داره برامون کفایت می‌کنه این یعنی فضای جستجو کوچکتر

۲-۲ : دستور in بطور کلی کند هست (برای list, set کوچیک خوبه) باید بجاش از الگوریتم‌ها و ساختمان داده درستش استفاده میکرد که Tree گزینه خوبی هست قطعاً.

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

نکته‌ی مهم :
حواستون باشه کجا از in استفاده می‌کنید و مهمتر اگر برای داده حجیم کد میزنید حتماً یکبار روی این حجم داده هم تست انجام بدید.

آقای Emanuele Viola استاد دانشگاه Northeastern هستند و حوزه کاریشون Computational Complexity هستش. اگه بخوام خیلی خیلی ساده بگم یعنی دنبال این قضیه هستند که کامپیوتر چه مسائلی رو میتونه حل بکنه و چه مسائلی رو نمی‌تونه حل بکنه. از وجناتشون اگر بخوام بگم علاوه بر مقالات خیلی خوبشون، مدرس خوبی هم هستند، فیلمای دوتا کلاس طراحی الگوریتم و نظریه محاسبات‌شون روی کانال یوتیوب‌شون هست. علاوه براین دست به قلمم هستند و یه وبلاگ خیلی جذاب دارند.

حالا همه اینا رو گفتم که برسیم اینجا. ایشون همین چند ساعت پیش، نسخه‌ی Draft کتابشون رو منتشر کردند. عنوان کتابشون هست : Mathematics of the impossible: Computational Complexity
همونطور که از اسمش پیداست، موضوع کتاب درباره‌ی نظریه پیچیدگیه و یا همون بحثی که بالاتر گفتم. منتهی فرق خیلی اساسی با کتابای دیگه این حوزه داره. یک، حجم جمع و جوری داره و میشه با یک برنامه‌ریزی خوبی خوندش. دو، برخلاف کتاب‌های این حوزه اصلا ترسناک نیست، یعنی اینطوری نیست که تا کتاب رو باز می‌کنی این حس بهت دست بده که زبان کتاب یونانیه. سه، بشدت متن روون و داستان وار و جذابی داره. مثلا توی فصل اولش میاد میگه میخوام یه تیزری از این کتاب بدم، بعد میاد میگه فرض کن یک کامپیوتر داری با ۳ بیت حافظه. این کامپیوتر یه کلاک داره که سر هر پالسش یکی از این دو عملیات رو انجام میده، یا یک بیت دیتا ورودی میخونه و حافظه رو آپدت می‌کنه، و یا متوقف میشه و یک مقداری رو برمی‌گردونه.

با همین کامپیوتر ساده شروع میکنه مسئله حل کردن. مسئله‌ی AND یک رشته n بیتی، مسئله‌ی چک کردن پالیندورم بودن یک رشته n بیتی و میرسه به مسئله‌ی Majority یک رشته n بیتی، یعنی بیش از نصف رشته اگر یک بود، روی یک توافق میشه و اگر نصف بیشتر رشته صفر بود روی صفر توافق میشه. سوالی مطرح می‌کنند که هر کسی در مرحله‌ی اول جوابش رو میگه نه، ولی متوجه می‌شید که میشه مسئله رو در زمانی که مد نظر مسئله هست حل کرد! و همونجا متوجه می‌شید که چقدر ارزش این علم بالاست.

خلاصه همینطوری فصل به فصل میان جلو و توی فصل آخر میگن I believe P=NP :))))

سر این قضیه که P = NP باشه خوبه یا بده قبلا یه پست توی کانال رفتم که بدون داشتن ذره‌ای سواد نظریه پیچیدگی می‌تونید متوجه‌اش بشید. پسته اینجاست.

یکی دیگه از کاربرد های fingerprinting میتونه request limit باشه.

تو هر api شما نیاز دارین برای gateway سرویس هاتون یک لیمیت بنویسید که کسی شما رو ddos نکنه.
یکی از راه حل های ابتدایی استفاده از IP Address هست. البته بخاطر وجود CGNAT عملا راهکار جالبی نیست چون هکر میتونه پشت CGNAT قایم شه که شما وایت لیست کردین و همچنان سیستمتون رو پایین بیاره.

پس برای یک راهکار safe باید چیکار کرد؟

1. برای روتر های private: از authentication header استفاده کنید و ریت لیمیت رو روی اون بذارین. در حالی که میتونه راه حل بنظر مناسبی باشه ولی هکر میتونه تعداد زیادی کاربر بسازه و با JWT هر کدوم بازم اسپم کنه. پس بازم راهکار کاملی نیست.

2. برای روتر ثبت نام: لیمیت کردن و حساسیت رو سرویس ثبت نام به ازای هر آی پی بدون داشتن وایت لیستی برای CGNATکه به طور periodic بلک لیست کنه اون آی پی رو و بعد چند ساعت دوباره بتونه حساب کاربری بسازه.

3. برای روتر پابلیک : استفاده از browser fingerprinting برای تشخیص دیوایس کاربر و گذاشتن ریمیت لیت روی ترکیب GPU fingerprint (مثل webgl یا webtrc) و IP بدون هیچ وایت لیستی. همین تکنیک میتونه رو روتر ثبت نام هم پیاده شه تا حساسیت روتر ثبت نام رو روی CGNAT کم کنه.


راهکار سوم راهکاریه که ddos shield ها ازش استفاده میکنن مثل cloudflare. راهکار بهترش اینه که خودتون مدل کاستومایز و فینگرپرینت مخصوص خودتون داشته باشین یا از سرویس پرمیومشون استفاده کنید که فایل جاوا اسکریپتشو تند تند آپدیت میکنن و به اطلاعات ویزیتور ها هم دسترسی میدن.


از نمونه سایت هایی که از راهکار سوم استفاده میکنن:
Sony Entertainment
Apple Store
Youtube


برای دیدن browser fıngerprint خودتون به این صفحه برین
@ManiFoldsPython

تجربه شخصی خودم از روند مصاحبه و نصیحت هایی که به مانی 3 ماه پیش میکردم 😁

1. OVERENGINEER AS MUCH AS YOU CAN
اولین و مهم ترین چیز همینه. این تجربم برمیگرده به مصاحبه اولم. لایو کدینگی که یک ساعت بود ولی 2 ساعت و نیم طول کشید 😂😂. آخر لایو کدینگ هم که 95درصد کدو نوشته بودم منو متوقف کرد و گفت کافیه. به من یک کدی نشون داد که همون کاری که من میخواستم بکنم رو تو 15 خط کد پایتون میکرد. من گفتم ریجکت شدم تموم شد رفت. پس فرداش آفر کاریش اومد و الان تو همون شرکت کار میکنم. گفت اگه رو پروداکشن اینطوری overengineer کنی دارت میزنم :)). شما با overengineer کردن تو لایو کد چلنج یا assigement مهارتتون رو show off میکنید و طبیعتا اجازه میده بهتون که نسبت به بقیه کاندید ها که تلاش داشتن KIS رو رعایت کنند جلو بیفتین و اون طرف متوجه شه که شما از کجا میاین (ترجمه I see where you're coming from😁) ریپوش اینجاست. اینکه چرا انتخاب شدم هم خوش یک سکشن جداست.


2. Try new technologies, don't be afraid of rejection
اینکه قبلا جنگو کار کردین ولی برای fast اقدام نمیکنید اشتباهه بنظرم. اگه اشتیاق کار کردن با اون استکو دارین حتما اپلای کنید. ملاک استخدام فقط بلد بودن و تسلط رو اون تکنولوژی نیست خیلی وقتا شانس اینو دارین رو تکنولوژی آفر بگیرین که شاید خیلی روش مسلط نیستین و صرفا آشنا هستین در صورتی که تو job requirement نوشته مسلط. مثال بارزش دوباره از خودم میزنم. من همیشه rest کار کردم. کل بک شرکتی که داشتم براش اپلای میکردم graphql بود و خیلی تاکید داشت روی تجربه با graphql. تو مصاحبه اول اصلا اشاره نکردم به اینکه هیچی از graphql بارم نیست. تو مرحله assignment یک هفته داکشو خوندم. شاید باورتون نشه ولی جاب آفر از اون پوزیشنم گرفتم :)) . پس دلیل نمیشه شما یک چیزی رو بلد نیستین تو آگهی بهش اشاره شده اپلای نکنید. تهش اینه که با اون تکنولوژی آشنا میشین.

3. THINK, THEN CODE
این از همه مهم تره. مهم ترین چیز critical thinking هست براشون. اینکه شما صرفا هدفتون انجام اون تسک نباشه. هدفتون هدف اون تسک باشه. حتی نیازی نیست از راهی که اشاره شده تو داکیومنت assignment برین. مثلا برای همین graphql پجینشن میخواست که من از راه حلی که خودش معرفی کرده بود نرفتم چون بنظره من اورلود نتورک داشت. راه حلشو تغییر دادم و یکی از دلایل اصلی قبول شدنم همین بود. یا اینکه مثلا درخواست رو نگفته بود async بزن ولی من درخواست اول رو sync میزدم که ببینم چند تا آیتم داریم بگیریم بعد به تعداد درخواست ها همرو تو سری دوم باهم async میزدم (که network efficient هم باشه و الکی اسپم نکنه). سورس کد ریپو. همه اینا نشون داد که به صورت مسئله حسابی فکر کردم. تو پوینت اولم فقط OVER-ENGINEER نکردم به صورت مسئله هم حسابی فکر کردم. سعی کردم تا جایی که میشه efficient باشه حتی شده با نقض داکیومنت assignment. هیچ شرکتی دنبال کسی نیست که فقط کپی پیست کنه یا فقط کاری که بهش میگن رو انجام بده و تک بعدی باشه, کد نویس ایده آل کسیه که خیلی فکر میکنه و میتونه راهکار نو و بهتر از راهکار قدیمی بده. با وجود اینکه من سابقه کار fastapi به صورت حرفه ای نداشتم یا graphql بلد نبودم چون صرفا thinker بودنمو خوب نشون دادم تونستم به این موفقیت برسم. از نمونه ریجکتیم هم بخوام بگم باید بگم یک assignment ام ریجکت شد و حتی فیدبک هم نگرفت چون خوب روش فکر نکرده بودم و صرفا کاری که بهم گفته بودن رو به ساده ترین شکل ممکن پیاده سازی کردم (انگار که رفع تکلیف باشه).


The most damaging phrease in the language is 'its always been done this way' - Grace Hopper

@ManiFoldsPython

@LATEX_Mesforush
در کانال آکادمی دکتر مس‌فروش می‌توانید تعداد زیادی از دروس ریاضی و کامپیوتر مرتبط با رشته‌های فنی و مهندسی و علوم پایه را که منطبق با سرفصل وزارت علوم، تحقیقات و فناوری و به طور کامل تدریس شده‌اند را بیابید. تمامی این دروس به شکل کامل و صد در صد رایگان بوده و با هدف برقراری عدالت آموزشی تهیه شده‌اند.
@LATEX_Mesforush

برنامه نویسی از پایه قسمت شصتم - اضافه کردن داشبورد

این قسمت رو با اضافه کردن اپ جدید شروع کردیم و اتفاقی با ماژول پروفایل و مفهوم profiler در پایتون آشنا شدیم. بعدش با مشکل cache مواجه شدیم و حلش کردیم. در ادامه متوجه شدیم که وقتی از یک تمپلت ارث بری می کنیم، جنگو اولویت استفاده از تمپلت base رو براساس app هایی که توی installed_app هستن تنظیم میکنه. و اگه دو تا base همنام داشته باشیم اولویت با اونی هست که بالاتر به installed_app اضافه شده. بعدش با flex-grow و justify-content و align-items توی css آشنا شدیم. در ادامه با مفهوم Semantic elemnts توی HTML5 هم بیشتر آشنا شدیم و بهترین روش برای نوشتن کدهامون رو از اینترنت سرچ کردیم. در نهایت بعد از ۳۰ دقیقه تونستیم یه تگ h1 به پروژه اضافه کنیم. عجب سرعت عملی

لینک آپارات:
https://www.aparat.com/v/qkZw3

لینک یوتیوب:
https://youtu.be/bvGGQ-7HKiY

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

توی این قسمت که حدودا ۱۰ دقیقه است. یه ایرادی رو برطرف کردیم که توی جلسه قبلی بهش دقت نکرده بودیم. بعدش باز یکم در مورد display direction و مفاهیم felx یاد گرفتیم. در نهایت هیچی به کدهای html اضافه نشد. و همچنان عجب سرعت عملی :)

لینک آپارات:
https://www.aparat.com/v/8q4y5
لینک یوتیوب:
https://youtu.be/YCgdErR2wBA

✅ از کانال @microfrontend_ir
در اغلب مصاحبه های فنی جنگو سوال کاربرد select_related پرسیده می‌شود با این وجو اغلب اهمیت این فانکشن نادیده گرفته می شود. عدم استفاده ویژگی مهم select_related در Django ORM میتواند تاثیر منفی سنگینی در اپلیکیشن داشته باشد. در این ویدیو کوتاه با یک مثال ساده سعی کردم تفاوت استفاده و عدم استفاده از django select_related را توضیح دهم

Video Link: https://youtu.be/TK3P4Cy5fNg

یادآوری ذکر شده در ویدیو:
همه چیز در مورد لاگ زدن در پایتون - Python Logging
https://youtu.be/32l7Wogtsxk

پیکربندی لاگ زدن در جنگو - django logging
https://youtu.be/LGatKmpL7k8


〰️〰️〰️〰️〰️〰️
© | @microfrontend_ir

ارسال آرگومان‌ها با تعداد نامشخص به تابع

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

زمانیکه از آرگومان‌های ستاره‌دار استفاده می‌شود در هنگام فراخوانی تابع نمی‌توان آرگومان ستاره‌دار را به صورت  parameter = arguman تعریف کرد. همانطور که در مثال اول مشاهده می‌شود سه مقدار 3 ، 2 و 5 به عنوان آرگومان به تابع ارسال می‌شوند. تابع، آن‌ها را در قالب یک تاپل در نظر می‌گیرد. در انتها این تاپل نمایش داده می‌شود.

نکته دیگر این است که تمام آرگومان‌های بعد از آرگومان ستاره‌دار باید به صورت parameter = arguman تعریف شوند.😊 همانطور که در مثال دوم مشاهده می‌شود آرگومان c ، که بعد از آرگومان ستاره‌دار b قرار دارد در هنگام فراخوانی به صورت c=4 تعریف شده است.

#آموزش_پایتون
#توابع
#آرگومان

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