⏰ مدیریت زمان و راندمان (برای برنامهنویسها) - قسمت 2
🔗 قسمت قبلی
💢 مدیریت زمان: تکنیکها و راهکارها
تو مدیریت زمان، تکنیکهای مختلفی وجود داره که میشه ازشون استفاده کرد. بریم که در ادامه با چنتا از محبوب ترین هاشون آشنا بشیم:
👈 برنامهریزی هفتگی:
یه برنامه ساده برای کل هفته بچین. چی میخوای انجام بدی؟ هر روز چه کارهایی داری؟ فقط حواستون باشه که خیلی جزئی نباشه چون باعث اضطراب و استرس بیشتر میشه. پس فقط فعالیت های مهمتون رو مشخص کنید و بقیه فعالیت ها را به صورت روزانه مشخص کنید؛ بزرگترین باگ این نوع برنامه ریزی اینکه ممکنه تو تله ی "توهم برنامهریزی یا همون Planning Fallacy" بیوفتید.
🖼 تصویر 1
👈 برنامهریزی مبتنی بر هدف
این ترفند تو خیلی از شرکت ها و حتی زندگی روزمره کاربرد داره. خلاصش اینه که یه هدف بزرگ رو انتخاب می کنی و بعد یه عالمه هدف کوچیک تر یا زیرمجموعه که باید انجامشون بدی تا به اون هدف بزرگ برسی مشخص می کنی اما یادتون باشه که هدف با زیرمجموعه فرق میکنه. هدف، چیزیه که قصد دارید بهش برسید و زیرمجموعه، کارهایی که برای رسیدن به اون هدف انجام میدید. مثلا، اگر قرار وزن کم کنید، هدف نهایی شما کاهش وزن هست و زیرمجموعه هاش ورزش کردن و تغذیه سالم هستن. ایجاد اهداف و زیرمجموعه ها برای حفظ تمرکز و توجه بر فعالیت هایی که انجام میدیم مهمه.
نکته مهم اینه که هدفها و زیرمجموعههامون باید واقعبینانه و قابل دسترس باشن. اگه هدفهامون خیلی بزرگ و دور از دسترس باشن، ممکنه خیلی زود دلسرد و از ادامه مسیر منصرف بشیم.
برای اینکه بتونیم پیشرفت خودمون رو اندازه گیری کنیم، میتونیم از شاخصهای کلیدی عملکرد (KPI) استفاده کنیم.
👈 تکنیک پومودورو (Pomodoro)
🖼 تصویر 2
پومودورو یه روش ساده و خفن برای مدیریت زمانه که کمک میکنه تمرکزت رو حفظ کنی و کارهات رو با راندمان بیشتری انجام بدی.
وقتی داری یه برنامه مینویسی، خیلی پیش میاد که حواست پرت بشه و به چیزهای دیگه مثل چک کردن شبکههای اجتماعی مشغول بشی. پومودورو بهت کمک میکنه که این کارها رو کنار بذاری و فقط روی کدنویسی تمرکز کنی.
✅ چطوری از تکنیک پومودورو استفاده کنیم؟
یه کاری که میخوای انجامش بدی رو انتخاب کن.
یه تایمر رو روی ۲۵ دقیقه تنظیم کن.
تا زمانی که تایمر زنگ نزده، فقط روی اون کار تمرکز کن.
وقتی تایمر زنگ زد، یه استراحت ۵ دقیقهای داشته باش.
بعد از استراحت، مراحل ۲ تا ۴ رو تکرار کن تا کار تموم بشه.
چرا ۲۵ دقیقه؟
🖼 تصویر 3
به ذهنت یه چارچوب زمانی میدی: وقتی یه زمان مشخص برای انجام یه کار داری، مغزت ناخودآگاه تلاش میکنه که کار رو تو همون زمان تموم کنه.
از حواس پرتی دور میمونی: تو هر قسمت ۲۵ دقیقهای، فقط روی یه کار تمرکز میکنی و چیزای دیگه مثل گوشیت نمیتونن حواست رو پرت کنن.
انرژیات رو حفظ میکنی: استراحتهای ۵ دقیقهای بین هر قسمت ۲۵ دقیقهای بهت کمک میکنه که خسته نشی و بتونی تمرکزت رو حفظ کنی.
چند تا نکته:
میتونی زمان هر قسمت و استراحت رو خودت تنظیم کنی.
یه کاغذ و قلم کنار دستت بزار تا حواس پرتیهات رو یادداشت کنی و بعداً بهشون رسیدگی کنی.
از یه اپلیکیشن یا تایمر پومودورو استفاده کن تا بهت تو مدیریت زمان کمک کنه.
دوتا نظریه ی جالب هم راجب پومودورو وجود داره:
🖼 تصویر 4
🖼 تصویر 5
—-
ادامه در پست بعدی...
🆔 @MdDaily
🔗 قسمت قبلی
💢 مدیریت زمان: تکنیکها و راهکارها
تو مدیریت زمان، تکنیکهای مختلفی وجود داره که میشه ازشون استفاده کرد. بریم که در ادامه با چنتا از محبوب ترین هاشون آشنا بشیم:
👈 برنامهریزی هفتگی:
یه برنامه ساده برای کل هفته بچین. چی میخوای انجام بدی؟ هر روز چه کارهایی داری؟ فقط حواستون باشه که خیلی جزئی نباشه چون باعث اضطراب و استرس بیشتر میشه. پس فقط فعالیت های مهمتون رو مشخص کنید و بقیه فعالیت ها را به صورت روزانه مشخص کنید؛ بزرگترین باگ این نوع برنامه ریزی اینکه ممکنه تو تله ی "توهم برنامهریزی یا همون Planning Fallacy" بیوفتید.
توهم برنامهریزی: پدیده ایه که زمانی رخ میده که افراد توانایی خودشون رو برای انجام وظایف در یک دوره زمانی معین بیش از حد تخمین میزنن. برای جلوگیری از این تله، مهمه که واقع بین باشی و رویدادهای پیشبینی نشدهای را که امکان داره در طول روز رخ بده، در نظر بگیری. پس تو در برنامهریزی هفتگی، زمان خالی برای رویدادهای پیشبینی نشده و فعالیتهای بدون برنامه در نظر بگیر
🖼 تصویر 1
👈 برنامهریزی مبتنی بر هدف
این ترفند تو خیلی از شرکت ها و حتی زندگی روزمره کاربرد داره. خلاصش اینه که یه هدف بزرگ رو انتخاب می کنی و بعد یه عالمه هدف کوچیک تر یا زیرمجموعه که باید انجامشون بدی تا به اون هدف بزرگ برسی مشخص می کنی اما یادتون باشه که هدف با زیرمجموعه فرق میکنه. هدف، چیزیه که قصد دارید بهش برسید و زیرمجموعه، کارهایی که برای رسیدن به اون هدف انجام میدید. مثلا، اگر قرار وزن کم کنید، هدف نهایی شما کاهش وزن هست و زیرمجموعه هاش ورزش کردن و تغذیه سالم هستن. ایجاد اهداف و زیرمجموعه ها برای حفظ تمرکز و توجه بر فعالیت هایی که انجام میدیم مهمه.
نکته مهم اینه که هدفها و زیرمجموعههامون باید واقعبینانه و قابل دسترس باشن. اگه هدفهامون خیلی بزرگ و دور از دسترس باشن، ممکنه خیلی زود دلسرد و از ادامه مسیر منصرف بشیم.
برای اینکه بتونیم پیشرفت خودمون رو اندازه گیری کنیم، میتونیم از شاخصهای کلیدی عملکرد (KPI) استفاده کنیم.
شاخص KPI معیار برای سنجش پیشرفته. مثلا اگه هدف داری که 5 کیلو وزن کم کنی، می تونی هر هفته خودت رو وزن کنی و ببینم چقدر به هدفت نزدیک شدی.
👈 تکنیک پومودورو (Pomodoro)
🖼 تصویر 2
پومودورو یه روش ساده و خفن برای مدیریت زمانه که کمک میکنه تمرکزت رو حفظ کنی و کارهات رو با راندمان بیشتری انجام بدی.
وقتی داری یه برنامه مینویسی، خیلی پیش میاد که حواست پرت بشه و به چیزهای دیگه مثل چک کردن شبکههای اجتماعی مشغول بشی. پومودورو بهت کمک میکنه که این کارها رو کنار بذاری و فقط روی کدنویسی تمرکز کنی.
✅ چطوری از تکنیک پومودورو استفاده کنیم؟
یه کاری که میخوای انجامش بدی رو انتخاب کن.
یه تایمر رو روی ۲۵ دقیقه تنظیم کن.
تا زمانی که تایمر زنگ نزده، فقط روی اون کار تمرکز کن.
وقتی تایمر زنگ زد، یه استراحت ۵ دقیقهای داشته باش.
بعد از استراحت، مراحل ۲ تا ۴ رو تکرار کن تا کار تموم بشه.
چرا ۲۵ دقیقه؟
🖼 تصویر 3
به ذهنت یه چارچوب زمانی میدی: وقتی یه زمان مشخص برای انجام یه کار داری، مغزت ناخودآگاه تلاش میکنه که کار رو تو همون زمان تموم کنه.
از حواس پرتی دور میمونی: تو هر قسمت ۲۵ دقیقهای، فقط روی یه کار تمرکز میکنی و چیزای دیگه مثل گوشیت نمیتونن حواست رو پرت کنن.
انرژیات رو حفظ میکنی: استراحتهای ۵ دقیقهای بین هر قسمت ۲۵ دقیقهای بهت کمک میکنه که خسته نشی و بتونی تمرکزت رو حفظ کنی.
چند تا نکته:
میتونی زمان هر قسمت و استراحت رو خودت تنظیم کنی.
یه کاغذ و قلم کنار دستت بزار تا حواس پرتیهات رو یادداشت کنی و بعداً بهشون رسیدگی کنی.
از یه اپلیکیشن یا تایمر پومودورو استفاده کن تا بهت تو مدیریت زمان کمک کنه.
دوتا نظریه ی جالب هم راجب پومودورو وجود داره:
قانون پارکینسون:
هر چقدر زمان بیشتری برای انجام یک کار داشته باشیم، بیشتر طول میکشه تا انجامش بدیم. مثال: فرض کنید میخواهید یه مقاله بنویسید. اگه یک ماه فرصت داشته باشید، احتمالاً تا آخرین روز صبر میکنید و در نهایت کار رو با عجله انجام میدید. اما اگه به خودتون فقط یک هفته فرصت بدید، احتمالاً کار رو سریعتر و با کیفیت بهتر انجام میدید.
🖼 تصویر 4
قانون پارتو:
۸۰٪ از نتایج ما از ۲۰٪ از تلاشهای ما میآیند.
مثال: فرض کنید میخواهید برای یک امتحان آماده بشید. اگه تمام مطالب رو در یک روز مطالعه کنید، احتمالاً فقط ۲۰٪ از مطالب رو به یاد خواهید داشت. اما اگه مطالب رو در طول چند هفته مطالعه کنید و هر روز فقط ۲۰٪ از مطالب رو مرور کنید، احتمالاً ۸۰٪ از مطالب رو به یاد خواهید داشت.
🖼 تصویر 5
—-
ادامه در پست بعدی...
🆔 @MdDaily
🔥5❤🔥1
⏰ مدیریت زمان و راندمان (برای برنامهنویسها) - قسمت 3 (پایانی)
🔗 قسمت اول
🔗 قسمت دوم
👈 ماتریس آیزنهاور
وقتی همه چیز قاطی پاتی شده و نمی دونی از کجا شروع کنی، ماتریس آیزنهاور مثل یه ناجی میاد و کمکت می کنه تا کارهاتو اولویت بندی کنی و روزتو برنامه ریزی کنی. راز کارش اینه که وظایف رو به 4 دسته تقسیم می کنه، بر اساس اینکه چقدر مهم و فوری هستن.
🖼 تصویر 1
مهم و فوری: کارهایی که باید همین الان انجامشون بدی.
مهم و غیر فوری: کارهایی که باید انجامشون بدی، ولی نه همین الان.
غیر مهم و فوری: کارهایی که باید همین الان انجامشون بدی، ولی مهم نیستن.
غیر مهم و غیر فوری: کارهایی که نه مهم هستن و نه فوری.
یاد گرفتن اینکه چطوری به کارهایی که مهم نیستن و فوری هم نیستن "نه" بگی خیلی مهمه. اینجوری میتونی روی کارهایی که واقعاً مهم هستن تمرکز کنی.
💢 همه اینها از دیدگاه یک توسعه دهنده
حالا که یه سری تکنیک مدیریت زمان رو یاد گرفتیم، بیایم ببینیم چطور میتونیم ازشون توی عمل برای مدیریت کارآمد زمانمون استفاده کنیم.
من، تو و اکثر برنامه نویسایی که میشناسیم، یه روال کاری شبیه به هم داریم که شامل میتینگ ها، کد نویسی و بررسی کد میشه. چطور میتونیم از تکنیک های مدیریت زمان توی این زمینه استفاده کنیم؟
بیایم با بخش تئوری که موضوع بعد فیزیکی و ذهنیه شروع کنیم.
بعد ذهنی: واسه اینکه بتونی وظایف روزمره رو انجام بدی، مهمه که انگیزه داشته باشی. واسه این کار، باید یه هدف واضح و مشخص داشته باشی. داری یه سری قابلیت رو توسعه میدی، تو جلسات شرکت میکنی، بررسی میکنی چرا؟ هدفت رو مشخص کن و هدف هایی رو واسه رسیدن به اون هدف تعیین کن. با انجام این کار، تعامل بیشتری با کارهای روزمره خواهی داشت.
بعد فیزیکی: اگه خسته، گرسنه، تشنه و اینجور چیزا باشی، انگیزه داشتن فایده ای نداره. به لانچ تایمت(lunchtime) احترام بذار، به نیاز انرژی بدنت توجه کن، ورزش کن و اینجور چیزا. بدنت هم یه ماشینیه و به نگهداری نیاز داره.
💡حالا بیایم به بخش عملی که موضوع تکنیک های مدیریت زمانه بریم.
ما قبلا از یه تکنیک توی بخش تئوری استفاده کردیم که اسمش برنامه ریزی مبتنی بر هدف بود. توی این تکنیک ما KPI ها و هدف هامون رو مشخص می کنیم. اما اینجا می خوایم از یه دیدگاه کلی به یه دیدگاه جزئی تر بریم، یعنی برنامه ریزی روزانه.
🗓 برنامه ریزی هفتگی: احتمالا یه برنامه داری که توش تمام جلسات، کارهای روزانه، برنامه ریزی ها، جلسات بررسی و... نوشته شده. هر چی که ریتم توسعه شرکت شما اقتضا می کنه. عادت کن که هفته ات رو از قبل برنامه ریزی کنی. اگه یه هدف مشخص برای یه هفته داری، از اصولی که اینجا یاد گرفتی استفاده کن و مشخص کن که چقدر زمان می خوای بهش اختصاص بدی. یادت نره که توی برنامه ریزی هفتگی یه سری وقت خالی هم بذاری برای کارهای غیر منتظره و فعالیت های بدون برنامه، چون اینجور کارها همیشه پیش میاد.
♾ ماتریس آیزنهاور: اگه به خاطر یه اتفاق غیرمنتظره یا یه مشکلی که پیش اومده، یه سری کار داری که با هم تداخل دارن، از ماتریس آیزنهاور استفاده کن تا کاراتو اولویت بندی کنی و روزتو برنامه ریزی کنی.
🍅 پومودورو: قبلا خیلی در مورد پومودورو حرف زدم، ولی بذار از دیدگاه خودم بگم که چطور ازش استفاده می کنم. من از دسته های 25 دقیقه ای و 5 دقیقه ای استراحت برای کارهایی استفاده می کنم که یه جورایی می دونم چطور باید انجامشون بدم.
برای کارهایی که حتی نمی دونم از کجا باید شروعشون کنم، یه پومودوروی 30 دقیقه ای می ذارم تا در موردش یاد بگیرم و بعد تصمیم می گیرم که می تونم خودم انجامش بدم یا به کمک کسی نیاز دارم.
💢 نتیجه گیری:
البته تکنیک های دیگه ای هم وجود داره که اینجا بهشون اشاره نکردم، مثل اهداف SMART و OKR ها، ولی به نظر من تکنیک هایی که اینجا گفتم مهم ترین هستن و میشه تو عمل ازشون استفاده کرد. یادتون باشه که همه چیزایی که اینجا گفته شد یه پروسه بهبود مستمره. پس خودتون رو وفق بدین و بهترین راهی که به دردتون می خوره رو پیدا کنین.
امیدوارم از این مجموعه پست خوشتون اومده باشه و بهتون کمک کنه تا زمانتون رو به طور موثر مدیریت کنین :)
🆔 @MdDaily
🔗 قسمت اول
🔗 قسمت دوم
👈 ماتریس آیزنهاور
وقتی همه چیز قاطی پاتی شده و نمی دونی از کجا شروع کنی، ماتریس آیزنهاور مثل یه ناجی میاد و کمکت می کنه تا کارهاتو اولویت بندی کنی و روزتو برنامه ریزی کنی. راز کارش اینه که وظایف رو به 4 دسته تقسیم می کنه، بر اساس اینکه چقدر مهم و فوری هستن.
🖼 تصویر 1
مهم و فوری: کارهایی که باید همین الان انجامشون بدی.
مهم و غیر فوری: کارهایی که باید انجامشون بدی، ولی نه همین الان.
غیر مهم و فوری: کارهایی که باید همین الان انجامشون بدی، ولی مهم نیستن.
غیر مهم و غیر فوری: کارهایی که نه مهم هستن و نه فوری.
یاد گرفتن اینکه چطوری به کارهایی که مهم نیستن و فوری هم نیستن "نه" بگی خیلی مهمه. اینجوری میتونی روی کارهایی که واقعاً مهم هستن تمرکز کنی.
💢 همه اینها از دیدگاه یک توسعه دهنده
حالا که یه سری تکنیک مدیریت زمان رو یاد گرفتیم، بیایم ببینیم چطور میتونیم ازشون توی عمل برای مدیریت کارآمد زمانمون استفاده کنیم.
من، تو و اکثر برنامه نویسایی که میشناسیم، یه روال کاری شبیه به هم داریم که شامل میتینگ ها، کد نویسی و بررسی کد میشه. چطور میتونیم از تکنیک های مدیریت زمان توی این زمینه استفاده کنیم؟
بیایم با بخش تئوری که موضوع بعد فیزیکی و ذهنیه شروع کنیم.
بعد ذهنی: واسه اینکه بتونی وظایف روزمره رو انجام بدی، مهمه که انگیزه داشته باشی. واسه این کار، باید یه هدف واضح و مشخص داشته باشی. داری یه سری قابلیت رو توسعه میدی، تو جلسات شرکت میکنی، بررسی میکنی چرا؟ هدفت رو مشخص کن و هدف هایی رو واسه رسیدن به اون هدف تعیین کن. با انجام این کار، تعامل بیشتری با کارهای روزمره خواهی داشت.
بعد فیزیکی: اگه خسته، گرسنه، تشنه و اینجور چیزا باشی، انگیزه داشتن فایده ای نداره. به لانچ تایمت(lunchtime) احترام بذار، به نیاز انرژی بدنت توجه کن، ورزش کن و اینجور چیزا. بدنت هم یه ماشینیه و به نگهداری نیاز داره.
💡حالا بیایم به بخش عملی که موضوع تکنیک های مدیریت زمانه بریم.
ما قبلا از یه تکنیک توی بخش تئوری استفاده کردیم که اسمش برنامه ریزی مبتنی بر هدف بود. توی این تکنیک ما KPI ها و هدف هامون رو مشخص می کنیم. اما اینجا می خوایم از یه دیدگاه کلی به یه دیدگاه جزئی تر بریم، یعنی برنامه ریزی روزانه.
🗓 برنامه ریزی هفتگی: احتمالا یه برنامه داری که توش تمام جلسات، کارهای روزانه، برنامه ریزی ها، جلسات بررسی و... نوشته شده. هر چی که ریتم توسعه شرکت شما اقتضا می کنه. عادت کن که هفته ات رو از قبل برنامه ریزی کنی. اگه یه هدف مشخص برای یه هفته داری، از اصولی که اینجا یاد گرفتی استفاده کن و مشخص کن که چقدر زمان می خوای بهش اختصاص بدی. یادت نره که توی برنامه ریزی هفتگی یه سری وقت خالی هم بذاری برای کارهای غیر منتظره و فعالیت های بدون برنامه، چون اینجور کارها همیشه پیش میاد.
♾ ماتریس آیزنهاور: اگه به خاطر یه اتفاق غیرمنتظره یا یه مشکلی که پیش اومده، یه سری کار داری که با هم تداخل دارن، از ماتریس آیزنهاور استفاده کن تا کاراتو اولویت بندی کنی و روزتو برنامه ریزی کنی.
🍅 پومودورو: قبلا خیلی در مورد پومودورو حرف زدم، ولی بذار از دیدگاه خودم بگم که چطور ازش استفاده می کنم. من از دسته های 25 دقیقه ای و 5 دقیقه ای استراحت برای کارهایی استفاده می کنم که یه جورایی می دونم چطور باید انجامشون بدم.
برای کارهایی که حتی نمی دونم از کجا باید شروعشون کنم، یه پومودوروی 30 دقیقه ای می ذارم تا در موردش یاد بگیرم و بعد تصمیم می گیرم که می تونم خودم انجامش بدم یا به کمک کسی نیاز دارم.
💢 نتیجه گیری:
البته تکنیک های دیگه ای هم وجود داره که اینجا بهشون اشاره نکردم، مثل اهداف SMART و OKR ها، ولی به نظر من تکنیک هایی که اینجا گفتم مهم ترین هستن و میشه تو عمل ازشون استفاده کرد. یادتون باشه که همه چیزایی که اینجا گفته شد یه پروسه بهبود مستمره. پس خودتون رو وفق بدین و بهترین راهی که به دردتون می خوره رو پیدا کنین.
امیدوارم از این مجموعه پست خوشتون اومده باشه و بهتون کمک کنه تا زمانتون رو به طور موثر مدیریت کنین :)
🆔 @MdDaily
❤🔥6🔥2❤1👍1
#tip
جلوگیری از اسپم فرم با هانی پات
طبق آخرین آمار تقریبا ۳۲ درصد از ترافیک اینترنت رو Bad bots ها تشکیل میدن. یعنی بات هایی که توی اینترنت میگردن داده جمع آوری میکنن یا ممکنه توی فرم های وبسایت ها اسپم بکنن مثل ارسال پیام های تبلیغاتی.
سناریویی رو در نظر بگرید که ما یه وبسایت داریم و توی این وبسایت یه صفحه ی ارتباط با ما ایجاد کردیم. حالا این بات های بد این صفحه ی ارتباط با ما رو پیدا کردن و شروع میکنن به ارسال پیام های تبلیغاتی و اسپم. چطوری میشه با کمترین پیچدگی ممکن از وارد شدن اطلاعات spam به دیتابیس جلوگیری کنیم؟
ممکنه با خودتون بگید خب از کپچا و Rate limiting استفاده میکنیم ولی بیایند یکم خلاقانه تر عمل کنیم!
خب تفاوت یه بات و یه کاربر موقع submit فرم چیه؟ تفاوتشون اینکه کاربر اون چیزی رو میبینه که شما می خواهید ببینه ولی بات همه چیزو میبینه.
بذارید یه مثال بزنم. یه فرم html ساده داریم با دوتا فیلد:
کاربر فقط فیلد Name رو میبینه ولی بات فیلد hidden رو هم میبینه و پرش میکنه. پس کافیه ما توی فرممون یه فیلد پنهان بذاریم که فقط توسط بات ها امکان پر شدنش وجود داره. به این روش میگن ایجاد هانی پات (Honeypot). در نتیجه وقتی داده ارسال میشه و فیلد hidden هم پرشده باشه، داده ها را وارد دیتابیس نمیکنیم :)
🆔 @MdDaily
جلوگیری از اسپم فرم با هانی پات
طبق آخرین آمار تقریبا ۳۲ درصد از ترافیک اینترنت رو Bad bots ها تشکیل میدن. یعنی بات هایی که توی اینترنت میگردن داده جمع آوری میکنن یا ممکنه توی فرم های وبسایت ها اسپم بکنن مثل ارسال پیام های تبلیغاتی.
سناریویی رو در نظر بگرید که ما یه وبسایت داریم و توی این وبسایت یه صفحه ی ارتباط با ما ایجاد کردیم. حالا این بات های بد این صفحه ی ارتباط با ما رو پیدا کردن و شروع میکنن به ارسال پیام های تبلیغاتی و اسپم. چطوری میشه با کمترین پیچدگی ممکن از وارد شدن اطلاعات spam به دیتابیس جلوگیری کنیم؟
ممکنه با خودتون بگید خب از کپچا و Rate limiting استفاده میکنیم ولی بیایند یکم خلاقانه تر عمل کنیم!
خب تفاوت یه بات و یه کاربر موقع submit فرم چیه؟ تفاوتشون اینکه کاربر اون چیزی رو میبینه که شما می خواهید ببینه ولی بات همه چیزو میبینه.
بذارید یه مثال بزنم. یه فرم html ساده داریم با دوتا فیلد:
<form>
<label for="name">Name:</label>
<input type="text" id="name" name="name" required>
<input type="hidden" id="hidden-field"
name="hidden-field" value="Only Bot Can See ME :)">
<button type="submit">Submit</button>
</form>
کاربر فقط فیلد Name رو میبینه ولی بات فیلد hidden رو هم میبینه و پرش میکنه. پس کافیه ما توی فرممون یه فیلد پنهان بذاریم که فقط توسط بات ها امکان پر شدنش وجود داره. به این روش میگن ایجاد هانی پات (Honeypot). در نتیجه وقتی داده ارسال میشه و فیلد hidden هم پرشده باشه، داده ها را وارد دیتابیس نمیکنیم :)
🆔 @MdDaily
👌18👍2🔥2
#معرفی
پروژه MarkdownDown
با استفاده از پروژه ی MarkdownDown میتونید آدرس هر وبسایتی رو بهش بدید و وبسایت رو تبدیل به markdown کنه.
قابلیت حذف محتوای اضافه مثل تبلیغات رو داره و حتی میتونید از قدرت chat gpt هم برای گرفتن خروجی بهتر استفاده کنید.
🔗 https://markdowndown.vercel.app/
🆔 @MdDaily
پروژه MarkdownDown
با استفاده از پروژه ی MarkdownDown میتونید آدرس هر وبسایتی رو بهش بدید و وبسایت رو تبدیل به markdown کنه.
قابلیت حذف محتوای اضافه مثل تبلیغات رو داره و حتی میتونید از قدرت chat gpt هم برای گرفتن خروجی بهتر استفاده کنید.
🔗 https://markdowndown.vercel.app/
🆔 @MdDaily
🔥5👍2
۱۱ تا tip کمک کننده در برنامه نویسی
۱.حفظ نکن!
یاد بگیر چطور اطلاعاتی که نیاز داری رو پیدا کنی. منظورم فقط StackOverflow و GenAI نیست. برای ابزارها و زبانهایی که استفاده میکنی، باید بدونی که مستنداتشون کجا پیدا میشه. کی بهترین راهنماها رو مینویسه؟ مهم نیست که یادت نمیمونه موقع استفاده از عملگر شرطی اولویت با ؟ یا : هست. مهم اینه که بدونی کی از یه عملگر شرطی استفاده کنی و کجا دقیقاً syntax رو پیدا کنی. ابزارها دائماً بهروز میشن یه راهی برای بهروز بودن پیدا کن، چه یه خبرنامه باشه چه یه دوست که عاشق CSS هست :)
۲.رو اصول اولیه عمیقاً کار کن!
اگه اصول اولیه رو خوب بلد باشی، یادگیری یه ابزار جدید تو اکوسیستم خیلی راحتتره. احتمالاً نرمافزاری که مینویسی سادهتر و قویتر میشه. دیگه سعی نمیکنی یه چیزی رو از اول بنویسی که قبلاً وجود داره، فقط چون نمیدونستی. خطاهایی که میگیری رو بهتر میفهمی و میتونی قبل از اینکه اتفاق بیفتن، پیشبینیشون کنی.
۳.تفکر سیستمی خیلی به دردت میخوره!
عیبیابی هر باگ به تفکر سیستمی نیاز داره. اگه به پریز برق فکر نکنی، موقعی که تستر روشن نمیشه، اصلاً بهش فکر نمیکنی که چک کنی. توانایی فکر کردن به کل سیستم باعث میشه که پیشبینی موارد خاص و طراحی ویژگیهای جدید راحتتر بشه.اگه دوست داشتید، این مقاله رو بخونید.
۴.قبل از پرسیدن، امتحان کن تا هیچ وقت سوالت مسخره نباشه!
برنامهنویسها معمولاً به سمت حل مشکل گرایش دارن. اگه بتونی نشون بدی که چند تا راه رو امتحان کردی و جواب نداده، احتمالاً خودشون میخوان دست به کار شن تا بفهمند چرا راهحلهای واضح جواب ندادن.
۵.هر خط کد یه دردسره!
کد رو طوری بنویس که انگار یه نفر دیگه قراره اون رو فیکس کنه. (حتی اگه اون یه نفر خودت باشی تو ۶ ماه دیگه!) دلیل کارهاتو مستند کن تا بعداً یه چیزی رو ناخواسته خراب نکنی. قبل از اینکه یه ابزار رو جزئی از سیستم کنی، نظرات بقیه رو راجع بهش بخون، شاید نظرات اون ابزار با قابلیتهایی که نیاز داری، جور درنیاد!
۶.خوندن کد بقیه رو تمرین کن!
شاید این حسو داشته باشی که قراره همیشه اپلیکیشنهای جدید بسازی. اما خیلی بیشتر احتمال داره که تو مشغول رفع باگ و اضافه کردن قابلیت به یه کد بیس موجود باشی. حتی ممکنه بیشتر از نوشتن کد، وقتت رو صرف خوندنش کنی. پس خوندن و بازنویسی کد رو تمرین کن :)
۷.تست کن و باز هم تست کن!
همونطور که Chocho تو صحبت DevNexus 2024 گفت، "کد تئوریه. نرمافزار عملیاته." همیشه قبل از اینکه بخوای کسی کدت رو ببینه، خودت اجراش کن و تست کن. تا جایی که میشه نوشتن تست رو تمرین کن. اینکه بتونی پیشبینی کنی چطور یه کاربر میتونه برنامهت رو خراب کنه و به چیزی فراتر از سناریوی ایدهآل فکر کنی، باعث میشه یه برنامهنویس بهتر بشی.
۸.تمرین کن تا نیازمندیها رو به نرمافزار تبدیل کنی!
ایشو:
ازت انتظار میره بتونی یه همچین نیازمندیای رو به یه لیست از مرحلهها (list of steps) یا شبهکد تبدیل کنی. اگه تیکت خیلی گنگه، برای شفاف تر شدنش سوال بپرس. بعد از اینکه مرحلهها رو مشخص کردی، نوبت این میرسه که اونا رو به کد و (امیدوارم) تست برای اون کد تبدیل کنی. بعدش هم کد رو وارد version control کنی، ریویو و کنترل کیفیت بشه و توی پروسهی deployment قرار بگیره. برای تمرین کردن این کار، پروژههای اپن سورس عالین.
۹.کامیونیتی خیلی مهمه!
تو قرار نیست توی شبکههای اجتماعی با دقیقترین و بیطرفترین دیدگاهها آشنا بشی. به یه شبکهی حمایتی نیاز داری که وقتی به اون دیدگاهها نیاز داری، به دادت برسه. اینجا نقش منتور هم مهمه. رفتن به میتآپها و کنفرانسها راههای عالی برای ساختن شبکه و گسترش دیدگاه توسعهدهندگی تو هستن. پیوستن به گروههای شبکهسازی، بهت دسترسی به دیدگاه توسعهدهندههای ارشد میده. سعی نکن تنهایی از پس این کار بربیای. اطلاعات زیادی اون بیرون ریخته و راحت میشه گیج شد.
۱۰.چیزی رو تو برنامهنویسی پیدا کن که ازش لذت میبری!
نمیگم عاشق شغلت بشو یا تبدیل به اون برنامهنویس افسانهای و پرشور (Passionate Programmer) بشین. اما یادگیری مداوم یعنی اینکه خودت رو برای ناخوشایندیهای(discomfort) مکرر آماده کنی. اگه نمیدونی چرا میخوای هر روز صبح بیدار شی و این کار رو با خودت بکنی، آسیب میبینی. میتونه یه دلیل کاملاً خودخواهانه باشه، اما باید دلیل خودت رو پیدا کنی.
۱۱.هرکسی تو مسیر خودش قرار داره!
تو با مسیر شغلی و محتوای بقیه رقابت نمیکنی. مسیر موفقیت دیگران شاید اصلاً برای تو کار نکنه. روی دیدگاه و نقاط قوت منحصربهفرد خودت تمرکز کن. صدات رو پیدا کن و با بقیه به اشتراک بذار. اون بیرون کسی هست که میخواد صدات رو بشنوه.
🆔 @MdDaily
۱.حفظ نکن!
یاد بگیر چطور اطلاعاتی که نیاز داری رو پیدا کنی. منظورم فقط StackOverflow و GenAI نیست. برای ابزارها و زبانهایی که استفاده میکنی، باید بدونی که مستنداتشون کجا پیدا میشه. کی بهترین راهنماها رو مینویسه؟ مهم نیست که یادت نمیمونه موقع استفاده از عملگر شرطی اولویت با ؟ یا : هست. مهم اینه که بدونی کی از یه عملگر شرطی استفاده کنی و کجا دقیقاً syntax رو پیدا کنی. ابزارها دائماً بهروز میشن یه راهی برای بهروز بودن پیدا کن، چه یه خبرنامه باشه چه یه دوست که عاشق CSS هست :)
۲.رو اصول اولیه عمیقاً کار کن!
اگه اصول اولیه رو خوب بلد باشی، یادگیری یه ابزار جدید تو اکوسیستم خیلی راحتتره. احتمالاً نرمافزاری که مینویسی سادهتر و قویتر میشه. دیگه سعی نمیکنی یه چیزی رو از اول بنویسی که قبلاً وجود داره، فقط چون نمیدونستی. خطاهایی که میگیری رو بهتر میفهمی و میتونی قبل از اینکه اتفاق بیفتن، پیشبینیشون کنی.
۳.تفکر سیستمی خیلی به دردت میخوره!
عیبیابی هر باگ به تفکر سیستمی نیاز داره. اگه به پریز برق فکر نکنی، موقعی که تستر روشن نمیشه، اصلاً بهش فکر نمیکنی که چک کنی. توانایی فکر کردن به کل سیستم باعث میشه که پیشبینی موارد خاص و طراحی ویژگیهای جدید راحتتر بشه.اگه دوست داشتید، این مقاله رو بخونید.
۴.قبل از پرسیدن، امتحان کن تا هیچ وقت سوالت مسخره نباشه!
برنامهنویسها معمولاً به سمت حل مشکل گرایش دارن. اگه بتونی نشون بدی که چند تا راه رو امتحان کردی و جواب نداده، احتمالاً خودشون میخوان دست به کار شن تا بفهمند چرا راهحلهای واضح جواب ندادن.
۵.هر خط کد یه دردسره!
کد رو طوری بنویس که انگار یه نفر دیگه قراره اون رو فیکس کنه. (حتی اگه اون یه نفر خودت باشی تو ۶ ماه دیگه!) دلیل کارهاتو مستند کن تا بعداً یه چیزی رو ناخواسته خراب نکنی. قبل از اینکه یه ابزار رو جزئی از سیستم کنی، نظرات بقیه رو راجع بهش بخون، شاید نظرات اون ابزار با قابلیتهایی که نیاز داری، جور درنیاد!
۶.خوندن کد بقیه رو تمرین کن!
شاید این حسو داشته باشی که قراره همیشه اپلیکیشنهای جدید بسازی. اما خیلی بیشتر احتمال داره که تو مشغول رفع باگ و اضافه کردن قابلیت به یه کد بیس موجود باشی. حتی ممکنه بیشتر از نوشتن کد، وقتت رو صرف خوندنش کنی. پس خوندن و بازنویسی کد رو تمرین کن :)
۷.تست کن و باز هم تست کن!
همونطور که Chocho تو صحبت DevNexus 2024 گفت، "کد تئوریه. نرمافزار عملیاته." همیشه قبل از اینکه بخوای کسی کدت رو ببینه، خودت اجراش کن و تست کن. تا جایی که میشه نوشتن تست رو تمرین کن. اینکه بتونی پیشبینی کنی چطور یه کاربر میتونه برنامهت رو خراب کنه و به چیزی فراتر از سناریوی ایدهآل فکر کنی، باعث میشه یه برنامهنویس بهتر بشی.
۸.تمرین کن تا نیازمندیها رو به نرمافزار تبدیل کنی!
ایشو:
یک دکمه به صفحه اضافه کن که یه modal باز کنه و کاربر بتونه این داده رو ویرایش کنه
ازت انتظار میره بتونی یه همچین نیازمندیای رو به یه لیست از مرحلهها (list of steps) یا شبهکد تبدیل کنی. اگه تیکت خیلی گنگه، برای شفاف تر شدنش سوال بپرس. بعد از اینکه مرحلهها رو مشخص کردی، نوبت این میرسه که اونا رو به کد و (امیدوارم) تست برای اون کد تبدیل کنی. بعدش هم کد رو وارد version control کنی، ریویو و کنترل کیفیت بشه و توی پروسهی deployment قرار بگیره. برای تمرین کردن این کار، پروژههای اپن سورس عالین.
۹.کامیونیتی خیلی مهمه!
تو قرار نیست توی شبکههای اجتماعی با دقیقترین و بیطرفترین دیدگاهها آشنا بشی. به یه شبکهی حمایتی نیاز داری که وقتی به اون دیدگاهها نیاز داری، به دادت برسه. اینجا نقش منتور هم مهمه. رفتن به میتآپها و کنفرانسها راههای عالی برای ساختن شبکه و گسترش دیدگاه توسعهدهندگی تو هستن. پیوستن به گروههای شبکهسازی، بهت دسترسی به دیدگاه توسعهدهندههای ارشد میده. سعی نکن تنهایی از پس این کار بربیای. اطلاعات زیادی اون بیرون ریخته و راحت میشه گیج شد.
۱۰.چیزی رو تو برنامهنویسی پیدا کن که ازش لذت میبری!
نمیگم عاشق شغلت بشو یا تبدیل به اون برنامهنویس افسانهای و پرشور (Passionate Programmer) بشین. اما یادگیری مداوم یعنی اینکه خودت رو برای ناخوشایندیهای(discomfort) مکرر آماده کنی. اگه نمیدونی چرا میخوای هر روز صبح بیدار شی و این کار رو با خودت بکنی، آسیب میبینی. میتونه یه دلیل کاملاً خودخواهانه باشه، اما باید دلیل خودت رو پیدا کنی.
۱۱.هرکسی تو مسیر خودش قرار داره!
تو با مسیر شغلی و محتوای بقیه رقابت نمیکنی. مسیر موفقیت دیگران شاید اصلاً برای تو کار نکنه. روی دیدگاه و نقاط قوت منحصربهفرد خودت تمرکز کن. صدات رو پیدا کن و با بقیه به اشتراک بذار. اون بیرون کسی هست که میخواد صدات رو بشنوه.
🆔 @MdDaily
❤🔥5👌3👍1🔥1
دیتابیس 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 مقیاسپذیری و انعطافپذیری رو به ارمغان میارن و هر دو موارد استفاده خاص خودشون رو دارن و میتونن در کنار هم استفاده بشن. در نهایت، انتخاب به ماهیت دادههای شما و نیازهای خاص اپلیکیشن شما بستگی داره.
🆔 @MdDaily
توی دنیای امروز، انتخاب بین 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 مقیاسپذیری و انعطافپذیری رو به ارمغان میارن و هر دو موارد استفاده خاص خودشون رو دارن و میتونن در کنار هم استفاده بشن. در نهایت، انتخاب به ماهیت دادههای شما و نیازهای خاص اپلیکیشن شما بستگی داره.
🆔 @MdDaily
👌4❤1👍1🔥1
#شاید_موقت
چند وقته میخوام مقاله ی 🧠 How to be a great software engineer without using your brain. رو در قالب پست کانال خلاصه و عامیانه کنم ولی موقعی که به فارسی برمیگرده اون حالو هوای مقاله اصلی رو از دست میده :)
درکل مقاله ی جالبیه. اگه پیشنهادی دارید خوشحال میشم توی کامنت ها به اشتراک بگذارید
چند وقته میخوام مقاله ی 🧠 How to be a great software engineer without using your brain. رو در قالب پست کانال خلاصه و عامیانه کنم ولی موقعی که به فارسی برمیگرده اون حالو هوای مقاله اصلی رو از دست میده :)
درکل مقاله ی جالبیه. اگه پیشنهادی دارید خوشحال میشم توی کامنت ها به اشتراک بگذارید
DEV Community
🧠 How to be a great software engineer without using your brain.
Edit: Now also available on my blog. I choose a lazy person to do a hard job. Because a lazy person...
👍3🔥1
هنر خود آموزی: چطوری هرچیزی رو تو برنامهنویسی به خودت یاد بدی 🤓
💢 مقدمهای بر خود آموزی
ببین چی شده، شنیدی بازار کار برنامه نویسی داغه داغه؟ میری یه ویدیو تو یوتیوب پیدا میکنی یا یه دوره عجیب غریب پولی که یه چیزایی یادت میده و میگی ها! این همون چیزی بود که کم داشتم! اما فقط چند روز (یا شاید چند ساعت) طول میکشه تا بفهمی برنامه نویسی کار سختیه و دنبال کردن یه دوره الکی که تو نت پیدا کردی فقط بلدی چیزای دیگه رو کپی کنی، بعدش که میای خودت یه چیزی بنویسی فقط مات و مبهوت به صفحه خالی کامپیوترت نگاه میکنی...
ادامه پست در تلگراف:
🔗 https://telegra.ph/هنر-خود-آموزی-چطوری-هرچیزی-رو-تو-برنامهنویسی-به-خودت-یاد-بدی-05-03
🆔 @MdDaily
💢 مقدمهای بر خود آموزی
ببین چی شده، شنیدی بازار کار برنامه نویسی داغه داغه؟ میری یه ویدیو تو یوتیوب پیدا میکنی یا یه دوره عجیب غریب پولی که یه چیزایی یادت میده و میگی ها! این همون چیزی بود که کم داشتم! اما فقط چند روز (یا شاید چند ساعت) طول میکشه تا بفهمی برنامه نویسی کار سختیه و دنبال کردن یه دوره الکی که تو نت پیدا کردی فقط بلدی چیزای دیگه رو کپی کنی، بعدش که میای خودت یه چیزی بنویسی فقط مات و مبهوت به صفحه خالی کامپیوترت نگاه میکنی...
ادامه پست در تلگراف:
🔗 https://telegra.ph/هنر-خود-آموزی-چطوری-هرچیزی-رو-تو-برنامهنویسی-به-خودت-یاد-بدی-05-03
* به خاطر محدودیت های کارکتر تلگرام تو یدونه پست جا نشد، توی تلگراف نوشتم :)
🆔 @MdDaily
❤5👍2👌2
چطوری جلوی فک کردن بیش از حد (اورتینک) رو بگیریم؟
توی مدت گذشته درگیر اورتینک شده بودم و راه کار های این مقاله کمکم کردن تا حد زیادی کنترلش کنم و توی این پست قرار باهم بررسیشون کنیم و پست قرار از زبان نویسنده ی مقاله نقل بشه با سناریوی اینکه تصمیم میگیره یک هفته مقاله ننویسه و این دلیل اورتینکش میشه :)
—
من همیشه آدمی بودم که زیاد فکر و خیال می کنه. این اتفاق به دلایل مختلفی می افتاد، مثلاً:
- وقتی باید بین بین انتخاب های سخت تصمیم بگیرم.
- وقتی از یه اتفاقی که ممکنه خوب پیش نره می ترسم، مدام به عواقبش فکر می کنم.
- نگرانم که اگه یه کاری رو خراب کنم، بقیه چی فکر می کنن.
۵ تا راهکاری که انجام دادم:
این کارهایی که می خوام بگم تقریباً همون کارهایی هستن که سر کار برای اینکه دیگه الکی فکر و خیال نکنم انجام می دم. پس فکر کنم توی شرایط مختلف دیگه هم به دردتون بخوره.
۱. بنویسید
مزایا و معایب صرف نظر کردن از مقاله ام را در این هفته نوشتم.
مزایا:
- به خودم و خانوادهم بیشتر میرسم.
معایب:
- ترسناک بود که یه هفته ننویسم.
- فکر می کردم اگه یه هفته ننویسم، بعدش دیگه هیچ وقت نمی نویسم.
بعدش یه ذره عمیق تر به مزایا و معایب فکر کردم و دیدم که آیا واقعا درستن یا نه.
دلایل
چقدر طول می کشه یه مقاله بنویسم؟
تو طول هفته ۴ تا ۶ ساعت تیکه تیکه وقت گذاشتم.
چرا انقدر طول کشید؟ میشه تو نصف این زمان هم تمومش کرد؟
چرا ننوشتن مقاله بده؟
خبرنامه ام رو بیشتر از ۶ ماهه که دارم می گردونم. پس یه عادته و یه هفته ننوشتنش باعث نمیشه از بین بره.
۲. یه ضرب الاجل تعیین کنید
به خودم چالش دادم که زیر ۲ ساعت تمومش کنم.
تو یه هفته معمولی، یه ذره وقت میذارم و از بین یه عالمه موضوعی که تا حالا جمع کردم، یکی رو انتخاب می کنم.
این بار که مرحله ۱ رو انجام دادم، دیدم که موضوعش باید اورتینک باشه!
دو تا اتفاق احتمالی رو نوشتم:
اگه تو ۲ ساعت تمومش کنم: این هفته منتشرش می کنم. یالا! این اتفاق افتاد.
اگه تموم نشه: هفته بعدش منتشرش می کنم و میگم که چطوری تصمیم گرفتم و بهش پایبند موندم.
پس یه جورایی دو سر برد بود.
۳. توجه پیوسته
برای کار فکری مثل نوشتن مقاله، به تمرکز نیاز دارم. تو هفتههای معمولی، نوشتن خبرنامه رو تو هر بار وقت کمی که پیدا میکردم، جا میدادم (بعضی وقتا حتی ۱۰ دقیقه).
برای همین مدام بین موضوعات مختلف جابجا میشدم و تمرکزم رو از دست میدادم. این کار کلی اثر منفی داشت. مثلا:
تو زمان نوشتن، بین دو سه تا موضوع پرش میکردم.
قسمتهای سخت رو برای آخر نگه میداشتم.
برای این دفعه، تصمیم گرفتم که بیشتر از ۳ سشن نداشته باشم.
سشن ۱ - ۱ ساعت: نوشتن خلاصه و پیشنویس اولیه.
سشن ۲ - ۳۰ دقیقه: بازنویسی قسمتهای بد با دید تازه. ساخت دو تا تصویر.
سشن ۳ - ۳۰ دقیقه: ویرایش نهایی و اعمال تغییرات جزئی.
نتیجه نهایی خیلی به چیزی که تصمیم گرفته بودم نزدیک بود.
🖼 تصویر
۴. مراقب کمالگرایی باشید
کمالگرایی باعث فکر کردن بیش از حد میشه! پس باید خیلی مراقب باشیم که تو دام کمالگرایی نیفتیم.
برای نوشتن خبرنامه، یه حس خوبی پیدا کردم که چی به اندازه کافی خوبه در مقابل اینکه خیلی خوبه. اما هنوزم با مرز بین خیلی خوب و فوقالعاده عالی مشکل دارم. معیار برای این مقاله این بود که به سطح «به اندازه کافی خوب» برسه. اگه تو ۲ ساعت بهش میرسیدم منتشرش میکردم وگرنه یه هفته عقبش مینداختم.
🖼 تصویر
وقتی تازه کاری رو شروع میکنید، فهمیدن اینکه «به اندازه کافی خوب» یعنی چی میتونه سخت باشه. تو این مواقع، گرفتن فیدبک زودهنگام بهتون کمک میکنه خودتون رو مچ کنید.
۵. اولویتبندی کنید
وقتی زمان محدوده، باید با دقت ازش استفاده کنید تا روی کارایی که بیشترین ارزش رو داره تمرکز کنید.
برای این مورد، P0ها و P1هارو تعریف کردم.
اولویت P0 - باید انجام بشه.
پیام اصلی و ارزش برای خواننده واضح باشه. تو این مورد: پیام اصلی = مراحلی که برای توقف اورتینک انجام شده و شما میتونید برای مبارزه با اورتینک خودتون ازش استفاده کنید.
مقاله به راحتی قابل خوندن باشه.
مقدمه جذاب و نتیجهگیری واضح داشته باشه.
اولویت P1 - خوبه که داشته باشیم.
مقدمه قویتر.
نکات عملی قویتری که سناریوهای مختلف رو پوشش بده.
تو این مورد: به اشتراک گذاشتن مثال یه مهندس نرمافزار که اکثر شما میتونید باهاش ارتباط برقرار کنید.
تصاویری با استعاره. اینا باعث میشه خواننده بگه «آها!»
بهینهسازی سئو
یادداشت پایانی
🆔 @MdDaily
توی مدت گذشته درگیر اورتینک شده بودم و راه کار های این مقاله کمکم کردن تا حد زیادی کنترلش کنم و توی این پست قرار باهم بررسیشون کنیم و پست قرار از زبان نویسنده ی مقاله نقل بشه با سناریوی اینکه تصمیم میگیره یک هفته مقاله ننویسه و این دلیل اورتینکش میشه :)
—
من همیشه آدمی بودم که زیاد فکر و خیال می کنه. این اتفاق به دلایل مختلفی می افتاد، مثلاً:
- وقتی باید بین بین انتخاب های سخت تصمیم بگیرم.
- وقتی از یه اتفاقی که ممکنه خوب پیش نره می ترسم، مدام به عواقبش فکر می کنم.
- نگرانم که اگه یه کاری رو خراب کنم، بقیه چی فکر می کنن.
۵ تا راهکاری که انجام دادم:
این کارهایی که می خوام بگم تقریباً همون کارهایی هستن که سر کار برای اینکه دیگه الکی فکر و خیال نکنم انجام می دم. پس فکر کنم توی شرایط مختلف دیگه هم به دردتون بخوره.
۱. بنویسید
مزایا و معایب صرف نظر کردن از مقاله ام را در این هفته نوشتم.
مزایا:
- به خودم و خانوادهم بیشتر میرسم.
معایب:
- ترسناک بود که یه هفته ننویسم.
- فکر می کردم اگه یه هفته ننویسم، بعدش دیگه هیچ وقت نمی نویسم.
بعدش یه ذره عمیق تر به مزایا و معایب فکر کردم و دیدم که آیا واقعا درستن یا نه.
دلایل
چقدر طول می کشه یه مقاله بنویسم؟
تو طول هفته ۴ تا ۶ ساعت تیکه تیکه وقت گذاشتم.
چرا انقدر طول کشید؟ میشه تو نصف این زمان هم تمومش کرد؟
چرا ننوشتن مقاله بده؟
خبرنامه ام رو بیشتر از ۶ ماهه که دارم می گردونم. پس یه عادته و یه هفته ننوشتنش باعث نمیشه از بین بره.
۲. یه ضرب الاجل تعیین کنید
به خودم چالش دادم که زیر ۲ ساعت تمومش کنم.
تو یه هفته معمولی، یه ذره وقت میذارم و از بین یه عالمه موضوعی که تا حالا جمع کردم، یکی رو انتخاب می کنم.
این بار که مرحله ۱ رو انجام دادم، دیدم که موضوعش باید اورتینک باشه!
دو تا اتفاق احتمالی رو نوشتم:
اگه تو ۲ ساعت تمومش کنم: این هفته منتشرش می کنم. یالا! این اتفاق افتاد.
اگه تموم نشه: هفته بعدش منتشرش می کنم و میگم که چطوری تصمیم گرفتم و بهش پایبند موندم.
پس یه جورایی دو سر برد بود.
۳. توجه پیوسته
برای کار فکری مثل نوشتن مقاله، به تمرکز نیاز دارم. تو هفتههای معمولی، نوشتن خبرنامه رو تو هر بار وقت کمی که پیدا میکردم، جا میدادم (بعضی وقتا حتی ۱۰ دقیقه).
برای همین مدام بین موضوعات مختلف جابجا میشدم و تمرکزم رو از دست میدادم. این کار کلی اثر منفی داشت. مثلا:
تو زمان نوشتن، بین دو سه تا موضوع پرش میکردم.
قسمتهای سخت رو برای آخر نگه میداشتم.
برای این دفعه، تصمیم گرفتم که بیشتر از ۳ سشن نداشته باشم.
سشن ۱ - ۱ ساعت: نوشتن خلاصه و پیشنویس اولیه.
سشن ۲ - ۳۰ دقیقه: بازنویسی قسمتهای بد با دید تازه. ساخت دو تا تصویر.
سشن ۳ - ۳۰ دقیقه: ویرایش نهایی و اعمال تغییرات جزئی.
نتیجه نهایی خیلی به چیزی که تصمیم گرفته بودم نزدیک بود.
🖼 تصویر
۴. مراقب کمالگرایی باشید
کمالگرایی باعث فکر کردن بیش از حد میشه! پس باید خیلی مراقب باشیم که تو دام کمالگرایی نیفتیم.
برای نوشتن خبرنامه، یه حس خوبی پیدا کردم که چی به اندازه کافی خوبه در مقابل اینکه خیلی خوبه. اما هنوزم با مرز بین خیلی خوب و فوقالعاده عالی مشکل دارم. معیار برای این مقاله این بود که به سطح «به اندازه کافی خوب» برسه. اگه تو ۲ ساعت بهش میرسیدم منتشرش میکردم وگرنه یه هفته عقبش مینداختم.
🖼 تصویر
وقتی تازه کاری رو شروع میکنید، فهمیدن اینکه «به اندازه کافی خوب» یعنی چی میتونه سخت باشه. تو این مواقع، گرفتن فیدبک زودهنگام بهتون کمک میکنه خودتون رو مچ کنید.
۵. اولویتبندی کنید
وقتی زمان محدوده، باید با دقت ازش استفاده کنید تا روی کارایی که بیشترین ارزش رو داره تمرکز کنید.
برای این مورد، P0ها و P1هارو تعریف کردم.
اولویت P0 - باید انجام بشه.
پیام اصلی و ارزش برای خواننده واضح باشه. تو این مورد: پیام اصلی = مراحلی که برای توقف اورتینک انجام شده و شما میتونید برای مبارزه با اورتینک خودتون ازش استفاده کنید.
مقاله به راحتی قابل خوندن باشه.
مقدمه جذاب و نتیجهگیری واضح داشته باشه.
اولویت P1 - خوبه که داشته باشیم.
مقدمه قویتر.
نکات عملی قویتری که سناریوهای مختلف رو پوشش بده.
تو این مورد: به اشتراک گذاشتن مثال یه مهندس نرمافزار که اکثر شما میتونید باهاش ارتباط برقرار کنید.
تصاویری با استعاره. اینا باعث میشه خواننده بگه «آها!»
بهینهسازی سئو
یادداشت پایانی
اورتینک هم بد نیست. اگه راجع به چیزی بیش از حد فکر میکنم، یعنی برام مهمه. البته به شرطی که به موقع متوجه فکر کردن بیش از حدم بشم و کاری در موردش انجام بدم. برای همه شما که بیش از حد فکر میکنید، امیدوارم این مقاله نکات عملی رو باهاتون به اشتراک گذاشته باشه.
🆔 @MdDaily
👌10👍2🔥2🎉1
توی نسخه ی وب X بودم دیدم به گزینه های more آیتم جدیدی به اسم Jobs درحالت Beta اضافه شده که شما میتونید با جستجوی کلید واژه های مربوط به حوزه ی کاریتون (به عنوان نمونه من golang رو نوشتم) موقعیت های شغلی مربوطش رو براتون میاره و گزینه ی Apply هم داره. به نظر میرسه با حجم داده ای که روی X هست شاید به زودی بتونه تبدیل به رقیب لینکدین بشه.
🔗 https://twitter.com/jobs
🆔 @MdDaily
🔗 https://twitter.com/jobs
🆔 @MdDaily
⚡3🦄1
درس هایی راجب برنامه نویسی از زبان Matt Butcher
یادتون باشه هر خط کدی که مینویسین باید بعدا ازش پشتیبانی کنین!
این حرف خیلی معنی داره که تو ادامه میگم:
- برنامه نویسی به عنوان صنعتگری
- چرخ رو از اول اختراع نکن
- هزینه پیچیدگی
- کاهش نیازهای آینده برای نگهداری
- چرا خود آیندتون (و دیگران) قدردان کد امروزن
برنامه نویسی به عنوان صنعتگری
«صنعتگری» به معنی تعهد به یه حرفه است، جایی که مهارت با گذشت زمان و از طریق تلاش سخت و تمرین مداوم به وجود میاد. نوشتن کد، با تمام دیباگ و تست کردن و بازنویسیهاش، یه کار کاملاً عملیه. ساختن نرمافزار خوب به مهارت، دانش و تمایل مداوم برای پیشرفت نیاز داره. وقتی کد مینویسین، وقت بذارین که کارتون رو خوب انجام بدین. درسته که «کمالگرایی دشمنه» و باید کد بزنین که کارتون راه بیفته. اما رعایت اصول درست کد نویسی، اسمگذاری درست متغیرها و فکر کردن به مشکلی که دارین حل میکنین، همه اینا باعث میشه که نگهداری از کدتون تو دراز مدت راحتتر بشه.
پشتیبانی از کد ضعیف یه درده. اما نگهداری از کد خوب، از لحاظ فکری خیلی راضیکنندهست.
چرخ رو از اول اختراع نکن
یه کتابخونه یا ابزاری هست که کار رو راه میندازه، ولی خب، ما میتونیم بهتر انجامش بدیم!
فکر میکنم هر مهندس نرمافزاری حداقل یه بار این کار رو کرده و همیشه یه جور توجیه هم هست:
کتابخونههای دیگهای هم بودن، اما سنگین/پر از باگ/پیچیده/و …
یه راه جدید دارم که بقیه بهش فکر نکرده بودن.
انجام دادنش خودم بیشتر یاد می گیرم تا اینکه از کد بقیه استفاده کنم (حرفت درسته، اما با هزینهای خیلی بیشتر از اون چیزی که فکرشو میکردی).
تو همه این موارد، دو تا چیز نادیده گرفته میشن:
چقدر بقیه زمان صرف کرده بودن که قبلاً مشکل رو حل کنن. (پختگی اون کد)
منِ آینده چقدر باید وقت بذاره واسه درست کردن و نگهداری اون کد.
پس وقتی که ابزار آماده هست، اما فکر میکنین شاید خودتون بهتر انجامش بدین، از خودتون بپرسین چقدر برای نگهداری از اون کد تو چند سال آینده اشتیاق دارین؟ آیا استثناهایی برای این قضیه وجود داره؟ بله! اما اونم بعد از اینکه واقعاً بررسی کردین که آیا راهحلهای موجود به اندازه کافی برای انجام کار خوب هستن یا نه.
هر چی کدت پیچیدهتر، دیباگش سختتره
فرض کنید یه تابع می نویسید که یه عملیاتی رو انجام میده ولی کدش پیچیدس و حالا برای دفاع از خودتون میگید تست نوشتید. و کدتون ار نظر فرمت بینقص و خیلی خوب کار میکنه. بعد یه روز یه آسیبپذیری پیدا میشه. یه هکر بتونه تابعی که نوشید رو مجبور کنه که بیشتر از حافظهی سیستم، حافظه اختصاص بده. بعد از چند سال که اصلاً به این کد دست نزدید، باید درستش کنید. وقتی کد رو میخونید، انگار یه چیز کاملاً غریبس , باید بفهمید چطور میتونید اون باگ رو درست کنید.
شاید مجبور بشین خطهای بیشتری کد بنویسین (چون کارهای پیچیده رو به تابعهای کوچیکتر تقسیم میکنین)، اما اگه نتیجهش بشه کدی که دیباگ و نگهداریش راحتتره، ارزشش رو داره.
کاهش نیازهای آینده برای پشتیبانی
هر سیستم خوبی یه سری کنترل کیفیت داره. کد هم باید همینطور باشه. باید یه استراتژی برای تست نوشتن پیدا کنید،به هر حال، مهم نیست استراتژی شما چیه، اگه الان تست نکنین، بعداً باید دیباگ کنین.
خودت آیندت یادش نمیاد که خودت الانت به چی فکر میکرده
پس همهچی رو مستند کن! آدما یه جور پیشفرض عجیب دارن. فکر میکنیم که فردا همه چیزایی که امروز اتفاق افتاده رو یادمون میمونه. خود آیندهت جزئیات ریز اینکه چرا امروز این کد رو به این شکل نوشتی، یا چرا اون متغیر رو fhr اسم گذاشتی، یا چرا کامنت // FIXME later رو رو خط ۲۳۵ جا گذاشتی، یادش نمیاد.
بهترین راهی که میتونی با محدودیتهای حافظهت مقابله کنی اینه که کدت رو واضح بنویسی. این یعنی:
کامنت بذار.
اسمها رو خوب انتخاب کن.
مستندات خوب بنویس.
کامیتمسیجهای مفید بنویس.
خود آیندهت ازت ممنون میشه. یا حداقل از دستت عصبانی نمیشه.
نتیجه گیری: اگه بقیه نتونن اونو بفهمند، همیشه مشکل شما باقی میمونه
پس طوری مستندش کن که بقیه بتونن اونو بفهمند.
اگه کدتون راحتفهم نباشه، مثل یه کابوس برمیگرده سراغتون. چون بقیه نمیتونن اونو بفهمند. کدتون رو انقدر راحتفهم کنین که یه نفر دیگه بتونه اونو درست کنه بدون اینکه حتی نیاز باشه شما بفهمین!
نتیجه گیری
این قانون رو به عنوان یه راه برای ترغیب کردن خودتون به بهبود کدتون پیشنهاد میدم:
یادتون باشه هر خط کدی که مینویسین باید بعدا ازش پشتیبانی کنین!
این کار باعث صرفهجویی در زمان و انرژی شما در آینده میشه. باعث میشه همکاراتون عصبانی نشن. تغییر دادن کد امروز به کد فردا رو راحتتر میکنه. و به احتمال زیاد باعث میشه همه فکر کنن شما هم یکی از اون برنامهنویسهای فوق حرفهای هستین.
🆔 @MdDaily
یادتون باشه هر خط کدی که مینویسین باید بعدا ازش پشتیبانی کنین!
این حرف خیلی معنی داره که تو ادامه میگم:
- برنامه نویسی به عنوان صنعتگری
- چرخ رو از اول اختراع نکن
- هزینه پیچیدگی
- کاهش نیازهای آینده برای نگهداری
- چرا خود آیندتون (و دیگران) قدردان کد امروزن
برنامه نویسی به عنوان صنعتگری
«صنعتگری» به معنی تعهد به یه حرفه است، جایی که مهارت با گذشت زمان و از طریق تلاش سخت و تمرین مداوم به وجود میاد. نوشتن کد، با تمام دیباگ و تست کردن و بازنویسیهاش، یه کار کاملاً عملیه. ساختن نرمافزار خوب به مهارت، دانش و تمایل مداوم برای پیشرفت نیاز داره. وقتی کد مینویسین، وقت بذارین که کارتون رو خوب انجام بدین. درسته که «کمالگرایی دشمنه» و باید کد بزنین که کارتون راه بیفته. اما رعایت اصول درست کد نویسی، اسمگذاری درست متغیرها و فکر کردن به مشکلی که دارین حل میکنین، همه اینا باعث میشه که نگهداری از کدتون تو دراز مدت راحتتر بشه.
پشتیبانی از کد ضعیف یه درده. اما نگهداری از کد خوب، از لحاظ فکری خیلی راضیکنندهست.
چرخ رو از اول اختراع نکن
یه کتابخونه یا ابزاری هست که کار رو راه میندازه، ولی خب، ما میتونیم بهتر انجامش بدیم!
فکر میکنم هر مهندس نرمافزاری حداقل یه بار این کار رو کرده و همیشه یه جور توجیه هم هست:
کتابخونههای دیگهای هم بودن، اما سنگین/پر از باگ/پیچیده/و …
یه راه جدید دارم که بقیه بهش فکر نکرده بودن.
انجام دادنش خودم بیشتر یاد می گیرم تا اینکه از کد بقیه استفاده کنم (حرفت درسته، اما با هزینهای خیلی بیشتر از اون چیزی که فکرشو میکردی).
تو همه این موارد، دو تا چیز نادیده گرفته میشن:
چقدر بقیه زمان صرف کرده بودن که قبلاً مشکل رو حل کنن. (پختگی اون کد)
منِ آینده چقدر باید وقت بذاره واسه درست کردن و نگهداری اون کد.
پس وقتی که ابزار آماده هست، اما فکر میکنین شاید خودتون بهتر انجامش بدین، از خودتون بپرسین چقدر برای نگهداری از اون کد تو چند سال آینده اشتیاق دارین؟ آیا استثناهایی برای این قضیه وجود داره؟ بله! اما اونم بعد از اینکه واقعاً بررسی کردین که آیا راهحلهای موجود به اندازه کافی برای انجام کار خوب هستن یا نه.
هر چی کدت پیچیدهتر، دیباگش سختتره
فرض کنید یه تابع می نویسید که یه عملیاتی رو انجام میده ولی کدش پیچیدس و حالا برای دفاع از خودتون میگید تست نوشتید. و کدتون ار نظر فرمت بینقص و خیلی خوب کار میکنه. بعد یه روز یه آسیبپذیری پیدا میشه. یه هکر بتونه تابعی که نوشید رو مجبور کنه که بیشتر از حافظهی سیستم، حافظه اختصاص بده. بعد از چند سال که اصلاً به این کد دست نزدید، باید درستش کنید. وقتی کد رو میخونید، انگار یه چیز کاملاً غریبس , باید بفهمید چطور میتونید اون باگ رو درست کنید.
شاید مجبور بشین خطهای بیشتری کد بنویسین (چون کارهای پیچیده رو به تابعهای کوچیکتر تقسیم میکنین)، اما اگه نتیجهش بشه کدی که دیباگ و نگهداریش راحتتره، ارزشش رو داره.
کاهش نیازهای آینده برای پشتیبانی
هر سیستم خوبی یه سری کنترل کیفیت داره. کد هم باید همینطور باشه. باید یه استراتژی برای تست نوشتن پیدا کنید،به هر حال، مهم نیست استراتژی شما چیه، اگه الان تست نکنین، بعداً باید دیباگ کنین.
خودت آیندت یادش نمیاد که خودت الانت به چی فکر میکرده
پس همهچی رو مستند کن! آدما یه جور پیشفرض عجیب دارن. فکر میکنیم که فردا همه چیزایی که امروز اتفاق افتاده رو یادمون میمونه. خود آیندهت جزئیات ریز اینکه چرا امروز این کد رو به این شکل نوشتی، یا چرا اون متغیر رو fhr اسم گذاشتی، یا چرا کامنت // FIXME later رو رو خط ۲۳۵ جا گذاشتی، یادش نمیاد.
بهترین راهی که میتونی با محدودیتهای حافظهت مقابله کنی اینه که کدت رو واضح بنویسی. این یعنی:
کامنت بذار.
اسمها رو خوب انتخاب کن.
مستندات خوب بنویس.
کامیتمسیجهای مفید بنویس.
خود آیندهت ازت ممنون میشه. یا حداقل از دستت عصبانی نمیشه.
نتیجه گیری: اگه بقیه نتونن اونو بفهمند، همیشه مشکل شما باقی میمونه
پس طوری مستندش کن که بقیه بتونن اونو بفهمند.
اگه کدتون راحتفهم نباشه، مثل یه کابوس برمیگرده سراغتون. چون بقیه نمیتونن اونو بفهمند. کدتون رو انقدر راحتفهم کنین که یه نفر دیگه بتونه اونو درست کنه بدون اینکه حتی نیاز باشه شما بفهمین!
نتیجه گیری
این قانون رو به عنوان یه راه برای ترغیب کردن خودتون به بهبود کدتون پیشنهاد میدم:
یادتون باشه هر خط کدی که مینویسین باید بعدا ازش پشتیبانی کنین!
این کار باعث صرفهجویی در زمان و انرژی شما در آینده میشه. باعث میشه همکاراتون عصبانی نشن. تغییر دادن کد امروز به کد فردا رو راحتتر میکنه. و به احتمال زیاد باعث میشه همه فکر کنن شما هم یکی از اون برنامهنویسهای فوق حرفهای هستین.
🆔 @MdDaily
❤🔥2👍2✍1🔥1👏1
#ام_دی_کورس
سوال مصاحبه System Design: طراحی کوتاه کننده URL
ادامه در:
🔗 https://mddaily.web.app/blog/system-design-interview-question-design-url-shortener/
🆔 @MdDaily
سوال مصاحبه System Design: طراحی کوتاه کننده URL
یه سوال مصاحبه طراحی سیستم داریم که توش باید یه ابزار کوتاه کننده URL مثل TinyURL یا Bitly رو از صفر طراحی کنیم. همه چی رو از الزامات طراحی و معماری و طراحی اجزا تا اینکه چطور میشه سیستم رو برای سرعت بالا و امنیت بیشتر ارتقا داد، بررسی میکنیم.
اول از همه باید مشخص کنیم که این سیستم چیکار باید بکنه و چیکار نباید بکنه.
از نظر کارکردی، دو تا وظیفه اصلی داره:
وقتی یه URL بلند بهش میدی، باید یه URL کوتاه بسازه.
وقتی یه URL کوتاه بهش میدی، باید کاربر رو به URL بلند ببره.
برای این سرویس دو تا چیزه خیلی مهمه: اینکه کارش رو خیلی سریع انجام بده (پاسخهای کوتاه) و اینکه همیشه در دسترس باشه (همیشه آنلاین). میشه گفت اولویت با این دوتاست.
سوالات شفاف سازی برای مصاحبه کننده
اینجا چند تا .....
ادامه در:
🔗 https://mddaily.web.app/blog/system-design-interview-question-design-url-shortener/
🆔 @MdDaily
❤🔥5👍1🔥1
Md Daily
#ام_دی_کورس سوال مصاحبه System Design: طراحی کوتاه کننده URL یه سوال مصاحبه طراحی سیستم داریم که توش باید یه ابزار کوتاه کننده URL مثل TinyURL یا Bitly رو از صفر طراحی کنیم. همه چی رو از الزامات طراحی و معماری و طراحی اجزا تا اینکه چطور میشه سیستم رو برای…
توی این قسمت از ام دی کورس خیلی ساده و خلاصه به System Design یه کوتاه کننده لینک پرداخته شده و راجب مباحثی مثل معماری، انتخاب دیتابیس مناسب، لودبالانسر، کشینگ و... صحبت شده و مثل همیشه منابعی که استفاده کردمم آخر مقاله در دسترسن :)
❤🔥5👍1
هوش مصنوعی، یار یا جاسوس؟ نگاهی به Copilot+ PC و خطراتش برای حریم خصوصی
هوش مصنوعی تو این چند سال حسابی سر و صدا کرده و کلی چیزای جدید و باحال بهمون داده. اما یه چیز هست که تو این هیاهو گم شده: حریم خصوصی ما!
از زمانی که مایکروسافت برای ادغام ابزارهای مبتنی بر هوش مصنوعی تو محصولاتش با OpenAI همکاری کرد، به نوعی قدرت پیدا کرده و محبوب ترینشونم Copilot هست. این قضیه یه برگ برنده تو تبلیغات برای مایکروسافت شده و حالا یه خط جدید از کامپیوترها به اسم Copilot+ PC راه انداخته. شرکتهایی مثل دل، HP، لنوو و بقیه هم کلی لپتاپ و کامپیوتر جدید دارن که قراره با پردازندههای سری اسنپدراگون X و یه NPU داخلی برای هوش مصنوعی عرضه بشن.
ابزار Recall که توی رویداد معرفی شد. وقتی روشنه، هر چند ثانیه یک بار از صفحه اسکرینشات میگیره. بعد این اطلاعات رو ذخیره میکنه، یه جور تایملاین قابل اسکرول میده که برگردی عقب و ببینی قبلا داشتی چیکار میکردی. مایکروسافت میگه تمام اسکرینشاتهای گرفته شده با Recall روی خود دستگاه ذخیره و رمزنگاری میشن. حتی اگه چند نفر از یه ویندوز استفاده کنن، باز هم نمیتونن به اسکرینشاتهای Recall بقیه دسترسی پیدا کنن، مگه اینکه از یه حساب کاربری مشترک استفاده کنن. Recall همچنین از سشن های وبگردی InPrivate تو مایکروسافت اج اسکرینشات نمیگیره. (فعلا معلوم نیست این قابلیت برای مرورگرهای دیگه هم همینطور باشه). این قابلیت همچنین هیچکدوم از محتواهای محافظتشده با DRM رو ضبط نمیکنه، مثل محتواهای سرویسهای استریم آنلاین. اما یه نکتهی منفی دیگه هم داره. Recall اطلاعات حساس مثل رمز عبور، شمارهی حسابهای بانکی و غیره رو هم ضبط میکنه چون هیچ moderation محتوائیای روش نیست. نتیجش چی میشه؟ داده های دردسترس بیشتر از شما برای malicious actors یا خرابکار ها :)
🔗 ویدیوی معرفی Copilot+ PCs
خوشبختانه میشه Recall رو از تنظیمات غیرفعال کرد، اما طبق سوالات متداول توی صفحهی وبشون، به احتمال زیاد Recall وقتی برای اولین بار Copilot+ PC رو روشن میکنی به صورت پیشفرض فعاله.
مایکروسافت همچنین قصد داره این قابلیت رو تو یه بهروزرسانی ویندوز تو آیندهی نزدیک برای دستگاههایی که از پردازندهی اسنپدراگون استفاده نمیکنن هم بیاره. با توجه به اینکه این قابلیت نیاز به NPU داره، باید ببینیم چه سیستمهایی میتونن ازش استفاده کنن.
🔗 تصویر منابع مورد نیاز برای ai مایکروسافت
با توجه به سابقه ی مایکروسافت توی نقض حریم شخصی حتی اگه تمام پردازش برای Recall به صورت محلی انجام بشه، من هیچوقت نمیتونم اجازه بدم همچین ابزاری هر کاری که رو کامپیوترم میکنم رو کنترل کنه.
مایکروسافت لازمه که قابلیت هوش مصنوعی Recall رو متنباز کنه تا کاربرا بهش اعتماد کنن. اما اونا نمیتونن این کارو بکنن، درسته؟ مهمتر اینکه، وقتی پای غولهای تکنولوژی وسط باشه، هیچوقت نمیدونی کی شرایط استفاده یا سیاستهای حفظ حریم خصوصیشون رو عوض میکنن. و وقتی این کارو بکنن، ازت انتظار میره یا باهاش کنار بیای یا کلا از سرویسشون استفاده نکنی.
به هر حال، اگه کنجکاو شدین، Copilot+ PC چند تا قابلیت دیگه هم داره. یکیش زیرنویس زندهی صدا و تصویر به انگلیسی از بیش از ۴۰ زبانه، یه قابلیت به اسم Cocreator که از نوشته یا شکلهایی که بهش میدید استفاده میکنه تا هرچیزی که مشخص کردید رو تفسیر کنه و نشونتون بده. یه قابلیت دیگه به اسم Auto Super Resolution که نرخ فریم (FPS) رو تو بازیها بالا میبره، و یه قابلیت به اسم Windows Studio Effects برای تماسهای تصویری.
خلاصه که هوش مصنوعی یه چیز خوبه و میتونه خیلی بهمون کمک کنه. ولی با توجه به انحصار های بوجود اومده چه قدر حریم شخصیمون در آینده به خطر میوفته. نظر شما چیه؟
🆔 @MdDaily
هوش مصنوعی تو این چند سال حسابی سر و صدا کرده و کلی چیزای جدید و باحال بهمون داده. اما یه چیز هست که تو این هیاهو گم شده: حریم خصوصی ما!
از زمانی که مایکروسافت برای ادغام ابزارهای مبتنی بر هوش مصنوعی تو محصولاتش با OpenAI همکاری کرد، به نوعی قدرت پیدا کرده و محبوب ترینشونم Copilot هست. این قضیه یه برگ برنده تو تبلیغات برای مایکروسافت شده و حالا یه خط جدید از کامپیوترها به اسم Copilot+ PC راه انداخته. شرکتهایی مثل دل، HP، لنوو و بقیه هم کلی لپتاپ و کامپیوتر جدید دارن که قراره با پردازندههای سری اسنپدراگون X و یه NPU داخلی برای هوش مصنوعی عرضه بشن.
ابزار Recall که توی رویداد معرفی شد. وقتی روشنه، هر چند ثانیه یک بار از صفحه اسکرینشات میگیره. بعد این اطلاعات رو ذخیره میکنه، یه جور تایملاین قابل اسکرول میده که برگردی عقب و ببینی قبلا داشتی چیکار میکردی. مایکروسافت میگه تمام اسکرینشاتهای گرفته شده با Recall روی خود دستگاه ذخیره و رمزنگاری میشن. حتی اگه چند نفر از یه ویندوز استفاده کنن، باز هم نمیتونن به اسکرینشاتهای Recall بقیه دسترسی پیدا کنن، مگه اینکه از یه حساب کاربری مشترک استفاده کنن. Recall همچنین از سشن های وبگردی InPrivate تو مایکروسافت اج اسکرینشات نمیگیره. (فعلا معلوم نیست این قابلیت برای مرورگرهای دیگه هم همینطور باشه). این قابلیت همچنین هیچکدوم از محتواهای محافظتشده با DRM رو ضبط نمیکنه، مثل محتواهای سرویسهای استریم آنلاین. اما یه نکتهی منفی دیگه هم داره. Recall اطلاعات حساس مثل رمز عبور، شمارهی حسابهای بانکی و غیره رو هم ضبط میکنه چون هیچ moderation محتوائیای روش نیست. نتیجش چی میشه؟ داده های دردسترس بیشتر از شما برای malicious actors یا خرابکار ها :)
🔗 ویدیوی معرفی Copilot+ PCs
خوشبختانه میشه Recall رو از تنظیمات غیرفعال کرد، اما طبق سوالات متداول توی صفحهی وبشون، به احتمال زیاد Recall وقتی برای اولین بار Copilot+ PC رو روشن میکنی به صورت پیشفرض فعاله.
مایکروسافت همچنین قصد داره این قابلیت رو تو یه بهروزرسانی ویندوز تو آیندهی نزدیک برای دستگاههایی که از پردازندهی اسنپدراگون استفاده نمیکنن هم بیاره. با توجه به اینکه این قابلیت نیاز به NPU داره، باید ببینیم چه سیستمهایی میتونن ازش استفاده کنن.
🔗 تصویر منابع مورد نیاز برای ai مایکروسافت
با توجه به سابقه ی مایکروسافت توی نقض حریم شخصی حتی اگه تمام پردازش برای Recall به صورت محلی انجام بشه، من هیچوقت نمیتونم اجازه بدم همچین ابزاری هر کاری که رو کامپیوترم میکنم رو کنترل کنه.
مایکروسافت لازمه که قابلیت هوش مصنوعی Recall رو متنباز کنه تا کاربرا بهش اعتماد کنن. اما اونا نمیتونن این کارو بکنن، درسته؟ مهمتر اینکه، وقتی پای غولهای تکنولوژی وسط باشه، هیچوقت نمیدونی کی شرایط استفاده یا سیاستهای حفظ حریم خصوصیشون رو عوض میکنن. و وقتی این کارو بکنن، ازت انتظار میره یا باهاش کنار بیای یا کلا از سرویسشون استفاده نکنی.
به هر حال، اگه کنجکاو شدین، Copilot+ PC چند تا قابلیت دیگه هم داره. یکیش زیرنویس زندهی صدا و تصویر به انگلیسی از بیش از ۴۰ زبانه، یه قابلیت به اسم Cocreator که از نوشته یا شکلهایی که بهش میدید استفاده میکنه تا هرچیزی که مشخص کردید رو تفسیر کنه و نشونتون بده. یه قابلیت دیگه به اسم Auto Super Resolution که نرخ فریم (FPS) رو تو بازیها بالا میبره، و یه قابلیت به اسم Windows Studio Effects برای تماسهای تصویری.
خلاصه که هوش مصنوعی یه چیز خوبه و میتونه خیلی بهمون کمک کنه. ولی با توجه به انحصار های بوجود اومده چه قدر حریم شخصیمون در آینده به خطر میوفته. نظر شما چیه؟
🆔 @MdDaily
👍6
کوپایلت برای تلگرام ربات رسمی داده :)
ولی نیاز به تایید شماره داره که متاسفانه فعلا برای شماره های ایرانی دردسترس نیست
🔗 آدرس ربات: @CopilotOfficialBot
🔗 آدرس معرفی تو سایت مایکروسافت:
https://www.microsoft.com/en-us/edge/copilot-for-social?form=MY02F9&ch=1
🆔 @MdDaily
ولی نیاز به تایید شماره داره که متاسفانه فعلا برای شماره های ایرانی دردسترس نیست
🔗 آدرس ربات: @CopilotOfficialBot
🔗 آدرس معرفی تو سایت مایکروسافت:
https://www.microsoft.com/en-us/edge/copilot-for-social?form=MY02F9&ch=1
🆔 @MdDaily
😁5❤🔥1👍1🥰1
من معمولا از پلتفرم های دیگه مطلب توی کانال نمیذارم ولی این یکی خیلی خوب بود :)
متیو کریمی توی یک رشته پست توئیتری اومده بود چیزایی که ازش درآمد داشته رو رایگان به اشتراک گذاشته مثل دوره های آموزشیش.
لینک دورهها:
جعبه ابزار بیزنس: https://eseminar.tv/wb13299
هزار و یک محتوا: https://eseminar.tv/wb10114
نکات کلیدی راهاندازی کسبوکار: https://eseminar.tv/wb14110
چاپ و بازاریابی و فروش کتاب: https://eseminar.tv/wb14193
موفقیت با طعم قهوه: https://eseminar.tv/wb15086
چگونه دوره آموزشی بسازیم: https://eseminar.tv/wb18476
راهکار افزایش فروش در ایران: https://eseminar.tv/wb29985
تسلط بر فریبکاری: https://eseminar.tv/wb114608
🎁 کد تخفیف:
و آخر توئیتشون گفتند:
</متیو کریمی>
🆔 @MdDaily
متیو کریمی توی یک رشته پست توئیتری اومده بود چیزایی که ازش درآمد داشته رو رایگان به اشتراک گذاشته مثل دوره های آموزشیش.
لینک دورهها:
جعبه ابزار بیزنس: https://eseminar.tv/wb13299
هزار و یک محتوا: https://eseminar.tv/wb10114
نکات کلیدی راهاندازی کسبوکار: https://eseminar.tv/wb14110
چاپ و بازاریابی و فروش کتاب: https://eseminar.tv/wb14193
موفقیت با طعم قهوه: https://eseminar.tv/wb15086
چگونه دوره آموزشی بسازیم: https://eseminar.tv/wb18476
راهکار افزایش فروش در ایران: https://eseminar.tv/wb29985
تسلط بر فریبکاری: https://eseminar.tv/wb114608
🎁 کد تخفیف:
freeiranaccess2024و آخر توئیتشون گفتند:
🖤 فقط یه خواهشی دارم اگر استفاده کردین برای عمه مرحومم که به خاطر کرونا فوت کرد دعا کنید اگر به دعا و انرژٓی مثبتتون اعتقاد دارین.
</متیو کریمی>
🆔 @MdDaily
👍7👎1😁1🗿1
چند Best Practice در طراحی REST API
امروزه که همه چی به هم وصله، REST APIs با طراحی خوب، پایه و اساس برنامههای کاربردی کارآمد و قابل ارتقا هستن.
نوشتن دیزاین های REST API تمیز به چند دلیل خیلی مهمه:
استفاده راحتتر: یه API با طراحی خوب، کاربرپسند و سادست، و برای توسعهدهندهها با هر سطحی قابل استفادهست. اینجوری دیگه نیازی به صرف زمان زیاد برای یادگیری نیست.
نگهداری راحتتر: کد تمیز، نگهداری رو راحتتر میکنه. با این کار پیدا کردن و رفع اشکال، اضافه کردن قابلیتهای جدید و ارتقای API سادهتر و هزینههای توسعه هم کم میشه.
کاهش زمان توسعه: با مشخصات API دقیق و مستندات شفاف، میشه خیلی سریعتر برنامهنویسی کرد چون دیگه نیازی به حدس و گمان و تستهای مفصل نیست. اینجوری هم در زمان و هم در منابع صرفهجویی میشه.
مقیاسپذیری بیشتر: یه طراحی تمیز، با ارائه یه معماری ماژولار که به راحتی قابل گسترشه، امکان مقیاسپذیری راحت رو فراهم میکنه. اینجوری API میتونه با نیازهای برنامه شما رشد کنه و مشکلی پیش نیاد.
استفاده مجدد بیشتر: یه API با طراحی خوب رو میشه تو چند برنامه دیگه هم استفاده کرد، اینجوری دیگه نیازی به تکرار کار نیست و همه چی منظمتر میشه. اینجوری توسعه برنامهها سادهتر میشه و در زمان و تلاش هم صرفهجویی میشه.
مستندات بهتر: طراحیهای تمیز، مستندسازی رو هم سادهتر میکنن و نحوه کارکرد API و نحوه استفاده درست ازش رو به طور کامل برای برنامهنویسها توضیح میدن. اینجوری همه چی شفاف میشه و استفاده از API هم راحتتر میشه.
رولز ها یا قوانین URI
ساختار یه URI به شکل زیره:
مثال:
تو دنیای URI دو نوع منبع (resource) داریم:
منابع مجموعه (Collection resources): این نوع منبع، مجموعهای از منابع دیگه رو در خودش داره. میشه اون رو به یه جدول تو دیتابیس تشبیه کرد. مثلا میشه یه منبع مجموعه به اسم users داشته باشیم که لیستی از تمام کاربرها رو در خودش داره.
منابع تکی (Singleton resources): این نوع منبع، فقط شامل یه منبع واحده. میشه اون رو به یه رکورد تو دیتابیس تشبیه کرد. مثلا میشه یه منبع تکی به اسم users/123 داشته باشیم که اطلاعات مربوط به یه کاربر خاص با شناسه ۱۲۳ رو نشون بده
نکات مهم طراحی Rest Api
۱. منابع Collection باید جمع (plural) باشن :
۲. منابع Singleton باید مفرد (singular) باشن و با شناسه یکتاشون (unique id) جایگزین بشن:
فرض کن میخوای اطلاعات یه بازیکن خاص رو نمایش بدی، بجای استفاده از players/Ronaldo بهتره از شناسه عددی یا کد اون بازیکن استفاده کنی، مثلا players/12345.
۴. برای بهتر خونده شدن، از خط تیره (-) به جای زیرخط (_) استفاده کنید:
۵. تو مسیرهای URI از حروف کوچک استفاده کنید:
۶. تو URI ها از پسوند فایل استفاده نکنید:
۷. از اسم فانکشن های CRUD تو URI استفاده نکنید:
برای عملیات ایجاد، خواندن، بروزرسانی و حذف منابع، از اسم هایی مثل create, read, update, delete تو URI استفاده نکن. بجاش از Http Method های استاندارد استفاده کن.
۸. بخش کوئری (query) تو URI فقط برای منابع Collection قابل استفاده است:
۹. از بخش کوئری برای اسکرول (paging) کردن نتایج منابع مجموعه استفاده کنید:
نسخه بندی API برای موارد زیر اهمیت داره:
حفظ سازگاری قبلی (Maintaining backward compatibility)
تضمین یک API سازگار و با طراحی خوب: استفاده از نامگذاریهای یکسان تو همه نسخهها به یه تجربه کاربری خوب کمک میکنه. تغییر endpoint این تجربه رو بهم میریزه و نسخه بندی به جلوگیری از این موضوع کمک میکنه.
چند استراتزی برای نسخه بندی API:
URI Versioning (پیشنهادی):
Header Versioning:
🆔 @MdDaily
امروزه که همه چی به هم وصله، REST APIs با طراحی خوب، پایه و اساس برنامههای کاربردی کارآمد و قابل ارتقا هستن.
نوشتن دیزاین های REST API تمیز به چند دلیل خیلی مهمه:
استفاده راحتتر: یه API با طراحی خوب، کاربرپسند و سادست، و برای توسعهدهندهها با هر سطحی قابل استفادهست. اینجوری دیگه نیازی به صرف زمان زیاد برای یادگیری نیست.
نگهداری راحتتر: کد تمیز، نگهداری رو راحتتر میکنه. با این کار پیدا کردن و رفع اشکال، اضافه کردن قابلیتهای جدید و ارتقای API سادهتر و هزینههای توسعه هم کم میشه.
کاهش زمان توسعه: با مشخصات API دقیق و مستندات شفاف، میشه خیلی سریعتر برنامهنویسی کرد چون دیگه نیازی به حدس و گمان و تستهای مفصل نیست. اینجوری هم در زمان و هم در منابع صرفهجویی میشه.
مقیاسپذیری بیشتر: یه طراحی تمیز، با ارائه یه معماری ماژولار که به راحتی قابل گسترشه، امکان مقیاسپذیری راحت رو فراهم میکنه. اینجوری API میتونه با نیازهای برنامه شما رشد کنه و مشکلی پیش نیاد.
استفاده مجدد بیشتر: یه API با طراحی خوب رو میشه تو چند برنامه دیگه هم استفاده کرد، اینجوری دیگه نیازی به تکرار کار نیست و همه چی منظمتر میشه. اینجوری توسعه برنامهها سادهتر میشه و در زمان و تلاش هم صرفهجویی میشه.
مستندات بهتر: طراحیهای تمیز، مستندسازی رو هم سادهتر میکنن و نحوه کارکرد API و نحوه استفاده درست ازش رو به طور کامل برای برنامهنویسها توضیح میدن. اینجوری همه چی شفاف میشه و استفاده از API هم راحتتر میشه.
رولز ها یا قوانین URI
ساختار یه URI به شکل زیره:
scheme :// authority / path [?query][#fragment]
مثال:
https://soccer.api.org/teams/dortmund/players?name=Rona#2
تو دنیای URI دو نوع منبع (resource) داریم:
منابع مجموعه (Collection resources): این نوع منبع، مجموعهای از منابع دیگه رو در خودش داره. میشه اون رو به یه جدول تو دیتابیس تشبیه کرد. مثلا میشه یه منبع مجموعه به اسم users داشته باشیم که لیستی از تمام کاربرها رو در خودش داره.
منابع تکی (Singleton resources): این نوع منبع، فقط شامل یه منبع واحده. میشه اون رو به یه رکورد تو دیتابیس تشبیه کرد. مثلا میشه یه منبع تکی به اسم users/123 داشته باشیم که اطلاعات مربوط به یه کاربر خاص با شناسه ۱۲۳ رو نشون بده
نکات مهم طراحی Rest Api
۱. منابع Collection باید جمع (plural) باشن :
✅ soccer.api.org/teams/dortmond
❌ soccer.api.org/team/dortmond
۲. منابع Singleton باید مفرد (singular) باشن و با شناسه یکتاشون (unique id) جایگزین بشن:
فرض کن میخوای اطلاعات یه بازیکن خاص رو نمایش بدی، بجای استفاده از players/Ronaldo بهتره از شناسه عددی یا کد اون بازیکن استفاده کنی، مثلا players/12345.
✅ soccer.api.org/teams/dortmond/players/58c1aaae-205a-11ef-aeea-a64c74618950۳. اسلش ته آدرس رو حذف کنید:
✅ soccer.api.org/teams/dortmond/players
❌ soccer.api.org/teams/dortmond/players/
۴. برای بهتر خونده شدن، از خط تیره (-) به جای زیرخط (_) استفاده کنید:
✅ api.blog.com/blogs/this-is-my-blog
❌ api.blog.com/blogs/this_is_my_blog
۵. تو مسیرهای URI از حروف کوچک استفاده کنید:
✅ api.example.com/my-api/my-resource
❌ api.example.com/My-Api/My-Resource
۶. تو URI ها از پسوند فایل استفاده نکنید:
✅ api.example.com/api/resource
❌ api.example.com/api/resource.json
۷. از اسم فانکشن های CRUD تو URI استفاده نکنید:
برای عملیات ایجاد، خواندن، بروزرسانی و حذف منابع، از اسم هایی مثل create, read, update, delete تو URI استفاده نکن. بجاش از Http Method های استاندارد استفاده کن.
✅ DELETE api.example.com/api/resource
❌ GET api.example.com/api.resource/delete
✅ GET /users
❌ GET /getUsers
۸. بخش کوئری (query) تو URI فقط برای منابع Collection قابل استفاده است:
✅ GET /users?role=admin
❌ GET /users/admin
۹. از بخش کوئری برای اسکرول (paging) کردن نتایج منابع مجموعه استفاده کنید:
✅ GET /users?pageSize=25&pageStartIndex=50نسخه بندی API (Versioning)
نسخه بندی API برای موارد زیر اهمیت داره:
حفظ سازگاری قبلی (Maintaining backward compatibility)
تضمین یک API سازگار و با طراحی خوب: استفاده از نامگذاریهای یکسان تو همه نسخهها به یه تجربه کاربری خوب کمک میکنه. تغییر endpoint این تجربه رو بهم میریزه و نسخه بندی به جلوگیری از این موضوع کمک میکنه.
چند استراتزی برای نسخه بندی API:
URI Versioning (پیشنهادی):
✅ GET /api/v1/users
✅ GET /api/v2/users
Header Versioning:
✅ GET /api/users
Headers: { "X-API-Version": "1" }
✅ GET /api/users
Headers: { "X-API-Version": "2" }🆔 @MdDaily
👍6🔥3❤1
توی گیت هاب CSS injection پیدا کردن :)
🔗 لینک توییت
برای تستش این پروفایل و ریپو های گیت هاب رو ببیند:
https://github.com/yacineMTB
https://github.com/vmfunc/vmfunc
https://github.com/RambIing
آپدیت: فعلا باگش فیکس شده ولی توی کامنت توییت اسکرین شات هاشون هست :)
🆔 @MdDaily
🔗 لینک توییت
برای تستش این پروفایل و ریپو های گیت هاب رو ببیند:
https://github.com/yacineMTB
https://github.com/vmfunc/vmfunc
https://github.com/RambIing
آپدیت: فعلا باگش فیکس شده ولی توی کامنت توییت اسکرین شات هاشون هست :)
🆔 @MdDaily
😁7