تصور اینکه ۶۰ سال پیش کدها شون رو روی یه سری punched card هک میکردن و هر پروژه ای شامل یه عالمه از این punched card ها بوده و سورس کد یه پروژه رو (ینی این کارت ها رو) توی کابینت یا کشو نگه میداشتن، و در کمتر از ۶۰ سال به این نقطه رسیدیم خیلی سخته‌‌‌.

(هر کارت یه خط برنامه رو در برمیگرفته و هر برنامه شامل تعداد خیلی زیادی از این کارت ها بوده که با یه دونه کش به هم میبستنشون تا گم و گور نشن.🤣 یعنی برنامت از نظر فیزیکی وزن زیادی داشته و برای حملش باید یه کامیون میگرفتی😂 )

فرض کن این کارت ها که هر کدوم شامل یه خط برنامه بودن از دستت ول میشدن و ترتیب کدها به هم میریخت.😂😂🤦‍♂🤦‍♂

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

جهان نرم افزار ترسناکه!!!

@purecoder_ir

قبل از Git سورس کنترل های مهم مثل subversion بر اساس ایده ی central repository کار میکردن. یه ریپوزیتوری مرکزی بود که همه بهش وصل میشدن.

ولی گیت ایده ی Distributed Source Control رو مطرح کرد.

یعنی قبلن اگه ۱۰۰ نفر روی یک پروژه کار میکردن، یه ریپوزیتوری مرکزی روی cloud بود که همه باید بهش متصل میشدن و روش کار میکردن و اون ریپو بود که نسخه ی معتبر پروژه بود.

قبل از subversion حتا cloud هم خیلی مطرح نبود.

ولی توی دنیای گیت اگه ۱۰۰ نفر روی یک پروژه کار کنن، همشون یه نسخه ی لوکال یا محلی برای خودشون دارن و همه ی این نسخه ها هم نسخه های معتبر پروژه هستن. درسته که یه ریپوزیتوری روی cloud هست. ولی این ریپو کمک میکنه که نسخه های لوکال به طور پیوسته باهم سینک یا همگام یشن. این به این معنی نیست که ا‌ون ریپویی که روی cloud هست از درجه ی اعتبار بالاتری نسبت به نسخه ی لوکال برخورداره. تمام نسخه هایی که توی تمام ماشین ها اجرا میشن از یک درجه ی اعتبار برخوردارن.

و این میشه ایده ی Distributed Source Control.

@purecoder_ir

برنامه نویس ها علاقه ی زیادی به reuse کردن کد دارن.

این علاقه باعث میشه که خیلی وقت ها دنبال این باشن که چند تا مفهوم (concept) رو generalize کنن و ازش یه base class تولید کنن که یه کدی رو به اشتراک میگذاره و بقیه کلاس ها ازش ارث بری میکنن ... .

خیلی وقت ها خیلی عجله میکنن و قبل از اینکه خود اون concept ها رو implement کرده باشن میخوان به زور ازش یه base class در بیارن. یعنی اول base class تولید میشه ‌ و بعد ... .

این عجله بیشتر وقت ها نتیجه ی خوبی نداره.

ابتدا باید هر concept به صورت جداگانه پیاده سازی بشه. صبر و تحمل به خرج بدیم و اجازه بدیم و اجازه بدیم و اجازه بدیم که اگه duplication واقعی بوجود اومد، اون موقع از قوه ی generilazation خودمون استفاده کنیم و یه base class استخراج کنیم.

ریفکتورینگ ابداع شده تا بتونیم صبور باشیم و هر کاری رو به موقع انجام بدیم و نه زودتر از موعدش.

@purecoder_ir

🔥Configurations in .NET

توی دات نت میتونیم تنظیمات برنامه رو توی سطوح مختلف به برنامه پاس بدیم.

1️⃣appsettings.json
2️⃣appsettings.[Environment].json
👉appsettings.Development.json
👉appsettings.Production.json
3️⃣OS Environment variables
4️⃣Command Line Args

1️⃣پایین ترین سطح appsettings.json هست.

2️⃣بعد از اون تنظیمات مربوط به environment خاص هست. مثل
👉appsettings.Development.json
👉appsettings.Production.json

تنطیماتی که اینجا قرار میگیرن, تنظیمات appsettings.json رو در صورت تداخل اوراید میکنن.

3️⃣سطح بعدی قرار دادن تنظیمات توی environment variable های سیستم عامل هست که این ها هم تنظیمات دو سطح قبلی رو در صورت تداخل اوراید میکنن.
اینجا میتونیم تظیمات رو با استفاده از env var هایی که روی سیستم عامل یا داکر کانتینر ست میکنیم اعمال کنیم.

