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

متاسفانه با خبر شدیم یکی از اساتید محبوب در حوزه سیستم های هوشمند و استاد تمام دانشگاه صنعتی امیرکبیر، پروفسور احمد عبدالله زاده بارفروش امروز ۲۱ خرداد ۱۴۰۳ در گذشتند.
روحشان شاد و یادشان گرامی

clean code, yes or no??

یکی از چالش هایی که کمابیش تو صنعت باهاش روبرو میشیم و از کمالگرایی نشئت میگیره، بحث over engineering هست.
اصول کد نویسی تمیز هم یه چیز تجربیه که طی سالها تجربه مهندسای نرم افزار تو صنعت ایجاد شده.
حالا یه جایی این کد نویسی تمیز میشه آنتی پترن یا بهتره بگم هشتاد درصد مواقع نیازی به رعایت کلین کد و این چیزا نیست.
خیلی وقتا کلین کد فقط کد رو بسیار کثیف و پیچیده میکنه و عملا طی مدت زمانی توسعه کد رو غیر ممکن میکنه!
پس سر این موضوع، دیزاین پترن ها، اصول معماری و ... وسواس به خرج ندید و اگر اونا رو پیاده نکردید هم عذاب وجدان نداشته باشید.
اگر یه مدت دستتون تو کد باشه خواه نا خواه خودتون میدونید که چه موقع باید از اینا استفاده کنید و چه موقع خیر!
اصولا تمیز کد زدن خیلی به این قوانین بستگی نداره و اگر زمانی حس کنید دارید زیاده روی میکنید بهتره که دست نگه دارید و کمتر فحش بخورید از جانب بقیه.

موضوع بعدی درباره لایه های LSTM هست

MLOps for research

همونطور که میدونید رویکرد MLOps به تبدیل الگوریتم های ماشین لرنینگ به نرم افزار های مقیاس پذیر میپردازه.

یه سوالی که پیش میاد اینه که به عنوان یه محقق نیازه MLOps بلد باشیم یا خیر؟

بله، به عنوان یه محقق شما باید به برخی از مفاهیم MLOps تسلط داشته باشید
در واقع شاید تفاوت شما با یه مهندس یادگیری ماشین در بحث دیپلوی باشه و لاغیر.

وقتی صحبت از ریسرچ میشه و مقاله ای میخواد عملی شه، با دیتای زیادی سر و کار داریم پس نیازه مباحث مربوط به MLOps رو بدونیم چون صرفا دیتای ما با تکنیک های معمولی نمیتونه پردازش شه پس باید یه زیرساخت قدرتمند هم ساخته شه طبیعتا.

https://youtu.be/iN0_vaJzx94?feature=shared

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

دیزاین پترن چیست؟
یه سری اشکالات رایج در برنامه نویسی و دیزاین وجود داشتن و دارن. اون اشکالات دائم تکرار میشن. حالا اگر ما بخوایم به شیوه code and fix مثل اون چیزی که تو مبانی برنامه نویسی میخوندیم بریم جلو بعد از مدتی کدمون کاملا بلا استفاده میشه . به بیان دیگه maintainability به شدت افت میکنه و کار کثیف در میاد.
جدا از اون، ما نیازه که قبل از پیاده سازی دیزاین رو انجام بدیم دیگه که بعد کدش رو بنویسیم.
رو این حساب کارکشته های حوزه برنامه نویسی اومدن برای حل این مشکلات اومدن و یه سری الگو پیشنهاد دادن.
یکی از مهمترین منابع کتاب GoF هست که خوندنش رو به همه عزیزان توصیه میکنم.

این ریپازیتوری گیتهاب رو چند مدت پیش ساختم برای پیاده سازی دیزاین پترن های پر استفاده بدون پیچیدگی خاص و بدون نیاز به درک زبان UML به زبان پایتون

https://github.com/abolfazl8131/python_design_patterns

✅سری مهندسی نرم‌افزار: پست 7
از لینکدین Saeed Shahrivari Joghan
توسعه چابک نرم‌افزار: سرعت یا انطباق؟

