بهترین و معتبرترین مدارک پایتون در جهان

[Python Institute] PCEP: Certified Entry-Level Python Programmer
Exam Only: $59
Exam + Practice Test: $71

[Python Institute] PCAP: Certified Associate in Python Programming
Exam Only: $259
Exam + Practice Test: $319

[Python Institute] PCPP1: Certified Professional in Python Programming 1
Exam Only: $195

[Python Institute] PCPP2: Certified Professional in Python Programming 2
Exam Only: $195

[Python Institute] PCAT: Certified Associate in Testing with Python
Exam Only: $295
Exam + Practice Test: $319

[Python Institute] PCAD: Certified Associate in Data Analytics with Python
Exam Only: $295
Exam + Practice Test: $319

اکستنش کارآمد مایکروسافت برای Vscode برای کارهای Data Science

اگر تجربه کار کردن با csv رو داشته باشید و بخواهید یه کار تحلیلی دم دستی بکنید احتمالا مستقیم میرید سراغ notebook. حالا یا jupyter رو مستقیم توی بروزر اجرا کنید یا  توی vscode هی باید کد روی dataframe های پاندا بزنی مخصوصا جایی باشه کد زدنه واقعا اهمیت نداشته باشه و خروجی تحلیل موردی شما اهمیت بیشتری داشته. مثلا وقتی که بخواهید unique_count مقادیر هر ستون رو بگیرید. یا مثلا سریعتر بتونم چندتا چیز رو با هم فیلتر کنم و درگیر نوشتن کوئری روی Dataframe نشم خیلی بهتره.
این اکستنش مایکروسافت
Data Wrangler
باهاش کار کردن واقعا لذت بخشه و سرعت کار رو بالا میبره مجبور نیستی روی چیزی که دوست نداری تمرکز کنی و فقط روی نتیجه تمرکز میکنیی.

جالبش اینکه هم روی سلولهای Jupyter  کار میکنه یعنی میتونید با کد pandas تغییرات مد نظر رو بدید و دیتافریم حاصل رو میگیره و روی تحلیل اولیه میزنه  و هم روی فایل CSV رو با ابزارهای تحلیلی باز میکنه و از عملیاتهایی که انجام میده کد تولید میکنه.

https://github.com/microsoft/vscode-data-wrangler

-اصل Command Query Separation در کلین کد

این اصل میگه تابع شما یا باید کاری انجام بده یه به سوالی جواب بده اگه هردوتاش رو میکنه بدون که اشتباه میزنی مثلا یه تابع باید یه چیزی رو تو ابجکتی تغییر بده یا یه اطلاعاتی بگیره ازش اگه جفت کار هارو بکنه یکم گیج کننده میشه

مثلا این مثال رو در نظر بگیرید

public boolean set(String attribute, String value);

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

if (set("username", "CleverDevs"))...

از نگاه خواننده کد ببینید : «این الان چک میکنه که یوزر نیم unclebob از قبل ست شده یا داره چک میکنه »

کلمه set یه فعله ولی وقتی توی شرط استفاده شده قید بنظر میاد و باعث نامفهموم شدن کد میشه
میتونیم به جای set از setAndCheckIfExists استفاده کنیم اما بازم ممکنه برای if statement جالب نباشه بهترین کار اینه که یچیزی مث کد زیر بزنیم :

if (attributeExists("username")) {
      setAttribute("username", "CleverDevs");
       x...
}

خلاصه این اصل این بود که تابعتون نباید هم کاری انجام بده هم چیزی بر گردونه

درس هایی راجب برنامه نویسی از زبان Matt Butcher

یادتون باشه هر خط کدی که می‌نویسین باید بعدا ازش پشتیبانی کنین!

این حرف خیلی معنی داره که تو ادامه می‌گم:

- برنامه نویسی به عنوان صنعتگری
- چرخ رو از اول اختراع نکن
- هزینه پیچیدگی
- کاهش نیازهای آینده برای نگهداری
- چرا خود آیندتون (و دیگران) قدردان کد امروزن

برنامه نویسی به عنوان صنعتگری

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

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

چرخ رو از اول اختراع نکن

یه کتابخونه یا ابزاری هست که کار رو راه می‌ندازه، ولی خب، ما میتونیم بهتر انجامش بدیم!
فکر می‌کنم هر مهندس نرم‌افزاری حداقل یه بار این کار رو کرده و همیشه یه جور توجیه هم هست:

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

تو همه این موارد، دو تا چیز نادیده گرفته میشن:

چقدر بقیه زمان صرف کرده بودن که قبلاً مشکل رو حل کنن. (پختگی اون کد)
منِ آینده چقدر باید وقت بذاره واسه درست کردن و نگهداری اون کد.

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

