معرفی توسعه رفتار محور

توسعه رفتار محور مجموعه‌ای از شیوه‌های مهندسی نرم افزار است که در ساخت و ارائه سریعتر، با ارزش تر و با کیفیت تر نرم افزار طراحی شده است، از شیوه‌های چابک و ناب مانند TDD و DDD بهره میبرد و از همه مهمتر با یک زبان مشترک ساده بین توسعه دهندگان ،ذینفعان و تحلیلگران کسب و کار جهت ارتباط باهمدیگر ارائه میدهد

در ابتدای مسیر BDD یک رویکرد ساده‌تر برای یادگیری TDD بود (پس اگه جایی خوندین که BDD همان TDD است تعجب نکنید این رویکرد اولیه آن بود)

در واقع TDD یک رویکرد مبتنی بر تست‌های واحد unit test برای تعیین و طراحی و ازمایش کدهای برنامه است

متخصصان TDD در ابتدا یک تست شکست خورده مینویسند که توصیفگر ویژگی جدید است و سپس کدهای زیادی مینویسند تا تست با موفقیت اجرا شود و سپس با بازنگری کد خود آن را بهبود داده تا جایی که مطمئن شوند که نگهداری کد ساده است، این رویکرد تا میزان قابل توجهی خطاهای سیستم را کاهش میدهد

با وجود مزایای TDD بسیاری از تیم‌ها با مشکل مواجه هستند اینکه از کجا شروع کنند و چه تست‌هایی باید در ابتدا نوشته شود و از کجا شروع کنند، TDD ممکن یک مشکل اساسی دارد اینکه ممکن است توسعه دهندگان را چنان درگیر جزئیات کند که ممکن است از اهداف اصلی کسب و کار دور شده و آن را فراموش کنند بعدها تیم ممکن است متوجه شود که نگهداری تعداد زیادی تست واحد کار بسیار مشکل سازی باشد

بسیاری از تست‌های سنتی یا حتی نوشته شده با رویکرد TDD با بخش خاصی از کدها ارتباط دارند و فراموش میکنند که باید با قسمت تجاری هماهنگ شوند

بیایید یک مثال بزنین:
در یک سیستم بانکی میخواهند فرایند انتقال پول از یک حساب به حساب دیگر انجام شود و دو تابع برای ان نوشته میشود تابع گرفتن اکانت و تابع انتقال پول، تست‌های ان نیز نوشته و پاس میشود اما یک مشکل وجود دارد این تست‌ها بیانگر دقیق فرآیند مدنظر نیست و با تغییر کد تست‌ها شکسته میشوند و باید نام تست‌های خود را نیز تغییر دهید، تست‌های واحد یک مشکل دیگر دارند آن هم اینکه با نگاه اولیه به آن نمی‌توانند توصیف‌گر دقیق فرآیند باشند و این موجب میشود که درک نوشتن تست‌های دیگر را نیز سختتر کند

جناب نورث (مخترع رویکرد BDD) مشاهده کرد با افزودن کلمه should به ابتدای نام تست‌های واحد میتوان تست‌های واحد با معنی داری نوشت که بیانگر این هستند که آن تست باید چکاری کند و بدین شکل شما متوجه میشوید که کلاس باید چکاری انجام دهد بجای اینکه چه روش یا عملکردی در حال آزمایش است اینگونه راحتتر میتوانید تلاش‌های خود را بر روی نیازهای اساسی کسب و کار متمرکز کنید و تست‌های بیشتر و بهتری نوشته شود که کیفیت کار را بالا ببرد، تست‌هایی که بدین شکل نوشته میشود بیشتر شبیه مشخصات است تا تست‌های واحد و بر روی رفتار برنامه تمرکز میکنند و از تست‌ها برای تایید و بیان ان رفتار استفاده میکنند و نگهداری آنها بدلیل واضح بودن هدف آنها بسیار آسانتر است (جناب نورث بعد از مشاهده تاثیر آن دیگر به آن 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): رشته‌ها در پایتون تغییرناپذیر هستن. پس از ایجاد یک رشته، نمیشه محتواشو   تغییر داد. این ویژگی باعث می‌شود که رشته‌ها در برابر تغییرات ناخواسته محافظت بشن.

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 فریم ریت بهتری داشته عجیبه؛ البته مقایسه به عوامل محیطی زیادی وابسته‌س و نمیشه با این اعداد مقایسه دقیقی انجام داد، اما به صورت کلی میشه این مقایسه رو قبول کرد.