حوالی سال ۲۰۰۱ میلادی تعدادی از افراد شناخته شده حوزه نرم‌افزار طی بیانیه‌ای اعلام کردند که به راه‌های بهتری برای توسعه نرم‌افزار نسبت به دهه ۹۰ میلادی رسیدند و عنوان این بیانیه رو گذاشتند «توسعه نرم‌افزار به صورت چابک». بر خلاف روش‌های کلاسیک اجایل ارز‌ش‌های جدیدی رو تاکید می‌کرد:
۱- ارزش بیشتر افراد و تعاملات نسبت به فرآیند‌ها و ابزار
۲- ارزش بیشتر نرم‌افزاری که کار می‌کنه نسبت به مستندات مفصل
۳- ارزش بیشتر تعامل با مشتری نسبت به مذاکره قرارداد
۴- ارزش بیشتر پاسخ به تغییر نسبت به پایبندی به برنامه قبلی
زیر بیانیه هم یه نکته نوشته شده که معمولاً کسی نمی‌خونه: «آيتم‌های آخری بی‌ارزش نیستند بلکه آیتم‌های اولی ارزش بیشتری دارند.»

من همیشه اعتقاد داشتم که اجایل بودن به معنی سریع بودن نیست بلکه ذات فلسفه اجایل «پاسخ و واکنش مناسب به تغییراته». به قول فرنگیا که میگن embracing change یعنی فراتر از پذیرش تغییرات اونها رو در آغوش بکشیم. سوال مهم اینه که «چرا باید انقدر در مقابل تغییرات منعطف باشیم؟» من در پاسخش دو تا نکته دارم:
۱- در فرآیند تولید نرم‌افزار مخصوصا شناسایی دقیق نیازمندی کاربر ما درگیر یه پروسه غیر قطعی، تکاملی و اکتشافی هستیم. یعنی ما به مرور متوجه نیازمندی دقیق کاربر میشیم و خیلی مواقع این نیازمندی‌ها تغییر می‌کنند پس ما باید به جای جنگیدن با تغییر اونها رو کامل بپذیریم. یکی از راهکار اصلی چابکی برای هضم تغییرات فرآیند تکرار‌شونده و افزایشی هست.
۲- از دید من چابکی و هضم تغییرات در راستای بقای کسب‌وکار تعریف میشه. یعنی مثل روال طبیعت اگه با تغییرات بیشتر خودت رو وفق بدی، بیشتر بقا پیدا می‌کنی. در واقع مثال خوب برای چابکی یوزپلنگ نیست که با اینکه خیلی سریعه ولی همه جا در حال انقراضه بلکه مثال خوب میتونه حضرت کروکدیل باشه که ده‌ها میلیون سال روی زمین بقا داشته. پس معمولاً شرکتی که چابکتر باشه به تغییرات واکنش بهتری نشون میده و در بازار بقای بیشتری پیدا می‌کنه.

در زمینه چابکی حرف زیاده ولی تو این پست بیشتر از این اطاله کلام نمی‌کنم و در پست‌های بعدی بیشتر توضیح میدم. برای یادآوری هم که شده بد نیست نگاهی مجدد به بیانیه چابکی بندازیم:
https://agilemanifesto.org/

دوست دارید موضوع بعدی چی باشه؟
public poll

الگوهای طراحی – 12
??????? 46%
@Mehrdadbn9, @Alicris7, @amir0xdev, @FAROKHPASHA, @erfan_rfmhr, @Amin_Shahbaghi, @alireza_fai, @Yaser11138, Maede, @lpic4, @Siro7o, @mojtb81

تحلیل و طراحی شی گرا – 9
????? 35%
@Mmo1983, @h4_m3d, @Mojo9494, @Amirkh_MoD, @P_R_909, @miladhzz, @Hoomanspp, @id_sakhtam, @Amir_pq021

متدولوژی UP – 3
?? 12%
@Pourya_shz, @SSeanin, @ZeinabSajjadi

متدولوژی DAD – 2
? 8%
@Mohammadreza_Mahmoudi, Sh_

? 26 people voted so far.