هر چی کدت پیچیده‌تر، دیباگش سخت‌تره

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

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

کاهش نیازهای آینده برای پشتیبانی
هر سیستم خوبی یه سری کنترل کیفیت داره. کد هم باید همین‌طور باشه. باید یه استراتژی برای تست نوشتن پیدا کنید،‌به هر حال، مهم نیست استراتژی شما چیه، اگه الان تست نکنین، بعداً باید دیباگ کنین.

خودت آیندت یادش نمیاد که خودت الانت به چی فکر میکرده
پس همه‌چی رو مستند کن! آدما یه جور پیش‌فرض عجیب دارن. فکر می‌کنیم که فردا همه چیزایی که امروز اتفاق افتاده رو یادمون می‌مونه. خود آینده‌ت جزئیات ریز اینکه چرا امروز این کد رو به این شکل نوشتی، یا چرا اون متغیر رو fhr اسم گذاشتی، یا چرا کامنت // FIXME later رو رو خط ۲۳۵ جا گذاشتی، یادش نمیاد.

بهترین راهی که می‌تونی با محدودیت‌های حافظه‌ت مقابله کنی اینه که کدت رو واضح بنویسی. این یعنی:

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

خود آینده‌ت ازت ممنون می‌شه. یا حداقل از دستت عصبانی نمی‌شه.

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

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

دیتابیس SQL در مقابل NoSQL: کی چی به کارمون میاد؟

توی دنیای امروز، انتخاب بین SQL و NoSQL می‌تونه گیچ کننده باشه، مخصوصاً با این همه گزینه‌ دردسترس. از دیتابیس های relational مثل MySQL یا PostgreSQL گرفته تا دیتابیس های مدرن مبتنی بر داکیومنت مثل MongoDB یا ذخیره‌سازهای کلید-مقدار مثل DynamoDB، انتخاب بهترین گزینه برای پروژه‌هامون می‌تونه حسابی سخت باشه.

تو این پست قرار این موضوع رو ساده‌تر کنیم و بفهمیم کدومشون برای چه کاری بهتره.

دیتابیس ها SQL چی هستن؟

دیتابیس های SQL که بهشون دیتابیس ها رابطه‌ای (relational databases) هم می‌گن، سال‌هاست که تو دنیای تکنولوژی حرف اول رو می‌زنن. این دیتابیس ها ساختارشون جدولی هست و از یه زبون به اسم SQL (زبان پرس و جوی ساختاریافته) برای تعریف و دستکاری داده‌ها استفاده می‌کنن. SQL برای کارهایی که به انسجام و دقت داده و کوئری های پیچیده نیاز دارن، عالیه.

یکی از مزایای اصلی دیتابیس ها SQL مثل MySQL و PostgreSQL  اینه که با استفاده از relationship ها، می‌تونن از یکپارچگی داده‌ها مطمئن بشن. دیتابیس ها SQL با تعریف یه سری قوانین از قبل، یه جوری داده‌ها رو ذخیره می‌کنن که همیشه دقیق و منظم باشن.


از SQL کجا ها استفاده کنیم؟

👈 سیستم‌های Transactional: برای سیستم‌هایی که نیاز به انجام تراکنش‌های دقیق دارن (مثل سیستم‌های بانکی یا فروشگاه‌های اینترنتی) عالیه. این سیستم‌ها یه جوری باید کار کنن که هیچوقت مشکلی تو ذخیره یا تغییر اطلاعات پیش نیاد.

👈 گزارش‌گیری و تحلیل

👈 انبار داده: از SQL خیلی وقت‌ها برای ذخیره و تحلیل اطلاعاتی مثل اطلاعات مربوط به فروش یا رفتار مشتری‌ها استفاده می‌شه.

دیتابیس ها NoSQL

دیتابیس ها NoSQL مثل MongoDB و ElasticSearch برخلاف پایگاه‌های SQL، رویکردی منعطف‌تر و بدون اسکما (schema-less) برای داده‌ها ارائه می‌دن. این پایگاه‌ها برای مدیریت حجم زیادی از داده‌های بدون ساختار یا نیمه ساختار طراحی شدن و برای مواردی که در اونجا مقیاس‌پذیری، انعطاف‌پذیری و کارایی حرف اول رو می‌زنن، عالی هستن.

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

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

از NoSQL کجا ها استفاده کنیم؟

👈 سیستم‌های توزیع‌شده و مقیاس‌پذیر.

👈 داده‌های حجیم و Real-Time Analytics: دیتابیس های NoSQL در سناریوهایی که شامل داده‌های حجیم و تحلیل لحظه‌ای هستن و در اونجا توان عملیاتی بالا و تأخیر کم اهمیت زیادی داره، عالی عمل می‌کنن.اون‌ها به طور معمول در اپلیکیشن‌هایی مانند IoT، تحلیل شبکه‌های اجتماعی و real-time recommendation engines استفاده می‌شن.


