تحلیل دیتاست‌های جدولی (Tabular) هم در ریسرچ و هم در کاربردهای واقعی خیلی مورد توجه هست. مقایسه‌هایی که تا الان انجام شده، نشون میده عملکرد مدل‌های دیپ اغلب پایین‌تر یا هم‌سطح مدل‌های بوستینگ گرادیان (GBMs) هست.
میخوام درباره مقاله‌ای صحبت کنم که مقایسه عمیقی روی مدل‌های آنسامبل مبتنی بر درخت تصمیم (TE)، دیپ (DL) و مدل‌های کلاسیک ML انجام داده. عنوان مقاله:
A Comprehensive Benchmark of Machine and Deep Learning Across Diverse Tabular Datasets link
حدود 111 دیتاست جدولی و 20 مدل مختلف برای مقایسه انتخاب شده. مقایسه‌های متنوعی انجام شده؛ مقایسه عملکرد مدل‌های DL و TE رو در تصویر بالا آوردم. نتایج جالبی بدست اومده:
* مدل CatBoost در 19 مورد از 111 دیتاست بهترین بوده.
* رتبه Random Forest قابل توجه هست.
* مدل XGBoost که خیلی‌ها انتخاب اولشون هست، در رتبه 10 دیده میشه!
* رتبه اول تا چهارم رو مدل‌های ML اشغال کردن.
* اولین مدل دیپ لرنینگی در رتبه 5 دیده میشه.
* شبکه MLP در رتبه 9 دیده میشه.
* شبکه TabNet آخره!
مقاله بخش‌های متنوعی داره و من فقط یک مقایسه رو آوردم. شاید بعدا بیشتر بنویسم.
میخوام درباره مقاله‌ای صحبت کنم که مقایسه عمیقی روی مدل‌های آنسامبل مبتنی بر درخت تصمیم (TE)، دیپ (DL) و مدل‌های کلاسیک ML انجام داده. عنوان مقاله:
A Comprehensive Benchmark of Machine and Deep Learning Across Diverse Tabular Datasets link
حدود 111 دیتاست جدولی و 20 مدل مختلف برای مقایسه انتخاب شده. مقایسه‌های متنوعی انجام شده؛ مقایسه عملکرد مدل‌های DL و TE رو در تصویر بالا آوردم. نتایج جالبی بدست اومده:
* مدل CatBoost در 19 مورد از 111 دیتاست بهترین بوده.
* رتبه Random Forest قابل توجه هست.
* مدل XGBoost که خیلی‌ها انتخاب اولشون هست، در رتبه 10 دیده میشه!
* رتبه اول تا چهارم رو مدل‌های ML اشغال کردن.
* اولین مدل دیپ لرنینگی در رتبه 5 دیده میشه.
* شبکه MLP در رتبه 9 دیده میشه.
* شبکه TabNet آخره!
مقاله بخش‌های متنوعی داره و من فقط یک مقایسه رو آوردم. شاید بعدا بیشتر بنویسم.
Forwarded from CodeCrafters (Behzad Azadi)
از جان مهندسین نرم افزار چه میخواهند؟؟
با توجه به انقلاب تکنولوژی و عصر ارتباطات و همچنین حرکت بسوی جوامع الکترونیک نیازهای جدیدی احساس شد، سازمانها روز به روز وابسته‌تر و نیازمندتر به نرم‌افزارها شدند چه نرم افزارهای خدماتی جهت توسعه و تسریع درون سازمانی خود، چه نرم‌افزارهای سیستمی مخصوص خود سازمان، بدین شکل سیستم‌های نرم افزاری به قلب تپنده هر سازمانی تبدیل گشت و موجب شد جایگاه ویژه‌ای در سازمانها با نام مهندس نرم افزار بوجود آید
اگر از سیر تاریخی مهندسی نرم افزار عبور کنیم بدون شک رویکرد اجایل دست کمی از یک انقلاب تفکری و رویکردی نداشت شاید با طنز بتوان گفت مهندسی نرم افزار به قبل و بعد از اجایل تقسیم خواهد شد
اما در پاسخ به این سوال که از جان مهندسین نرم افزار چه میخواهند، پاسخ بدین شکل خواهد بود، علاوه بر ساختن صحیح یک نرم افزار ،انتظار می‌رود که یک نرم افزار مناسب ساخته شود
در این سری از پست‌ها میخواهیم راجب BDD (Behavior-Driven Development) توسعه مبتنی بر رفتار صحبت کنیم که از بالاترین سطح تا پایینترین سطح کدزنی را تحت تاثیر خواهد گذاشت و منجر به ایجاد یک نرم افزار مناسب میشود و علاوه بر آن به شما کمک خواهد کرد تا به یکی از بزرگترین چالش‌های موجود که زمان تحویل بموقع نرم افزار است فائق آیید
شاید تا کنون براتون سوال شده که چرا فلان سازمان با صرف هزینه‌های گزاف و سرسام آور هیچوقت نتوانست یک نرم افزار درخور و شایسته ارائه دهد و هیچوقت به خروجی درست و مناسب نرسید، BDD بر این ماجرا متمرکز است و با طرح این مسئله و شکافتن و بررسی کردن این موضوع به ما پاسخ خواهد داد و به ما خواهد گفت چه کسی یا کسانی را باید مورد هدف قرار دهیم
شما با ردگیری دو هشتک زیر در کانال ازین ببعد میتوانید به سلسله پست‌ها مربوط به توسعه رفتار محور دست پیدا کنید
#BDD
#behavior_driven_development
@code_crafters
با توجه به انقلاب تکنولوژی و عصر ارتباطات و همچنین حرکت بسوی جوامع الکترونیک نیازهای جدیدی احساس شد، سازمانها روز به روز وابسته‌تر و نیازمندتر به نرم‌افزارها شدند چه نرم افزارهای خدماتی جهت توسعه و تسریع درون سازمانی خود، چه نرم‌افزارهای سیستمی مخصوص خود سازمان، بدین شکل سیستم‌های نرم افزاری به قلب تپنده هر سازمانی تبدیل گشت و موجب شد جایگاه ویژه‌ای در سازمانها با نام مهندس نرم افزار بوجود آید
اگر از سیر تاریخی مهندسی نرم افزار عبور کنیم بدون شک رویکرد اجایل دست کمی از یک انقلاب تفکری و رویکردی نداشت شاید با طنز بتوان گفت مهندسی نرم افزار به قبل و بعد از اجایل تقسیم خواهد شد
من در ذهن خودم بدین شکل می‌اندیشم: مهندسی نرم افزار کلاسیک و مهندسی نرم افزار مدرن مبتنی بر اجایل
اما در پاسخ به این سوال که از جان مهندسین نرم افزار چه میخواهند، پاسخ بدین شکل خواهد بود، علاوه بر ساختن صحیح یک نرم افزار ،انتظار می‌رود که یک نرم افزار مناسب ساخته شود
در این سری از پست‌ها میخواهیم راجب BDD (Behavior-Driven Development) توسعه مبتنی بر رفتار صحبت کنیم که از بالاترین سطح تا پایینترین سطح کدزنی را تحت تاثیر خواهد گذاشت و منجر به ایجاد یک نرم افزار مناسب میشود و علاوه بر آن به شما کمک خواهد کرد تا به یکی از بزرگترین چالش‌های موجود که زمان تحویل بموقع نرم افزار است فائق آیید
شاید تا کنون براتون سوال شده که چرا فلان سازمان با صرف هزینه‌های گزاف و سرسام آور هیچوقت نتوانست یک نرم افزار درخور و شایسته ارائه دهد و هیچوقت به خروجی درست و مناسب نرسید، BDD بر این ماجرا متمرکز است و با طرح این مسئله و شکافتن و بررسی کردن این موضوع به ما پاسخ خواهد داد و به ما خواهد گفت چه کسی یا کسانی را باید مورد هدف قرار دهیم
شما با ردگیری دو هشتک زیر در کانال ازین ببعد میتوانید به سلسله پست‌ها مربوط به توسعه رفتار محور دست پیدا کنید
#BDD
#behavior_driven_development
@code_crafters
❤2
شاپرک برگزار میکند: رویداد امنیت سایبری CASH24
رویداد فتح پرچم CASH24 با هدف ارتقاء دانش و مهارت‌های امنیت سایبری به ویژه در صنعت پرداخت برای نخستین بار از سوی شرکت شاپرک برگزار میشود.
به گزارش روابط عمومی شرکت شاپرک، این رویداد در دو بخش مسابقه CTF و همایش علمی طی سه روز در هفته آخر شهریور ماه و با حضور مدیران ارشد بانک مرکزی، گروه ملی انفورماتیک و متخصصان امنیت سایبری برگزار خواهد شد.
نخستین دوره از رقابت‌های تست نفوذ سایبری شاپرک تحت عنوان رقابت‌های فتح پرچم (Capture the Flag (CTF با هدف شناسایی و مقابله با آسیب‌پذیری‌های محصولات نرم‌افزاری و سامانه‌های امنیتی در روزهای 24 و 25 شهریورماه به صورت آنلاین برگزار میشود.
مسابقهCASH24 (CTF Arena For Security & Hacking) شاپرک شامل بخش‌های مختلفی از جمله امنیت برنامه‌های وب و برنامک‌های موبایل، رمزنگاری و مهندسی معکوس و تحلیل جرم‌شناسی دیجیتال است.
جوایز تیم‌های برنده که شامل جایزه‌های ارزنده‌ای است، همزمان با رویداد امنیت سایبری شاپرک به برندگان اهدا خواهد شد.
رویداد علمی ـ تخصصی امنیت سایبری شاپرک با همکاری آکادینو و حمایت چهار شرکت پرداخت الکترونیک امیدپی، به پرداخت، پارسیان و سپ در روز 27 شهریورماه در قالب کارگاه‌ها و سخنرانی‌های علمی برگزار خواهد شد.
تیم‌های علاقه‌مند برای شرکت در مسابقه می‌توانند از طریق لینک زیر ثبت نام کنند:
https://cash.ctfd.io
رویداد فتح پرچم CASH24 با هدف ارتقاء دانش و مهارت‌های امنیت سایبری به ویژه در صنعت پرداخت برای نخستین بار از سوی شرکت شاپرک برگزار میشود.
به گزارش روابط عمومی شرکت شاپرک، این رویداد در دو بخش مسابقه CTF و همایش علمی طی سه روز در هفته آخر شهریور ماه و با حضور مدیران ارشد بانک مرکزی، گروه ملی انفورماتیک و متخصصان امنیت سایبری برگزار خواهد شد.
نخستین دوره از رقابت‌های تست نفوذ سایبری شاپرک تحت عنوان رقابت‌های فتح پرچم (Capture the Flag (CTF با هدف شناسایی و مقابله با آسیب‌پذیری‌های محصولات نرم‌افزاری و سامانه‌های امنیتی در روزهای 24 و 25 شهریورماه به صورت آنلاین برگزار میشود.
مسابقهCASH24 (CTF Arena For Security & Hacking) شاپرک شامل بخش‌های مختلفی از جمله امنیت برنامه‌های وب و برنامک‌های موبایل، رمزنگاری و مهندسی معکوس و تحلیل جرم‌شناسی دیجیتال است.
جوایز تیم‌های برنده که شامل جایزه‌های ارزنده‌ای است، همزمان با رویداد امنیت سایبری شاپرک به برندگان اهدا خواهد شد.
رویداد علمی ـ تخصصی امنیت سایبری شاپرک با همکاری آکادینو و حمایت چهار شرکت پرداخت الکترونیک امیدپی، به پرداخت، پارسیان و سپ در روز 27 شهریورماه در قالب کارگاه‌ها و سخنرانی‌های علمی برگزار خواهد شد.
تیم‌های علاقه‌مند برای شرکت در مسابقه می‌توانند از طریق لینک زیر ثبت نام کنند:
https://cash.ctfd.io
توی برنامه نویسی زیادی خسیس نباشید
اگه ذهنیتتون به سمتی بره که همیشه در حال محاسبه باشه چه حرکتی بزنم که حافظه کمتر و سرعت بیشتری داشته باشه توی باتلاق میفتید و قدرت ساختن یه سیستم بزرگ و انعطاف پذیر رو از دست میدید.
بعضی مواقع انقدری به سمت الگوریتم میریم که داریم به کلیت سیستم آسیب میزنیم مثلا قراره یه دیتایی ارسال کنیم بجای اینکه به این شکل ارسال کنیم
{"name":"linuxor","type":"channel"}
میایم یه صرفه جویی کثیف میکنیم
["linuxor",2]
ما اینجا توی حافظه صرفه جویی کردیم ولی هر جایی بخوایم از این دیتا استفاده کنیم باید بدونیم ایندکس صفرم name هست و ایندکس یکم type و عدد 2 هم برای type یعنی channel این یعنی نیاز به مستندات بیشتر.
درسته حافظه کمتری مصرف کردیم ولی قدرت خوانایی کد رو آوردیم پایین در واقع با بهتر کردن یه بخش جزئی سیستم به کلیت سیستم آسیب زدیم، و اگه این کارو هی توی بخش های مختلف سیستم تکرار کنیم در نهایت به جایی میرسیم که دیگه صرفه نداره سیستم رو توسعه بدیم.
اگه ذهنیتتون به سمتی بره که همیشه در حال محاسبه باشه چه حرکتی بزنم که حافظه کمتر و سرعت بیشتری داشته باشه توی باتلاق میفتید و قدرت ساختن یه سیستم بزرگ و انعطاف پذیر رو از دست میدید.
بعضی مواقع انقدری به سمت الگوریتم میریم که داریم به کلیت سیستم آسیب میزنیم مثلا قراره یه دیتایی ارسال کنیم بجای اینکه به این شکل ارسال کنیم
{"name":"linuxor","type":"channel"}
میایم یه صرفه جویی کثیف میکنیم
["linuxor",2]
ما اینجا توی حافظه صرفه جویی کردیم ولی هر جایی بخوایم از این دیتا استفاده کنیم باید بدونیم ایندکس صفرم name هست و ایندکس یکم type و عدد 2 هم برای type یعنی channel این یعنی نیاز به مستندات بیشتر.
درسته حافظه کمتری مصرف کردیم ولی قدرت خوانایی کد رو آوردیم پایین در واقع با بهتر کردن یه بخش جزئی سیستم به کلیت سیستم آسیب زدیم، و اگه این کارو هی توی بخش های مختلف سیستم تکرار کنیم در نهایت به جایی میرسیم که دیگه صرفه نداره سیستم رو توسعه بدیم.
برخلاف تصور عام که فکر میکنن با افزایش تعداد پردازنده ها سرعت اجرای یه برنامه افزایش پیدا میکنه،
آمدال ثابت کرد که در واقع الگوریتم نقش تعیین کننده ای داره و افزایش تعداد پردازنده ها به یه مقدار محدودی میتونه توی روند افزایش سرعت به ما کمک کنه.
و این تصور که اگه تعداد پردازنده هارو به سمت بی نهایت ببریم سرعت هم بینهایت افزایش پیدا میکنه اشتباهه و در نهایت به یه جایی میرسه که دیگه با افزایش تعداد پردازنده سرعت بیشتر نمیشه.
آمدال ثابت کرد که در واقع الگوریتم نقش تعیین کننده ای داره و افزایش تعداد پردازنده ها به یه مقدار محدودی میتونه توی روند افزایش سرعت به ما کمک کنه.
و این تصور که اگه تعداد پردازنده هارو به سمت بی نهایت ببریم سرعت هم بینهایت افزایش پیدا میکنه اشتباهه و در نهایت به یه جایی میرسه که دیگه با افزایش تعداد پردازنده سرعت بیشتر نمیشه.
👎1👏1
وقتی که دو نفر، در دو منطقه‌ی جغرافیایی، همزمان اقدام به نصب یک کتابخونه، بعنوان مثال با دستور
pip install 'NAME-OF-LIBRARY'
میکنند، لزومن ورژن هر دو شخص برابر نخواهد بود. حتی اگر ورژن پیپ و پایتون در هر دو سیستم برابر باشه.
این نکته در هنگام کار و تست کدها خیلی مهمه که دقیقن نسخه کتابخونه رو چک کنیم. دلیل این اختلاف هم، از این بابت هست که ممکنه برای هر شخص یک مخزن خاص برای دانلود توسط پیپ در شبکه مشخص بشه. پیپ در هنگام نصب، سعی میکنه نزدیکترین مخزن رو برای دانلود انتخاب کند.
یعنی، برای شخص اول، آخرین ورژن دانلود و نصب بشه، در حالی که نفر دوم، از مخزنی اقدام به دانلود کنه که هنوز فرایند آپلود آخرین نسخه تکمیل نشده است و ورژنی که نصب میشه، قدیمی باشد.
و همین اختلاف‌های ریز، گاهن مشکلات بزرگی رو تولید میکنه. حالا برو بگرد دنبال دلیل 😎.
راه حلش هم ساده است؛ یا دقیقن ورژن مد نظر رو ذکر کنیم. یا هر دو شخص از یک آدرس مخزن استفاده کنند.
pip install 'NAME-OF-LIBRARY'
میکنند، لزومن ورژن هر دو شخص برابر نخواهد بود. حتی اگر ورژن پیپ و پایتون در هر دو سیستم برابر باشه.
این نکته در هنگام کار و تست کدها خیلی مهمه که دقیقن نسخه کتابخونه رو چک کنیم. دلیل این اختلاف هم، از این بابت هست که ممکنه برای هر شخص یک مخزن خاص برای دانلود توسط پیپ در شبکه مشخص بشه. پیپ در هنگام نصب، سعی میکنه نزدیکترین مخزن رو برای دانلود انتخاب کند.
یعنی، برای شخص اول، آخرین ورژن دانلود و نصب بشه، در حالی که نفر دوم، از مخزنی اقدام به دانلود کنه که هنوز فرایند آپلود آخرین نسخه تکمیل نشده است و ورژنی که نصب میشه، قدیمی باشد.
و همین اختلاف‌های ریز، گاهن مشکلات بزرگی رو تولید میکنه. حالا برو بگرد دنبال دلیل 😎.
راه حلش هم ساده است؛ یا دقیقن ورژن مد نظر رو ذکر کنیم. یا هر دو شخص از یک آدرس مخزن استفاده کنند.
👍2
یکی از مهمترین مفاهیم پایه در Generative AI و پردازش تصویر رو میخوام بهتون توضیح بدهم.
همون طور که میدونید عکس هم یه نوع دیتای کامپوتری هست و از یه سری ماتریکس با اعداد و ارقامی تشکیل شده ولی این اعداد و ارقام چی هستند؟
یکی از سیستم های رنگی که عکس رو داخل اون تعریف میکنند سیستم RGB هست و مخفف سه رنگ Red, Green و Blue هست. در واقع هر عکسی که از تابش نور درست شده باشه از ترکیب این سه رنگ تشکیل شده.
به این سه تا رنگ میگن کانال (Channel).
میدونیم به کوچکترین واحد یک عکس پیکسل میگن، اینم میدونیم که هر عکسی یک سایز داره، یعنی یک طول و یک عرض. وقتی مثلا میگیم این عکس طولش ۱۰ و عرضش ۱۰ است یعنی طول این عکس به اندازه ۱۰ تا پیکسل ارتفاع داره (ده تا از اون مربع کوچیک ها که من با کاغذ شطرنجی ساختم) و عرضش هم همینطور.
و هر کدوم از پیکسل های یک عکس هم یک عدد R، یک عدد G و یک عدد B به خودش میگیره که این مفهومش اینه که هر پیکسل یک عکس یه شدتی از رنگ های قرمز و سبز و آبی داره و این عدد بین صفر تا ۲۵۶ هست (در سیستم های ۸ بیتی چون دو به توان ۸ میشه ۲۵۶).
#پردازش_تصویر
همون طور که میدونید عکس هم یه نوع دیتای کامپوتری هست و از یه سری ماتریکس با اعداد و ارقامی تشکیل شده ولی این اعداد و ارقام چی هستند؟
یکی از سیستم های رنگی که عکس رو داخل اون تعریف میکنند سیستم RGB هست و مخفف سه رنگ Red, Green و Blue هست. در واقع هر عکسی که از تابش نور درست شده باشه از ترکیب این سه رنگ تشکیل شده.
به این سه تا رنگ میگن کانال (Channel).
میدونیم به کوچکترین واحد یک عکس پیکسل میگن، اینم میدونیم که هر عکسی یک سایز داره، یعنی یک طول و یک عرض. وقتی مثلا میگیم این عکس طولش ۱۰ و عرضش ۱۰ است یعنی طول این عکس به اندازه ۱۰ تا پیکسل ارتفاع داره (ده تا از اون مربع کوچیک ها که من با کاغذ شطرنجی ساختم) و عرضش هم همینطور.
و هر کدوم از پیکسل های یک عکس هم یک عدد R، یک عدد G و یک عدد B به خودش میگیره که این مفهومش اینه که هر پیکسل یک عکس یه شدتی از رنگ های قرمز و سبز و آبی داره و این عدد بین صفر تا ۲۵۶ هست (در سیستم های ۸ بیتی چون دو به توان ۸ میشه ۲۵۶).
#پردازش_تصویر
🔥1
Forwarded from Ninja Learn | نینجا لرن
بچه‌ها سلام 👋
امروز میخوام یه سری تجربیات و نکات رو باهاتون به اشتراک بذارم. 😊
تو این مسیر بک‌اند دولوپری، چیزایی هست که شاید اولش به نظر مهم نیاد ولی واقعاً اهمیت داره. بیاید با هم مرور کنیم:
1⃣ دیتابیس‌ها رو جدی بگیرید
از همون اول کار دیتابیس رو دست‌کم نگیرید. خیلی وقتا دولوپرها دیتابیس رو فقط یه محل ذخیره داده می‌بینن ولی واقعیت اینه که نحوه طراحی و مدیریت دیتابیس تاثیر زیادی روی عملکرد کلی سیستم داره. ساختار درست دیتابیس، ایندکس‌ها، نرمال‌سازی و حتی دِنورمال‌سازی وقتی لازمه، همه اینا چیزایی هست که باید بلد باشی.
2⃣ فریمورک مهمه، ولی تسلط به مفاهیم مهم‌تره
ببینید، همه ما از یه جایی شروع کردیم و احتمالا با یه فریمورک خاص، مثل Django یا Laravel، کار رو شروع کردیم. ولی اگه به مفاهیم پایه‌ای مثل HTTP، RESTful APIs، و اصول SOLID مسلط باشی، راحتتر می‌تونی با فریم‌ورک‌های مختلف کار کنی. یادگیری یه فریمورک جدید نباید برات چالشی باشه اگه مفاهیم اساسی رو بلدی.
3⃣ کد خوانا بنویس، نه فقط برای کامپایلر، برای بقیه هم!
این نکته شاید تکراری باشه ولی هنوزم خیلیا رعایت نمی‌کنن. کد رو جوری بنویس که خودت یا هر کس دیگه‌ای که قراره بعداً باهاش کار کنه، راحت بفهمه. کامنت‌های بیجا هم ننویس ولی اگه جایی پیچیده‌ست، کامنت بذار. یادت باشه: «کد برای کامپیوتر نوشته نمیشه، برای آدم‌ها نوشته میشه.»
4⃣ تست نویسی از نون شب واجب‌تره
این یکی از اون چیزاییه که خود منم اولش ازش فراری بودم، ولی وقتی میری تو پروژه‌های بزرگ، می‌فهمی که بدون تست درست و حسابی، خیلی راحت ممکنه همه چی به هم بریزه. یونیت تست‌ها، اینتگریشن تست‌ها، و حتی تست‌های خودکار (Automated Tests) رو حتماً تو برنامه‌هات بزار.
5⃣ همیشه در حال یادگیری باش
دنیای برنامه‌نویسی خیلی سریع تغییر میکنه. امروز یه تکنولوژی خیلی خفنه، فردا یه چیز جدید میاد و همه ازش حرف می‌زنن. خودت رو محدود به یه زبان یا تکنولوژی نکن. دائماً در حال یادگیری باش، حتی اگه شده یه ساعتی در هفته رو به یادگیری اختصاص بده.
6⃣ همکار خوب بودن رو یاد بگیر
آخرش همونطور که همه میدونیم، بک‌اند دولوپری فقط کد زدن نیست. باید با بقیه اعضای تیم هماهنگ باشی، با فرانت‌اندی‌ها، دیزاینرها، و حتی مشتریا ارتباط خوبی داشته باشی. همکار خوب بودن و داشتن مهارت‌های نرم (soft skills) هم بخشی از این شغل هست.
خب بچه‌ها، این‌ها تجربیات و نکاتی بود که دوست داشتم باهاتون به اشتراک بذارم.
امیدوارم براتون مفید بوده باشه. 🌹
اگه سوالی دارید یا می‌خواید در مورد موضوع خاصی بیشتر بدونید، کامنت بذارید یا دایرکت بدید.
به امید موفقیت‌های بیشتر برای همتون! ✌🏻
@ninja_learn_ir
امروز میخوام یه سری تجربیات و نکات رو باهاتون به اشتراک بذارم. 😊
تو این مسیر بک‌اند دولوپری، چیزایی هست که شاید اولش به نظر مهم نیاد ولی واقعاً اهمیت داره. بیاید با هم مرور کنیم:
1⃣ دیتابیس‌ها رو جدی بگیرید
از همون اول کار دیتابیس رو دست‌کم نگیرید. خیلی وقتا دولوپرها دیتابیس رو فقط یه محل ذخیره داده می‌بینن ولی واقعیت اینه که نحوه طراحی و مدیریت دیتابیس تاثیر زیادی روی عملکرد کلی سیستم داره. ساختار درست دیتابیس، ایندکس‌ها، نرمال‌سازی و حتی دِنورمال‌سازی وقتی لازمه، همه اینا چیزایی هست که باید بلد باشی.
2⃣ فریمورک مهمه، ولی تسلط به مفاهیم مهم‌تره
ببینید، همه ما از یه جایی شروع کردیم و احتمالا با یه فریمورک خاص، مثل Django یا Laravel، کار رو شروع کردیم. ولی اگه به مفاهیم پایه‌ای مثل HTTP، RESTful APIs، و اصول SOLID مسلط باشی، راحتتر می‌تونی با فریم‌ورک‌های مختلف کار کنی. یادگیری یه فریمورک جدید نباید برات چالشی باشه اگه مفاهیم اساسی رو بلدی.
3⃣ کد خوانا بنویس، نه فقط برای کامپایلر، برای بقیه هم!
این نکته شاید تکراری باشه ولی هنوزم خیلیا رعایت نمی‌کنن. کد رو جوری بنویس که خودت یا هر کس دیگه‌ای که قراره بعداً باهاش کار کنه، راحت بفهمه. کامنت‌های بیجا هم ننویس ولی اگه جایی پیچیده‌ست، کامنت بذار. یادت باشه: «کد برای کامپیوتر نوشته نمیشه، برای آدم‌ها نوشته میشه.»
4⃣ تست نویسی از نون شب واجب‌تره
این یکی از اون چیزاییه که خود منم اولش ازش فراری بودم، ولی وقتی میری تو پروژه‌های بزرگ، می‌فهمی که بدون تست درست و حسابی، خیلی راحت ممکنه همه چی به هم بریزه. یونیت تست‌ها، اینتگریشن تست‌ها، و حتی تست‌های خودکار (Automated Tests) رو حتماً تو برنامه‌هات بزار.
5⃣ همیشه در حال یادگیری باش
دنیای برنامه‌نویسی خیلی سریع تغییر میکنه. امروز یه تکنولوژی خیلی خفنه، فردا یه چیز جدید میاد و همه ازش حرف می‌زنن. خودت رو محدود به یه زبان یا تکنولوژی نکن. دائماً در حال یادگیری باش، حتی اگه شده یه ساعتی در هفته رو به یادگیری اختصاص بده.
6⃣ همکار خوب بودن رو یاد بگیر
آخرش همونطور که همه میدونیم، بک‌اند دولوپری فقط کد زدن نیست. باید با بقیه اعضای تیم هماهنگ باشی، با فرانت‌اندی‌ها، دیزاینرها، و حتی مشتریا ارتباط خوبی داشته باشی. همکار خوب بودن و داشتن مهارت‌های نرم (soft skills) هم بخشی از این شغل هست.
خب بچه‌ها، این‌ها تجربیات و نکاتی بود که دوست داشتم باهاتون به اشتراک بذارم.
امیدوارم براتون مفید بوده باشه. 🌹
اگه سوالی دارید یا می‌خواید در مورد موضوع خاصی بیشتر بدونید، کامنت بذارید یا دایرکت بدید.
به امید موفقیت‌های بیشتر برای همتون! ✌🏻
@ninja_learn_ir
👍2
دیروز تو کارخونه ی نوآوری آزادی داشتم با یکی از همکارانم صحبت میکردیم که چرا open ai تو قسمتی از پروژه هاش از زبان Go استفاده کرده به جای #پایتون. ایشون گفتند به خاطر اینکه زبان پایتون یک زبان مفسری هست و زبان های مفسری سرعت اجراشون کند هست.
تو این موضوع خیلی حرف دارم که چرا با وجود کند بودن پایتون همچنان این زبان به عنوان اولین و مهمترین زبان در حوزه ی AI داره استفاده میشه و دولوپرهای AI چه استراتژی هایی رو به کار میگیرند تا این ضعف پایتون رو پوشش بدن.
به زودی راجب این موضوع یک مقاله ی خوب و کامل مینویسم ولی یکی از کارهایی که میکنند اینه که مدل ml رو توسط ماژول های pickle و یا joblib سیو میکنند، با این کار از مدل یه فایل باینری صفر و یکی ساخته میشه و همونطور که میدونید فرمت های باینری بسیار سریع execute میشن. بقیه ی کارهارو تو مقاله ی جدیدم میگم.
منتظر باشید😎.
تو این موضوع خیلی حرف دارم که چرا با وجود کند بودن پایتون همچنان این زبان به عنوان اولین و مهمترین زبان در حوزه ی AI داره استفاده میشه و دولوپرهای AI چه استراتژی هایی رو به کار میگیرند تا این ضعف پایتون رو پوشش بدن.
به زودی راجب این موضوع یک مقاله ی خوب و کامل مینویسم ولی یکی از کارهایی که میکنند اینه که مدل ml رو توسط ماژول های pickle و یا joblib سیو میکنند، با این کار از مدل یه فایل باینری صفر و یکی ساخته میشه و همونطور که میدونید فرمت های باینری بسیار سریع execute میشن. بقیه ی کارهارو تو مقاله ی جدیدم میگم.
منتظر باشید😎.
مدل یا سامانه؟!
در پیاده‌سازی اپلیکیشن‌های مبتنی بر هوش مصنوعی دو رویکرد کلی وجود دارد:
۱. ساخت یک مدلِ End-to-End که صفر تا صد کار را از روی داده‌ی آموزشی، یادگرفته و در قالب یک مدلِ یک‌پارچه به انجام کار (Task) می‌پردازد.
۲. ساخت یک سامانه‌ی Compound AI که از اجزای مختلف از جمله مدل‌ها و ماژول‌ها و ابزارهای نرم‌افزاری مختلف تشکیل شده و در قالب یک سامانه‌ی ترکیبی، به انجام کار می‌پردازد. این سامانه در حین انجام کار ممکن‌ست چندین بار، یک مدل مشخص را به‌شکل‌های مختلف فراخوانی کند.
روش اول ساده‌تر و تاحدی سریع‌ترست. پژوهشی موسوم به Scaling Laws هم نشان میدهد که با افزایش پیچیدگی محاسباتی مدل میتوان به نتایج بهتری رسید. ازطرفی بهینه‌سازی کلیِ این روش ساده‌ست چون برخلافِ یک سامانه‌ی AI متشکل از اجرایی مثل موتور جستجو، همه‌ی اجزای یک مدل End-to-End مشتق‌پذیر و قابل‌بهینه‌سازی‌اند.
بااین‌حال، روندها نشان‌دهنده‌ی این‌اند که علاقه‌مندی بیشتر به‌سمت طراحی سامانه‌ها (System Design) و بهره‌گیری از ابزارها و روش‌های موجود در مهندسی‌ست. در زیر، شش دلیل برای این علاقه‌مندی آمده‌ست.
- وقتی از مدل‌ها استفاده میکنیم، هزینه‌ی تمام‌شده و دقت، مشخص و ثابت‌ست اما اپلیکیشن‌ها و بخش‌های مختلف آنها، بسته به کاربرد، نیاز به دقت و هزینه‌ی متفاوت دارند. مثلا وقتی قرارست یک متن حقوقی دقیق نوشته شود، هزینه‌ی GPT-4o اصلا برای کاربر دغدغه نیست اما زمانی که اپلیکیشنی مثل GitHub Copilot قصد کمک به تکمیل کد برنامه‌نویس در هر خط را دارد، احتمالا استفاده از یک مدل ساده‌تر و ارزان‌تر مطلوب‌ترست.
- در بعضی از تسک‌ها (مثلا حل مسابقات برنامه‌نویسی)، افزایش جدی هزینه‌ی آموزش مدل (مثلا افزایش سه‌برابری)، باعث بهبود عملکرد مدل میشود ولی نه زیاد (مثلا دقت ۳۰ درصد میشه ۳۵ درصد) اما فقط با مهندسی‌ِ یک سامانه‌ی Compound AI ممکن‌ست بهبود بسیاری حاصل شود (مثلا ۸۰ درصد) - منبع
- مدل‌های ML (با وجود قابلیت Generalization) محدود به داده‌های آموزشی‌اند ولی اپلیکیشن‌های AI نیاز به پویایی دارند. استفاده از یک سامانه به‌جای یک مدل، امکان استفاده‌ی لحظه‌ای از جستجو و بازیابی به‌منظور دریافت اطلاعت جدید و دقیق را به اپلیکیشن اضافه میکند. با دسترسی مستقیم به مراجع خارجی در کنار دانش داخلیِ مدل، اپلیکیشن قابلیت شفافیت (Transparency) و تفسیرپذیری (Interpretability) بیشتری پیدا میکند که این قدم مهمی در راستای Trustworthy AI است.
- خیلی از داده‌ها را بهعلت رعایت مسايل مربوط به privacy و copyright و safety نمی‌توان موقع آموزش به مدل نشان داد. استفاده از سامانه‌های Compound AI به ما اجازه‌ی کنترل داده‌ها باتوجه به سطح دسترسی افراد (ACL) را میدهد. به‌این شکل اپلیکیشن در هنگام استفاده‌ی کودک به داده‌های مشخص‌تر و امن‌تری دسترسی دارد، فایل‌های شخصی افراد فقط براستفاده‌ی خودشان قابل بازیابی‌اند، برای دسترسی به بعضی از داده‌ها میتوان حقوق مولف را درنظر گرفت و …
- مدل‌ها پتانسیل بالایی در تولید توهم (Hullucination) دارند. استفاده از ابزارهایی مثل Guardrails و Outlines و LMQL و SGLang در سامانه‌های AI، به ما اجازه‌ی ارزیابی، پایش و پالایش خروجی مدل را می‌دهند. این موضوع می‌تواند در کنترل سوگیری‌های اجتماعی (Social Bias) ازجمل سوگیری‌های سیاسی، نژادی، مذهبی و … کمک‌کننده باشد. پژوهش جدیدی نشان میدهد که بیشتر مدل‌های زبانی موجود (بهعلت سوگیری در داده‌های جمع‌آور‌ی‌شده از رسانه‌ها) ازنظر سیاسی چپ-گرا‌اند.
- با اینکه همه‌ی اجزای یک سامانه‌ی AI مشتق‌پذیر نیستند اما ابزارهایی مانند DSPy معرفی شده‌اند که به‌روش‌هایی سعی در بهینه‌کردن کل پایپ‌لاین سامانه به‌صورت End-to-End دارند.
مرجع: بخش‌های از نوشتار بالا از این بلاگ‌پست برداشت شده‌ست.
در پیاده‌سازی اپلیکیشن‌های مبتنی بر هوش مصنوعی دو رویکرد کلی وجود دارد:
۱. ساخت یک مدلِ End-to-End که صفر تا صد کار را از روی داده‌ی آموزشی، یادگرفته و در قالب یک مدلِ یک‌پارچه به انجام کار (Task) می‌پردازد.
۲. ساخت یک سامانه‌ی Compound AI که از اجزای مختلف از جمله مدل‌ها و ماژول‌ها و ابزارهای نرم‌افزاری مختلف تشکیل شده و در قالب یک سامانه‌ی ترکیبی، به انجام کار می‌پردازد. این سامانه در حین انجام کار ممکن‌ست چندین بار، یک مدل مشخص را به‌شکل‌های مختلف فراخوانی کند.
روش اول ساده‌تر و تاحدی سریع‌ترست. پژوهشی موسوم به Scaling Laws هم نشان میدهد که با افزایش پیچیدگی محاسباتی مدل میتوان به نتایج بهتری رسید. ازطرفی بهینه‌سازی کلیِ این روش ساده‌ست چون برخلافِ یک سامانه‌ی AI متشکل از اجرایی مثل موتور جستجو، همه‌ی اجزای یک مدل End-to-End مشتق‌پذیر و قابل‌بهینه‌سازی‌اند.
بااین‌حال، روندها نشان‌دهنده‌ی این‌اند که علاقه‌مندی بیشتر به‌سمت طراحی سامانه‌ها (System Design) و بهره‌گیری از ابزارها و روش‌های موجود در مهندسی‌ست. در زیر، شش دلیل برای این علاقه‌مندی آمده‌ست.
- وقتی از مدل‌ها استفاده میکنیم، هزینه‌ی تمام‌شده و دقت، مشخص و ثابت‌ست اما اپلیکیشن‌ها و بخش‌های مختلف آنها، بسته به کاربرد، نیاز به دقت و هزینه‌ی متفاوت دارند. مثلا وقتی قرارست یک متن حقوقی دقیق نوشته شود، هزینه‌ی GPT-4o اصلا برای کاربر دغدغه نیست اما زمانی که اپلیکیشنی مثل GitHub Copilot قصد کمک به تکمیل کد برنامه‌نویس در هر خط را دارد، احتمالا استفاده از یک مدل ساده‌تر و ارزان‌تر مطلوب‌ترست.
- در بعضی از تسک‌ها (مثلا حل مسابقات برنامه‌نویسی)، افزایش جدی هزینه‌ی آموزش مدل (مثلا افزایش سه‌برابری)، باعث بهبود عملکرد مدل میشود ولی نه زیاد (مثلا دقت ۳۰ درصد میشه ۳۵ درصد) اما فقط با مهندسی‌ِ یک سامانه‌ی Compound AI ممکن‌ست بهبود بسیاری حاصل شود (مثلا ۸۰ درصد) - منبع
- مدل‌های ML (با وجود قابلیت Generalization) محدود به داده‌های آموزشی‌اند ولی اپلیکیشن‌های AI نیاز به پویایی دارند. استفاده از یک سامانه به‌جای یک مدل، امکان استفاده‌ی لحظه‌ای از جستجو و بازیابی به‌منظور دریافت اطلاعت جدید و دقیق را به اپلیکیشن اضافه میکند. با دسترسی مستقیم به مراجع خارجی در کنار دانش داخلیِ مدل، اپلیکیشن قابلیت شفافیت (Transparency) و تفسیرپذیری (Interpretability) بیشتری پیدا میکند که این قدم مهمی در راستای Trustworthy AI است.
- خیلی از داده‌ها را بهعلت رعایت مسايل مربوط به privacy و copyright و safety نمی‌توان موقع آموزش به مدل نشان داد. استفاده از سامانه‌های Compound AI به ما اجازه‌ی کنترل داده‌ها باتوجه به سطح دسترسی افراد (ACL) را میدهد. به‌این شکل اپلیکیشن در هنگام استفاده‌ی کودک به داده‌های مشخص‌تر و امن‌تری دسترسی دارد، فایل‌های شخصی افراد فقط براستفاده‌ی خودشان قابل بازیابی‌اند، برای دسترسی به بعضی از داده‌ها میتوان حقوق مولف را درنظر گرفت و …
- مدل‌ها پتانسیل بالایی در تولید توهم (Hullucination) دارند. استفاده از ابزارهایی مثل Guardrails و Outlines و LMQL و SGLang در سامانه‌های AI، به ما اجازه‌ی ارزیابی، پایش و پالایش خروجی مدل را می‌دهند. این موضوع می‌تواند در کنترل سوگیری‌های اجتماعی (Social Bias) ازجمل سوگیری‌های سیاسی، نژادی، مذهبی و … کمک‌کننده باشد. پژوهش جدیدی نشان میدهد که بیشتر مدل‌های زبانی موجود (بهعلت سوگیری در داده‌های جمع‌آور‌ی‌شده از رسانه‌ها) ازنظر سیاسی چپ-گرا‌اند.
- با اینکه همه‌ی اجزای یک سامانه‌ی AI مشتق‌پذیر نیستند اما ابزارهایی مانند DSPy معرفی شده‌اند که به‌روش‌هایی سعی در بهینه‌کردن کل پایپ‌لاین سامانه به‌صورت End-to-End دارند.
مرجع: بخش‌های از نوشتار بالا از این بلاگ‌پست برداشت شده‌ست.
Forwarded from CodeCrafters (Behzad Azadi)
معرفی توسعه رفتار محور
توسعه رفتار محور مجموعه‌ای از شیوه‌های مهندسی نرم افزار است که در ساخت و ارائه سریعتر، با ارزش تر و با کیفیت تر نرم افزار طراحی شده است، از شیوه‌های چابک و ناب مانند TDD و DDD بهره میبرد و از همه مهمتر با یک زبان مشترک ساده بین توسعه دهندگان ،ذینفعان و تحلیلگران کسب و کار جهت ارتباط باهمدیگر ارائه میدهد
در ابتدای مسیر BDD یک رویکرد ساده‌تر برای یادگیری TDD بود (پس اگه جایی خوندین که BDD همان TDD است تعجب نکنید این رویکرد اولیه آن بود )
با وجود مزایای TDD بسیاری از تیم‌ها با مشکل مواجه هستند اینکه از کجا شروع کنند و چه تست‌هایی باید در ابتدا نوشته شود و از کجا شروع کنند، TDD ممکن یک مشکل اساسی دارد اینکه ممکن است توسعه دهندگان را چنان درگیر جزئیات کند که ممکن است از اهداف اصلی کسب و کار دور شده و آن را فراموش کنند بعدها تیم ممکن است متوجه شود که نگهداری تعداد زیادی تست واحد کار بسیار مشکل سازی باشد
بسیاری از تست‌های سنتی یا حتی نوشته شده با رویکرد TDD با بخش خاصی از کدها ارتباط دارند و فراموش میکنند که باید با قسمت تجاری هماهنگ شوند
بیایید یک مثال بزنین:
در یک سیستم بانکی میخواهند فرایند انتقال پول از یک حساب به حساب دیگر انجام شود و دو تابع برای ان نوشته میشود تابع گرفتن اکانت و تابع انتقال پول، تست‌های ان نیز نوشته و پاس میشود اما یک مشکل وجود دارد این تست‌ها بیانگر دقیق فرآیند مدنظر نیست و با تغییر کد تست‌ها شکسته میشوند و باید نام تست‌های خود را نیز تغییر دهید، تست‌های واحد یک مشکل دیگر دارند آن هم اینکه با نگاه اولیه به آن نمی‌توانند توصیفگر دقیق فرآیند باشند و این موجب میشود که درک نوشتن تست‌های دیگر را نیز سختتر کند
جناب نورث (مخترع رویکرد BDD ) مشاهده کرد با افزودن کلمه should به ابتدای نام تست‌های واحد میتوان تست‌های واحد با معنی داری نوشت که بیانگر این هستند که آن تست باید چکاری کند و بدین شکل شما متوجه میشوید که کلاس باید چکاری انجام دهد بجای اینکه چه روش یا عملکردی در حال آزمایش است اینگونه راحتتر میتوانید تلاش‌های خود را بر روی نیازهای اساسی کسب و کار متمرکز کنید و تست‌های بیشتر و بهتری نوشته شود که کیفیت کار را بالا ببرد، تست‌هایی که بدین شکل نوشته میشود بیشتر شبیه مشخصات است تا تست‌های واحد و بر روی رفتار برنامه تمرکز میکنند و از تست‌ها برای تایید و بیان ان رفتار استفاده میکنند و نگهداری آنها بدلیل واضح بودن هدف آنها بسیار آسانتر است (جناب نورث بعد از مشاهده تاثیر آن دیگر به آن TDD نگفت و امروزه شیوه‌های کاملا متمایزی از همدیگر هستند)
هدف مخترعان BDD ایجاد یک زبان فراگیر ساده که قابل درک برای تحلیلگران کسب و کار باشد که بتوانند از آن برای تعریف نیازمندی‌های خود استفاده کنند به مثال زیر دقت کنید
یک صاحب کسب و کار می تواند به راحتی سناریویی را که به این شکل نوشته شده درک کند. اهداف روشن و عینی را برای هر داستان از نظر اینکه چه چیزی باید توسعه یابد و چه چیزی باید آزمایش شود ارائه می دهد و امروز به شکل نمادین با عنوان Gherking تبدیل شد
متخصصان BDD دوست دارند با شناسایی اهداف تجاری و جستجوی ویژگی‌هایی که به تخقق این اهداف کمک میکند شروع کنند که با همکاری کاربر از نمونه‌های عینی برای نشان دادن این ویژگی ها استفاده میکنند، این نمونه‌ها در قالب اجرایی خودکار میشوند که هم نرم افزار را تایید میکند و هم اسناد فنی و عملکردی بروز رسانی خودکار را ارائه میدهد، اصول BDD در سطح کدنویسی به توسعه دهندگان کمک میکند تا کد با کیفیت بالاتر، بهتر تست شده، مستندتر شده و استفاده و نگهداری آن آسانتر باشد تصویر اول در کامنت‌ها
تمرکز بر ویژگی‌هایی با ارزش تجاری
یکی از چالش‌های بزرگ نرم افزاری عدم اطمینان در مورد نیارمندی‌هاست. یک ویژگی یک عملکرد قابل لمس و قابل تحویل است که به کسب و کار کمک میکند به اهداف تجاری خود دست یابد،
#BDD
#behavior_driven_design
@code_crafters
توسعه رفتار محور مجموعه‌ای از شیوه‌های مهندسی نرم افزار است که در ساخت و ارائه سریعتر، با ارزش تر و با کیفیت تر نرم افزار طراحی شده است، از شیوه‌های چابک و ناب مانند TDD و DDD بهره میبرد و از همه مهمتر با یک زبان مشترک ساده بین توسعه دهندگان ،ذینفعان و تحلیلگران کسب و کار جهت ارتباط باهمدیگر ارائه میدهد
در ابتدای مسیر BDD یک رویکرد ساده‌تر برای یادگیری TDD بود (
در واقع TDD یک رویکرد مبتنی بر تست‌های واحد unit test برای تعیین و طراحی و ازمایش کدهای برنامه است
متخصصان TDD در ابتدا یک تست شکست خورده مینویسند که توصیفگر ویژگی جدید است و سپس کدهای زیادی مینویسند تا تست با موفقیت اجرا شود و سپس با بازنگری کد خود آن را بهبود داده تا جایی که مطمئن شوند که نگهداری کد ساده است، این رویکرد تا میزان قابل توجهی خطاهای سیستم را کاهش میدهد
با وجود مزایای TDD بسیاری از تیم‌ها با مشکل مواجه هستند اینکه از کجا شروع کنند و چه تست‌هایی باید در ابتدا نوشته شود و از کجا شروع کنند، TDD ممکن یک مشکل اساسی دارد اینکه ممکن است توسعه دهندگان را چنان درگیر جزئیات کند که ممکن است از اهداف اصلی کسب و کار دور شده و آن را فراموش کنند بعدها تیم ممکن است متوجه شود که نگهداری تعداد زیادی تست واحد کار بسیار مشکل سازی باشد
بسیاری از تست‌های سنتی یا حتی نوشته شده با رویکرد TDD با بخش خاصی از کدها ارتباط دارند و فراموش میکنند که باید با قسمت تجاری هماهنگ شوند
بیایید یک مثال بزنین:
در یک سیستم بانکی میخواهند فرایند انتقال پول از یک حساب به حساب دیگر انجام شود و دو تابع برای ان نوشته میشود تابع گرفتن اکانت و تابع انتقال پول، تست‌های ان نیز نوشته و پاس میشود اما یک مشکل وجود دارد این تست‌ها بیانگر دقیق فرآیند مدنظر نیست و با تغییر کد تست‌ها شکسته میشوند و باید نام تست‌های خود را نیز تغییر دهید، تست‌های واحد یک مشکل دیگر دارند آن هم اینکه با نگاه اولیه به آن نمی‌توانند توصیفگر دقیق فرآیند باشند و این موجب میشود که درک نوشتن تست‌های دیگر را نیز سختتر کند
جناب نورث (
هدف مخترعان BDD ایجاد یک زبان فراگیر ساده که قابل درک برای تحلیلگران کسب و کار باشد که بتوانند از آن برای تعریف نیازمندی‌های خود استفاده کنند به مثال زیر دقت کنید
Given a customer has a current account
When the customer transfers funds from this account to an overseas account
Then the funds should be deposited in the overseas account
And the transaction fee should be deducted from the current account
یک صاحب کسب و کار می تواند به راحتی سناریویی را که به این شکل نوشته شده درک کند. اهداف روشن و عینی را برای هر داستان از نظر اینکه چه چیزی باید توسعه یابد و چه چیزی باید آزمایش شود ارائه می دهد و امروز به شکل نمادین با عنوان Gherking تبدیل شد
متخصصان BDD دوست دارند با شناسایی اهداف تجاری و جستجوی ویژگی‌هایی که به تخقق این اهداف کمک میکند شروع کنند که با همکاری کاربر از نمونه‌های عینی برای نشان دادن این ویژگی ها استفاده میکنند، این نمونه‌ها در قالب اجرایی خودکار میشوند که هم نرم افزار را تایید میکند و هم اسناد فنی و عملکردی بروز رسانی خودکار را ارائه میدهد، اصول BDD در سطح کدنویسی به توسعه دهندگان کمک میکند تا کد با کیفیت بالاتر، بهتر تست شده، مستندتر شده و استفاده و نگهداری آن آسانتر باشد تصویر اول در کامنت‌ها
تمرکز بر ویژگی‌هایی با ارزش تجاری
یکی از چالش‌های بزرگ نرم افزاری عدم اطمینان در مورد نیارمندی‌هاست. یک ویژگی یک عملکرد قابل لمس و قابل تحویل است که به کسب و کار کمک میکند به اهداف تجاری خود دست یابد،
#BDD
#behavior_driven_design
@code_crafters
تا حالا به امنیت هر نوع داده ساختار و متغیر ها فکر کردی؟
برای زبان #پایتون امنیت داده‌ها رو میشه از جنبه های مختلف بررسی کرد، از جمله امنیت تغییرناپذیری (immutability)
رشته‌ها (Strings): رشته‌ها در پایتون تغییرناپذیر هستن. پس از ایجاد یک رشته، نمیشه محتواشو تغییر داد. این ویژگی باعث میشود که رشته‌ها در برابر تغییرات ناخواسته محافظت بشن.
تاپل‌ها (Tuples): تاپل‌ها هم تغییرناپذیرن. بنابراین، پس از ایجاد یک تاپل، نمیشه المان‌هاشو تغییر داد.
لیست‌ها (Lists): لیست‌ها تغییرپذیرن. بنابراین، میشه المان‌های اونارو تغییر داد، افزود یا حذف کرد. این ویژگی ممکنه باعث مشکلات امنیتی بشه اگه لیست‌ها بدون کنترل مناسب تغییر کنند.
مجموعه‌ها (Sets) و دیکشنری (Dictionaries): این دو ساختمان داده نیز تغییرپذیر هستند. بنابراین، میشه المان‌ها رو بهشون افزود یا حذف کرد.
برای زبان #پایتون امنیت داده‌ها رو میشه از جنبه های مختلف بررسی کرد، از جمله امنیت تغییرناپذیری (immutability)
رشته‌ها (Strings): رشته‌ها در پایتون تغییرناپذیر هستن. پس از ایجاد یک رشته، نمیشه محتواشو تغییر داد. این ویژگی باعث میشود که رشته‌ها در برابر تغییرات ناخواسته محافظت بشن.
s = "Hello"
s[0] = 'h' # این خط خطا میده چون رشته‌ها تغییرناپذیر هستن
تاپل‌ها (Tuples): تاپل‌ها هم تغییرناپذیرن. بنابراین، پس از ایجاد یک تاپل، نمیشه المان‌هاشو تغییر داد.
t = (1, 2, 3)
t[0] = 10 # این خط خطا میده چون تاپل‌ها تغییرناپذیر هستن
لیست‌ها (Lists): لیست‌ها تغییرپذیرن. بنابراین، میشه المان‌های اونارو تغییر داد، افزود یا حذف کرد. این ویژگی ممکنه باعث مشکلات امنیتی بشه اگه لیست‌ها بدون کنترل مناسب تغییر کنند.
lst = [1, 2, 3]
lst[0] = 10 # این خط درسته چون لیست‌ها تغییرپذیر هستن
مجموعه‌ها (Sets) و دیکشنری (Dictionaries): این دو ساختمان داده نیز تغییرپذیر هستند. بنابراین، میشه المان‌ها رو بهشون افزود یا حذف کرد.
my_set = {1, 2, 3}
my_set.add(4) # افزودن یک المان به مجموعه
my_dict = {'a': 1, 'b': 2}
my_dict['c'] = 3 # افزودن یک جفت کلید-مقدار به دیکشنرییه نفر اومده روی لپ تاپ فریمورک چند تا بازی رو بین ویندوز 11 و لینوکس فدورا 40 مقایسه کرده.
مقایسه روی میزان FPS بوده و نتایج مقایسه به اینصورت شده :
بازی Shadow of the Tomb Raider روی لینوکس نیتیو نسبت به ویندوز 7% فریم ریت بیشتری داشته.
بازی Total War: Warhammer III روی لینوکس نیتیو نسبت به ویندوز 2% فریم ریت کمتری داشته.
بازی Forza Horizon 5 روی لینوکس از طریق پروتون نسبت به ویندوز 7% فریم ریت کمتری داشته.
بازی Cyberpunk 2077 روی لینوکس از طریق پروتون نسبت به ویندوز 7% فریم ریت بیشتری داشته.
پروتون درواقع یه لایه سازگار کننده بازی ویندوز برای لینوکسه اینکه روی لینوکس Cyberpunk فریم ریت بهتری داشته عجیبه؛ البته مقایسه به عوامل محیطی زیادی وابسته‌س و نمیشه با این اعداد مقایسه دقیقی انجام داد، اما به صورت کلی میشه این مقایسه رو قبول کرد.
برای دیدن مقاله اینجا کلیک کنید.
مقایسه روی میزان FPS بوده و نتایج مقایسه به اینصورت شده :
بازی Shadow of the Tomb Raider روی لینوکس نیتیو نسبت به ویندوز 7% فریم ریت بیشتری داشته.
بازی Total War: Warhammer III روی لینوکس نیتیو نسبت به ویندوز 2% فریم ریت کمتری داشته.
بازی Forza Horizon 5 روی لینوکس از طریق پروتون نسبت به ویندوز 7% فریم ریت کمتری داشته.
بازی Cyberpunk 2077 روی لینوکس از طریق پروتون نسبت به ویندوز 7% فریم ریت بیشتری داشته.
پروتون درواقع یه لایه سازگار کننده بازی ویندوز برای لینوکسه اینکه روی لینوکس Cyberpunk فریم ریت بهتری داشته عجیبه؛ البته مقایسه به عوامل محیطی زیادی وابسته‌س و نمیشه با این اعداد مقایسه دقیقی انجام داد، اما به صورت کلی میشه این مقایسه رو قبول کرد.
برای دیدن مقاله اینجا کلیک کنید.
Forbes
Linux Scores A Surprising Gaming Victory Against Windows 11
The conversation around gaming on Linux sure has changed in the last few years. And these benchmark results prove it.
Forwarded from RSG - Iran
این تغییر به طور مستقیم به غلظت CRP در نمونه ادرار مرتبط است. سنسور برای تشخیص غلظت‌های CRP در محدوده ۱ تا ۱۰۰۰ میلی‌گرم بر لیتر کالیبره شده است که نشان‌دهنده دامنه دینامیکی گسترده و حساسیت آن است.
گردآورنده: حسین الله‌دادی
#مقاله
Please open Telegram to view this post
VIEW IN TELEGRAM
اگه اینارو نمیدونی ادعایی تو برنامه نویسی نداشته باش!
شاید پارامترهای 'arg' و 'kwarg' توی تعریف توابع یا داکیومنت های کتابخونه های مختلف #پایتون دیده باشین.
اما این دوتا پارامتر دقیقا چیکار میکنن؟
زمان تعریف توابع میشه یک یا چند آرگیومنت رو به عنوان ورودی به اون تابع تعریف کرد اما اگر ندونیم که ورودی ها دقیقا چند تا هستند یا در آینده بخواییم چیزهای دیگه رو هم به عنوان ورودی به تابع بدیم به مشکل برمیخوریم و اینجاست که این دو تا پارامتر وارد عمل میشن.
پارامتر *arg: اگر تابعی از این پارامتر استفاده کنه به ترتیب وردی هایی که بهش داده شده رو میگیره و داخل پارامترهاش میریزه اما هر ورودی بیش تر از تعداد ورودی های ثابت رو به *arg اختصاص میده
توی مثال بالا تابع مقدار ورودی 'one' رو با "hello" پر میکنه و باقی ورودی ها رو داخل *arg میریزه.
پارامتر *arg از مجوعه پارامترهای position based هست یعنی ترتیب ورودی هایی که بهش داده میشه اهمیت داره و به تبع اون میشه به همون ترتیب داخل تابع بهشون دسترسی داشت.
پارامتر **kwarg: این پارامتر هم مثل پارامتر قبلی برای ورودی دادن اضافی به توابع استفاده میشه با این تفاوت که ساختار اون به صورت دیکشنری هست و ورودی هایی که از این طریق به تابع داده میشن رو باید به صورت مقادیر {key:value} تعریف کرد.
در مثال بالا مقدار arg1 با "Hi" پر میشه و بقیه ورودی ها با **kwarg اختصاص پیدا میکنند در نتیجه داخل تابع به جای دسترسی به ورودی ها با استفاده از slicing که در *arg استفاده میشه.
نکته مهم: نام گذاری برای این دو پارامتر آزاد هست و هر اسمی که بعد از * یا ** بیاد همون کاربرد موارد گفته شده بالا رو داره.
#python
شاید پارامترهای 'arg' و 'kwarg' توی تعریف توابع یا داکیومنت های کتابخونه های مختلف #پایتون دیده باشین.
اما این دوتا پارامتر دقیقا چیکار میکنن؟
زمان تعریف توابع میشه یک یا چند آرگیومنت رو به عنوان ورودی به اون تابع تعریف کرد اما اگر ندونیم که ورودی ها دقیقا چند تا هستند یا در آینده بخواییم چیزهای دیگه رو هم به عنوان ورودی به تابع بدیم به مشکل برمیخوریم و اینجاست که این دو تا پارامتر وارد عمل میشن.
پارامتر *arg: اگر تابعی از این پارامتر استفاده کنه به ترتیب وردی هایی که بهش داده شده رو میگیره و داخل پارامترهاش میریزه اما هر ورودی بیش تر از تعداد ورودی های ثابت رو به *arg اختصاص میده
def testfunc(one,*argv):
for arg in argv:
print(arg)
testfunc('Hello', 'this', 'is', 'SiliconBrain')
توی مثال بالا تابع مقدار ورودی 'one' رو با "hello" پر میکنه و باقی ورودی ها رو داخل *arg میریزه.
پارامتر *arg از مجوعه پارامترهای position based هست یعنی ترتیب ورودی هایی که بهش داده میشه اهمیت داره و به تبع اون میشه به همون ترتیب داخل تابع بهشون دسترسی داشت.
پارامتر **kwarg: این پارامتر هم مثل پارامتر قبلی برای ورودی دادن اضافی به توابع استفاده میشه با این تفاوت که ساختار اون به صورت دیکشنری هست و ورودی هایی که از این طریق به تابع داده میشن رو باید به صورت مقادیر {key:value} تعریف کرد.
def testfunc(arg1, **kwargs):
for key, value in kwargs.items():
print(f"{key} == {value}")
testfunc("Hi", first='this', mid='is', last='SiliconBrain')
در مثال بالا مقدار arg1 با "Hi" پر میشه و بقیه ورودی ها با **kwarg اختصاص پیدا میکنند در نتیجه داخل تابع به جای دسترسی به ورودی ها با استفاده از slicing که در *arg استفاده میشه.
نکته مهم: نام گذاری برای این دو پارامتر آزاد هست و هر اسمی که بعد از * یا ** بیاد همون کاربرد موارد گفته شده بالا رو داره.
#python
یکی از مشکلات کلیدی و پایه تمامی دانشجویان حوزه امنیت سیستم‌های کامپیوتری و برنامه‌نویسی، ریاضی و زیرشاخه‌های آن است. بعد از حدود 1 سال تلاش به هر صورت دوره پایه آیو با عنوان Nexus of Thought تکمیل شد. این دوره شامل مباحث ریاضی مهندسی، ریاضی گسسته، منطق، تئوری اطلاعات، طراحی و سنتز سیستم‌های دینامیک و استاتیک، تحلیل ساختار کامپیوترها و پردازنده، استخراج دی اف دی، پردازش سیگنال و اصول کدینگ اطلاعات در شبکه است.
شایان ذکر است، این دوره رایگان خواهد بود و هر دانشجو که وارد دوره‌های آیو میشود، در فاز Preparation این دوره را دریافت خواهد کرد تا وقتی وارد کورس میشود، تمامی اصول پایه علوم کامپیوتری را فهمیده باشد. امیدوارم این دوره، موجب بهتر شدن تعمق دانشجویان در حوزه مهندسی دیجیتال شود. با تشکر از تمامی اعضای آیو که در انجام و آماده‌سازی این دوره کمک کردند.
شایان ذکر است، این دوره رایگان خواهد بود و هر دانشجو که وارد دوره‌های آیو میشود، در فاز Preparation این دوره را دریافت خواهد کرد تا وقتی وارد کورس میشود، تمامی اصول پایه علوم کامپیوتری را فهمیده باشد. امیدوارم این دوره، موجب بهتر شدن تعمق دانشجویان در حوزه مهندسی دیجیتال شود. با تشکر از تمامی اعضای آیو که در انجام و آماده‌سازی این دوره کمک کردند.