4️⃣اخری هم command line args هست که نسبت به همه اولویت بالاتری داره.

✅پس برای مثال اگه یه connection string رو توی appsettings گذاشته باشی و توی development ازش استفاده کنی, توی پروداکشن میتونی با env var ای که روی داکر ست میکنی اورایدش کنی.

پ.ن: این اولویت بندی و اوراید کردن توسط فریمورک انجام میشه و لازم نیست ما کاری انجام بدیم.

توی برنامه ما با استفاده از configuration کانفیک مربوطه رو میگیرم و‌ استفاده میکنیم و همه ی کارهای مربوط‌ به اولویت بندی و اوراید شدن توسط فریمورک انجام میشه.

Configuration["ConnectionString:Default"]

🔥فرمت کانفیگ هایی که توی appsettings.json قرار میگیرن به صورت json هست:

{
     "ConnectionString": { 
           "Default ": "...."
     }
}

ولی موقع تنظیم کردن توی environment variable باید به این صورت عمل کنیم:

expose ConnectionString__Default = "..." // linux

setx ConnectionString__Default  "..." //windows 

اون __ کار nested object توی json رو میکنه!!!
توی داکر هم باید با همین فرمت تعریف بشن (__)

@purecoder_ir

🔥سطح مهندس های نرم افزار ایران از نگاه کسی که توی گوگل بوده و سال ها خارج از ایران بوده.

😱کسایی که میگن توی ایران سطح فنی همه پایینه و مرغ خارجیا غازه، مشکل از خودشونه!!!

❓خودمون چه قدمی برای بهبود برداشتیم؟

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

@purecoder_ir

🔥Fluent Validation

✅پکیج Fluent Validation یه پکیج محبوب توی سی شارپ هست که برای input validation استفاده میشه و امکانات زیادی داره.

🔥داشتم دنبال چنین چیزی توی دارت میگشتم که یه پکیج با اسم مشابه پیدا کردم که به طور کامل از نمونه ی سی شارپش الهام گرفته.

https://pub.dev/packages/fluent_validation

class UserValidator extends AbstractValidator<User> {
 UserValidator() {
  ruleFor((user) => user.age, key: 'age').isNotNull().greaterThanOrEqual(13);
  ruleFor((user) => user.name, key: 'name').isNotEmpty();
 }
}

// Later on
final UserValidator validator = UserValidator();
ValidationResult result = validator.validate(user);

result.errors.first.key == 'The key of the rule that errored (for example age)'
result.errors.first.iss.onessage == 'The supplied error message (Passed by you, or default)'
result.errors.first.code == 'The error code'

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

@purecoder_ir

واقعن هیچ شرکتی کار درست تر از Jet Brains نیست...

این یه دونه رو بذارید متعصب باشیم😂😂

🍁وقتی که توی یه web cotroller همه دپندسی ها رو به کانستراکتور inject میکنیم، همه چیز خوشکل و گوگولی به نظر میاد. ولی ممکنه بعضی از action ها از بعضی دپندنسی ها استفاده نکنن.

👈برای مثال توی کلاس CustomersController چند تا متد زیر رو داشته باشیم:

✔️Search
✔️GetById
✔️Add
✔️EditPersonalInfo
✔️Remove

دپندنسی هایی که هر کدوم از این اکشن متد ها نیاز دارن ممکنه متفاوت باشه.

❓حالا اگه همه دپندنسی ها رو به کانستراکتور inject کنیم چه اتفاقی میوفته؟

فرض میکنیم دپندسی ها scoped یا Transient باشن...

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

😱😱حالا خود اون دپندسی ها هم هر کدومشون ممکنه چنتا دپندسی دیگه داشته باشن!!!

پس توی هر رکوئست چندین تا دپندنسی ساخته میشه که اصلن به کار نمیان!!!

🙄پرفرمنس رو دریاب نه خوشکلی!!!

❓راه حل چیه؟

✅اینجاست که inject کردن دپندسی ها به متد به جای کانستراکتور راه حل بهتریه.

🔥اون دپندسی هایی که توسط همه ی متد ها استفاده میشن رو به کانستراکتور inject میکنیم و اونهایی که فقط توسط یه متد خاص استفاده میشن رو به همون متد...

هدف کد هم مشخص تر میشه.
به هر حال web cotroller ها کلاس هایی نیستن که خیلی single responsibility داشته باشن.

👈البته فریمورکی که استفاده میکنی باید این رو پشتیبانی کنه.

@purecoder_ir