تصورات غلط رایج

با وجود تمام نقاط قوتی که دیتابیس های SQL و NoSQL دارن، در موردشون یه سری تصورات غلط رایج وجود داره.

دیتابیس ها SQL انعطاف‌پذیر نیستن: درسته که دیتابیس ها SQL اسکما یا ساختار ثابتی دارن، اما اون‌ها امکانات قدرتمندی برای تعریف روابط بین جداول و اعمال محدودیت‌های یکپارچگی داده ارائه می‌دن.

دیتابیس ها SQL نمی‌تونن به صورت horizontal مقیاس‌پذیر باشن: هر دوی دیتابیس ها SQL و NoSQL می‌تونن به صورت horizontal مقیاس‌پذیر باشن، حتی اگه روش های مقیاس پذیریشون متفاوت باشه

دیتابیس ها NoSQL از transactional پشتیبانی نمی‌کنن: بسیاری از دیتابیس ها NoSQL قابلیت‌های تراکنشی رو ارائه می‌دن، با وجود اینکه با چیزی که تو دیتابیس ها SQL به عنوان ACID شناخته می‌شه، فرق کنه.

دیتابیس ها NoSQL همیشه از دیتابیس ها SQL سریع‌تر هستن: عملکرد یه پایگاه داده به عوامل مختلفی بستگی داره، از جمله ماهیت حجم کاری، توزیع داده، الگوهای دسترسی به داده و استراتژی‌های ایندکس‌گذاری. هر دوی دیتابیس ها SQL و NoSQL می‌تونن بهینه سازی بشن.

نتیجه‌گیری

در نتیجه، انتخاب راه‌حل مناسب دیتابیس برای پروژه نیازمند درک دقیق نقاط قوت و ضعف دیتابیس هاس. در حالی که دیتابیس های SQL در یکپارچگی داده قوی و پشتیبانی از کوئری های پیچیده رو ارائه می‌دن، دیتابیس ها NoSQL مقیاس‌پذیری و انعطاف‌پذیری رو به ارمغان میارن و هر دو موارد استفاده خاص خودشون رو دارن و می‌تونن در کنار هم استفاده بشن. در نهایت، انتخاب به ماهیت داده‌های شما و نیازهای خاص اپلیکیشن شما بستگی داره.

بحث داغ زبان‌های برنامه‌نویسی: چرا اصلاً مهم نیست؟


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

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

یهویی چی شد؟ یهو همه گیر دادن به پرفورمنس!

طرفدارای یه زبان میگن: "زبان X از زبان Y سریع‌تره!" آره بابا، یه سری تست و بنچمارک نشون میده که یه ذره سرعت اجرا یا مصرف حافظه تو زبونا فرق می‌کنه. ولی بیخیال، واسه 99 درصد برنامه‌ها این فرق‌ها مثه اینه که موقع کدنویسی جوراب قرمز بپوشی یا آبی! مهم معماری، الگوریتم و استراتژی بهینه‌سازیه که کارو راه میندازه. یه سیستم بد طراحی‌شده، چه با Rust نوشته بشه چه با Ruby، آخرش بد و ناکار آمد هستش.

یادگیری زبون برنامه‌نویسی سخته؟

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

لاتاری کتابخونه

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

حرف آخر

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

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

یک مبحثی که خیلی وقت‌ها آدم‌های رو داخل #جنگو گیج میکنه موضوع Aggregation هستش. برای مثال کوئری پایین:

>>> from django.db.models import Avg, Max, Min
>>> Book.objects.aggregate(Avg("price"), Max("price"), Min("price"))
# {'price__avg': 34.35, 'price__max': Decimal('81.20'), 'price__min': Decimal('12.99')}

خب این کوئری مشخصه چه کاری داره انجام میده، همه میتونن بفهمنش مخصوصا وقتی خروجی کوئری رو میبینن، اما اگر ازشون بپرسید خب Aggregation چی هستش هیچ ایده ای ندارن! و این ماجرا از ضعف در دانش SQL سر چشمه میگیره. چون خیلی از آدم‌هایی که دارن #django کار میکنن مستقیم سراغ جنگو اومدن و نرفتن چیزهای دیگه رو مطالعه کنن و یاد بگیرن.

اسم Aggregation داخل ORM جنگو مستقیما از SQL میاد. در SQL یک سری فانکشن وجود داره که بهشون Aggregation functions میگن و کارشون خلاصه سازی اطلاعات:
MIN() - returns the smallest value within the selected column
MAX() - returns the largest value within the selected column
COUNT() - returns the number of rows in a set
SUM() - returns the total sum of a numerical column
AVG() - returns the average value of a numerical column