برای دیدن مقاله اینجا کلیک کنید.

اگه اینارو نمیدونی ادعایی تو برنامه نویسی نداشته باش!

شاید پارامترهای '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 این دوره را دریافت خواهد کرد تا وقتی وارد کورس می‌شود، تمامی اصول پایه علوم کامپیوتری را فهمیده باشد. امیدوارم این دوره، موجب بهتر شدن تعمق دانشجویان در حوزه مهندسی دیجیتال شود. با تشکر از تمامی اعضای آیو که در انجام و آماده‌سازی این دوره کمک کردند.

جایگزین Llama3.1 فقط می‌تونه یک نسخه بهتر براساس همین معماری باشه :

arcee-ai/Llama-3.1-SuperNova-Lite

مدل ۸ میلیارد پارامتری هست، مدل ۷۰ میلیاردی فقط از طریق api در دسترس هست.
طبق ادعا از 405b, gpt4o, ... بهتر عمل می‌کنه؛ البته برای تسک‌های مربوط به
instruction-following

شخصاً هم همین رو احساس کردم توی تست‌ها.

یک نفر در Stackoverflow سوال کرده بود "چطور میشه گپ بین دقت داده train و test رو در مدل‌های Machine Learning حل کرد"؟ سوال برای یک مسئله سری زمانی بود. اول با خودم گفتم آقا خسته نباشی ملت صبح و شب در تلاش برای همین کار هستن تا هوش مصنوعی بهتر یاد بگیره. اما خوب تصمیم گرفتم به سوالش جواب بدم و حتی vote منفی سوالش رو که بقیه داده بودن خنثی کردم. روند توسعه مدل Machine Learning خیلی اوقات خوب انجام نمیشه و موارد پایه‌ای دیتاساینس و ماشین لرن رعایت نمیشه. مواردی مثل مانیتور کردن bias variance، شروع با مدل ساده و ارتقا با توجه به بایاس واریانس، experiment tracking و MLOps , بعضی روش‌های Advanced رو در 8 مورد نوشتم.
پ.ن: تمامی LLM ها و چت جی پی تی از منابعی مثل Stackoverflow کار و ریزه کاری کدزنی رو یاد گرفتن و باهوش شدن. پس مشارکت در Stackoverflow فراموش نشه.
آپدیت: یک مشارکت کننده رده بالا اومد گفت آقا چرا همچین سوالی رو جواب دادی و این سوال افزایش پرفورمنس در model dev هست نه سوال برنامه نویسی و اینجا off topic محسوب میشه. منم گفتم آره طرف باید این سوال رو در کامیونیتی مثل Cross Validated میپرسید (از زیرمجموعه های stackexchange هست اگر ندیدین حتما سر بزنید). اما طرف خوشش نیومد در کل و یک رای منفی هم داد و رفت! اما قصد نوشتن اون مطلب بود که اینجا میارم کاملش رو

In theory, the gap between train and test sets' error can not be less than what is called Bayes error, which is sometimes equivalent to human-level intelligence/error in fields where human natural perception is high (such as NLP and Vision). However, in Time Series, it is difficult to predict how far we can minimize this gap. The following steps are what I suggest and they are all basically about using model's bias & variance in each experiment and then use some techniques to improve the model:

0. Use an experiment tracking tool: Start by organizing all your experiments using MLOps tools such as WandB and MLflow that let you log metadata (such as cross-validation results) and save models as artifacts. I prefer Weights&Biases which lets you do multiple experiments using Sweep and Grid Search or Bayesian Optimization to maximize a defined metric on your cross-validation for HPO. Note: Do not waste your time by overly tuning the models' parameters when doing HPO. It is wise to work on data centric approaches instead

1. Start with simple models: Avoid starting with irrelevant or overly complicated models. Begin with simple models and monitor their bias and variance. If you observe underfitting, you might want to use models that can capture non-linear relationships and work well with tabular time series data, such as Random Forest and XGBoost. Avoid jumping directly to complicated RNN models like LSTM, which were initially developed for NLP applications and have not performed well in time series competitions.

2. Address overfitting: Once you solve the underfitting problem, you may reach a model that can learn non-linear relationships in the training data. At this point, your model might exhibit high variance and overfitting on the training data. There are several ways to mitigate overfitting:

