یک نقشه راه کامل برای یادگیری ساختار داده ها و الگوریتم ها (DSA) : 👇👇
1. یادگیری مبانی برنامه نویسی : با یادگیری اصول اولیه یک زبان برنامه نویسی مانند پایتون، جاوا یا C++ شروع کنید. به مفاهیمی مانند variables, loops, functions, and arrays مسلط شوید.
2. یادگیری ساختارهای داده: ساختارهای داده اساسی مانند :
arrays, linked lists, stacks, queues, trees, graphs, and hash tables
را به خوبی درک کنید. عملیات قابل اجرا بر روی این ساختارهای داده و پیچیدگی های زمانی آنها را مطالعه کنید.
3. آشنایی کامل با الگوریتم‌ها : الگوریتم‌های رایج مانند
searching, sorting, recursion, dynamic programming, greedy algorithms, and divide and conquer
را بیاموزید. نحوه کار این الگوریتم ها و پیچیدگی های زمانی آنها را درک کنید.
4. حل مسئله: حل مشکلات کدنویسی را در پلتفرم هایی مانند LeetCode، HackerRank یا Codeforces تمرین کنید. از مشکلات آسان شروع کنید و به تدریج به سمت مشکلات متوسط و سخت بروید.
5. تجزیه و تحلیل پیچیدگی : یاد بگیرید چگونه پیچیدگی زمانی و مکانی الگوریتم ها را تجزیه و تحلیل کنید. با نماد Big O و نحوه محاسبه پیچیدگی الگوریتم های مختلف آشنا شوید.
6. ساختارهای داده پیشرفته : به ساختارهای داده پیشرفته مانند
AVL trees, B-trees, tries, segment trees, and fenwick trees.
مسلط شوید. درک زمان و نحوه استفاده از این ساختارهای داده در حل مسئله.
7. الگوریتم های نمودار : الگوریتم های Graph traversal مانند BFS و DFS را یاد بگیرید. الگوریتم هایی مانند Dijkstra's algorithm, Bellman-Ford algorithm, and Floyd-Warshall را برای حل مشکلات با کوتاه ترین مسیر مطالعه کنید.
8. برنامه نویسی پویا : بر تکنیک های برنامه نویسی پویا برای حل موثر مسائل پیچیده مسلط شوید. حل مسائل برنامه نویسی پویا را تمرین کنید و مهارت های خود را ارتقا دهید.
9. تمرین و مرور : به طور منظم مشکلات کدنویسی را تمرین کنید و راه حل های خود را مرور کنید. اشتباهات خود را تجزیه و تحلیل کنید و از آنها درس بگیرید تا مهارت های حل مسئله خود را بهبود ببخشید.
10. مصاحبه های ساختگی : با شرکت در مصاحبه های ساختگی و حل مشکلات کدگذاری به سبک مصاحبه، برای مصاحبه های فنی آماده شوید. توضیح فرآیند فکر و استدلال پشت راه حل های خود را تمرین کنید.
منابع برتر DSA برای مصاحبه کدنویسی
👉 GeekforGeeks
👉 Leetcode
👉 Hackerrank
👉 FreeCodeCamp
👉 Best DSA Resources
1. یادگیری مبانی برنامه نویسی : با یادگیری اصول اولیه یک زبان برنامه نویسی مانند پایتون، جاوا یا C++ شروع کنید. به مفاهیمی مانند variables, loops, functions, and arrays مسلط شوید.
2. یادگیری ساختارهای داده: ساختارهای داده اساسی مانند :
arrays, linked lists, stacks, queues, trees, graphs, and hash tables
را به خوبی درک کنید. عملیات قابل اجرا بر روی این ساختارهای داده و پیچیدگی های زمانی آنها را مطالعه کنید.
3. آشنایی کامل با الگوریتم‌ها : الگوریتم‌های رایج مانند
searching, sorting, recursion, dynamic programming, greedy algorithms, and divide and conquer
را بیاموزید. نحوه کار این الگوریتم ها و پیچیدگی های زمانی آنها را درک کنید.
4. حل مسئله: حل مشکلات کدنویسی را در پلتفرم هایی مانند LeetCode، HackerRank یا Codeforces تمرین کنید. از مشکلات آسان شروع کنید و به تدریج به سمت مشکلات متوسط و سخت بروید.
5. تجزیه و تحلیل پیچیدگی : یاد بگیرید چگونه پیچیدگی زمانی و مکانی الگوریتم ها را تجزیه و تحلیل کنید. با نماد Big O و نحوه محاسبه پیچیدگی الگوریتم های مختلف آشنا شوید.
6. ساختارهای داده پیشرفته : به ساختارهای داده پیشرفته مانند
AVL trees, B-trees, tries, segment trees, and fenwick trees.
مسلط شوید. درک زمان و نحوه استفاده از این ساختارهای داده در حل مسئله.
7. الگوریتم های نمودار : الگوریتم های Graph traversal مانند BFS و DFS را یاد بگیرید. الگوریتم هایی مانند Dijkstra's algorithm, Bellman-Ford algorithm, and Floyd-Warshall را برای حل مشکلات با کوتاه ترین مسیر مطالعه کنید.
8. برنامه نویسی پویا : بر تکنیک های برنامه نویسی پویا برای حل موثر مسائل پیچیده مسلط شوید. حل مسائل برنامه نویسی پویا را تمرین کنید و مهارت های خود را ارتقا دهید.
9. تمرین و مرور : به طور منظم مشکلات کدنویسی را تمرین کنید و راه حل های خود را مرور کنید. اشتباهات خود را تجزیه و تحلیل کنید و از آنها درس بگیرید تا مهارت های حل مسئله خود را بهبود ببخشید.
10. مصاحبه های ساختگی : با شرکت در مصاحبه های ساختگی و حل مشکلات کدگذاری به سبک مصاحبه، برای مصاحبه های فنی آماده شوید. توضیح فرآیند فکر و استدلال پشت راه حل های خود را تمرین کنید.
منابع برتر DSA برای مصاحبه کدنویسی
👉 GeekforGeeks
👉 Leetcode
👉 Hackerrank
👉 FreeCodeCamp
👉 Best DSA Resources
GeeksforGeeks
The Ultimate Beginner's Guide For DSA - GeeksforGeeks
A Computer Science portal for geeks. It contains well written, well thought and well explained computer science and programming articles, quizzes and practice/competitive programming/company interview Questions.
Forwarded from Pythonism
به به چقد دوستون دارم :(
اومدم چندتا مورد راجع به برنامه نویسی بگم نصف شبی به چالش بکشونیم خودمونو.
یسری چیزا هستن که تو هر شغلی اینا عادین مثلا یک #حسابدار ممکنه یجایی عددی رو اشتباه وارد کنه، ممکنه عددی رو اشتباه بخونه، ممکنه کالایی رو اشتباه بزنه و... یا یک فروشنده ممکنه رمز کارت شمارو به اشتباه بزنه یا مبلغ رو اشتباه بزنه اینا مواردین که ما بار ها و بارها دیدیم توی اجتماع و دلیلشم کند ذهن یا بلانسبت خنگ بودن طرف نیست این بخاطر زیاد کارکردن، درگیری زیاد، تکراری شدن اون کار بصورت روتین هستش که باعث میشه یه وقتایی مغز ارور بده :( تو برنامه نویسی یسری موارد هستن مثل:
- فراموش کردن سینتکس زبان
- نامفهوم بودن کد های قبلی یا حتی کامنت ها
- پیدا نکردن راه حل برای باگ یا تسک
- فراموش کردن فریم ورک یا کدای اون
درگیری روی یک تسک یا باگ به مدت چند روز یا ساعت
دلیل همه اینا اینه که شما ساعتها درگیر میشید و یک چیز عادی هست البته اگر همچین مواردی نباشه مطمئن باشید ادامه راه سخت میشه براتون جاهایی هنگ کردن نیازه به جواب نرسیدن نیازه تغیر رویه لازمه و الی آخر
تو کارتون مخصوصا برنامه نویسی اصلا تعصب نداشته باشید همیشه جستجو کنید، بپرسید، مطالعه کنید، بخونید و قهوه بخورید درکنار اینا :(
نا امید نشید #پایتونیزمی های عزیز❤️
#SXL
@pythonism_xl
اومدم چندتا مورد راجع به برنامه نویسی بگم نصف شبی به چالش بکشونیم خودمونو.
یسری چیزا هستن که تو هر شغلی اینا عادین مثلا یک #حسابدار ممکنه یجایی عددی رو اشتباه وارد کنه، ممکنه عددی رو اشتباه بخونه، ممکنه کالایی رو اشتباه بزنه و... یا یک فروشنده ممکنه رمز کارت شمارو به اشتباه بزنه یا مبلغ رو اشتباه بزنه اینا مواردین که ما بار ها و بارها دیدیم توی اجتماع و دلیلشم کند ذهن یا بلانسبت خنگ بودن طرف نیست این بخاطر زیاد کارکردن، درگیری زیاد، تکراری شدن اون کار بصورت روتین هستش که باعث میشه یه وقتایی مغز ارور بده :( تو برنامه نویسی یسری موارد هستن مثل:
- فراموش کردن سینتکس زبان
- نامفهوم بودن کد های قبلی یا حتی کامنت ها
- پیدا نکردن راه حل برای باگ یا تسک
- فراموش کردن فریم ورک یا کدای اون
درگیری روی یک تسک یا باگ به مدت چند روز یا ساعت
دلیل همه اینا اینه که شما ساعتها درگیر میشید و یک چیز عادی هست البته اگر همچین مواردی نباشه مطمئن باشید ادامه راه سخت میشه براتون جاهایی هنگ کردن نیازه به جواب نرسیدن نیازه تغیر رویه لازمه و الی آخر
تو کارتون مخصوصا برنامه نویسی اصلا تعصب نداشته باشید همیشه جستجو کنید، بپرسید، مطالعه کنید، بخونید و قهوه بخورید درکنار اینا :(
نا امید نشید #پایتونیزمی های عزیز❤️
#SXL
@pythonism_xl
انواع سرچ ها روی لیست:
خیلی خلاصه چند تا از انواع سرچ ها رو روی لیست باهم ببینیم:
فرض کنید یه لیست نا مرتبی از اعداد داریم به این شکل:
lst = [30, 2, 7, 14, 1, 25, 4, 15, 9]
اگه بخواهیم دنبال عدد ۱۵ بگردیم باید چیکار کنیم؟
1- Linear search(not optimized)
میتونیم از ایندکس شماره صفر شروع کنیم و تک تک تا انتها بریم جلو و اعداد رو نگاه کنیم ببینیم ۱۵ داخلشون هست یا نه. این درواقع کاری هست که پایتون انجام میده زمانی که شما از in استفاده میکنید. چون اعداد ترتیبی ندارن کار دیگه ای نمیشه کرد.
________________________________________
اگه اعداد مرتب بودن چی؟
lst = [1, 2, 4, 7, 9, 14, 15, 25, 30]
2- Linear search(optimized)
فرض کنیم میخواهیم دنبال عدد ۵ بگردیم. دوباره میتونیم شروع کنیم تک تک اعداد رو مقایسه کنیم، ولی بعد از اینکه به عدد ۷ رسیدیم، میتونیم دیگه ادامه ندیم. چون اعداد مرتب هستن، حتما توی اعداد بزرگتر از ۷ هم نخواهد بود. بهتر شد اینجا.
3- Jump search
میتونیم به جای اینکه تک تک به جلو بریم و اعداد رو، چند تا چند تا جلو بریم و بپریم اصطلاحا (jump search).
فرض کنید دنبال عدد ۲۵ میگردیم. میتونیم اعداد رو ۲ تا ۲ تا جلو بریم، یعنی اول ایندکس شماره ۰ (یا عدد ۱) و نگاه میکنیم، بعد میریم ایندکس شماره ۲ (یا عدد ۴)، بعد ایندکس شماره ۴ (یا عدد ۹) و تا آخر، هر جا که دیدیم عدد ایندکس مورد نظر بزرگتر از عدد مقصود ماست، یعنی به اون تیکه از لیست که ممکنه عدد هدف داخلش باشه رسیدیم، فقط کافیه داخل اون رو به صورت linear نگاه کنیم. برای پیدا کردن عدد ۲۵ ، فقط ۶ تا مقایسه لازم بود. (تو حالت خطی ۸ تا). حالا این jump ما چقدر باشه خوبه؟ محاسبات نشون میده که رادیکال n بهترین گام هست. ( n تعداد آیتم های داخل لیست هست)
4- Binary search
کافیه توی هر مرحله لیستمون رو به دو قسمت تقسیم کنیم، و آیتم هدف رو با آیتم وسطی مقایسه کنیم، اگه کوچیکتر بود، دیگه فقط توی اون نیمه ی سمت چپ دنبالش میگردیم، اگه بزرگتر بود توی نیمه ی سمت راست. و دوباره همینکار رو تکرار میکنیم تا به هدف برسیم.
5- Interpolation search
خیلی شبیه binary search هست با این تفاوت که اونجا نقطه ای که لیست ما رو تقسیم میکرد و دقیقا وسط لیست میگرفتیم، ولی اینجا با استفاده از این فرمول، اون نقطه رو بدست میاریم:
mid = low + ((key - arr[low]) * (high - low) / (arr[high] - arr[low]));
low = کوچکترین ایندکس
high = بزرگترین ایندکس
key = آیتم هدف
این فرمول نقطه ی تقسیم رو مایل به چپ یا راست پیدا میکنه، نزدیک تر به آیتم هدف. ولی برای اینکه interpolation search بتونه خیلی سریع عمل کنه، باید لیست ما به صورت یکنواخت توزیع شده باشه.
6 - Exponential search
توی این روش که برای لیست های خیلی بزرگ کاربرد داره، از ابتدا شروع میکنیم به گشتن، ولی گام های ما به صورت exponential هست (توان های ۲):
0, 1, 4, 9, 16, 25, ...
وقتی که آیتمی پیدا کردیم که از آیتم هدف ما بزرگتر بود، میایم اون تیکه رو دوباره فقط جست و جو میکنیم(مثل jump search) ولی دیگه این جست و جو خطی نیست بلکه روش binary search انجام میدیم.
نکته: این الگوریتم ها بسته به شرایط الگوریتم های خیلی بهتری هستن از کاری که پایتون انجام میده. به پایتون حتی اگه لیست مرتب شده هم بدید باز تک تک سرچ میکنه. ولی خب نکته اینجاست که اون با C پیاده سازی شده و احتمالا توی خیلی از پیاده سازی های pure python از الگوریتم هایی با time complexity بهتر سریعتر باشه.
در آینده سعی میکنم بیشتر درمورد time complexity ی هرکدوم از این انواع سرچ و اینکه کجا کدوم بهتره استفاده بشه صحبت کنیم.
خیلی خلاصه چند تا از انواع سرچ ها رو روی لیست باهم ببینیم:
فرض کنید یه لیست نا مرتبی از اعداد داریم به این شکل:
lst = [30, 2, 7, 14, 1, 25, 4, 15, 9]
اگه بخواهیم دنبال عدد ۱۵ بگردیم باید چیکار کنیم؟
1- Linear search(not optimized)
میتونیم از ایندکس شماره صفر شروع کنیم و تک تک تا انتها بریم جلو و اعداد رو نگاه کنیم ببینیم ۱۵ داخلشون هست یا نه. این درواقع کاری هست که پایتون انجام میده زمانی که شما از in استفاده میکنید. چون اعداد ترتیبی ندارن کار دیگه ای نمیشه کرد.
________________________________________
اگه اعداد مرتب بودن چی؟
lst = [1, 2, 4, 7, 9, 14, 15, 25, 30]
2- Linear search(optimized)
فرض کنیم میخواهیم دنبال عدد ۵ بگردیم. دوباره میتونیم شروع کنیم تک تک اعداد رو مقایسه کنیم، ولی بعد از اینکه به عدد ۷ رسیدیم، میتونیم دیگه ادامه ندیم. چون اعداد مرتب هستن، حتما توی اعداد بزرگتر از ۷ هم نخواهد بود. بهتر شد اینجا.
3- Jump search
میتونیم به جای اینکه تک تک به جلو بریم و اعداد رو، چند تا چند تا جلو بریم و بپریم اصطلاحا (jump search).
فرض کنید دنبال عدد ۲۵ میگردیم. میتونیم اعداد رو ۲ تا ۲ تا جلو بریم، یعنی اول ایندکس شماره ۰ (یا عدد ۱) و نگاه میکنیم، بعد میریم ایندکس شماره ۲ (یا عدد ۴)، بعد ایندکس شماره ۴ (یا عدد ۹) و تا آخر، هر جا که دیدیم عدد ایندکس مورد نظر بزرگتر از عدد مقصود ماست، یعنی به اون تیکه از لیست که ممکنه عدد هدف داخلش باشه رسیدیم، فقط کافیه داخل اون رو به صورت linear نگاه کنیم. برای پیدا کردن عدد ۲۵ ، فقط ۶ تا مقایسه لازم بود. (تو حالت خطی ۸ تا). حالا این jump ما چقدر باشه خوبه؟ محاسبات نشون میده که رادیکال n بهترین گام هست. ( n تعداد آیتم های داخل لیست هست)
4- Binary search
کافیه توی هر مرحله لیستمون رو به دو قسمت تقسیم کنیم، و آیتم هدف رو با آیتم وسطی مقایسه کنیم، اگه کوچیکتر بود، دیگه فقط توی اون نیمه ی سمت چپ دنبالش میگردیم، اگه بزرگتر بود توی نیمه ی سمت راست. و دوباره همینکار رو تکرار میکنیم تا به هدف برسیم.
5- Interpolation search
خیلی شبیه binary search هست با این تفاوت که اونجا نقطه ای که لیست ما رو تقسیم میکرد و دقیقا وسط لیست میگرفتیم، ولی اینجا با استفاده از این فرمول، اون نقطه رو بدست میاریم:
mid = low + ((key - arr[low]) * (high - low) / (arr[high] - arr[low]));
low = کوچکترین ایندکس
high = بزرگترین ایندکس
key = آیتم هدف
این فرمول نقطه ی تقسیم رو مایل به چپ یا راست پیدا میکنه، نزدیک تر به آیتم هدف. ولی برای اینکه interpolation search بتونه خیلی سریع عمل کنه، باید لیست ما به صورت یکنواخت توزیع شده باشه.
6 - Exponential search
توی این روش که برای لیست های خیلی بزرگ کاربرد داره، از ابتدا شروع میکنیم به گشتن، ولی گام های ما به صورت exponential هست (توان های ۲):
0, 1, 4, 9, 16, 25, ...
وقتی که آیتمی پیدا کردیم که از آیتم هدف ما بزرگتر بود، میایم اون تیکه رو دوباره فقط جست و جو میکنیم(مثل jump search) ولی دیگه این جست و جو خطی نیست بلکه روش binary search انجام میدیم.
نکته: این الگوریتم ها بسته به شرایط الگوریتم های خیلی بهتری هستن از کاری که پایتون انجام میده. به پایتون حتی اگه لیست مرتب شده هم بدید باز تک تک سرچ میکنه. ولی خب نکته اینجاست که اون با C پیاده سازی شده و احتمالا توی خیلی از پیاده سازی های pure python از الگوریتم هایی با time complexity بهتر سریعتر باشه.
در آینده سعی میکنم بیشتر درمورد time complexity ی هرکدوم از این انواع سرچ و اینکه کجا کدوم بهتره استفاده بشه صحبت کنیم.
Wikipedia
Jump search
search algorithm
🗃 390 پروژه رایگان پایتون
این ریپو دارای 390 پروژه متن باز عالی با مجموع 1.7 میلیون ستاره است که در 28 دسته گروه بندی شده اند. همه پروژه ها با امتیاز کیفیت پروژه رتبه بندی می شوند که بر اساس معیارهای مختلفی که به طور خودکار از GitHub و مدیران بسته های مختلف جمع آوری می شود، محاسبه می شود.
🔻🔻
https://github.com/ml-tooling/best-of-python
این ریپو دارای 390 پروژه متن باز عالی با مجموع 1.7 میلیون ستاره است که در 28 دسته گروه بندی شده اند. همه پروژه ها با امتیاز کیفیت پروژه رتبه بندی می شوند که بر اساس معیارهای مختلفی که به طور خودکار از GitHub و مدیران بسته های مختلف جمع آوری می شود، محاسبه می شود.
🔻🔻
https://github.com/ml-tooling/best-of-python
GitHub
GitHub - ml-tooling/best-of-python: 🏆 A ranked list of awesome Python open-source libraries and tools. Updated weekly.
🏆 A ranked list of awesome Python open-source libraries and tools. Updated weekly. - ml-tooling/best-of-python
Forwarded from Python BackendHub (Mani)
سوال پرسیدن که این پکیج چیه اصلا و کارش چیه. اولا باید بگم اگه onboarding guide اش رو بخونید خیلی راحته استفاده ازش. تو ۱ دقیقه میتونید بالا بیارین و شروع به استفاده کنید. بدون اینکه چیزی رو بخواین هاست کنید.
اول بذارین توضیح بدم observation یعنی چی. ما توی devops دو آپریشن داریم که شبیه همن و گاها باهم اشتباه گرفته میشن. اولیش مانتورینگه. مانیتورینگ به پروسه ای میگن که دیتا کالکت میشه از سرویسی, و یک ریپورت از سلامت سرویس بر اساس metric های مشخصی که برای سلامت سیستم رو نشون میدن و کالکت شدن ساخته میشه. یعنی چی؟ مثلا تعداد ریسپانس های 5xx در ۲۴ ساعت گذشته. یکی از شناخته شده ترین ابزار برای اینکار prometheus هست. observability به پروسه ای میگن که رویکرد تحقیقاتی داره. یعنی دنبال این نیست که بگه چقدر ریسپانس 5xx وجود داره. دنبال دلیل وجود این ریسپانس هاست. چرا الان این درخواست تو پروداکشن ارور ۵۰۰ میده؟ خوندن کل لاگ سرویس قدیمی ترین و ابتدایی ترین راهکار بود.
وقتی بک اند پیچیده تر شد, دیگه خوندن لاگ واقعا کارساز نبود. شما فکر کنید در لحظه ۱۰۰ درخواست داره میاد براتون. چطور میخواین لاگ هارو بخونید؟ تو قدم بعدی لاگ های هر درخواست رو جدا کردن. ولی بازم کار ساز نبود تو دنیای distributed system. چون مثلا یک سرویس ۱ با سرویس ۲ داشت حرف میزد. ورودی که میداد بهش درست نبود. سرویس ۱ صرفا یک exception میگرفت که سرویس ۲ استتوس ۵۰۰ داده. و این کافی نبود برای اینکه متوجه شیم چه اتفاقی میفته.
سولوشن های زیادی اومدن تو مارکت. از قبیل sentry که شاید اسمشو شنیده باشین. یا datadog و لوکی و ... . اینقدر این سولوشن ها زیاد شدن و هر کدوم ساز خودشون رو میزدن. نمیشد راحت از این سولوشن سوییچ کرد به اون یکی. نمیشد مزایا دو سولوشن رو همزمان داشت. و learning curve سختی داشت اگه میخواستین سوییچ کنید از یکی به یکی دیگه.
اینجا بود که CNCF (Cloud native compute foundation) یک پروژه جدید رو استارت زد. همون فاندیشنی که کوبر و prometheus و خیلی ابزار های تحت کلاد رو ساخته. اومد یک پروتکلی ساخت به اسم opentelemetry.
یعنی چی پروتکل؟ یعنی گفت sentry جان من برام مهم نیست شما لاگ رو چطور ذخیره میکنی یا پردازش میکنی اینترنالی. شما باید span داشته باشی. metric داشته باشی. و trace. و دقیقا تعریف کرد که اینا چین. یعنی اومد گفت اینترفیس خارجی یک سیستم observability چطور باید باشه؟ چون در نهایت همه این سیستما شبیه هم بودن. و حالا چون همشون داشتن از یک پروتکل خاصی پیروی میکردن شما میتونستی راحت از سولوشن یک سوییچ کنی به سولوشن دو. مثلا شاید مثالشو دیده باشین که تو سیستم فایل استوریج بعضی استوریجا s3 compatible هستن. اینم دقیقا شبیه همونه.
استک observation به دو قسمت تقسیم میشه. یکی میشه exporter و یکی میشه داشبورد. exporter معمولا یک لایبریه که شما نصب میکنی. و باهاش اون دیتایی که میخوای export میکنی. و میگی دیتا رو کجا بفرسته.(یک وقتام برعکسه, سرور داره دیتا رو میگیره). قسمت دوم میشه اینترنال اون استک. مثلا دیتایی که فرستاده میشه تو چه دیتابیسی ذخیره میشه؟ چطوری پردازش میشه؟ چی به شما نمایش داده میشه؟من بهش میگم داشبورد.
خوده opentelemetry داشبورد خاصی نداره. صرفا یک سری exporter تو زبون های مختلف داره که میتونید تو گیتهابش ببینید. مثلا برای fastapi و جنگو لایبری داره. ولی پیاده سازی و داشبوردی نداره برای نشون دادن این اطلاعات. چون همونطور که گفتم در نهایت فقط یک پروتکل و specification هست. از طرفی سولوشن های داشبورد زیاده.یک سرچ کنید میرسید بهش. مثلا من خودم signoz استفاده میکنم.
خب همه اینارو گفتم. حالا نقش logfire این وسط چیه؟ logfire همون لایبری های اکسپورتر opentelemetry رو اینترفیسشو بهتر کرده. و با pydantic هم اینتگریتشون کرده. و یکم utilty اضافه کرده. این قسمت exporter اش هست که اوپن سورسه.
یک قسمت داشبورد هم داره که هنوز اوپن سورس نشده. و مشخص نیست که بشه یا نه. ولی فعلا رایگانه.
اینجا قشنگ صفر تا صد توضیح داده. بعد توضیح های من حالا خیلی بهتر متوجه میشین.
@PyBackendHub
اول بذارین توضیح بدم observation یعنی چی. ما توی devops دو آپریشن داریم که شبیه همن و گاها باهم اشتباه گرفته میشن. اولیش مانتورینگه. مانیتورینگ به پروسه ای میگن که دیتا کالکت میشه از سرویسی, و یک ریپورت از سلامت سرویس بر اساس metric های مشخصی که برای سلامت سیستم رو نشون میدن و کالکت شدن ساخته میشه. یعنی چی؟ مثلا تعداد ریسپانس های 5xx در ۲۴ ساعت گذشته. یکی از شناخته شده ترین ابزار برای اینکار prometheus هست. observability به پروسه ای میگن که رویکرد تحقیقاتی داره. یعنی دنبال این نیست که بگه چقدر ریسپانس 5xx وجود داره. دنبال دلیل وجود این ریسپانس هاست. چرا الان این درخواست تو پروداکشن ارور ۵۰۰ میده؟ خوندن کل لاگ سرویس قدیمی ترین و ابتدایی ترین راهکار بود.
وقتی بک اند پیچیده تر شد, دیگه خوندن لاگ واقعا کارساز نبود. شما فکر کنید در لحظه ۱۰۰ درخواست داره میاد براتون. چطور میخواین لاگ هارو بخونید؟ تو قدم بعدی لاگ های هر درخواست رو جدا کردن. ولی بازم کار ساز نبود تو دنیای distributed system. چون مثلا یک سرویس ۱ با سرویس ۲ داشت حرف میزد. ورودی که میداد بهش درست نبود. سرویس ۱ صرفا یک exception میگرفت که سرویس ۲ استتوس ۵۰۰ داده. و این کافی نبود برای اینکه متوجه شیم چه اتفاقی میفته.
سولوشن های زیادی اومدن تو مارکت. از قبیل sentry که شاید اسمشو شنیده باشین. یا datadog و لوکی و ... . اینقدر این سولوشن ها زیاد شدن و هر کدوم ساز خودشون رو میزدن. نمیشد راحت از این سولوشن سوییچ کرد به اون یکی. نمیشد مزایا دو سولوشن رو همزمان داشت. و learning curve سختی داشت اگه میخواستین سوییچ کنید از یکی به یکی دیگه.
اینجا بود که CNCF (Cloud native compute foundation) یک پروژه جدید رو استارت زد. همون فاندیشنی که کوبر و prometheus و خیلی ابزار های تحت کلاد رو ساخته. اومد یک پروتکلی ساخت به اسم opentelemetry.
یعنی چی پروتکل؟ یعنی گفت sentry جان من برام مهم نیست شما لاگ رو چطور ذخیره میکنی یا پردازش میکنی اینترنالی. شما باید span داشته باشی. metric داشته باشی. و trace. و دقیقا تعریف کرد که اینا چین. یعنی اومد گفت اینترفیس خارجی یک سیستم observability چطور باید باشه؟ چون در نهایت همه این سیستما شبیه هم بودن. و حالا چون همشون داشتن از یک پروتکل خاصی پیروی میکردن شما میتونستی راحت از سولوشن یک سوییچ کنی به سولوشن دو. مثلا شاید مثالشو دیده باشین که تو سیستم فایل استوریج بعضی استوریجا s3 compatible هستن. اینم دقیقا شبیه همونه.
استک observation به دو قسمت تقسیم میشه. یکی میشه exporter و یکی میشه داشبورد. exporter معمولا یک لایبریه که شما نصب میکنی. و باهاش اون دیتایی که میخوای export میکنی. و میگی دیتا رو کجا بفرسته.(یک وقتام برعکسه, سرور داره دیتا رو میگیره). قسمت دوم میشه اینترنال اون استک. مثلا دیتایی که فرستاده میشه تو چه دیتابیسی ذخیره میشه؟ چطوری پردازش میشه؟ چی به شما نمایش داده میشه؟من بهش میگم داشبورد.
خوده opentelemetry داشبورد خاصی نداره. صرفا یک سری exporter تو زبون های مختلف داره که میتونید تو گیتهابش ببینید. مثلا برای fastapi و جنگو لایبری داره. ولی پیاده سازی و داشبوردی نداره برای نشون دادن این اطلاعات. چون همونطور که گفتم در نهایت فقط یک پروتکل و specification هست. از طرفی سولوشن های داشبورد زیاده.یک سرچ کنید میرسید بهش. مثلا من خودم signoz استفاده میکنم.
خب همه اینارو گفتم. حالا نقش logfire این وسط چیه؟ logfire همون لایبری های اکسپورتر opentelemetry رو اینترفیسشو بهتر کرده. و با pydantic هم اینتگریتشون کرده. و یکم utilty اضافه کرده. این قسمت exporter اش هست که اوپن سورسه.
یک قسمت داشبورد هم داره که هنوز اوپن سورس نشده. و مشخص نیست که بشه یا نه. ولی فعلا رایگانه.
اینجا قشنگ صفر تا صد توضیح داده. بعد توضیح های من حالا خیلی بهتر متوجه میشین.
@PyBackendHub
Forwarded from CodeCrafters (Mojtaba)
رویه ذخیره شده Stored Procedure ناجی برنامه های تحت فشار:
در دنیای برنامه‌نویسی(منظور ما سمت Back-End است Front-End 🥸)، بهینه‌سازی و عملکرد روان برنامه‌ها از اهمیت بالایی برخوردار است. در این میان، پایگاه‌های داده نقش حیاتی در ذخیره‌سازی و بازیابی اطلاعات ایفا میکنند.
رویه ذخیره‌شده یا Stored Procedure چیست ؟
به صورت خلاصه Stored Procedure یک مجموعه از دستورات SQL است که کار خاصی را انجام میدهد و ما برای آن یک نام مرتبط میگذاریم و در هر جایی که نیاز داشته باشیم آن را فراخوانی میکنیم (اگر پارامتر خاصی نیاز داشته باشد هم میتوانیم به آن پاس بدهیم )
به صورت معمول برنامه نویس ها از ORM هایی مخصوص زبان برنامه نویسی که با آن کار میکنند برای ایجاد کوئری بر روی دیتابیس استفاده میکنند ولی ORM (منظورم هر ORM است حتی اگر معجزه برنامه نویسی قرن باشد!!!) چندین ایراد مهم و اساسی دارند که در ادامه به آن ها اشاره میشود:
۱. شما باید هزینه تبدیل کد هایتان را به SQL پرداخت کنید(با کاهش قدرت برنامه) در نهایت پایگاه داده شما با SQL کار میکند نه زبان برنامه نویسی شما !!!
۲.وقتی از ORM ها استفاده میکنید اگر نیاز به کوئری پیچیده و یا خیلی خاصی داشته باشید قدرت زیادی برای مدیریت این چالش با استفاده از ORM نخواهید داشت.
۳. معمولا برای فراخوانی یک مقدار از پایگاه داده به چندین روش مختلف میتوان این کار را انجام داد که یه سری از این روش ها دارای پرفومنس خوب و بعضی از روش ها دارای پرفومنس وحشتناک هستند (این مورد مربوط به افزایش پرفومنس در SQL است که توضیح طولانی دارد که در اینجا جای نمیگیرد ولی برای آشنایی بیشتر ساده ترین مورد را اشاره میکنم :
تصور کنید جدولی به نام کارکنان و با ۱۵ ردیف داریم و میخواهید مقدار نام از جدول کارکنان خود را بخوانید با استفاده از ORM خود در نهایت به این کوئری خواهید رسید :
در حالی که شما فقط به نام کارکنان در این جدول نیاز دارید و این جدول دارای ۱۵ ردیف است که فراخوانی ۱۴ ردیف دیگر بیهوده و هزینه برخواهد بود
و این کوئری نیاز شما را برطرف میکرد :
که دارای پرفومنس بهتری خواهد بود
{شاید بتوانید جلوی استفاده از * بگیرید و ORM را مجبور به فرخوانی تنها name کنید ولی در موارد دیگر همچنین ساده هم نخواهد بود }
) وقتی از ORM خود استفاده میکنید شما کنترل زیادی برای اینکه از چه روشی استفاده کند نخواهید داشت و صرفا کد های ORM خود را خواهید دید
۴. گاها پیش میآید که شما برای فراخوانی مقدار در پایگاه داده با استفاده از ORM کوئری میسازید ولی ORM کوئری عجیبی تولید میکند که فشار فوق العاده ای بر روی برنامه شما وارد میکند.(برای جلوگیری این مورد اگر اصرار به استفاده از ORM دارید باید به موارد پیشرفته ORM خود مراجعه کنید که نیاز به تمرین و زمان است)
از معایب استفاده از Stored Procedure میتوان به این موارد اشاره کرد:
۱. نیاز به دانش خوبی از SQL دارد
۲. در صورت تغییر پایگاه داده نیاز به بازنویسی خواهند داشت
۳.نوشتن برنامه با سرعت خیلی پایین تری پیش خواهد رفت.
مقایسه Stored Procedure با ORM:
در واقع ORMها (Object-Relational Mapping) ابزاری برای نگاشت اشیاء برنامه به ساختارهای پایگاه داده هستند. ORMها به طور خودکار وظایف مربوط به ترجمه کوئری‌ها از زبان برنامه‌نویسی به زبان SQL را انجام می‌دهند.
در حالی که ORMها مزایایی از جمله سادگی و سهولت استفاده را ارائه می‌دهند، اما در مقایسه با Stored Procedureها، معایبی نیز دارند. ORMها می‌توانند به دلیل ترجمه‌های اضافی، باعث افت عملکرد شوند. همچنین، ORMها در مدیریت کوئری‌های پیچیده و خاص، انعطاف‌پذیری Stored Procedureها را ندارند.
در نتیجه :اگر برنامه شما دارای فشار زیادی بر روی پایگاه داده است و همین طور برنامه شما دارای بار زیادی است میتوانید برای مدیریت آن از Stored Procedure ها در پایگاه داده تان استفاده کنید
یا اینکه میتوانید استفاده نکنید و به زیبایی کد های خود با استفاده از ORM به خود افتخار کنید و بگذارید پایگاه داده تحت فشار کد های SQL عجیب شما تبدیل به نفت شود
این مورد کاملا بستگی به برنامه و نیاز شما بستگی دارد.
#Database #General
@Code_Crafters
در دنیای برنامه‌نویسی(منظور ما سمت Back-End است Front-End 🥸)، بهینه‌سازی و عملکرد روان برنامه‌ها از اهمیت بالایی برخوردار است. در این میان، پایگاه‌های داده نقش حیاتی در ذخیره‌سازی و بازیابی اطلاعات ایفا میکنند.
رویه ذخیره‌شده یا Stored Procedure چیست ؟
به صورت خلاصه Stored Procedure یک مجموعه از دستورات SQL است که کار خاصی را انجام میدهد و ما برای آن یک نام مرتبط میگذاریم و در هر جایی که نیاز داشته باشیم آن را فراخوانی میکنیم (اگر پارامتر خاصی نیاز داشته باشد هم میتوانیم به آن پاس بدهیم )
به صورت معمول برنامه نویس ها از ORM هایی مخصوص زبان برنامه نویسی که با آن کار میکنند برای ایجاد کوئری بر روی دیتابیس استفاده میکنند ولی ORM (منظورم هر ORM است حتی اگر معجزه برنامه نویسی قرن باشد!!!) چندین ایراد مهم و اساسی دارند که در ادامه به آن ها اشاره میشود:
۱. شما باید هزینه تبدیل کد هایتان را به SQL پرداخت کنید(با کاهش قدرت برنامه) در نهایت پایگاه داده شما با SQL کار میکند نه زبان برنامه نویسی شما !!!
۲.وقتی از ORM ها استفاده میکنید اگر نیاز به کوئری پیچیده و یا خیلی خاصی داشته باشید قدرت زیادی برای مدیریت این چالش با استفاده از ORM نخواهید داشت.
۳. معمولا برای فراخوانی یک مقدار از پایگاه داده به چندین روش مختلف میتوان این کار را انجام داد که یه سری از این روش ها دارای پرفومنس خوب و بعضی از روش ها دارای پرفومنس وحشتناک هستند (این مورد مربوط به افزایش پرفومنس در SQL است که توضیح طولانی دارد که در اینجا جای نمیگیرد ولی برای آشنایی بیشتر ساده ترین مورد را اشاره میکنم :
تصور کنید جدولی به نام کارکنان و با ۱۵ ردیف داریم و میخواهید مقدار نام از جدول کارکنان خود را بخوانید با استفاده از ORM خود در نهایت به این کوئری خواهید رسید :
select * from employee;
در حالی که شما فقط به نام کارکنان در این جدول نیاز دارید و این جدول دارای ۱۵ ردیف است که فراخوانی ۱۴ ردیف دیگر بیهوده و هزینه برخواهد بود
و این کوئری نیاز شما را برطرف میکرد :
select name from employee;
که دارای پرفومنس بهتری خواهد بود
{شاید بتوانید جلوی استفاده از * بگیرید و ORM را مجبور به فرخوانی تنها name کنید ولی در موارد دیگر همچنین ساده هم نخواهد بود }
) وقتی از ORM خود استفاده میکنید شما کنترل زیادی برای اینکه از چه روشی استفاده کند نخواهید داشت و صرفا کد های ORM خود را خواهید دید
۴. گاها پیش میآید که شما برای فراخوانی مقدار در پایگاه داده با استفاده از ORM کوئری میسازید ولی ORM کوئری عجیبی تولید میکند که فشار فوق العاده ای بر روی برنامه شما وارد میکند.(برای جلوگیری این مورد اگر اصرار به استفاده از ORM دارید باید به موارد پیشرفته ORM خود مراجعه کنید که نیاز به تمرین و زمان است)
از معایب استفاده از Stored Procedure میتوان به این موارد اشاره کرد:
۱. نیاز به دانش خوبی از SQL دارد
۲. در صورت تغییر پایگاه داده نیاز به بازنویسی خواهند داشت
۳.نوشتن برنامه با سرعت خیلی پایین تری پیش خواهد رفت.
مقایسه Stored Procedure با ORM:
در واقع ORMها (Object-Relational Mapping) ابزاری برای نگاشت اشیاء برنامه به ساختارهای پایگاه داده هستند. ORMها به طور خودکار وظایف مربوط به ترجمه کوئری‌ها از زبان برنامه‌نویسی به زبان SQL را انجام می‌دهند.
در حالی که ORMها مزایایی از جمله سادگی و سهولت استفاده را ارائه می‌دهند، اما در مقایسه با Stored Procedureها، معایبی نیز دارند. ORMها می‌توانند به دلیل ترجمه‌های اضافی، باعث افت عملکرد شوند. همچنین، ORMها در مدیریت کوئری‌های پیچیده و خاص، انعطاف‌پذیری Stored Procedureها را ندارند.
در نتیجه :اگر برنامه شما دارای فشار زیادی بر روی پایگاه داده است و همین طور برنامه شما دارای بار زیادی است میتوانید برای مدیریت آن از Stored Procedure ها در پایگاه داده تان استفاده کنید
یا اینکه میتوانید استفاده نکنید و به زیبایی کد های خود با استفاده از ORM به خود افتخار کنید و بگذارید پایگاه داده تحت فشار کد های SQL عجیب شما تبدیل به نفت شود
این مورد کاملا بستگی به برنامه و نیاز شما بستگی دارد.
#Database #General
@Code_Crafters
به دنبال ساختار باشید و نه چارچوب
چند روز پیش یه مربی کودک یه حرف خیلی مهمی زد با این مفهوم: «ما اینجا برای بچه ها ساختار تعیین می کنیم نه چارچوب، چارچوب یعنی حد و مرز!»
این جمله رو باید قاب کرد و زد رو دیوار، احتمالا در ابعاد خیلی زیادی از زندگی مهم باشه. در مهندسی نرم افزار و توسعه محصول هم خیلی حرف مهمیه.
بیشتر اوقات ما دنبال چارچوب هستیم در مهندسی نرم افزار، به همین دلیل وقتی خودمون رو به یه چارچوب خاص محدود می کنیم با چالش های زیادی روبرو میشیم. در حالیکه بهتره ما برای توسعه محصول ساختار داشته باشیم و طبق اصول ساختاری کار رو پیش ببریم، اینطوری چالش مون کمتر میشه.
اجازه بدید برداشت خودم از چارچوب و ساختار رو کمی بیشتر باز کنم. ساختار میشه مجموعه از قواعد رفتاری که باید سعی کنیم در توسعه محصول بهشون پایبند باشیم، در مقابل، چارچوب میشه تعیین کردن یه سری حد و مرز مشخص به شیوه ای سختگیرانه.
مثلا اگه بخوام برای توسعه یک سرویس ساختار تعیین کنم احتمالا میگم: این سرویس باید توان پاسخگویی بالایی داشته باشه، در مقابل خطا مقاوم باشه، قابلیت مقیاس پذیری داشته باشه، یک قرارداد ساده و شفاف به کلاینت ها ارائه بده و مواردی از این دست.
اما اگه بخوام چارچوب برای سرویس تعیین کنم احتمالا میگم: ما باید از ساختار کد مبتنی بر clean code یا ddd در فلان repository که خودمون یا دیگران اونو نوشتن پیروی کنیم، باید همه ورودی هارو تو پوشه port قرار بدیم، باید همه مدل هامون تو پوشه models باشه، باید از فلان روش ci/cd استفاده کنیم.
در توسعه محصول تعیین کردن حد و مرز و چارچوب میتونه خوب باشه، اما بشرطی که تعیین این حد و مرز تنها زمان پیاده سازی سرویس باشه و متعهد بشیم که کورکورانه و سختگیرانه نخوایم این چارچوب رو به همه سرویس ها و محصولات تحمیل کنیم.
خیلی از practiceهایی که معروف شدند مثل clean code و ddd و tdd و غیره هم از نظر من بیشتر به دنبال این هستند که به شما کمک کنند که برای کارتون ساختار تعیین کنید. در حالیکه اشتباهی که زیاد رخ میده اینه که ما با خوندن این مطالب احتمالا بیشتر به سمت درآوردن چارچوب میریم... همه ش به دنبال این هستیم که مثلا یه boilerplate داشته باشیم که از clean code پیروی کنه و همون رو همه جا استفاده کنیم.
من گاها به دوستان متذکر میشم که خوندن این الگوها و منابع خیلی خوبه، به شرطی که شما سعی کنی جان کلام و دغدغه اصلی رو متوجه بشی، نه اینکه سعی کنی به دنبال یک راه حل فست فودی و چارچوب مشخص و معین باشی که کورکورانه همه جا ازش استفاده کنی.
شما وقتی برای کارت ساختار داشته باشی میتونی انعطاف پذیر باشی و بسته به نیازت چارچوب تعیین کنی، اما اگه بخوای یه چارچوب معین رو همه جا رعایت کنی احتمالا یه جاهایی اصول ساختاری خودت رو مجبور میشی زیر پا بذاری چون هیچ چارچوب واحدی وجود نداره که برای همه نیازها مناسب باشه.
چند روز پیش یه مربی کودک یه حرف خیلی مهمی زد با این مفهوم: «ما اینجا برای بچه ها ساختار تعیین می کنیم نه چارچوب، چارچوب یعنی حد و مرز!»
این جمله رو باید قاب کرد و زد رو دیوار، احتمالا در ابعاد خیلی زیادی از زندگی مهم باشه. در مهندسی نرم افزار و توسعه محصول هم خیلی حرف مهمیه.
بیشتر اوقات ما دنبال چارچوب هستیم در مهندسی نرم افزار، به همین دلیل وقتی خودمون رو به یه چارچوب خاص محدود می کنیم با چالش های زیادی روبرو میشیم. در حالیکه بهتره ما برای توسعه محصول ساختار داشته باشیم و طبق اصول ساختاری کار رو پیش ببریم، اینطوری چالش مون کمتر میشه.
اجازه بدید برداشت خودم از چارچوب و ساختار رو کمی بیشتر باز کنم. ساختار میشه مجموعه از قواعد رفتاری که باید سعی کنیم در توسعه محصول بهشون پایبند باشیم، در مقابل، چارچوب میشه تعیین کردن یه سری حد و مرز مشخص به شیوه ای سختگیرانه.
مثلا اگه بخوام برای توسعه یک سرویس ساختار تعیین کنم احتمالا میگم: این سرویس باید توان پاسخگویی بالایی داشته باشه، در مقابل خطا مقاوم باشه، قابلیت مقیاس پذیری داشته باشه، یک قرارداد ساده و شفاف به کلاینت ها ارائه بده و مواردی از این دست.
اما اگه بخوام چارچوب برای سرویس تعیین کنم احتمالا میگم: ما باید از ساختار کد مبتنی بر clean code یا ddd در فلان repository که خودمون یا دیگران اونو نوشتن پیروی کنیم، باید همه ورودی هارو تو پوشه port قرار بدیم، باید همه مدل هامون تو پوشه models باشه، باید از فلان روش ci/cd استفاده کنیم.
در توسعه محصول تعیین کردن حد و مرز و چارچوب میتونه خوب باشه، اما بشرطی که تعیین این حد و مرز تنها زمان پیاده سازی سرویس باشه و متعهد بشیم که کورکورانه و سختگیرانه نخوایم این چارچوب رو به همه سرویس ها و محصولات تحمیل کنیم.
خیلی از practiceهایی که معروف شدند مثل clean code و ddd و tdd و غیره هم از نظر من بیشتر به دنبال این هستند که به شما کمک کنند که برای کارتون ساختار تعیین کنید. در حالیکه اشتباهی که زیاد رخ میده اینه که ما با خوندن این مطالب احتمالا بیشتر به سمت درآوردن چارچوب میریم... همه ش به دنبال این هستیم که مثلا یه boilerplate داشته باشیم که از clean code پیروی کنه و همون رو همه جا استفاده کنیم.
من گاها به دوستان متذکر میشم که خوندن این الگوها و منابع خیلی خوبه، به شرطی که شما سعی کنی جان کلام و دغدغه اصلی رو متوجه بشی، نه اینکه سعی کنی به دنبال یک راه حل فست فودی و چارچوب مشخص و معین باشی که کورکورانه همه جا ازش استفاده کنی.
شما وقتی برای کارت ساختار داشته باشی میتونی انعطاف پذیر باشی و بسته به نیازت چارچوب تعیین کنی، اما اگه بخوای یه چارچوب معین رو همه جا رعایت کنی احتمالا یه جاهایی اصول ساختاری خودت رو مجبور میشی زیر پا بذاری چون هیچ چارچوب واحدی وجود نداره که برای همه نیازها مناسب باشه.
12 نکته مهم در مورد «علم داده» که در هیچ دوره‌ای به شما یاد نمی دهند!
مشاغل زیادی در زمینه علم داده وجود دارد، (تحلیلگر داده، مهندس یادگیری ماشین، دانشمند داده و...) اما متقاضیان زیادی نیز وجود دارند و فرآیند مصاحبه و استخدام در مشاغل علوم داده یک بازی با اطلاعات نامتقارن عظیم است. صبور باشید، فرصت‌ها پیش خواهند آمد، اما بیشتر از آن چه که فکر می کنید گاهی طول می‌کشد.
اگر کنجکاو و عاشق یادگیری هستید، باید بدانید که هرگز هر چیزی را که دوست دارید در مورد Data Science بدانید، نخواهید دانست. علم داده یک زمینه بسیار گسترده است و زمان و دانش شما هم اندک. پس از این که همه چیز را نمی‌دانید ناامید نشوید.
هر دانشمند داده داستان خود را دارد، پس خود را با دیگران مقایسه نکنید. اگر همکار شما در مورد سری‌های زمانی - یا هر موضوع دیگری، بیشتر از شما می‌داند، نیاز نیست خود را با او مقایسه کنید. زیرا او همیشه با این ابزار کار کرده است، مطالعاتش در این زمینه بوده و تجربه بیشتری دارد. پس اگر دقیق‌تر نگاه کنید، می‌بینید که در موضوعات دیگر از او بهتر هستید (شاید برنامه‌نویس بهتری باشید یا دانش آماری و ریاضیات بیشتری داشته باشید).
درباره محصول/ محصولات کسب و کاری که فرآیند آنالیز داده را برای آن انجام می‌دهید، اطلاعات کسب کنید. هیچ مدیر سطح A واقعاً به الگوریتم‌ها، مقادیر p، دقت، AUC یا امتیاز f1 اهمیت نمی‌دهد. آنها می خواهند بدانند که کدام مشکل در حال حل شدن است و درآمد (یا پس اندازی) که از انجام پروژه شرکت توسط شما بدست می‌آورند چقدر است. پس بهترین مدل، مدلی است که مشکل پروژه را حل کند؛ مدیران این را می‌خواهند.
مدل های یادگیری ماشین تنها بخش بسیار کوچکی از وظایف روزانه یک دانشمند داده را شامل می‌شوند. شما بیشتر زمان خود را در پروژه‌هایتان صرف پاکسازی داده‌ها و جمع آوری اطلاعات میکنید.
برخی از تکنیک‌های علوم داده در آموزش‌های تئوری و دوره‌هایی که می‌گذرانید به خوبی کار می کنند، اما در داده‌های دنیایِ واقعی تقریباً بی فایده هستند. من دوست دارم از SMOTE به عنوان مثال استفاده کنم. در Medium، این تکنیک بی عیب و نقص به نظر می‌رسد، در حالی که در دنیای واقعی ممکن است کاملاً ناکار آمد باشد (البته نه به طور کامل).
احتمالاً برخی از مفاهیم مثل نشت داده‌ها و اعتبار سنجی را در طول تحصیل یاد نگرفته‌اید. این به این معنی است که شما تنها زمانی که برخی از مدل‌ها در حال تولید هستند، از کار افتادن آنها را تجربه خواهید کرد. یعنی کاربرد بعضی از مفاهیم علوم داده را تنها در زمان کار بر روی پروژه یاد خواهید گرفت. پس مطمئن شوید که برای جلوگیری از یک حادثه بزرگ، برای نظارت بر مدل‌های خود زمان صرف میکنید و یادگیری را ادامه می‌دهید!
همه شرکت‌ها دوست دارند بگویند که داده‌محور هستند، اما تعداد بسیار کمی از آنها واقعاً از این فرهنگ استقبال میکنند. بدتر از آن، این است که شما همیشه رهبران را در کنار خود در این مبارزه نخواهید داشت!!!
تفاوت بین استنتاج و پیش بینی را بدانید. یک الگوریتم ممکن است بسته به موقعیت، مفروضات و خطرات متفاوتی داشته باشد.
ابزارهای Tensorflow، Pycaret، Catboost و دیگر کتابخانه‌ها ذهن شما را متحیر خواهند کرد. می‌دانم، من هم از آنها استفاده کرده‌ام. اما هرگز قدرت Numpy، Pandas و Scikit-Learn را دست کم نگیرید. با استفاده از این سه کتابخانه، راه حل‌های باورنکردنی خواهید ساخت.
افتضاح است که ساعت ها (یا حتی روزها) را برای مطالعه صرف کنید و بعداً متوجه شوید که در مورد داده‌ها سوء تفاهم وجود دارد یا اشتباهی وجود دارد که متوجه نشده اید. این تجربه وحشتناک است، اما برای همه اتفاق می افتد. خودتان را سرزنش نکنید و صبوری خود را در مواجهه با همکارانتان از دست ندهید. آن‌چه را که باید یاد بگیرید، بیاموزید و همیشه به جلو حرکت کنید!
همیشه شرکت‌ها به هر کسی که موفق می‌شد نوعی از pd.merge() یا هر چیزی را با پایتون اجرا کند، هزینه زیادی پرداخت می‌کردند. اما الان این فاکتور تغییر کرده است. علم داده در حال تکامل است و امروزه تقاضاها بیشتر شده است. فضای ابری، دانش مهندسی داده، اینترنت اشیا، علیت و مهارت های دیگر برخی از پیش نیازهایی هستند که ممکن است امروزه در موقعیت های شغلی جدید با آنها روبرو شوید.
مشاغل زیادی در زمینه علم داده وجود دارد، (تحلیلگر داده، مهندس یادگیری ماشین، دانشمند داده و...) اما متقاضیان زیادی نیز وجود دارند و فرآیند مصاحبه و استخدام در مشاغل علوم داده یک بازی با اطلاعات نامتقارن عظیم است. صبور باشید، فرصت‌ها پیش خواهند آمد، اما بیشتر از آن چه که فکر می کنید گاهی طول می‌کشد.
اگر کنجکاو و عاشق یادگیری هستید، باید بدانید که هرگز هر چیزی را که دوست دارید در مورد Data Science بدانید، نخواهید دانست. علم داده یک زمینه بسیار گسترده است و زمان و دانش شما هم اندک. پس از این که همه چیز را نمی‌دانید ناامید نشوید.
هر دانشمند داده داستان خود را دارد، پس خود را با دیگران مقایسه نکنید. اگر همکار شما در مورد سری‌های زمانی - یا هر موضوع دیگری، بیشتر از شما می‌داند، نیاز نیست خود را با او مقایسه کنید. زیرا او همیشه با این ابزار کار کرده است، مطالعاتش در این زمینه بوده و تجربه بیشتری دارد. پس اگر دقیق‌تر نگاه کنید، می‌بینید که در موضوعات دیگر از او بهتر هستید (شاید برنامه‌نویس بهتری باشید یا دانش آماری و ریاضیات بیشتری داشته باشید).
درباره محصول/ محصولات کسب و کاری که فرآیند آنالیز داده را برای آن انجام می‌دهید، اطلاعات کسب کنید. هیچ مدیر سطح A واقعاً به الگوریتم‌ها، مقادیر p، دقت، AUC یا امتیاز f1 اهمیت نمی‌دهد. آنها می خواهند بدانند که کدام مشکل در حال حل شدن است و درآمد (یا پس اندازی) که از انجام پروژه شرکت توسط شما بدست می‌آورند چقدر است. پس بهترین مدل، مدلی است که مشکل پروژه را حل کند؛ مدیران این را می‌خواهند.
مدل های یادگیری ماشین تنها بخش بسیار کوچکی از وظایف روزانه یک دانشمند داده را شامل می‌شوند. شما بیشتر زمان خود را در پروژه‌هایتان صرف پاکسازی داده‌ها و جمع آوری اطلاعات میکنید.
برخی از تکنیک‌های علوم داده در آموزش‌های تئوری و دوره‌هایی که می‌گذرانید به خوبی کار می کنند، اما در داده‌های دنیایِ واقعی تقریباً بی فایده هستند. من دوست دارم از SMOTE به عنوان مثال استفاده کنم. در Medium، این تکنیک بی عیب و نقص به نظر می‌رسد، در حالی که در دنیای واقعی ممکن است کاملاً ناکار آمد باشد (البته نه به طور کامل).
احتمالاً برخی از مفاهیم مثل نشت داده‌ها و اعتبار سنجی را در طول تحصیل یاد نگرفته‌اید. این به این معنی است که شما تنها زمانی که برخی از مدل‌ها در حال تولید هستند، از کار افتادن آنها را تجربه خواهید کرد. یعنی کاربرد بعضی از مفاهیم علوم داده را تنها در زمان کار بر روی پروژه یاد خواهید گرفت. پس مطمئن شوید که برای جلوگیری از یک حادثه بزرگ، برای نظارت بر مدل‌های خود زمان صرف میکنید و یادگیری را ادامه می‌دهید!
همه شرکت‌ها دوست دارند بگویند که داده‌محور هستند، اما تعداد بسیار کمی از آنها واقعاً از این فرهنگ استقبال میکنند. بدتر از آن، این است که شما همیشه رهبران را در کنار خود در این مبارزه نخواهید داشت!!!
تفاوت بین استنتاج و پیش بینی را بدانید. یک الگوریتم ممکن است بسته به موقعیت، مفروضات و خطرات متفاوتی داشته باشد.
ابزارهای Tensorflow، Pycaret، Catboost و دیگر کتابخانه‌ها ذهن شما را متحیر خواهند کرد. می‌دانم، من هم از آنها استفاده کرده‌ام. اما هرگز قدرت Numpy، Pandas و Scikit-Learn را دست کم نگیرید. با استفاده از این سه کتابخانه، راه حل‌های باورنکردنی خواهید ساخت.
افتضاح است که ساعت ها (یا حتی روزها) را برای مطالعه صرف کنید و بعداً متوجه شوید که در مورد داده‌ها سوء تفاهم وجود دارد یا اشتباهی وجود دارد که متوجه نشده اید. این تجربه وحشتناک است، اما برای همه اتفاق می افتد. خودتان را سرزنش نکنید و صبوری خود را در مواجهه با همکارانتان از دست ندهید. آن‌چه را که باید یاد بگیرید، بیاموزید و همیشه به جلو حرکت کنید!
همیشه شرکت‌ها به هر کسی که موفق می‌شد نوعی از pd.merge() یا هر چیزی را با پایتون اجرا کند، هزینه زیادی پرداخت می‌کردند. اما الان این فاکتور تغییر کرده است. علم داده در حال تکامل است و امروزه تقاضاها بیشتر شده است. فضای ابری، دانش مهندسی داده، اینترنت اشیا، علیت و مهارت های دیگر برخی از پیش نیازهایی هستند که ممکن است امروزه در موقعیت های شغلی جدید با آنها روبرو شوید.
50 OOPs Interview questions.pdf
299.7 KB
۵۰ سوال در خصوص شی گرایی برای آمادگی در مصاحبه
سوالات مصاحبه زبان پایتون
سوالات مصاحبه زبان پایتون
✅ هر وقت صحبت از شیء گرایی و ارث بری میشه پای Mixin هم میاد وسط. اما دقیقا چیه؟ Mixin توی پایتون یک الگو هستش و کدهایی که از این الگو بهره می‌برند کلمه‌ی کلیدی خاصی یا چیز اضافه‌تری ندارند. فرض کنین ما میخواهیم یک متد جدید به یک کلاس اضافه کنیم تا
مثلا کلاس‌های زیر رو در نظر بگیرید.
حالا نیاز داریم که متد play music رو هم به این کلاس ها اضافه کنیم، دوتا راه داریم. اولیش اینه که:
اما یک ایرادی وجود داره. اینجا خودمون رو تکرار کردیم. درواقع اومدیم دوبار یک تکه کد رو تکرار کردیم و این از نظر کدینگ وجه خوبی نداره. پس این راه حل ما نیست.
روش دوم اینه بیایم به بیس کلاسمون یعنی Vehicle یک متد تحت عنوان play_music اضافه کنیم.
اما در این صورت کلاس موتورسیکلت هم دارای رفتار پخش موزیک خواهد شد و این اشتباه است. اینجا است که Mixin خودش رو نشون میده. به کد زیر توجه کنید.
درواقع از کلاس PlayMusicMixin قرار نیست هیچ شیٔ ای ساخته شود و صرفا مهم این است که کارایی کلاس‌های خاصی را افزایش شود.
پ.ن: اون کلمه‌ی Mixin انتهای اسم کلاس هم قراردادیه، بهتره نوشته بشه ولی اجبار نداره.
کارایی یا Functionality اون رو زیاد کنیم. اینجا میشه از Mixin استفاده کرد.مثلا کلاس‌های زیر رو در نظر بگیرید.
class Vehicle:
pass
class Car(Vehicle):
pass
class Van(Vehicle):
pass
class Motorcycle(Vehicle):
pass
حالا نیاز داریم که متد play music رو هم به این کلاس ها اضافه کنیم، دوتا راه داریم. اولیش اینه که:
class Vehicle:
pass
class Car(Vehicle):
def play_music(self):
print("play_music")
class Van(Vehicle):
def play_music(self):
print("play_music")
class Motorcycle(Vehicle):
pass
اما یک ایرادی وجود داره. اینجا خودمون رو تکرار کردیم. درواقع اومدیم دوبار یک تکه کد رو تکرار کردیم و این از نظر کدینگ وجه خوبی نداره. پس این راه حل ما نیست.
روش دوم اینه بیایم به بیس کلاسمون یعنی Vehicle یک متد تحت عنوان play_music اضافه کنیم.
class Vehicle:
def play_music(self):
print("play_music")
class Car(Vehicle):
pass
class Van(Vehicle):
pass
class Motorcycle(Vehicle):
pass
اما در این صورت کلاس موتورسیکلت هم دارای رفتار پخش موزیک خواهد شد و این اشتباه است. اینجا است که Mixin خودش رو نشون میده. به کد زیر توجه کنید.
class Vehicle:
pass
class PlayMusicMixin:
def play_music(self):
print("play_music")
class Car(Vehicle, PlayMusicMixin):
pass
class Van(Vehicle, PlayMusicMixin):
pass
class Motorcycle(Vehicle):
pass
درواقع از کلاس PlayMusicMixin قرار نیست هیچ شیٔ ای ساخته شود و صرفا مهم این است که کارایی کلاس‌های خاصی را افزایش شود.
پ.ن: اون کلمه‌ی Mixin انتهای اسم کلاس هم قراردادیه، بهتره نوشته بشه ولی اجبار نداره.
تو خیلی زبونا ما تایپی داریم به نام Never از جمله پایتون. به چه دردی میخوره این تایپ؟
خیلی مفیده. و یکی از قشنگ ترین کاربردش exhaustive block هست. یعنی به شما اجازه اجازه میده که کدتون رو تو کیس های مختلف تو یک بلاک هندل کنید بدون اینکه چیزی رو جا بذارین. و اگه یک چیزی بعدا اضافه کردن که هندل نکرده بودین تایپ چکر ایراد بگیره ازتون و بتونید هندل کنید. مثلا فکر کنید شما User status دارین. و رفتار سیستم شما تغییر میکنه نسبه به وضعیت یوزر. و این رفتار تو تک تک بیزنس کیس ها وجود داره. یک راهش استفاده از دیزاین پترنه که به قول مارتین به نحوی کل لاجیکتون تو یک فایل باشه.و برای هر وضعیت هندلر داشته باشین. ولی یک راه خیلی آسونتر استفاده از تایپ Never هست. که خیلی قابل اعتماد تره و فضایی نمیذاره برای خطا کردن!
الان این کد fail میشه تو تایپ چک. چرا؟ چون user_status تو اون بلاک میتونه هر استتوسی جز Banned باشه. وقتی فیل نمیشه که شما همه کیس های ممکن رو هندل کرده باشین. دقیقا همین موضوع تو زبونای دیگه هم هست.
خلاصه که از IDE و تایپ چکر بیشتر بهره ببرین 😁 تو سال ۲۰۲۴ هستیم. و تایپینگ های زبونا اینقدر قوی شدن که بعضا turing complete هستن!
خیلی مفیده. و یکی از قشنگ ترین کاربردش exhaustive block هست. یعنی به شما اجازه اجازه میده که کدتون رو تو کیس های مختلف تو یک بلاک هندل کنید بدون اینکه چیزی رو جا بذارین. و اگه یک چیزی بعدا اضافه کردن که هندل نکرده بودین تایپ چکر ایراد بگیره ازتون و بتونید هندل کنید. مثلا فکر کنید شما User status دارین. و رفتار سیستم شما تغییر میکنه نسبه به وضعیت یوزر. و این رفتار تو تک تک بیزنس کیس ها وجود داره. یک راهش استفاده از دیزاین پترنه که به قول مارتین به نحوی کل لاجیکتون تو یک فایل باشه.و برای هر وضعیت هندلر داشته باشین. ولی یک راه خیلی آسونتر استفاده از تایپ Never هست. که خیلی قابل اعتماد تره و فضایی نمیذاره برای خطا کردن!
class UserStatus(StrEnum):
Verified = auto()
Unverified = auto()
Banned = auto()
# any other...
user_status: UserStatus
match user_status:
case UserStatus.Banned:
# handle here
...
case _:
assert_never(user_status)
الان این کد fail میشه تو تایپ چک. چرا؟ چون user_status تو اون بلاک میتونه هر استتوسی جز Banned باشه. وقتی فیل نمیشه که شما همه کیس های ممکن رو هندل کرده باشین. دقیقا همین موضوع تو زبونای دیگه هم هست.
enum UserStatus {
Verified,
Unverified,
Banned
}
const user_status: UserStatus
switch(user_status) {
case UserStatus.Banned:
// handle here...
default:
user_status satisfies never;
}
خلاصه که از IDE و تایپ چکر بیشتر بهره ببرین 😁 تو سال ۲۰۲۴ هستیم. و تایپینگ های زبونا اینقدر قوی شدن که بعضا turing complete هستن!
۳ تابع مهم پایتون
در این پست میخوام ۳ تابع از مهم ترین توابع پایتون که خیلی کاربردی هستند رو معرفی کنم.
1-Lambda:
لامبدا یک روش ساده برای تعریف تابع در پایتون است. این توابع غالباً به نام «عملگرهای لامبدا» یا «تابع‌های لامبدا» نامیده می‌شوند.
مثال:
lambda_cube = lambda x: x*x*x
print(tambda_cube(15))
# output: 3375
2-Map:
این تابع زمانی استفاده می شود که بخواهید برای هر آیتم در یک ساختار داده، تابعی را اجرا کنید.
مثال:
fruit = ['apple','grapes','orange','cherry','kiwi']
result = map(lambda x: x.title(), fruit)
for data in result:
prtnt(data, end=' ')
# Apple Grapes Orange Cherry Kiwi
3-Filter:
این تابع برای فیلتر کردن هر نوع داده ای بر اساس یک شرط معین در یک ساختار استفاده می شود.
مثال:
fruit = ['apple','grapes','orange','cherry','kiwi']
result = filter(lambda x: len(x)<5, fruit)
for data in result
print(data)
در این پست میخوام ۳ تابع از مهم ترین توابع پایتون که خیلی کاربردی هستند رو معرفی کنم.
1-Lambda:
لامبدا یک روش ساده برای تعریف تابع در پایتون است. این توابع غالباً به نام «عملگرهای لامبدا» یا «تابع‌های لامبدا» نامیده می‌شوند.
مثال:
lambda_cube = lambda x: x*x*x
print(tambda_cube(15))
# output: 3375
2-Map:
این تابع زمانی استفاده می شود که بخواهید برای هر آیتم در یک ساختار داده، تابعی را اجرا کنید.
مثال:
fruit = ['apple','grapes','orange','cherry','kiwi']
result = map(lambda x: x.title(), fruit)
for data in result:
prtnt(data, end=' ')
# Apple Grapes Orange Cherry Kiwi
3-Filter:
این تابع برای فیلتر کردن هر نوع داده ای بر اساس یک شرط معین در یک ساختار استفاده می شود.
مثال:
fruit = ['apple','grapes','orange','cherry','kiwi']
result = filter(lambda x: len(x)<5, fruit)
for data in result
print(data)
یک پستی دیدم تو لینکدین و یک چیزیه که حقیقتا خیلی مخالفشم. نظره شما چیه؟ مصاحبه کننده میاد از قبل یک سوالی آماده میکنه, و یک جوابی تو ذهنش داره. اگه شما دقیقا همون جواب تو ذهن مصاحبه کننده رو بدی قبولی. و اگه ندی قبول نیستی.
بنظرم این مدل مصاحبه بدترین مصاحبه هست. اصلا شبیه دنیای واقعی نیست. هدف مصاحبه این نیست که شما به جواب درست برسی. هدف اینه که یک نفر بیاد و بتونیم باهم یک مشکلی رو حل کنیم با هم فکری. سوالی که فقط ۱ جواب داره سوال خوبی نیست. تو دنیای واقعی یک سولوشن نداریم بلکه ترید آف داریم.
بنظرم این مدل مصاحبه بدترین مصاحبه هست. اصلا شبیه دنیای واقعی نیست. هدف مصاحبه این نیست که شما به جواب درست برسی. هدف اینه که یک نفر بیاد و بتونیم باهم یک مشکلی رو حل کنیم با هم فکری. سوالی که فقط ۱ جواب داره سوال خوبی نیست. تو دنیای واقعی یک سولوشن نداریم بلکه ترید آف داریم.
🧑💻PythonDev🧑💻
یک پستی دیدم تو لینکدین و یک چیزیه که حقیقتا خیلی مخالفشم. نظره شما چیه؟ مصاحبه کننده میاد از قبل یک سوالی آماده میکنه, و یک جوابی تو ذهنش داره. اگه شما دقیقا همون جواب تو ذهن مصاحبه کننده رو بدی قبولی. و اگه ندی قبول نیستی. بنظرم این مدل مصاحبه بدترین مصاحبه…
یک نکته بگم که احساس میکنم اکثرا که سوال اینطوری طرح میکنن به دنبال تقلید از شرکت های بزرگ و Faang هستن. من خودم حقیقتا به یک شرکت نسبتا بزرگ پارسال مصاحبه داشتم و تو مصاحبه سوال الگوریتمی رو به کند ترین روش ممکن حل کردم ولی پاس داده شدم مرحله بعد و فیدبکی که گرفتم این بود که مهم نیست اگه اینو به صورت آپتیمایز ترین حالت ممکن حل کنی. مهم ارتباط گرفتن موقع حل سواله و اینکه آگاه باشی از ترید آف.
تو کیس بالا خیلیا به روشی حل کرده بودن که حالت <ایده آل>از دیده مصاحبه کننده نبود و تقلب بود. ولی بنظره من اتفاقا خیلی با ارزش تره. وقتی من سولوشنی میدم که کلا out of box بوده و داره نیاز بیزنس من رو پوشش میده چرا که نه؟
تو کیس بالا خیلیا به روشی حل کرده بودن که حالت <ایده آل>از دیده مصاحبه کننده نبود و تقلب بود. ولی بنظره من اتفاقا خیلی با ارزش تره. وقتی من سولوشنی میدم که کلا out of box بوده و داره نیاز بیزنس من رو پوشش میده چرا که نه؟
Forwarded from Python BackendHub (Mani)
نسخه ۰.۱.۰ فریم ورک AioClock منتشر شد 🔥🔥
آیوکلاک یک فریم ورک برای scheduling هست که کاملا Async عه و هر چیزی که یک فریم ورک نیاز داره رو داخلش داره, مثل دپندسی اینجکشن و startup/stop ایونت و ...
تغییرات نسخه جدید:
- بهبود داکیومنت و خوانایی بسیار بالا
- اضافه شدن پلاگین FastAPI - تو لایه HTTP میتونید ببینید چه تسک هایی دارین, که قراره ران بشن و اگه لازم بود یک تسک با درخواست POST همون لحظه ران کنید!
- اضافه شدن API Internal - برای کنترل لایبری, و نوشتن پلاگین FastAPI که میتونید ابزار CLI باهاش بنویسید یا مثل پلاگین فست رو برای فریم ورک های وب دیگه استفاده کنید.
Github
Documentation
برای حمایت خوشحال میشم استار بدید یا contribute کنید.
@PyBackendHub
آیوکلاک یک فریم ورک برای scheduling هست که کاملا Async عه و هر چیزی که یک فریم ورک نیاز داره رو داخلش داره, مثل دپندسی اینجکشن و startup/stop ایونت و ...
تغییرات نسخه جدید:
- بهبود داکیومنت و خوانایی بسیار بالا
- اضافه شدن پلاگین FastAPI - تو لایه HTTP میتونید ببینید چه تسک هایی دارین, که قراره ران بشن و اگه لازم بود یک تسک با درخواست POST همون لحظه ران کنید!
- اضافه شدن API Internal - برای کنترل لایبری, و نوشتن پلاگین FastAPI که میتونید ابزار CLI باهاش بنویسید یا مثل پلاگین فست رو برای فریم ورک های وب دیگه استفاده کنید.
Github
Documentation
برای حمایت خوشحال میشم استار بدید یا contribute کنید.
@PyBackendHub