و خب شما میتونید داخل کوئری‌های SQL ازشون استفاده کنید و دیتا خروجی رو خلاصه سازی کنید و یا یک آمار ازش دربیارید. مثلا میانگین قیمت کتاب‌های تو سال اخیر و ...
یک کوئری مثال برای Aggregation میتونه این باشه:

SELECT AVG(Price) as price_avg FROM Books WHERE puddate=''2023-01-01'';

خب از اونجایی که ORM جنگو در نهایت قرار کار همین SQL نوشتن برای شما انجام بده و کوئری‌ شمارو به SQL تبدیل کنه شما دقیقا همین کوئری میتونید داخل جنگو به این صورت بنویسید:

>>> from django.db.models import Avg
>>> from datetime import datetime
>>> Books.objects.filter(pubdate=datetime(2023, 1, 1)).aggregate(price_avg=Avg("price"))

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

در نهایت از دانش SQL غافل نباشید و حتما یادش بیگیرید. هرچی بیشتر SQL بدونید زندگی راحت‌تری خواهید داشت.

@TorhamDevCH

این روزا بازی همستر طوری سر وصدا ایجاد کرده که اونای که تلگرام نداشتن هم دارن جوین میشن جدیدا تقریبا امروز بالای ۱۵ تا از مخاطب هام وارد تلگرام شدن و هر کدوم یکی در میون لینک دعوت فرستاده 😅😅

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

من فک میکردم درآمد ساقی ها زیاد باشه تا اینکه دیدم ساقی محلمون با همه شماره هاش joined the Telegram

احتمالا همستر وریفای با صرافی بزاره
کاربران آسیا و ایران رو حذف کنه

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

#Python
یکی پایه های شیء گرایی encapsulation هست، توی پایتون برای اجرا این قانون چند راه مختلف داریم، یکی از اون ها استفاده از دکوریتور ‎[at]property هستش. با بکار گیری این دکوریتور ما برای متغییر های داخل کلاس تعیین میکنیم که چه مقداری بهشون اساین بشه، یا اصلا دسترسی اساین رو میگیریم!!
برای مثال: فرض کنید ما در یک کلاس به متغییری نیاز داریم که فقط عددی از 0 تا 100 داخلش ذخیره کنیم. اسم متغییر رو y در نظرم می گیریم.
در تصویر داخل کلاس یک متغییر به اسم y_ داریم(متغییر هایی که با یک _ شروع بشن protected و اونایی که با ــ شروع میشن private هستن)
متغییر y_ درواقع همون متغییر y هست اما با توجه به اینکه مقدار این متغییر نباید مستقیم توسط instance کلاس تغییر کنه، چون باید حتما بین 0 تا 100 باشه. پس ما یک متغییر protected تعریف میکنیم که مقدار 0 تا 100 رو نگهداری کنه و یک فانکشن به اسم y که به متغییر y_ مقدار بدهد و همچنین مقدار y_ را برگرداند. به این نوع از فانکشن ها property میگن، که getter ,setter و deleter را برای یک متغییر تنظیم میکند(طبق تصویر).

اونوقت بگید LaraGram بده!

امکان ساخت Conversation ها به همین سادگی.

- ولیدیت کردن پاسخ هر سوال
- نام گذاری برای هر سوال جهت پردازش راحت تر.
- ارسال سوال به صورت media
- ساخت Conversation با کیبورد
- مشخص کردن کامند جهت skip سوال
-‏ action جهت اجرا آنی پس از دریافت پاسخ
- مشخص کردن تعداد Attempt
- مشخص کردن Timeout بدون پاسخ ماندن
- مشحص کردن کامند لغو Conversation
- مشخص کردن عملیات پس از Conversation

همه این قابلیت ها تنها با متد های پیش ساخته با یک خط کد

البته که این قابلیت ها در ورژن 2 منتشر میشن😉
https://github.com/laraXgram/LaraGram

👨‍💻📚این روزا چون درگیر امتحان های دانشگاه هستم زیاد وقت نمیکنم که مطلب بزارم ولی خوب یکی از کارهای که در کنار آزمون های دانشگاه دارم انجام میدم این هستش که دارم یه جزوه کامل برای برنامه نویسی پایتون آماده میکنم که دردسترس علاقه مند ها به این زبان برنامه نویسی قرار بدم خیلی سعی کردم تا جایی که میتونم به ذکر جزئیات بپردازم و چیزی رو از قلم نندازم به زودی توی کانال قرار میدم که استفاده کنید👨‍💻📚