Add more training data or use data augmentation techniques. For example, a 2017 Kaggle winning solution for tabular data augmentation and representation learning used DAE. Regularization techniques: Apply L1 and L2 regularization (known as reg_lambda and reg_alpha in XGBoost) to penalize large weights and coefficients. Early stopping, Dropout, and Reduce Learning Rate on Plateau are other techniques commonly used for neural networks.

3. Use ensemble methods: Combine multiple models using techniques like soft voting.

4. Blending & stacking: Implement blending and stacking techniques to leverage the strengths of different models.

5. Advanced time series representations: Explore advanced methods such as signature kernels and wavelets to create better features and representations of your data.

6. Advanced tabular ML models: Look into new models like GRANDE, which combines the advantages of tree-based models and neural networks. Note that if you want to use models such as RF, XGB or GRANDE for time series problems you should do some shape transform first.

7. Improved time-series CV: You can use more advanced time-series Cross-Validation techniques like Embargo & Purge which usually used in quantitative finance.

از ابتدا انگلیسی نوشته شد و عوضش نکردم. سه مورد اول بیشترین اهمیت رو در روند توسعه یک مدل Machine Learning دارن. رایج ترین اشتباهات هم مربوط به انتخاب اولین مدل هست. در واقع مدل اول باید یک مدل ساده و مورد پذیرش در اون حوزه باشه و با مشاهده underfitting به مرور پیچیدگی اضافه میشه: مدل‌های دقیق‌تر یا پارامترهایی که پیچیدگی اضافه میکنن. مثلا اضافه کردن لایه در شبکه عصبی یا max_depth در tree-based models
مورد اول هم حتما به کارتون اضافه کنید. یادگیری mlflow یا wandb واقعا سادس اما مزیت بالایی برای سیستمی که میسازید داره.
بالا اشاره نکردم اما کالیبره کردن مدل‌ها با با روش‌های Uncertainty Quantification خیلی کمک کنندس. برای مثال Conformal Prediction در Classification کمک میکنه False Positive کمتری داشته باشید. در این مورد بیشتر مینویسم.

پندی که میتونیم از این داستان بگیریم چیه؟
تو هر شاخه ای که میخایم وارد بشیم اول از همه به زیرساخت اون موضوع کامل مسلط بشیم
مثال من میخام پنتستر شبکه بشم از همون اول شروع نکنم به سنس دیدن
اول از همه باید به عنوان یه مهندس شبکه فعالیت کنم و یاد بگیرم بعد که مسلط شدم حالا میتونم برم تو مباحث تست نفوذش

اولین مورد توی عکس رو ببینید و با ردیف 50 مقایسه کنید.

Gemma 2 2B > ChatGpt 3.5 Turbo

این مدل به تازگی منتشر شد، دقت کنید اطراف این مدل نتایج بهتری از مدل‌های ۷، ۱۴ و حتی ۳۲ میلیاردی چندماه قبل داره. اهمیت دیتا

پ.ن : خودم هنوز باورم نمی‌شه
با این وضعیت فکر کنید مدل ۹ میلیاردی و ۲۷ میلیاردی آپدیت جدید بگیره

مورد دوم :
۱۳ روز دیگه معرفی Pixel 9 Pro هست و چون این مدل برای On-device هم مناسب سازی شده
ممکن هست این مدل، مدل اصلی روی گوشی‌های Google باشه


یک سری آدم نشستن؛ همین حالا مدل رو روی linux tablet ها اجرا کردن؛ با توجه به اینکه فعلا فقط CPU هست تقریبا حدود ۸-۱۲ توکن بر ثانیه خروجی میده.
زیر ۲۸ توکن بر ثانیه حوصله سربر میشه برای یوزر

توی تست های خودمم روی GPU زیر ۲ ثانیه مدل load میشه Q4 سرعتی هم که نیازی به توضیح نداره.

به بهانه‌ی این مطلب چند تا نکته در مورد خوندن کد بگم:

۱- خوندن کد خوبه و هر کدی هم باشه کلا خوبه. مثل کتاب خوندن. از نظر من کد خوندن مثل رمان و کتاب خوندنه.

۲- با خوندن کد بیشتر و بهتر، کدهای بهتری هم خواهید نوشت. یادگیری دیزاین پترن و اصول کد تمیز خوبه ولی دیدن اینکه در عمل چه چیزی باعث خوب شدن کد می‌شه یه چیز دیگه‌ست و اگه کد بخونید از بقیه جلو می‌افتید.

