رویه ذخیره شده Stored Procedure ناجی برنامه های تحت فشار:
در دنیای برنامه‌نویسی(منظور ما سمت 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 پیروی کنه و همون رو همه جا استفاده کنیم.

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

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

اگه دوست دارید
فرق بین set , list ,tuple و dictionary رو تو پایتون بدونید میتونید یه نگاه به این عکس بندازید که شیک و جمع و جور همشون رو باهم مقایسه کرده

12 نکته مهم در مورد «علم داده» که در هیچ دوره‌ای به شما یاد نمی دهند!


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


اگر کنجکاو و عاشق یادگیری هستید، باید بدانید که هرگز هر چیزی را که دوست دارید در مورد Data Science بدانید، نخواهید دانست. علم داده یک زمینه بسیار گسترده است و زمان و دانش شما هم اندک. پس از این که همه چیز را نمی‌دانید ناامید نشوید.


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


درباره محصول/ محصولات کسب و کاری که فرآیند آنالیز داده را برای آن انجام می‌دهید، اطلاعات کسب کنید. هیچ مدیر سطح A واقعاً به الگوریتم‌ها، مقادیر p، دقت، AUC یا امتیاز f1 اهمیت نمی‌دهد. آن‌ها می خواهند بدانند که کدام مشکل در حال حل شدن است و درآمد (یا پس اندازی) که از انجام پروژه شرکت توسط شما بدست می‌آورند چقدر است. پس بهترین مدل، مدلی است که مشکل پروژه را حل کند؛ مدیران این را می‌خواهند.


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


برخی از تکنیک‌های علوم داده در آموزش‌های تئوری و دوره‌هایی که می‌گذرانید به خوبی کار می کنند، اما در داده‌های دنیایِ واقعی تقریباً بی فایده هستند. من دوست دارم از SMOTE به عنوان مثال استفاده کنم. در Medium، این تکنیک بی عیب و نقص به نظر می‌رسد، در حالی که در دنیای واقعی ممکن است کاملاً ناکار آمد باشد (البته نه به طور کامل).


احتمالاً برخی از مفاهیم مثل نشت داده‌ها و اعتبار سنجی را در طول تحصیل یاد نگرفته‌اید. این به این معنی است که شما تنها زمانی که برخی از مدل‌ها در حال تولید هستند، از کار افتادن آن‌ها را تجربه خواهید کرد. یعنی کاربرد بعضی از مفاهیم علوم داده را تنها در زمان کار بر روی پروژه یاد خواهید گرفت. پس مطمئن شوید که برای جلوگیری از یک حادثه بزرگ، برای نظارت بر مدل‌های خود زمان صرف می‌کنید و یادگیری را ادامه می‌دهید!


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

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


ابزارهای Tensorflow، Pycaret، Catboost و دیگر کتابخانه‌ها ذهن شما را متحیر خواهند کرد. می‌دانم، من هم از آن‌ها استفاده کرده‌ام. اما هرگز قدرت Numpy، Pandas و Scikit-Learn را دست کم نگیرید. با استفاده از این سه کتابخانه، راه حل‌های باورنکردنی خواهید ساخت.


افتضاح است که ساعت ها (یا حتی روزها) را برای مطالعه صرف کنید و بعداً متوجه شوید که در مورد داده‌ها سوء تفاهم وجود دارد یا اشتباهی وجود دارد که متوجه نشده اید. این تجربه وحشتناک است، اما برای همه اتفاق می افتد. خودتان را سرزنش نکنید و صبوری خود را در مواجهه با همکارانتان از دست ندهید. آن‌چه را که باید یاد بگیرید، بیاموزید و همیشه به جلو حرکت کنید!


همیشه شرکت‌ها به هر کسی که موفق می‌شد نوعی از pd.merge() یا هر چیزی را با پایتون اجرا کند، هزینه زیادی پرداخت می‌کردند. اما الان این فاکتور تغییر کرده است. علم داده در حال تکامل است و امروزه تقاضاها بیشتر شده است. فضای ابری، دانش مهندسی داده، اینترنت اشیا، علیت و مهارت های دیگر برخی از پیش نیازهایی هستند که ممکن است امروزه در موقعیت های شغلی جدید با آن‌ها روبرو شوید.

✅ هر وقت صحبت از شیء گرایی و ارث بری میشه پای Mixin هم میاد وسط. اما دقیقا چیه؟ 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 هست. که خیلی قابل اعتماد تره و فضایی نمیذاره برای خطا کردن!

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)

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

یک نکته بگم که احساس میکنم اکثرا که سوال اینطوری طرح میکنن به دنبال تقلید از شرکت های بزرگ و Faang هستن. من خودم حقیقتا به یک شرکت نسبتا بزرگ پارسال مصاحبه داشتم و تو مصاحبه سوال الگوریتمی رو به کند ترین روش ممکن حل کردم ولی پاس داده شدم مرحله بعد و فیدبکی که گرفتم این بود که مهم نیست اگه اینو به صورت آپتیمایز ترین حالت ممکن حل کنی. مهم ارتباط گرفتن موقع حل سواله و اینکه آگاه باشی از ترید آف. 
تو کیس بالا خیلیا به روشی حل کرده بودن که حالت <ایده آل>‌از دیده مصاحبه کننده نبود و تقلب بود. ولی بنظره من اتفاقا خیلی با ارزش تره. وقتی من سولوشنی میدم که کلا out of box بوده و داره نیاز بیزنس من رو پوشش میده چرا که نه؟

نسخه ۰.۱.۰ فریم ورک AioClock منتشر شد 🔥🔥

آیوکلاک یک فریم ورک برای scheduling هست که کاملا Async عه و هر چیزی که یک فریم ورک نیاز داره رو داخلش داره, مثل دپندسی اینجکشن و startup/stop ایونت و ...

تغییرات نسخه جدید:

- بهبود داکیومنت و خوانایی بسیار بالا

- اضافه شدن پلاگین FastAPI - تو لایه HTTP میتونید ببینید چه تسک هایی دارین, که قراره ران بشن و اگه لازم بود یک تسک با درخواست POST همون لحظه ران کنید!

- اضافه شدن API Internal - برای کنترل لایبری, و نوشتن پلاگین FastAPI که میتونید ابزار CLI باهاش بنویسید یا مثل پلاگین فست رو برای فریم ورک های وب دیگه استفاده کنید.


Github
Documentation

برای حمایت خوشحال میشم استار بدید یا contribute کنید.

@PyBackendHub

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

[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 مقیاس‌پذیری و انعطاف‌پذیری رو به ارمغان میارن و هر دو موارد استفاده خاص خودشون رو دارن و می‌تونن در کنار هم استفاده بشن. در نهایت، انتخاب به ماهیت داده‌های شما و نیازهای خاص اپلیکیشن شما بستگی داره.