اگه کانفیگ های v2ray که پول هم دادی براش کار نمیکنه این پست رو چک کن:
https://news.1rj.ru/str/normal_developer/25
@syntax_fa
https://news.1rj.ru/str/normal_developer/25
@syntax_fa
👍4👎1
یه شخصی تو لینکدین این پست رو گذاشته که قراره با هم بررسیش کنیم:
چرا نباید از Signals ها در جنگو استفاده کنیم؟
اگر تجربه کار با Django را داشته باشید، احتمالاً با Signals آشنا هستید. سیگنالها به شما این امکان را میدهند که بعد از رخ دادن یک رویداد خاص، مانند ذخیره یا حذف یک شی، کدی را اجرا کنید. اما آیا همیشه بهترین انتخاب هستند؟ بیایید با هم بررسی کنیم.
کاربرد سیگنالها
سیگنالها در Django برای مواردی مانند ارسال ایمیل بعد از ایجاد یک شی یا بهروزرسانی دادههای مرتبط، استفاده میشوند. به این معنی که وقتی یک تغییر در دیتابیس رخ میده، میتونیم با استفاده از سیگنالها به آن پاسخ دهیم. این رویکرد به ما کمک میکند تا وابستگیها را کاهش بدیم و بین بخشهای مختلف برنامه ارتباط برقرار کنیم.
چرا نباید از سیگنالها استفاده کنیم؟
با وجود کاربردهای سیگنالها، استفاده از آنها معایب خودشون رو هم دارن. یکی از مشکلات اساسی سیگنالها این است که پیچیدگی و عدم پیشبینیپذیری را افزایش میدن. کدهایی که بهوسیله سیگنال اجرا میشوند، ممکن است در جریان اصلی کد ما نباشند و ما بهراحتی متوجه نشیم که چه زمانی و چرا آنها فراخوانی میشوند. این موضوع نه تنها کار دیباگ کردن رو سخت میکنه، بلکه ممکنه رفتار ناخواستهای هم که ازش انتظار نداریم رو هم داشته باشه.
یکی دیگه از مشکل های سیگنالها اینه که همگام (Synchronous) اجرا میشن. برخلاف تصوری که ممکنه داشته باشیم، سیگنالها بهصورت غیرهمگام اجرا نمیشن و هیچ پروسه پسزمینهای برای آنها وجود ندارد. این موضوع باعث میشه که اگر سیگنال با خطا مواجه بشن، این خطا مستقیما در جریان اصلی کد شما بروز کند و حتی ممکن است رفتارهای ناخواسته به وجود بیاد.
بهعنوان مثال، فرض کنید شما در حال توسعه کدی هستید که تعداد فروش یک نوع تاپینگ پیتزا را هنگام ایجاد پیتزای جدید بهروزرسانی میکند. اگر از سیگنال استفاده کنید، ممکن است در مواردی که از متدهای bulk مانند bulk_create یا .update() استفاده میکنید، این سیگنال فراخوانی نشود و این به دادههای ناهماهنگ منجر شود.
همچنین سیگنالها ممکنه که نگهداری کد را سختتر کنند. توسعهدهندگانی که کد شما را بعدا نگهداری میکنند، ممکنه زمان زیادی را صرف پیدا کردن محل تعریف و اتصال سیگنالها کنند، بهخصوص اگر سیگنالها در فایلهای مختلف پخش شده باشند.
چه چیزی میتواند جایگزین باشد؟
به جای استفاده از سیگنالها، یکی از راهکارهای بهتر استفاده از متدهای مدل مثل save() هست. زمانی که بیزینس لاجیک خود را درون متد save() مدل قرار میدهید، همه چیز شفافتر و قابل پیشبینیتر خواهد بود. به این ترتیب، کد جلو چشم شما قرار دارد و نیازی نیست نگران اجرا شدن یا نشدن سیگنالها باشید. این کار باعث میشود کد تمیزتر و خواناتر باشد و همچنین بهراحتی قابل تست و نگهداری شود.
برای مثال، میتوانید یک متد در مدل خود تعریف کنید که منطق بهروزرسانی را مدیریت کند و سپس این متد را در متد save() فراخوانی کنید. این روش نه تنها ساختار کد شما را سادهتر میکند، بلکه به توسعهدهندگان آینده هم کمک میکند تا بهراحتی جریان کد را دنبال کنند.
————————————-
نظر من راجب این پست:
استفاده از سیگنال ها تو برخی شرایط بنظرم خیلیم مفید هستش.
برای مثال میتونیم با استفاده از سیگنال ها، سرویس ها و اجزای مختلف رو از هم decouple تر کنیم.
فرض کنید موقعی که یک یوزر جدید ساخته میشه، چند تا سرویس دیگه هم یه سری عملیات انجام میدن. مثلا نوتیف خوش آمد گویی ارسال میکنیم.
ساختار پروژمونم یکپارچه هستش.
تو این شرایط اگه اپ نوتیف قرار باشه بعد از ساخته شدن یک یوزر جدید چیزی رو نوتیف کنه، کافیه تو خود اپ نوتیف مشخص کنیم که به سیگنال پست یوزر علاقه مند هستیم و اگه سیگنال پستی از سمت یوزر زده شد بیا و فلان چیزو نوتیف کن.
اینطوری سرویس ها نسبت به هم decouple تر شدن و دیگه یوزر کاری نداره زمانی که یوزری جدیدی ساخته شد، بقیه سرویس ها چیکار کنن، فقط سیگنالو ارسال میکنه هر کی علاقه مند بود دریافتش میکنه.
الگوی observer:
سیگنال ها درواقع پیاده سازی الگوی observer هستن که برای ارتباط بین اجزای مخنلف سیستم خیلی مفیده.
فقط چند تا نکته باقی میمونه اینکه از سیگنال ها هوشمندانه استفاده کنیم، تو استفاده ازشون زیاده روی نکنیم و حتما داکیومنت کنیم تا باعث سردرگمی نشه
#django #Signals
@Syntax_fa
چرا نباید از Signals ها در جنگو استفاده کنیم؟
اگر تجربه کار با Django را داشته باشید، احتمالاً با Signals آشنا هستید. سیگنالها به شما این امکان را میدهند که بعد از رخ دادن یک رویداد خاص، مانند ذخیره یا حذف یک شی، کدی را اجرا کنید. اما آیا همیشه بهترین انتخاب هستند؟ بیایید با هم بررسی کنیم.
کاربرد سیگنالها
سیگنالها در Django برای مواردی مانند ارسال ایمیل بعد از ایجاد یک شی یا بهروزرسانی دادههای مرتبط، استفاده میشوند. به این معنی که وقتی یک تغییر در دیتابیس رخ میده، میتونیم با استفاده از سیگنالها به آن پاسخ دهیم. این رویکرد به ما کمک میکند تا وابستگیها را کاهش بدیم و بین بخشهای مختلف برنامه ارتباط برقرار کنیم.
چرا نباید از سیگنالها استفاده کنیم؟
با وجود کاربردهای سیگنالها، استفاده از آنها معایب خودشون رو هم دارن. یکی از مشکلات اساسی سیگنالها این است که پیچیدگی و عدم پیشبینیپذیری را افزایش میدن. کدهایی که بهوسیله سیگنال اجرا میشوند، ممکن است در جریان اصلی کد ما نباشند و ما بهراحتی متوجه نشیم که چه زمانی و چرا آنها فراخوانی میشوند. این موضوع نه تنها کار دیباگ کردن رو سخت میکنه، بلکه ممکنه رفتار ناخواستهای هم که ازش انتظار نداریم رو هم داشته باشه.
یکی دیگه از مشکل های سیگنالها اینه که همگام (Synchronous) اجرا میشن. برخلاف تصوری که ممکنه داشته باشیم، سیگنالها بهصورت غیرهمگام اجرا نمیشن و هیچ پروسه پسزمینهای برای آنها وجود ندارد. این موضوع باعث میشه که اگر سیگنال با خطا مواجه بشن، این خطا مستقیما در جریان اصلی کد شما بروز کند و حتی ممکن است رفتارهای ناخواسته به وجود بیاد.
بهعنوان مثال، فرض کنید شما در حال توسعه کدی هستید که تعداد فروش یک نوع تاپینگ پیتزا را هنگام ایجاد پیتزای جدید بهروزرسانی میکند. اگر از سیگنال استفاده کنید، ممکن است در مواردی که از متدهای bulk مانند bulk_create یا .update() استفاده میکنید، این سیگنال فراخوانی نشود و این به دادههای ناهماهنگ منجر شود.
همچنین سیگنالها ممکنه که نگهداری کد را سختتر کنند. توسعهدهندگانی که کد شما را بعدا نگهداری میکنند، ممکنه زمان زیادی را صرف پیدا کردن محل تعریف و اتصال سیگنالها کنند، بهخصوص اگر سیگنالها در فایلهای مختلف پخش شده باشند.
چه چیزی میتواند جایگزین باشد؟
به جای استفاده از سیگنالها، یکی از راهکارهای بهتر استفاده از متدهای مدل مثل save() هست. زمانی که بیزینس لاجیک خود را درون متد save() مدل قرار میدهید، همه چیز شفافتر و قابل پیشبینیتر خواهد بود. به این ترتیب، کد جلو چشم شما قرار دارد و نیازی نیست نگران اجرا شدن یا نشدن سیگنالها باشید. این کار باعث میشود کد تمیزتر و خواناتر باشد و همچنین بهراحتی قابل تست و نگهداری شود.
برای مثال، میتوانید یک متد در مدل خود تعریف کنید که منطق بهروزرسانی را مدیریت کند و سپس این متد را در متد save() فراخوانی کنید. این روش نه تنها ساختار کد شما را سادهتر میکند، بلکه به توسعهدهندگان آینده هم کمک میکند تا بهراحتی جریان کد را دنبال کنند.
————————————-
نظر من راجب این پست:
استفاده از سیگنال ها تو برخی شرایط بنظرم خیلیم مفید هستش.
برای مثال میتونیم با استفاده از سیگنال ها، سرویس ها و اجزای مختلف رو از هم decouple تر کنیم.
فرض کنید موقعی که یک یوزر جدید ساخته میشه، چند تا سرویس دیگه هم یه سری عملیات انجام میدن. مثلا نوتیف خوش آمد گویی ارسال میکنیم.
ساختار پروژمونم یکپارچه هستش.
تو این شرایط اگه اپ نوتیف قرار باشه بعد از ساخته شدن یک یوزر جدید چیزی رو نوتیف کنه، کافیه تو خود اپ نوتیف مشخص کنیم که به سیگنال پست یوزر علاقه مند هستیم و اگه سیگنال پستی از سمت یوزر زده شد بیا و فلان چیزو نوتیف کن.
اینطوری سرویس ها نسبت به هم decouple تر شدن و دیگه یوزر کاری نداره زمانی که یوزری جدیدی ساخته شد، بقیه سرویس ها چیکار کنن، فقط سیگنالو ارسال میکنه هر کی علاقه مند بود دریافتش میکنه.
الگوی observer:
سیگنال ها درواقع پیاده سازی الگوی observer هستن که برای ارتباط بین اجزای مخنلف سیستم خیلی مفیده.
فقط چند تا نکته باقی میمونه اینکه از سیگنال ها هوشمندانه استفاده کنیم، تو استفاده ازشون زیاده روی نکنیم و حتما داکیومنت کنیم تا باعث سردرگمی نشه
#django #Signals
@Syntax_fa
👍5🔥3
📱 زندگی برنامهنویسها قبل و بعد از چتباتهای هوش مصنوعی:
قبل:
- گوگل: بهترین دوست
- Stack Overflow: خونه دوم
- کپی-پیست: مهارت اصلی
بعد:
- چتجیپیتی: رفیق فابریک
- پرامپت مهندسی: تخصص جدید
- هوش مصنوعی: همکار جدید
دنیای برنامهنویسی قبل از عصر هوش مصنوعی
برای نسل جدید برنامهنویسان که در عصر هوش مصنوعی و چتباتها رشد کردهاند، تصور دنیای برنامهنویسی بدون این ابزارها شاید سخت باشد. اما واقعیت این است که تا همین چند سال پیش، برنامهنویسان با چالشهای متفاوتی روبرو بودند.
جستجو: هنر اصلی برنامهنویسی
قبل از ظهور چتباتهای هوشمند، مهارت در جستجوی اطلاعات یکی از مهمترین تواناییهای یک برنامهنویس بود. ساعتها وقت صرف پیدا کردن راهحلها در مستندات و وبلاگهای مختلف میشد. گاهی یافتن پاسخ یک سؤال ساده، ساعت ها طول میکشید.
Stack Overflow: ناجی برنامهنویسان
سایت Stack Overflow نقش حیاتی در زندگی برنامهنویسان داشت. بسیاری از مشکلات با جستجو در این سایت و خواندن پاسخهای دیگران حل میشد. البته پیدا کردن پاسخ مناسب در میان انبوه نظرات، خود چالشی بزرگ بود.(هنوزم ناجی برنامه نویساس)
دیباگ: کابوس شبانه
پیدا کردن و رفع باگها، یکی از چالشبرانگیزترین بخشهای برنامهنویسی است. گاهی ساعتها یا حتی روزها صرف پیدا کردن یک اشتباه کوچک در کد میشد. امروزه، هوش مصنوعی میتواند در شناسایی و رفع بسیاری از این مشکلات کمک کند.
#fun
@Syntax_fa
قبل:
- گوگل: بهترین دوست
- Stack Overflow: خونه دوم
- کپی-پیست: مهارت اصلی
بعد:
- چتجیپیتی: رفیق فابریک
- پرامپت مهندسی: تخصص جدید
- هوش مصنوعی: همکار جدید
دنیای برنامهنویسی قبل از عصر هوش مصنوعی
برای نسل جدید برنامهنویسان که در عصر هوش مصنوعی و چتباتها رشد کردهاند، تصور دنیای برنامهنویسی بدون این ابزارها شاید سخت باشد. اما واقعیت این است که تا همین چند سال پیش، برنامهنویسان با چالشهای متفاوتی روبرو بودند.
جستجو: هنر اصلی برنامهنویسی
قبل از ظهور چتباتهای هوشمند، مهارت در جستجوی اطلاعات یکی از مهمترین تواناییهای یک برنامهنویس بود. ساعتها وقت صرف پیدا کردن راهحلها در مستندات و وبلاگهای مختلف میشد. گاهی یافتن پاسخ یک سؤال ساده، ساعت ها طول میکشید.
Stack Overflow: ناجی برنامهنویسان
سایت Stack Overflow نقش حیاتی در زندگی برنامهنویسان داشت. بسیاری از مشکلات با جستجو در این سایت و خواندن پاسخهای دیگران حل میشد. البته پیدا کردن پاسخ مناسب در میان انبوه نظرات، خود چالشی بزرگ بود.(هنوزم ناجی برنامه نویساس)
دیباگ: کابوس شبانه
پیدا کردن و رفع باگها، یکی از چالشبرانگیزترین بخشهای برنامهنویسی است. گاهی ساعتها یا حتی روزها صرف پیدا کردن یک اشتباه کوچک در کد میشد. امروزه، هوش مصنوعی میتواند در شناسایی و رفع بسیاری از این مشکلات کمک کند.
#fun
@Syntax_fa
😁9👍6
این آقا خیلی تو لینکدین فارسی سروصدا به پا کرده و تو کتابخونه tensorflow کانتریبیوت کرده.
چند روز پیش تو یه کانال دیگم اشاره کرده بودن اما اینبار تو لینکدین خودمم پستشو دیدم.
هزارو خورده ای ری اکشن با کلی کامنت
اما قسمت دارک ماجرا زمانیه که محتویات کانتریبیوتش رو میبینیم که کلا یدونه کلمه از کامنت رو تغییر داده
واقعا لینکدین خیلی عجیبه
#fun
@Syntax_fa
چند روز پیش تو یه کانال دیگم اشاره کرده بودن اما اینبار تو لینکدین خودمم پستشو دیدم.
هزارو خورده ای ری اکشن با کلی کامنت
اما قسمت دارک ماجرا زمانیه که محتویات کانتریبیوتش رو میبینیم که کلا یدونه کلمه از کامنت رو تغییر داده
واقعا لینکدین خیلی عجیبه
#fun
@Syntax_fa
🤣53😁3👍1
کمی دور از انتظار باشه این رو به عنوان کسی دارم میگم که سالها ظهور و ناپدید شدن تکنولوژی ها و نوع تفکر قالب بر نرم افزار رو لمس کردم و در این فضا کار کردم به عنوان کسی که وقتی #ویژوال بیسیک کار میکردم فکر نمیکردم روزی از بازار حذف بشه یا فکر نمیکردم دات نت با یک تغییر در ساختار و رفتن سراغ #netcore بتونه با جاوا رقابت کنه و باز هم برام قابل تعریف نبود که زبان تازه به دنیا اومده ای مثل #گولنگ و #راست چنین با اقتدار قد علم کنن و مرزهای پرفورمنس رو به لرزه دربیارن و شاید تصور اینکه روزی در دنیای وب رقیبهایی به این قدرت رو برای #php متصور بشم سخت بود اما امروز با توجه به تمام تغیرات چه در نگرش به نرم افزار و معماری نرم افزار و همچنین پیش اومدن هوش مصنوعی در این حوزه به ناچار باید بگم دنیای #شی گرایی و #معماریهای شی گرا کم کم دارن کوله بارشون رو میبندن و زبانهای شی گرا باید جاشون رو به زبانهای جوانتر مثل همین #گولنگ و #راست بدن حرف من کنار رفتن زبانهای جاوا یا سی شارپ نیست دوستان موضوع کم رنگ شدن و قدرت گرفتن تفکر جدید هست تغییر نگرش زمانبر و طولانی مدت خواهد بود ولی #ساده سازی نوع #تفکر در برنامه نویسی و گذار از روش های سنتی و معماریهای سنتی در حال انجامه برای همین شما اسم #ورتیکال یا معماریهای مدرن دیگه رو میشنوید #مراقب جا موندن از قطار پر سرعت تغییرات باشید
Source
@Syntax_fa
Source
@Syntax_fa
👍25🔥3👻1
~> چالشهای یادگیری Go برای برنامهنویسهای تازهکار 🥰
یکی از مهمترین چالشهایی که برنامهنویسهای جدید موقع یادگیری Go باهاش روبرو میشن، درک مفهوم کانکارنسی هستش. Go با معرفی goroutines و channels سعی میکنه مدل سادهای برای برنامهنویسی همروند ارائه بده، اما درک عمیق این مفاهیم برای افرادی که تازه شروع کردن سخت میشه.
ارور هندلینگ در Go هم چالش دیگهای هستش که برنامهنویسهای جدید باهاش درگیر میشن. برخلاف زبانهایی مثل Java که از try-catch استفاده میکنن، Go از یک پترن سادهتر با استفاده از مقادیر error استفاده میکنه. این روش باعث میشه کد تمیزتر بشه، اما نیاز به چک کردن مکرر خطاها داره که میتونه برای تازهکارها گیجکننده باشه.
درک سیستم تایپهای Go برای برنامهنویسهایی که از زبانهای شیگرا میان میتونه چالشبرانگیز باشه. Go اصلاً یک زبان شیگرا نیست و به جای کلاس و آبجکت، از type برای تعریف structها و interfaceها استفاده میکنه. این structها و interfaceها صرفاً تایپ هستن و برای داک تایپینگ استفاده میشن. این تفاوت پارادایم برای کسایی که با OOP آشنا هستن میتونه گیجکننده باشه.
پوینترها توی Go یکی دیگه از نقاط چالشبرانگیز هستن. اگرچه Go نسبت به C مدیریت حافظه رو سادهتر کرده، اما هنوز هم درک اینکه کی باید از پوینتر استفاده کرد و کی نباید، برای برنامهنویسهای جدید سخت میشه.
سیستم پکیجهای Go و نحوه مدیریت dependencyها هم میتونه گیجکننده باشه. از Go 1.11 به بعد، سیستم module معرفی شد که اگرچه مشکلات قبلی GOPATH رو حل کرده، اما یادگیری نحوه کار با go.mod و go.sum برای تازهکارها زمانبر هستش.
یکی از ویژگیهای خاص Go که درکش برای برنامهنویسهای جدید سخت میشه، interfaceها هستن. Go از implicit interface implementation استفاده میکنه که با زبانهای دیگه متفاوت هستش و نیاز به تغییر دیدگاه داره.
نکته دیگهای که برای برنامهنویسهای تازهکار چالشبرانگیز میشه، عدم وجود جنریکها تا قبل از Go 1.18 بود. حالا که جنریکها اضافه شدن، یادگیری syntax و best practiceهای مربوط به اونها خودش یه چالش جدید محسوب میشه.
همچنین، Go یه سری قوانین سختگیرانه در مورد code formatting و نامگذاری داره. مثلاً اگه یه متغیر exported تعریف کنی، حتماً باید با حرف بزرگ شروع بشه، یا اینکه هر statement باید با semicolon تموم بشه (که البته کامپایلر خودش اضافه میکنه). این قوانین اگرچه به خوانایی کد کمک میکنن، اما رعایت کردنشون برای تازهکارها میتونه سخت باشه.
Source
@Syntax_fa
یکی از مهمترین چالشهایی که برنامهنویسهای جدید موقع یادگیری Go باهاش روبرو میشن، درک مفهوم کانکارنسی هستش. Go با معرفی goroutines و channels سعی میکنه مدل سادهای برای برنامهنویسی همروند ارائه بده، اما درک عمیق این مفاهیم برای افرادی که تازه شروع کردن سخت میشه.
ارور هندلینگ در Go هم چالش دیگهای هستش که برنامهنویسهای جدید باهاش درگیر میشن. برخلاف زبانهایی مثل Java که از try-catch استفاده میکنن، Go از یک پترن سادهتر با استفاده از مقادیر error استفاده میکنه. این روش باعث میشه کد تمیزتر بشه، اما نیاز به چک کردن مکرر خطاها داره که میتونه برای تازهکارها گیجکننده باشه.
درک سیستم تایپهای Go برای برنامهنویسهایی که از زبانهای شیگرا میان میتونه چالشبرانگیز باشه. Go اصلاً یک زبان شیگرا نیست و به جای کلاس و آبجکت، از type برای تعریف structها و interfaceها استفاده میکنه. این structها و interfaceها صرفاً تایپ هستن و برای داک تایپینگ استفاده میشن. این تفاوت پارادایم برای کسایی که با OOP آشنا هستن میتونه گیجکننده باشه.
پوینترها توی Go یکی دیگه از نقاط چالشبرانگیز هستن. اگرچه Go نسبت به C مدیریت حافظه رو سادهتر کرده، اما هنوز هم درک اینکه کی باید از پوینتر استفاده کرد و کی نباید، برای برنامهنویسهای جدید سخت میشه.
سیستم پکیجهای Go و نحوه مدیریت dependencyها هم میتونه گیجکننده باشه. از Go 1.11 به بعد، سیستم module معرفی شد که اگرچه مشکلات قبلی GOPATH رو حل کرده، اما یادگیری نحوه کار با go.mod و go.sum برای تازهکارها زمانبر هستش.
یکی از ویژگیهای خاص Go که درکش برای برنامهنویسهای جدید سخت میشه، interfaceها هستن. Go از implicit interface implementation استفاده میکنه که با زبانهای دیگه متفاوت هستش و نیاز به تغییر دیدگاه داره.
نکته دیگهای که برای برنامهنویسهای تازهکار چالشبرانگیز میشه، عدم وجود جنریکها تا قبل از Go 1.18 بود. حالا که جنریکها اضافه شدن، یادگیری syntax و best practiceهای مربوط به اونها خودش یه چالش جدید محسوب میشه.
همچنین، Go یه سری قوانین سختگیرانه در مورد code formatting و نامگذاری داره. مثلاً اگه یه متغیر exported تعریف کنی، حتماً باید با حرف بزرگ شروع بشه، یا اینکه هر statement باید با semicolon تموم بشه (که البته کامپایلر خودش اضافه میکنه). این قوانین اگرچه به خوانایی کد کمک میکنن، اما رعایت کردنشون برای تازهکارها میتونه سخت باشه.
Source
@Syntax_fa
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13🔥3👻1
This media is not supported in your browser
VIEW IN TELEGRAM
شما در این ویدئو یک CPU آیفون را در زیر میکروسکوپ در کنار یک تار مو بعنوان مقایسه اندازه آن مشاهده میکنید.
@Syntax_fa
@Syntax_fa
😱20🤣5👍2👻2
تست Canary: راز پشت پرده تغییرات گوگل
چند وقت پیش داشتم ایمیلهایم را در گوگل چک میکردم که یک ویژگی جدید توجه من را جلب کرد؛ دکمهای مخصوص پرسش از هوش مصنوعی دربارهی محتوای ایمیلها. فکر کردم این یک تغییر جذاب است و سری به بقیه ایمیلهایم زدم تا از این فیچر استفاده کنم. اما جالب بود که این ویژگی فقط در یک ایمیل فعال شده بود! چرا همه کاربران این ویژگی را ندارند؟ مگر این همان گوگل نیست که وقتی چیزی اضافه میکند برای همه فعال میشود؟
با کمی تحقیق و کنجکاوی، به یک واژه رسیدم:
Canary Test
چرا تست Canary؟
تصور کنید گوگل میخواهد ویژگی جدیدی را به سرویس ایمیل خود اضافه کند. اگر این ویژگی بهدرستی کار نکند، ممکن است کل سیستم ایمیل دچار مشکل شود. اما به کمک Canary Test، ابتدا این تغییرات را برای گروه کوچکی از کاربران فعال میکنند. اگر همهچیز درست کار کرد، این تغییر را برای کاربران بیشتری اجرا میکنند؛ و اگر مشکلی رخ داد، بهسرعت به نسخه قبلی برمیگردند، بدون اینکه کسی متوجه شود.
فواید این تست
این تست مثل نگهبانی است که با فداکاری جلوی آسیبهای بزرگ را میگیرد
ریسک کمتر: ابتدا در شرایط محدود بررسی میشود که ویژگی جدید مشکلی ایجاد نکند.
شناسایی مشکلات: قبل از اینکه همه کاربران با باگها روبرو شوند، تیم توسعه آنها را شناسایی و رفع میکند.
تجربهی کاربری بهتر: بدون اختلال و با اطمینان بالا، کاربران از قابلیتهای جدید لذت میبرند.
گوگل، فیسبوک و سایر غولها چطور از Canary Test استفاده میکنند؟
در این روش، غولهای فناوری مثل گوگل و فیسبوک ابتدا تغییرات را به درصد کوچکی از کاربران عرضه میکنند. این کاربران بهعنوان "قناریهای" سیستم انتخاب میشوند تا در صورت شناسایی خطر، باقی کاربران در امان بمانند. اگر همهچیز خوب پیش رفت، تغییرات به همه عرضه میشود؛ و اگر نه، بهراحتی تغییرات را متوقف میکنند.
پس اگر روزی دیدید که شما یک قابلیت خاص در یک اپلیکیشن دارید و دوستانتان نه، بدانید شاید شما هم یکی از «قناریها»ی سیستم باشید! 🐤
Source
@Syntax_fa
چند وقت پیش داشتم ایمیلهایم را در گوگل چک میکردم که یک ویژگی جدید توجه من را جلب کرد؛ دکمهای مخصوص پرسش از هوش مصنوعی دربارهی محتوای ایمیلها. فکر کردم این یک تغییر جذاب است و سری به بقیه ایمیلهایم زدم تا از این فیچر استفاده کنم. اما جالب بود که این ویژگی فقط در یک ایمیل فعال شده بود! چرا همه کاربران این ویژگی را ندارند؟ مگر این همان گوگل نیست که وقتی چیزی اضافه میکند برای همه فعال میشود؟
با کمی تحقیق و کنجکاوی، به یک واژه رسیدم:
Canary Test
چرا تست Canary؟
تصور کنید گوگل میخواهد ویژگی جدیدی را به سرویس ایمیل خود اضافه کند. اگر این ویژگی بهدرستی کار نکند، ممکن است کل سیستم ایمیل دچار مشکل شود. اما به کمک Canary Test، ابتدا این تغییرات را برای گروه کوچکی از کاربران فعال میکنند. اگر همهچیز درست کار کرد، این تغییر را برای کاربران بیشتری اجرا میکنند؛ و اگر مشکلی رخ داد، بهسرعت به نسخه قبلی برمیگردند، بدون اینکه کسی متوجه شود.
فواید این تست
این تست مثل نگهبانی است که با فداکاری جلوی آسیبهای بزرگ را میگیرد
ریسک کمتر: ابتدا در شرایط محدود بررسی میشود که ویژگی جدید مشکلی ایجاد نکند.
شناسایی مشکلات: قبل از اینکه همه کاربران با باگها روبرو شوند، تیم توسعه آنها را شناسایی و رفع میکند.
تجربهی کاربری بهتر: بدون اختلال و با اطمینان بالا، کاربران از قابلیتهای جدید لذت میبرند.
گوگل، فیسبوک و سایر غولها چطور از Canary Test استفاده میکنند؟
در این روش، غولهای فناوری مثل گوگل و فیسبوک ابتدا تغییرات را به درصد کوچکی از کاربران عرضه میکنند. این کاربران بهعنوان "قناریهای" سیستم انتخاب میشوند تا در صورت شناسایی خطر، باقی کاربران در امان بمانند. اگر همهچیز خوب پیش رفت، تغییرات به همه عرضه میشود؛ و اگر نه، بهراحتی تغییرات را متوقف میکنند.
پس اگر روزی دیدید که شما یک قابلیت خاص در یک اپلیکیشن دارید و دوستانتان نه، بدانید شاید شما هم یکی از «قناریها»ی سیستم باشید! 🐤
Source
@Syntax_fa
👍13👻4
ادعای هک اطلاعات یکونیم میلیون کاربران بلو بانک.
دیگه فکر کنم برای ملت فرقی نمیکنه چون کل ایران اپن سورسه.
https://youtu.be/iaMeC798mdI?si=uN3oCDuAuIHUjRY6
@Syntax_fa
دیگه فکر کنم برای ملت فرقی نمیکنه چون کل ایران اپن سورسه.
https://youtu.be/iaMeC798mdI?si=uN3oCDuAuIHUjRY6
@Syntax_fa
YouTube
ادعای هک اطلاعات یک و نیم میلیون کاربر بلو بانک!
در این ویدیو به بررسی ادعای هکر به بدست آوردن اطلاعات یک و نیم میلیون از کاربران بلو بانک می پردازیم.
#hack #بلو_بانک #بانک #هک
#hack #بلو_بانک #بانک #هک
👍12👎2😱2
گفتگو شنیدنی GoCasts با مهندس کیانوش مختاریان، مهندس نرم افزار، رهبر فنی سابق در گوگل.
https://gocasts.ir/talk-with-kain
@Syntax_fa
https://gocasts.ir/talk-with-kain
@Syntax_fa
🔥15👍4👎4
در برنامهنویسی، اصطلاح "Idiomatic" به معنای استفاده از الگوها و روشهایی است که در یک زبان برنامهنویسی خاص به عنوان استاندارد و رایج شناخته میشوند. این موضوع اهمیت زیادی دارد و چندین دلیل برای آن وجود دارد:
1. خوانایی کد: کدی که به صورت idiomatic نوشته شده باشد، برای سایر برنامهنویسانی که با آن زبان آشنا هستند، راحتتر قابل درک است. این باعث میشود که تیمها به راحتی بتوانند با یکدیگر همکاری کنند.
2. نگهداری آسانتر: کدی که از الگوهای استاندارد پیروی میکند، به راحتی قابل نگهداری و اصلاح است. این امر بهویژه در پروژههای بزرگتر که افراد مختلفی روی آن کار میکنند، بسیار مهم است.
3. عملکرد بهتر: در بسیاری از موارد، استفاده از روشهای idiomatic به بهبود عملکرد کمک میکند، زیرا این روشها اغلب بهترین شیوههای بهینهسازی شده برای زبان مربوطه هستند.
4. کاهش خطاها: پیروی از الگوهای رایج به کاهش خطاها و باگها کمک میکند، زیرا این الگوها معمولاً توسط جامعه توسعهدهندگان آزمایش شدهاند و مطمئنتر هستند.
#idiomatic
@Syntax_fa
1. خوانایی کد: کدی که به صورت idiomatic نوشته شده باشد، برای سایر برنامهنویسانی که با آن زبان آشنا هستند، راحتتر قابل درک است. این باعث میشود که تیمها به راحتی بتوانند با یکدیگر همکاری کنند.
2. نگهداری آسانتر: کدی که از الگوهای استاندارد پیروی میکند، به راحتی قابل نگهداری و اصلاح است. این امر بهویژه در پروژههای بزرگتر که افراد مختلفی روی آن کار میکنند، بسیار مهم است.
3. عملکرد بهتر: در بسیاری از موارد، استفاده از روشهای idiomatic به بهبود عملکرد کمک میکند، زیرا این روشها اغلب بهترین شیوههای بهینهسازی شده برای زبان مربوطه هستند.
4. کاهش خطاها: پیروی از الگوهای رایج به کاهش خطاها و باگها کمک میکند، زیرا این الگوها معمولاً توسط جامعه توسعهدهندگان آزمایش شدهاند و مطمئنتر هستند.
#idiomatic
@Syntax_fa
👍14👻3🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
Backpressure
تو این پست با چند مثال Backpressure رو بررسی میکنیم.
مثال اول:کارخانه شکلات
در برنامه تلویزیونی "I Love Lucy" قسمتی وجود دارد که Lucy در یک کارخانه بستهبندی شیرینی کار میکند. وظیفه او برداشتن شیرینی از نوار نقاله و بستهبندی هر کدام در کاغذ است.
او با این مشکل مواجه می شود که تعداد شیرینی هایی که در نوار نقاله می أید بیشتر از توان او در بسته بندی است.
او دو روش مختلف برای مقابله با آن را امتحان میکند: کنار گذاشتن برخی تا بعدا بهشون رسیدگی کنه (buffering)، و در نهایت شروع به خوردن و پنهان کردن آنها در کلاهش میکند (dropping). با این حال، در مورد یک کارخانه شکلات، هیچ یک از این استراتژیهای Backpressure عملی نیستند. در عوض، او نیاز داشت که نوار نقاله را آهستهتر کنند؛ به عبارت دیگر، او نیاز به کنترل سرعت producer دارد.
مثال دوم: خواندن و نوشتن از فایل:
حالا درباره Backpressure مرتبط با نرمافزار صحبت میکنیم. رایجترین حالت هنگام کار با file system است.
نوشتن در فایل کندتر از خواندن فایل است. تصور کنید یک hard drive که سرعت موثر خواندن ۱۵۰ مگابایت بر ثانیه و سرعت نوشتن ۱۰۰ مگابایت بر ثانیه را ارائه میدهد. اگر بخواهید فایلی را با حداکثر سرعت ممکن به memory بخوانید، در حالی که همزمان آن را با حداکثر سرعت ممکن به دیسک بنویسید - باید هر ثانیه ۵۰ مگابایت را buffer کنید. در هر ثانیه 50 مگابایت را باید بافر کنید!
شما نمیتوانید به بافر رسیدگی کنید تا زمانی که خواندن فایل ورودی کاملاً به پایان برسد.
حالا تصور کنید این کار را با یک فایل ۶ گیگابایتی انجام میدهید. تا زمانی که فایل را کاملاً خواندهاید، یک buffer ۲ گیگابایتی خواهید داشت که هنوز باید نوشتن آن را تمام کنید.
مقدار زیادی memory هدر رفته است. در برخی سیستمها این ممکن است حتی از مقدار memory موجود فراتر رود.
نگران نباشید، راهحل ساده است: فقط به همان سرعتی بخوانید که میتوانید بنویسید. تقریباً تمام I/O library ها abstraction هایی را برای انجام خودکار این کار برای شما ارائه میدهند.
مثال سوم: ارتباط Server
مثال بعدی ارتباط بین server ها است. امروزه استفاده از معماری microservice که در آن مسئولیتها بین چندین server تقسیم میشود بسیار رایج است.
Backpressure
معمولاً این سناریو زمانی رخ میدهد که یک server درخواستها را سریعتر از آنچه server دیگر میتواند پردازش کند، ارسال میکند.
اگر server A، ۱۰۰ rps (requests per second) به server B بفرستد، اما server B فقط بتواند ۷۵ rps را پردازش کند، شما یک کسری ۲۵ rps دارید.
در هر صورت، server B باید به نوعی با Backpressure مقابله کند. Buffer کردن آن کسری ۲۵ rps یک گزینه است، اما اگر آن افزایش ثابت بماند، به زودی memory تمام میشود و از کار میافتد. Drop کردن درخواستها گزینه دیگری است که در اکثر سناریو ها قابل قبول نیست.
گزینه ایدهآل این است که server B نرخ ارسال درخواستهای server A را کنترل کند، اما باز هم این همیشه عملی نیست - اگر server A به نمایندگی از یک کاربر درخواست میکند، شما نمیتوانید کاربر ها را کنترل کنید که آهستهتر شوند، اغلب بهتر است که server درخواست کننده buffer داشته باشد، تا بتوانید بار memory را در downstream، جایی که استرس وجود دارد، بهتر توزیع کنید و بر سایر درخواست کنندگان تأثیر نگذارید.
به عنوان مثال، اگر سه نوع مختلف سرویس (A, B, C) همگی به یک سرویس downstream مشترک (Z) درخواست بدهند، و یکی از آنها (A) تحت بار بالا باشد، سرویس Z میتواند به طور موثر به سرویس A بگوید "آهستهتر شو" (کنترل producer) که باعث میشود سرویس A درخواستها را buffer کند. اگر این ادامه پیدا کند، در نهایت سرویس A با کمبود memory مواجه میشود، با این حال، دو سرویس دیگر (B, C) همچنان فعال میمانند، همانطور که سرویس downstream Z نیز فعال میماند زیرا اجازه نمیدهد یک سرویس بدرفتار از دسترسی برابر برای دیگران جلوگیری کند. در این مورد ممکن است قطعی اجتنابناپذیر باشد، اما ما محدوده را محدود کردیم و از Denial of Service زنجیرهای جلوگیری کردیم.
مثال ها:
https://medium.com/@jayphelps/backpressure-explained-the-flow-of-data-through-software-2350b3e77ce7
#Backpressure
@Syntax_fa
تو این پست با چند مثال Backpressure رو بررسی میکنیم.
مثال اول:کارخانه شکلات
در برنامه تلویزیونی "I Love Lucy" قسمتی وجود دارد که Lucy در یک کارخانه بستهبندی شیرینی کار میکند. وظیفه او برداشتن شیرینی از نوار نقاله و بستهبندی هر کدام در کاغذ است.
او با این مشکل مواجه می شود که تعداد شیرینی هایی که در نوار نقاله می أید بیشتر از توان او در بسته بندی است.
او دو روش مختلف برای مقابله با آن را امتحان میکند: کنار گذاشتن برخی تا بعدا بهشون رسیدگی کنه (buffering)، و در نهایت شروع به خوردن و پنهان کردن آنها در کلاهش میکند (dropping). با این حال، در مورد یک کارخانه شکلات، هیچ یک از این استراتژیهای Backpressure عملی نیستند. در عوض، او نیاز داشت که نوار نقاله را آهستهتر کنند؛ به عبارت دیگر، او نیاز به کنترل سرعت producer دارد.
مثال دوم: خواندن و نوشتن از فایل:
حالا درباره Backpressure مرتبط با نرمافزار صحبت میکنیم. رایجترین حالت هنگام کار با file system است.
نوشتن در فایل کندتر از خواندن فایل است. تصور کنید یک hard drive که سرعت موثر خواندن ۱۵۰ مگابایت بر ثانیه و سرعت نوشتن ۱۰۰ مگابایت بر ثانیه را ارائه میدهد. اگر بخواهید فایلی را با حداکثر سرعت ممکن به memory بخوانید، در حالی که همزمان آن را با حداکثر سرعت ممکن به دیسک بنویسید - باید هر ثانیه ۵۰ مگابایت را buffer کنید. در هر ثانیه 50 مگابایت را باید بافر کنید!
شما نمیتوانید به بافر رسیدگی کنید تا زمانی که خواندن فایل ورودی کاملاً به پایان برسد.
حالا تصور کنید این کار را با یک فایل ۶ گیگابایتی انجام میدهید. تا زمانی که فایل را کاملاً خواندهاید، یک buffer ۲ گیگابایتی خواهید داشت که هنوز باید نوشتن آن را تمام کنید.
6 GB / 150 MB = 40 seconds
150 MB - 100 MB = 50 MB deficit
50 MB x 40 = 2 GB !!!
مقدار زیادی memory هدر رفته است. در برخی سیستمها این ممکن است حتی از مقدار memory موجود فراتر رود.
نگران نباشید، راهحل ساده است: فقط به همان سرعتی بخوانید که میتوانید بنویسید. تقریباً تمام I/O library ها abstraction هایی را برای انجام خودکار این کار برای شما ارائه میدهند.
مثال سوم: ارتباط Server
مثال بعدی ارتباط بین server ها است. امروزه استفاده از معماری microservice که در آن مسئولیتها بین چندین server تقسیم میشود بسیار رایج است.
Backpressure
معمولاً این سناریو زمانی رخ میدهد که یک server درخواستها را سریعتر از آنچه server دیگر میتواند پردازش کند، ارسال میکند.
اگر server A، ۱۰۰ rps (requests per second) به server B بفرستد، اما server B فقط بتواند ۷۵ rps را پردازش کند، شما یک کسری ۲۵ rps دارید.
در هر صورت، server B باید به نوعی با Backpressure مقابله کند. Buffer کردن آن کسری ۲۵ rps یک گزینه است، اما اگر آن افزایش ثابت بماند، به زودی memory تمام میشود و از کار میافتد. Drop کردن درخواستها گزینه دیگری است که در اکثر سناریو ها قابل قبول نیست.
گزینه ایدهآل این است که server B نرخ ارسال درخواستهای server A را کنترل کند، اما باز هم این همیشه عملی نیست - اگر server A به نمایندگی از یک کاربر درخواست میکند، شما نمیتوانید کاربر ها را کنترل کنید که آهستهتر شوند، اغلب بهتر است که server درخواست کننده buffer داشته باشد، تا بتوانید بار memory را در downstream، جایی که استرس وجود دارد، بهتر توزیع کنید و بر سایر درخواست کنندگان تأثیر نگذارید.
به عنوان مثال، اگر سه نوع مختلف سرویس (A, B, C) همگی به یک سرویس downstream مشترک (Z) درخواست بدهند، و یکی از آنها (A) تحت بار بالا باشد، سرویس Z میتواند به طور موثر به سرویس A بگوید "آهستهتر شو" (کنترل producer) که باعث میشود سرویس A درخواستها را buffer کند. اگر این ادامه پیدا کند، در نهایت سرویس A با کمبود memory مواجه میشود، با این حال، دو سرویس دیگر (B, C) همچنان فعال میمانند، همانطور که سرویس downstream Z نیز فعال میماند زیرا اجازه نمیدهد یک سرویس بدرفتار از دسترسی برابر برای دیگران جلوگیری کند. در این مورد ممکن است قطعی اجتنابناپذیر باشد، اما ما محدوده را محدود کردیم و از Denial of Service زنجیرهای جلوگیری کردیم.
مثال ها:
https://medium.com/@jayphelps/backpressure-explained-the-flow-of-data-through-software-2350b3e77ce7
#Backpressure
@Syntax_fa
👍5❤2👻2🔥1
وقتی به جای سیستمها، انسانها هک میشوند!
طبق تحقیقات و گزارشها، تخمین زده میشود که حدود 70 تا 90 درصد از حملات سایبری موفق، به نوعی از تکنیکهای مهندسی اجتماعی استفاده میکنند. این آمار نشاندهنده اهمیت آموزش و آگاهیبخشی به کاربران برای کاهش ریسک این گونه حملات است.
https://youtu.be/Z_S9jFkdCjY
@Syntax_fa
طبق تحقیقات و گزارشها، تخمین زده میشود که حدود 70 تا 90 درصد از حملات سایبری موفق، به نوعی از تکنیکهای مهندسی اجتماعی استفاده میکنند. این آمار نشاندهنده اهمیت آموزش و آگاهیبخشی به کاربران برای کاهش ریسک این گونه حملات است.
https://youtu.be/Z_S9jFkdCjY
@Syntax_fa
👍7👻4😱2
This media is not supported in your browser
VIEW IN TELEGRAM
یه تنوعی بدین به خودتون😂🔥
VsCode Extention : power mode
VsCode Extention : power mode
👻11🤣7🔥1
Forwarded from Normal Developer
مشکل خود سنیور پنداری!
جدیدا خیلیا رو میبینم که قبل از تخصصشون عنوان سنیور رو وصل میکنن. ولی واقعیت امر اینه که سنیور بودن یه لقب نیست. به زمان هم خیلی بستگی نداره که بعد از فعالیت n ساله در یک زمینه شما به این مرحله برسید.
کسی که خودش رو سنیور خطاب میکنه در واقع مهارت های خیلی زیادی رو باید داشته باشه که یکیشون برنامه نویسیه!
مهارت های نرم، مهارت یادگیری چیزهای جدید، طرز فکر و راهکار یابی و ... بخشی از پیشنیاز این صفت میشه.
تو فرایند جذب نیروی جدید برای شرکتمون رزومه های زیادی رو چک کردم و واقعا همه دوست دارن این عنوان رو قبل اسمشون داشته باشن.
عجیب ترین چیزی که دیدم هم مربوط میشه به یه فردی که بعد از یه بوت کمپ با یه شرکت شروع به همکاری چند ماهه کرده بود و عنوان شغلی خودش تو اون شرکت رو نوشته بود "Senior Django Developer"!
یعنی در فاصله کمتر از چند ماه به این درجه از عرفان رسیده بوده!
@normal_developer
جدیدا خیلیا رو میبینم که قبل از تخصصشون عنوان سنیور رو وصل میکنن. ولی واقعیت امر اینه که سنیور بودن یه لقب نیست. به زمان هم خیلی بستگی نداره که بعد از فعالیت n ساله در یک زمینه شما به این مرحله برسید.
کسی که خودش رو سنیور خطاب میکنه در واقع مهارت های خیلی زیادی رو باید داشته باشه که یکیشون برنامه نویسیه!
مهارت های نرم، مهارت یادگیری چیزهای جدید، طرز فکر و راهکار یابی و ... بخشی از پیشنیاز این صفت میشه.
تو فرایند جذب نیروی جدید برای شرکتمون رزومه های زیادی رو چک کردم و واقعا همه دوست دارن این عنوان رو قبل اسمشون داشته باشن.
عجیب ترین چیزی که دیدم هم مربوط میشه به یه فردی که بعد از یه بوت کمپ با یه شرکت شروع به همکاری چند ماهه کرده بود و عنوان شغلی خودش تو اون شرکت رو نوشته بود "Senior Django Developer"!
یعنی در فاصله کمتر از چند ماه به این درجه از عرفان رسیده بوده!
@normal_developer
👍22🤣9😁2
Hard Coding
به معنای استفاده از مقادیر ثابت و تعریفشده درون کد یک برنامه، بهجای استفاده از ورودیهای داینامیک، متغیرها یا منابع خارجی (مثل فایلهای کانفیگ یا پایگاههای داده). در این روش، مقادیر بهصورت مستقیم در کد قرار میگیرند و برای تغییر آنها نیاز به ویرایش دستی کد است.
مثال ساده:
مزایای Hard Coding
1. سادگی اولیه: کدنویسی سریعتر و آسانتر است، زیرا نیازی به ایجاد ساختارهای پیچیده برای مدیریت مقادیر نیست.
2. کاهش پیچیدگی در پروژههای کوچک: در برنامههای کوچک و ساده، ممکن است نیازی به طراحی سیستمهای دینامیک برای مدیریت مقادیر نباشد.
3. کاهش وابستگی به منابع خارجی: در صورت hard coding، نیازی به مدیریت فایلهای پیکربندی، پایگاه داده یا ورودیهای خارجی وجود ندارد.
معایب Hard Coding
1. کاهش انعطافپذیری: تغییر مقادیر ثابت نیازمند تغییر کد منبع و بازنویسی یا بازسازی برنامه است، که میتواند زمانبر باشد.
2. نگهداری سختتر: در برنامههای بزرگ، مدیریت مقادیر hard coded دشوار است و میتواند باعث افزایش احتمال بروز خطا شود.
3. محدودیت در تنظیمات داینامیک: برنامههای مبتنی بر hard coding نمیتوانند به راحتی خود را با شرایط یا محیطهای مختلف سازگار کنند.
جایگزینها برای Hard Coding
1. استفاده از فایلهای تنظیمات (Config Files): ذخیره مقادیر در فایلهای خارجی مانند
2. دیتابیس: استفاده از دیتابیس برای مدیریت مقادیر پویا.
3. متغیرهای محیطی (Environment Variables): استفاده از متغیرهای سیستمعامل برای ذخیره مقادیر حساس مانند secret key.
4. ورودیهای پویا از کاربر: گرفتن مقادیر از کاربر بهصورت runtime.
متغیر هایی که حساس نیستند بهتره براشون fallback تعریف کنیم.
برای مثال اول چک بشه اگه بصورت دستی داخل کانفیگ مقداری براشون ست شده، از اونجا بخونه ولی اگه نبود با مقدار پیشفرض کار کنه و اروری نده. تا برناممون برای استفاده راحت تر باشه و برای شخصی سازی هم دستمون رو باز بذاره.
#hard_coding
@Syntax_fa
به معنای استفاده از مقادیر ثابت و تعریفشده درون کد یک برنامه، بهجای استفاده از ورودیهای داینامیک، متغیرها یا منابع خارجی (مثل فایلهای کانفیگ یا پایگاههای داده). در این روش، مقادیر بهصورت مستقیم در کد قرار میگیرند و برای تغییر آنها نیاز به ویرایش دستی کد است.
مثال ساده:
# Hard coded example
deposit = 0.1
price = 100
final_price = price + (price * deposit)
print(final_price)
مزایای Hard Coding
1. سادگی اولیه: کدنویسی سریعتر و آسانتر است، زیرا نیازی به ایجاد ساختارهای پیچیده برای مدیریت مقادیر نیست.
2. کاهش پیچیدگی در پروژههای کوچک: در برنامههای کوچک و ساده، ممکن است نیازی به طراحی سیستمهای دینامیک برای مدیریت مقادیر نباشد.
3. کاهش وابستگی به منابع خارجی: در صورت hard coding، نیازی به مدیریت فایلهای پیکربندی، پایگاه داده یا ورودیهای خارجی وجود ندارد.
معایب Hard Coding
1. کاهش انعطافپذیری: تغییر مقادیر ثابت نیازمند تغییر کد منبع و بازنویسی یا بازسازی برنامه است، که میتواند زمانبر باشد.
2. نگهداری سختتر: در برنامههای بزرگ، مدیریت مقادیر hard coded دشوار است و میتواند باعث افزایش احتمال بروز خطا شود.
3. محدودیت در تنظیمات داینامیک: برنامههای مبتنی بر hard coding نمیتوانند به راحتی خود را با شرایط یا محیطهای مختلف سازگار کنند.
جایگزینها برای Hard Coding
1. استفاده از فایلهای تنظیمات (Config Files): ذخیره مقادیر در فایلهای خارجی مانند
JSON`، `YAML`، یا `INI.2. دیتابیس: استفاده از دیتابیس برای مدیریت مقادیر پویا.
3. متغیرهای محیطی (Environment Variables): استفاده از متغیرهای سیستمعامل برای ذخیره مقادیر حساس مانند secret key.
4. ورودیهای پویا از کاربر: گرفتن مقادیر از کاربر بهصورت runtime.
متغیر هایی که حساس نیستند بهتره براشون fallback تعریف کنیم.
برای مثال اول چک بشه اگه بصورت دستی داخل کانفیگ مقداری براشون ست شده، از اونجا بخونه ولی اگه نبود با مقدار پیشفرض کار کنه و اروری نده. تا برناممون برای استفاده راحت تر باشه و برای شخصی سازی هم دستمون رو باز بذاره.
#hard_coding
@Syntax_fa
👍12🔥2👻2