❓چالش

یه دونه account داریم که میتونه activate و deactivate بشه

حالا میخوایم یه rest api برای activate و deactivate کردنش طراحی کنیم

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

1⃣

PUT
api/accounts/{id}

Body :
{
      isActive: true
}

2⃣

PATCH 
api/accounts/{id}

Body :
{
      isActive: true
}

3⃣

PUT
1) api/accounts/{id}/activate
2)api/accounts/{id}/deactivate 

4⃣

PATCH 
1) api/accounts/{id}/activate
2)api/accounts/{id}/deactivate 

5⃣

PUT
api/accounts/{id}/status

Body :
{
      isActive: true
}

6⃣

PATCH 
api/accounts/{id}/status

Body :
{
      isActive: true
}

@purecoder_ir

🔥فصل Render Tree و Layer Tree در حال پیشرویه

خیلی مفصله و حالا حالا ها ادامه داره😍

🔗لینک دوره:
https://purecoder.ir/course/flutterys-journey/

ثبت نام:
🆔@PureCoder_Support

🔥کوئیز 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

🧨Single Responsibility 🔥
🧨Seperation of Concerns🔥

❌استفاده از attribute ها برای موضوع dependency injection و قرار دادن attribute ها بالای سر کلاس ها, معمولن باعث نقض اصل Single Responsibility و Seperation of Concerns میشه ...

✅ دانش wire up کردن و بقیه موضوعات مربوط به dependency injection بهتره که یک جا جمع و متمرکز بشه و استفاده از attribute ها معمولن trade off خوبی در مقابل متمرکز بودنش نیست.

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

@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

✅گزینه ی ۳ درسته که اکثرن هم همون رو انتخاب کردن.

❓حالا اگه بخوای همین رو با GraphQL طراحی کنی، چی میزنی؟

توی کامنت بگو👇

پ.ن: فرقی نمیکنه فرانت کار کنی یا بکند، این موارد دانش عمومی هست که برای همه لازمه.

@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