۳- همونطور که وقتی الفبا رو یاد گرفتیم نمیشه انتظار داشت که آثار شکسپیر رو بخونیم، قاعدتا اگه اولین کدی که می‌خونیم کد لینوکس باشه، خیلی چیزاشو متوجه نمی‌شیم. می‌شه اول از چیز‌های ساده‌تر شروع کرد.

۴- یه سری پروژه‌ها (مثلا minix) به هدف اینکه سورس کد قابل فهمی داشته باشن نوشته می‌شن و یه سری دیگه به هدف پرفورمنس و کاربردی بودن و ... شروع کردن از اونایی که سورس کد مرتب تر و ساده‌تری دارن قطعا توصیه می‌شه. مخصوصا اگه ایده‌ی کلی از اون سیستمی که پیاده‌سازی می‌شه نداریم. مثلا اگه نمی‌دونیم سیستم‌عامل چطوری کار می‌کنه بهتره اول کتاب در موردش بخونیم. بعد یه کتاب یا منبعی که سورس‌کد رو توضیح داده بخونیم (یا همین مینیکس که سورس کد ساده و با کامنتی داره). و در نهایت می‌تونیم (شاید بتونیم) سورس کد یه سیستم‌عامل واقعی رو بخونیم.

۵- خوندن کد خیلی وقتا مثل کتاب نیست که از اول شروع کنیم تا آخر بریم، بلکه به شکل چرخیدن تو یه جنگل بزرگه. می‌چرخیم و جاهای جالبش رو نگاه می‌کنیم. مثلا همین که فایل cgroupش رو باز می‌کنیم. گاهی هم سعی می‌کنیم ساختارمندتر کار کنیم مثلا main رو باز می‌کنیم و از اونجا می‌ریم جلو. (البته اگه mainی در کار باشه!)

۶- (شاید نظر نامحبوب) خیلی وقتا نیازی نیست همه‌ی کد رو خونده باشیم یا حتی فهمیده باشیم تا بتونیم یه contributionی انجام بدیم. برای انجام یه تغییر کافیه بدونیم کلیت داستان چیه (مثلا main چطوری کار می‌کنه، قسمتی که کد من رو کال می‌کنه چطوریه و معماری و پوشه‌بندی کلی چطوریه) و تغییرمون رو در جای درستش اعمال کنیم. مثلا اگه می‌خوایم کوئری بهینه‌تری برای دیتابیس بنویسیم خیلی وقتا نیاز نیست که بدونیم تو dockerfile چه خبره یا مثلا تو http handler دقیقا چه اتفاقی می‌افته. یا در مثال لینوکسش، اگه می‌خوایم در مورد cgroup بیشتر بدونیم قاعدتا نیاز نیست در مورد درایورهای گرافیک چیز زیادی بدونیم. مخصوصا اگه معماری کد خوب باشه و الکی چیزا رو به هم متصل نکرده باشه.

🧠 آغاز ثبت‌نام رایگان مسابقات بین‌المللی هوش مصنوعی رایان (Rayan) | دانشگاه صنعتی شریف

🪙با بیش از ۳۵ هزار دلار جایزه نقدی
🎓چاپ دستاوردهای ۱۰ تیم برتر در کنفرانس‌‌ها/مجلات برتر بین‌المللی هوش مصنوعی
👥 امکان شرکت به صورت تیم‌های ۱ تا ۴ نفره
🗓شروع مسابقه از ۲۶ مهرماه ۱۴۰۳

💬موضوعات مورد بررسی اعتمادپذیری در یادگیری عمیق:
💬 Model Poisoning
💬 Compositional Generalization
💬 Zero-Shot Anomaly Detection

👀 مسابقات بین‌المللی هوش مصنوعی رایان با حمایت معاونت علمی ریاست‌جمهوری و موضوع Trustworthy AI، توسط دانشگاه صنعتی شریف برگزار می‌گردد. این مسابقه در ۳ مرحله (۲ مرحله مجازی و ۱ مرحله حضوری) از تاریخ ۲۶ مهر آغاز می‌شود.

⭐️ رایان جهت حمایت از تیم‌های برتر راه‌یافته به مرحله سوم، ضمن تأمین مالی بابت هزینه سفر و اسکان، دستاوردهای علمی تیم‌های برتر را در یکی از کنفرانس‌ها یا مجلات مطرح این حوزه با ذکر نام اعضای تیم در مقاله‌ی مربوطه، چاپ و منتشر خواهد کرد. این شرکت‌کنندگان برای دستیابی به جایزه ۳۵ هزار دلاری برای تیم‌های برتر، در فاز سوم به رقابت می‌پردازند.