🔥کوئیز Rest

❌گزینه ی ۱ طبق استاندارد های رست درست نیست چون که متد PUT برای replace کردن کل resource بکار میره و نه آپدیت جزئی اون.

❌گزینه ۳ و ۴ درست نیستن چون تبدیل به RPC شدن، همچنین گزینه ۳ آپدیت جزئی ریسورس رو با PUT هندل کرده.

✅گزینه ۲ طبق استاندارد های رست درست هست، آپدیت جزئی ریسورس و استفاده از PATCH

✅گزینه ۵ درست هست چون اینجا ریسورس رو محدود کردیم و کلش رو با PUT جایگزین(replace) کردیم.

✅گزینه ۶ میتونه درست باشه ولی ۵ نسبت به ۶ بهتره چون کل ریسورس رو داره replace میکنه و مفهوم رو بهتر میرسونه.

❓بین گزینه ۲ و ۵ کدوم یک بهتر هستن؟

❓هر دو از نظر استاندارد های رست درستن ولی از زاویه دید دیزاین کدوم شون بهتره؟

✅بستگی به شرایط داره.

@purecoder_ir

🔥این ویدیو مربوط به سال 2016 ( احتمالن قبل از معرفی شدن رسمی فلاتر) هست که یکی از توسعه دهنده های فلاتر نکات خیلی خوبی رو در مورد فلاتر بیان میکنه.

این ویدیو رو سال 1400 دیدم و اولش تقریبن هیچی ازش نفهمیدم تا این که بعدش سورس کد فلاتر رو خوندم و بعدش متوجه شدم چی میگه...😅😅

حتمن ببینینش...

https://www.youtube.com/watch?v=UUfXWzp0-DU&t=100s

@purecoder_ir

وقتی رویگرد های و متدولوژی های مختلف توی مهندسی نرم افزار رو میبنیم و حتا وقتی که خیلی توی اسکیل کوچیتکتر نگاه میکنیم و پترن های حیلی کوچولو که برای حل problem های کوچیک طراحی شدن رو میبینیم یه وجه مشترک توی همشون وجود داره و اون این هست که اکثرن از نظریه Divide and Conquer استفاده کردن.

@PureCoder_ir

🔥چالش طراحی API

❓یه دونه کلاس Order به صورت زیر داریم:

class Order{

  List<OrderLine> _lines = [];

  void AddProduct(Product product, int quantity){

  }

}

class OrderLine{

  final Product product;
  final int quantity;
}

class Product{
  final String name;
}

حالا میخوایم یه API برای اضافه کردن یه ایتم جدید (item یا Line) به Order طراحی کنیم.

بنظرت کدوم یک از API های زیر بهتره؟

1️⃣

POST: api/orders/{id}
body
{
     product: 1,
     quantity: 4
}

2️⃣

PATCH: api/orders/{id}
body
{
     product: 1,
     quantity: 4
}

3️⃣

POST: api/orders/{id}/lines
body
{
     product: 1,
     quantity: 4
}

4️⃣

PUT: api/orders/{id}/lines
body
{
     product: 1,
     quantity: 4
}

@purecoder_ir

✨Redux

@purecoder_ir

❓به نظرت کامیت های گیت رو بهتره با فعل گذشته بزنیم یا فعل امری ؟

1️⃣حالت اول: فعل گذشته

👉new feature added

2️⃣حالت دوم: فعل امری

👉add new feature

✅توی حالت اول داریم به یه fact ای که اتفاق افتاده اشاره میکنیم و توی حالت دوم مدل ادبیات به گونه ای هست که داریم یه کامند یا دستور رو صادر میکنیم.

❓خارج از بحث استانداردهایی که بعضی ها تعیین کردن و ماهم احتمالن بدون چون و چرا پذیرفتیم و طبق همون ها جلو رفتیم، به نظرت از بین ۲ استایل بالا کدوم یکی بهتره؟

لطفن توی نظر سنجی زیر شرکت کن و اگه توضیحی داری میتونی نظرت رو این پایین بگی...👇

@purecoder_ir

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

هم الکی اموزشش رو 20 ساعت کش نمیده و توی 5 ساعت جمعش میکنه و هم خیلی مختصر و مفید اون چیزی رو که باید میگه...

مکسیمیلیان که رسمن مثل قرص خواب هست و برای وقتایی که بی خوابی زده به کلت خوبه😂😂😂

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

@purecoder_ir

✅OSI Model
✅Layered Architecture

@purecoder_ir

✅Flutter Framework
✅Layered Architecture

@purecoder_ir

⛔️🙅‍♂🙅‍♀تفکر باینری

ما برنامه نویس ها کدهامون در نهایت به صورت باینری توسط ماشین ترجمه و تفسیر میشه، ولی خودمون نباید باینری فکر کنیم.

تفکر و تحلیل صفر و یکی خیلی مواقع خطرناک میشه.

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

@purecoder_ir

⛔️🙅‍♂🙅‍♀تفکر باینری

یکی از جاهایی که تفکر باینری گریبان ما رو میگیره اینه که توی بیشتر موقعیت ها به دنبال best practice ها و bad practice ها میگردیم که best رو انجام بدیم و از bad ها اجتناب کنیم. یا دنبال یه شابلون میگردیم که بهمون بدن و ازش همه جا استفاده کنیم و طبق اون کد بزنیم.

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

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

چی میشه که وقتی به دنیای نرم افزار قدم میگذاریم به یک باره تغییر مسیر میدیم و میخوایم همه چیز رو صفر و یک ببینیم و best و bad ها رو با یه خط مرزی کاملن مشخص تفکیک کنیم؟

واقعیت اینه که بیشترین چیزی که باید به دنبالش باشیم trade off و تصمیم گیری بر اساس شرایط هست.

بیشتر از تمرکز بر best practice ها و bad practice ها و تکرارشون توی کد و دیزاین، باید دلایل پشت راه حل های مختلف رو بدونیم و به جای اینکه برای هر problem فقط یه راه حل توی جیبمون داشته باشیم و بقیه راه حل ها رو بکوبیم، باید بتونیم بهترین رو با بررسی همه ی جوانب انتخاب کنیم.

@purecoder_ir

آدم وقتی یه تکنیک، پترن، یا کلن هرچیزی رو به خوبی درک میکنه که بفهمه کجاها نباید ازش استفاده کنه...

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

@purecoder_ir

خب درصد خوبی از دوستان درست گفتن که خوشحال کننده هست.

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

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

معمولن توی پیاده سازی این مکانیزم پترن هایی مثل کامند هم در کنار اسنپ شات وارد میشن تا کار رو تکمیل کنن.

@purecoder_ir

✂️تخفیف ویژه دوره Fluttery's Journey

😍دوستان عزیز از الان تا پایان عید نوروز تخفیف ویژه ۵۵ درصدی روی دوره فلاتر داریم

🔥۱۰ فصل دوره تکمیل شده که میتونی توی تصویر بالا ببینی...

🔗توضیحات دوره رو از لینک زیر ببین👇

https://purecoder.ir/course/flutterys-journey/

🆔️برای مشاوره یا ثبت نام هم میتونی به پشتبانی پیام بدی👇

@purecoder_support

🟢موضوع دوره: بک گراند فلاتر
💰هزينه دوره: ۲ میلیون
✂️هزینه با تخفیف ۵۵ درصد: ۹۰۰

تخفیف تا پایان عید نوروز فعال هست.