سلام سلام.
من در دو جا کتاب هایی که می خونم رو لیست می کنم.
یکی وبلاگم خودم هست در بخش قفسه کتاب که سعی می کنم بعد از معرفی، چند خطی هم براشون بنویسم.
این قفسه رو می تونید از اینجا پیدا کنید :
https://B2n.ir/book-shelf
یه بخش دیگه هم مربوط به کتاب های تخصصی-فنی هست که توی سایت @refhubofficial یک بخشی رو عزیزان به من اختصاص دادن که می تونید از اونجا کتاب ها رو ببینید که از این آدرس قابل دسترسی هست :
https://B2n.ir/m-refhub
من در دو جا کتاب هایی که می خونم رو لیست می کنم.
یکی وبلاگم خودم هست در بخش قفسه کتاب که سعی می کنم بعد از معرفی، چند خطی هم براشون بنویسم.
این قفسه رو می تونید از اینجا پیدا کنید :
https://B2n.ir/book-shelf
یه بخش دیگه هم مربوط به کتاب های تخصصی-فنی هست که توی سایت @refhubofficial یک بخشی رو عزیزان به من اختصاص دادن که می تونید از اونجا کتاب ها رو ببینید که از این آدرس قابل دسترسی هست :
https://B2n.ir/m-refhub
❤11👍3🆒1
سلام.
عزیزی اومده پیش من و برای دوره ای که می‌خواد برگزار کنه(آموزش برنامه نویسی) سیلابس هاشو چک کنه.
من با کانتنت مخالف بودم، چون به نظرم برای اون سطح زیاد بود و قوام و ساختار نداشت.
اون دوست عزیز قبول نکرد.
اینجا همونجایی هست که بر میگردم به اصالت.
برگزار کردن دوره و جمع کردن به تعداد آدم و دریافت پول ازشون کار راحتیه، ولی چه قدر اصالت داریم که:
۱. محتوا با کیفیته؟
۲. خودمون توامندیم؟
۳. مسیر مشخصه؟
۴. برنامه اصولیه؟
این میشه نتیجه اینکه توی سال هایی که من تدریس آموزشگاهی داشتم، بخشی از دانشجو هام از دوره اساتید معروفی میومدن که بعد از صرف کلی زمان و پول، قادر به کار نبودن.
اصالت داشتن در انتقال دانش(چه در تیم، چه در شرکت، چه در دوره آموزشی و یا چه در آموزشگاه) خیلی کار سخت و جان کاهیه.
عزیزی اومده پیش من و برای دوره ای که می‌خواد برگزار کنه(آموزش برنامه نویسی) سیلابس هاشو چک کنه.
من با کانتنت مخالف بودم، چون به نظرم برای اون سطح زیاد بود و قوام و ساختار نداشت.
اون دوست عزیز قبول نکرد.
اینجا همونجایی هست که بر میگردم به اصالت.
برگزار کردن دوره و جمع کردن به تعداد آدم و دریافت پول ازشون کار راحتیه، ولی چه قدر اصالت داریم که:
۱. محتوا با کیفیته؟
۲. خودمون توامندیم؟
۳. مسیر مشخصه؟
۴. برنامه اصولیه؟
این میشه نتیجه اینکه توی سال هایی که من تدریس آموزشگاهی داشتم، بخشی از دانشجو هام از دوره اساتید معروفی میومدن که بعد از صرف کلی زمان و پول، قادر به کار نبودن.
اصالت داشتن در انتقال دانش(چه در تیم، چه در شرکت، چه در دوره آموزشی و یا چه در آموزشگاه) خیلی کار سخت و جان کاهیه.
👍25❤4👎1
فردا اولین جلسه دوره Techlead 360 هست و من خیلی هیجان شروع دوره رو دارم.
این احتمالا آخرین برگزاری این دوره در امسال خواهد بود.
در کنار دوره Techlead 360 که دوره حرفه ای مدیران تک هست، دوره بعدی رو به زودی معرفی خواهیم کرد با عنوان "10x Engineer" که برای مهندسان نرم افزار طراحی شده و هدفش پرورش مهندسین نرم افزاری هست که یه سر و گردن از بقیه بالاتر باشن و توانمندی هایی داشته باشن که سازمان ها رو جا به جا کنه. توانمندی هایی که به صورت عادی شاید حتی براتون مشخص هم نبوده.
این احتمالا آخرین برگزاری این دوره در امسال خواهد بود.
در کنار دوره Techlead 360 که دوره حرفه ای مدیران تک هست، دوره بعدی رو به زودی معرفی خواهیم کرد با عنوان "10x Engineer" که برای مهندسان نرم افزار طراحی شده و هدفش پرورش مهندسین نرم افزاری هست که یه سر و گردن از بقیه بالاتر باشن و توانمندی هایی داشته باشن که سازمان ها رو جا به جا کنه. توانمندی هایی که به صورت عادی شاید حتی براتون مشخص هم نبوده.
👍12❤11🎉3🔥1
Forwarded from tech-afternoon (Amin Mesbahi)
✨ DORA چیه؟
فریم‌ورک DORA که مختصر شده‌ی DevOps Research and Assessment است، یک فریم‌ورک برای تحقیق و ارزیابیه که تمرکزش روی بهبود مستمر تحویل نرم‌افزار در سازمان‌هاست. هدف DORA کمک به تیم‌ها و سازمان‌ها برای بهبود عملکرد و شناسایی نقاط ضعف فرآیند توسعه و عملیاتشونه. DORA بر اساس گزارش‌های سالانه مثل "Accelerate State of DevOps" و ۴ معیار کلیدی (DORA Metrics) شناخته میشه:
اول: Lead Time for Changes
زمان لازم برای انتقال تغییرات کد به محیط تولید.
دوم: Deployment Frequency
تعداد دفعات دیپلوی به محیط تولید.
سوم: Change Failure Rate
درصد دیپلوی‌های ناموفق که باعث مشکلات در محیط تولید میشه.
چهارم: Time to Restore Service
زمان لازم برای رفع خرابی و بازگرداندن سیستم به حالت پایدار.
🧐 به چه درد می‌خوره؟
فریم‌ورک DORA به تیم‌ها کمک میکنه تا عملکرد خودشون رو ارزیابی کنن و با استفاده از «داده» تصمیم بگیرن که کدوم بخش‌ها نیاز به بهبود دارن. گزارش‌های DORA به سازمان‌ها کمک میکنه تا با بررسی این معیارها، روند بهبود مستمر رو پیاده‌سازی کنن و بهترین عملکرد رو به دست بیارن.
⚙️ استفاده از DORA برای بهبود پایدار عملکرد مهندسی سازمانه، چند موضوع مهم:
🔹 چالش جمع‌آوری داده: به دست آوردن داده‌های دقیق برای متریک‌های DORA همیشه آسون نیست. ابزارهای اتوماتیک کمک می‌کنن، ولی هنوز هم تلاش زیادی برای ادغام این ابزارها در اکوسیستم سازمان نیاز هست.
🔹 اهمیت بازخورد: تیم‌ها می‌تونن از گزارش‌های DORA به عنوان بخشی از فرآیند بهبود مستمر استفاده کنن، مشابه یک ریتروسپکتیو تیمی که با تحلیل گزارش‌ها به اقدامات جدید می‌رسن.
🔹 تأثیرات پیاده‌سازی درست DORA: پیاده‌سازی درست DORA خیلی به رهبری و نحوه حمایت از اون بستگی داره. اگر تیم‌ها آزادی عمل داشته باشن تا بهبودهای خودشون رو انتخاب کنن، نتایج پایدارتری به دست می‌آد.
🔹تیم‌های موفق از استانداردهای صنعتی الهام می‌گیرن: تبیین قابلیت‌های DORA باعث میشه تا تیم‌ها بهتر بتونن معیارها رو درک کنن و از "این نظر منه" و "نظر تو چیه" فاصله بگیرن و به یک استاندارد صنعتی مشترک برسن.
🧾 نکات جالب از گزارش DORA 2024
🔸 رشد استفاده از هوش مصنوعی: پذیرش هوش مصنوعی داره به شدت رشد میکنه و تیم‌ها گزارش دادن که استفاده از AI باعث افزایش بهره‌وری، کیفیت کد، و سرعت بررسی‌های کد شده. با این حال، استفاده از AI تأثیر منفی کوچکی روی پایداری تحویل نرم‌افزار داشته.
🔸 مهندسی پلتفرم: گزارش اشاره کرده که تیم‌های استفاده‌کننده از پلتفرم‌های داخلی ۱۰ درصد بهره‌وری بیشتری داشتن، ولی کاهش ۸ درصدی در throughput و ۱۴ درصدی در stability هم مشاهده شده.
🔸 تثبیت اولویت‌ها: سازمان‌هایی که اولویت‌های پایدار دارن، بهره‌وری بیشتری دارن و سطح فرسودگی (burnout) کارکنان پایین‌تره.
❇️ خلاصه اینکه، روشمند و ساختاریافته در مورد فرایندهامون رفتار کنیم 😉
🔗 وب‌سایت DORA
🔗 گزارش سال ۲۰۲۴
فریم‌ورک DORA که مختصر شده‌ی DevOps Research and Assessment است، یک فریم‌ورک برای تحقیق و ارزیابیه که تمرکزش روی بهبود مستمر تحویل نرم‌افزار در سازمان‌هاست. هدف DORA کمک به تیم‌ها و سازمان‌ها برای بهبود عملکرد و شناسایی نقاط ضعف فرآیند توسعه و عملیاتشونه. DORA بر اساس گزارش‌های سالانه مثل "Accelerate State of DevOps" و ۴ معیار کلیدی (DORA Metrics) شناخته میشه:
اول: Lead Time for Changes
زمان لازم برای انتقال تغییرات کد به محیط تولید.
دوم: Deployment Frequency
تعداد دفعات دیپلوی به محیط تولید.
سوم: Change Failure Rate
درصد دیپلوی‌های ناموفق که باعث مشکلات در محیط تولید میشه.
چهارم: Time to Restore Service
زمان لازم برای رفع خرابی و بازگرداندن سیستم به حالت پایدار.
🧐 به چه درد می‌خوره؟
فریم‌ورک DORA به تیم‌ها کمک میکنه تا عملکرد خودشون رو ارزیابی کنن و با استفاده از «داده» تصمیم بگیرن که کدوم بخش‌ها نیاز به بهبود دارن. گزارش‌های DORA به سازمان‌ها کمک میکنه تا با بررسی این معیارها، روند بهبود مستمر رو پیاده‌سازی کنن و بهترین عملکرد رو به دست بیارن.
⚙️ استفاده از DORA برای بهبود پایدار عملکرد مهندسی سازمانه، چند موضوع مهم:
🔹 چالش جمع‌آوری داده: به دست آوردن داده‌های دقیق برای متریک‌های DORA همیشه آسون نیست. ابزارهای اتوماتیک کمک می‌کنن، ولی هنوز هم تلاش زیادی برای ادغام این ابزارها در اکوسیستم سازمان نیاز هست.
🔹 اهمیت بازخورد: تیم‌ها می‌تونن از گزارش‌های DORA به عنوان بخشی از فرآیند بهبود مستمر استفاده کنن، مشابه یک ریتروسپکتیو تیمی که با تحلیل گزارش‌ها به اقدامات جدید می‌رسن.
🔹 تأثیرات پیاده‌سازی درست DORA: پیاده‌سازی درست DORA خیلی به رهبری و نحوه حمایت از اون بستگی داره. اگر تیم‌ها آزادی عمل داشته باشن تا بهبودهای خودشون رو انتخاب کنن، نتایج پایدارتری به دست می‌آد.
🔹تیم‌های موفق از استانداردهای صنعتی الهام می‌گیرن: تبیین قابلیت‌های DORA باعث میشه تا تیم‌ها بهتر بتونن معیارها رو درک کنن و از "این نظر منه" و "نظر تو چیه" فاصله بگیرن و به یک استاندارد صنعتی مشترک برسن.
🧾 نکات جالب از گزارش DORA 2024
🔸 رشد استفاده از هوش مصنوعی: پذیرش هوش مصنوعی داره به شدت رشد میکنه و تیم‌ها گزارش دادن که استفاده از AI باعث افزایش بهره‌وری، کیفیت کد، و سرعت بررسی‌های کد شده. با این حال، استفاده از AI تأثیر منفی کوچکی روی پایداری تحویل نرم‌افزار داشته.
🔸 مهندسی پلتفرم: گزارش اشاره کرده که تیم‌های استفاده‌کننده از پلتفرم‌های داخلی ۱۰ درصد بهره‌وری بیشتری داشتن، ولی کاهش ۸ درصدی در throughput و ۱۴ درصدی در stability هم مشاهده شده.
🔸 تثبیت اولویت‌ها: سازمان‌هایی که اولویت‌های پایدار دارن، بهره‌وری بیشتری دارن و سطح فرسودگی (burnout) کارکنان پایین‌تره.
❇️ خلاصه اینکه، روشمند و ساختاریافته در مورد فرایندهامون رفتار کنیم 😉
🔗 وب‌سایت DORA
🔗 گزارش سال ۲۰۲۴
dora.dev
DORA | Get Better at Getting Better
DORA is a long running research program that seeks to understand the capabilities that drive software delivery and operations performance. DORA helps teams apply those capabilities, leading to better organizational performance.
👍9
tech-afternoon
✨ DORA چیه؟ فریم‌ورک DORA که مختصر شده‌ی DevOps Research and Assessment است، یک فریم‌ورک برای تحقیق و ارزیابیه که تمرکزش روی بهبود مستمر تحویل نرم‌افزار در سازمان‌هاست. هدف DORA کمک به تیم‌ها و سازمان‌ها برای بهبود عملکرد و شناسایی نقاط ضعف فرآیند توسعه…
این پست از استاد امین مصباحی عزیز رو ببینید.
نکته قابل توجهش برای من، روشمند و ساختیافته کردن کارهاست که بهبود واقعی رو ایجاد می کنه.
نکته قابل توجهش برای من، روشمند و ساختیافته کردن کارهاست که بهبود واقعی رو ایجاد می کنه.
👍5
Forwarded from tech-afternoon (Amin Mesbahi)
🎇 رویداد Microsoft Ignite 2024 و آینده‌ی SQL Server
رویداد Microsoft Ignite یکی از مهمترین رویدادهای سالانه مایکروسافته که تمرکز اصلیش روی ارائه آخرین نوآوری‌ها، تکنولوژی‌ها و پیشرفت‌های Azure و خدمات ابری، دیتابیس، DevOps، هوش مصنوعی و امنیته. رویداد امسال هم مثل چند سال گذشته که تب AI حسابی داغ بوده، کلی معرفی محصول روی هوش مصنوعی داره که از فردا شروع میشه. یکی از موضوعات مهمش هم AI برای SQL Server است.
📢 جلسه: The SQL Server roadmap: The next generation database AI platform
🗓 چهارشنبه، ۲۰ نوامبر ساعت ۱۸ (به وقت تهران)
توی این جلسه قراره تا شاهد معرفی آخرین قابلیت‌های هوش مصنوعی که قراره در نسخه آینده‌ی SQL Server اضافه بشه باشیم. احتمالا متوجه می‌شیم که نسخه بعدی چیه و چه‌زمانی منتشر میشه، از طرف دیگه ابزارهای AI و ML که به صورت بومی توی Microsoft SQL Server و Azure SQL رونمایی می‌شن رو می‌بینیم. موضوعات جلسه:
- معرفی AI-native capabilities که امکانات هوش مصنوعی رو به طور مستقیم در موتور SQL Server اضافه میکنه.
- پشتیبانی از مدل‌های ML: قابلیت اجرای مدل‌های ML از طریق T-SQL بدون نیاز به سرویس خارجی.
- بهبود AutoML integration از نظر عملکرد تحلیل داده و قابلیت‌های پیش‌بینی بدون نیاز به دانش عمیق از ML.
🤖 🤖 🤖 حالا بد نیست یه نگاه به بازار دیتابیس‌های سنتی بندازیم و بررسی وضعیت AI توی دیتابیس‌های مختلف
نسخه فعلی Microsoft SQL Server
بهبود یکپارچگی با Python و R: نسخه‌های قبلی ابتدا R و بعدتر Python به SQL Server اضافه شدن و امکان اجرای اسکریپت‌های Python و R رو به همراه داده‌ها فراهم کرده شده بودن.
امکانات ML Services: سرویس‌های یادگیری ماشین توی SQL Server یکپارچه هستن تا مدل‌های ML به سادگی روی دیتابیس آموزش ببینن و اجرا بشن.
اتصال و ادغام با Azure AI: امکان اتصال و ادغام SQL Server با سرویس‌های Azure AI برای استفاده از مدل‌های آماده و از پیش آموزش‌دیده.
🔴 دیتابیس سرور Oracle Database 23ai
اوراکل به عنوان رقیب سنتی SQL Server توی نسخه 23 توجه ویژه‌ای به AI و ML داشت و عملا AI Vector Search رو هم به انجین آورد.
قابلیت In-database Machine Learning که مستقیماً توی دل دیتابیس انجین قرار داده باعث میشه بتونیم مدل‌های ML رو بدون انتقال داده به سرویس خارجی اجرا کنیم.
قابلیتAutoML هم به کاربر امکان پیدا کردن خودکار بهترین مدل و تنظیمات رو برای داده‌های موجودش فراهم میکنه.
پشتیبانی از Python و SQLML: اوراکل هم از پایتون برای پیاده‌سازی مدل‌های ML پشتیبانی میکنه
🟢 ۳: سرور PostgreSQL
بین دیتابیس‌های کدباز PostgreSQL هم به عنوان انجین خوشنام و پیشرو، قابلیت‌های AI و ML رو از طریق افزونه‌ها و پلاگین‌ها فراهم میکنه:
- افزونه pgml: افزونه‌ای برای Machine Learning که امکان آموزش و اجرای مدل‌ها رو از دل دیتابیس فراهم میکنه.
- یکپارچگی Python integration) PL/Python) امکان نوشتن توابع Python و اجرا در داخل PostgreSQL ممکن میکنه.
- پشتیبانی از ابزارهای محبوب ML مثل TensorFlow و Scikit-learn که از طریق Python در دسترسه.
🟡 ۴: سرور MySQL
MySQL با وجود محبوبیت زیاد، از لحاظ قابلیت‌های بومی AI و ML از رقبا عقب‌تره! که البته از Oracle جز این انتظار نمی‌ره! از روزی که MySQL کم‌توجه بوده بهش 😏
✨ ✨ 🧞♂️ انتظارات از نسخه بعدی Microsoft SQL Server
با توجه به تمرکز مایکروسافت روی AI، میشه «حدس زد» که قابلیت‌های زیر در نسخه‌های آتی SQL Server اضافه بشه (فقط حدس منه، خبر نیست!):
- قابلیت AI-driven Query Optimization: استفاده از هوش مصنوعی برای بهبود عملکرد کوئری‌ها و کاهش زمان پاسخگویی.
- بهبود AutoML Integration: یکپارچگی بیشتر با سرویس‌های AutoML Azure و امکان آموزش مدل‌های پیچیده‌تر.
- اضافه شدن Native AI Functions: اضافه شدن توابع پیش‌فرض AI مثل توابع پیش‌بینی و دسته‌بندی به T-SQL.
- تمهیدات Data Privacy & AI: استفاده از AI برای تضمین امنیت و حریم خصوصی داده‌ها در دیتابیس.
👨💻 نظر شما چیه؟ چهارشنبه این جلسه رو میبینید؟ کاربرد AI توی دیتابیس انجین براتون جذابیت/کاربرد داره؟
صفحه رسمی رویداد
صفحه رسمی جلسات رویداد Ignite 2024
رویداد Microsoft Ignite یکی از مهمترین رویدادهای سالانه مایکروسافته که تمرکز اصلیش روی ارائه آخرین نوآوری‌ها، تکنولوژی‌ها و پیشرفت‌های Azure و خدمات ابری، دیتابیس، DevOps، هوش مصنوعی و امنیته. رویداد امسال هم مثل چند سال گذشته که تب AI حسابی داغ بوده، کلی معرفی محصول روی هوش مصنوعی داره که از فردا شروع میشه. یکی از موضوعات مهمش هم AI برای SQL Server است.
📢 جلسه: The SQL Server roadmap: The next generation database AI platform
🗓 چهارشنبه، ۲۰ نوامبر ساعت ۱۸ (به وقت تهران)
توی این جلسه قراره تا شاهد معرفی آخرین قابلیت‌های هوش مصنوعی که قراره در نسخه آینده‌ی SQL Server اضافه بشه باشیم. احتمالا متوجه می‌شیم که نسخه بعدی چیه و چه‌زمانی منتشر میشه، از طرف دیگه ابزارهای AI و ML که به صورت بومی توی Microsoft SQL Server و Azure SQL رونمایی می‌شن رو می‌بینیم. موضوعات جلسه:
- معرفی AI-native capabilities که امکانات هوش مصنوعی رو به طور مستقیم در موتور SQL Server اضافه میکنه.
- پشتیبانی از مدل‌های ML: قابلیت اجرای مدل‌های ML از طریق T-SQL بدون نیاز به سرویس خارجی.
- بهبود AutoML integration از نظر عملکرد تحلیل داده و قابلیت‌های پیش‌بینی بدون نیاز به دانش عمیق از ML.
🤖 🤖 🤖 حالا بد نیست یه نگاه به بازار دیتابیس‌های سنتی بندازیم و بررسی وضعیت AI توی دیتابیس‌های مختلف
نسخه فعلی Microsoft SQL Server
بهبود یکپارچگی با Python و R: نسخه‌های قبلی ابتدا R و بعدتر Python به SQL Server اضافه شدن و امکان اجرای اسکریپت‌های Python و R رو به همراه داده‌ها فراهم کرده شده بودن.
امکانات ML Services: سرویس‌های یادگیری ماشین توی SQL Server یکپارچه هستن تا مدل‌های ML به سادگی روی دیتابیس آموزش ببینن و اجرا بشن.
اتصال و ادغام با Azure AI: امکان اتصال و ادغام SQL Server با سرویس‌های Azure AI برای استفاده از مدل‌های آماده و از پیش آموزش‌دیده.
🔴 دیتابیس سرور Oracle Database 23ai
اوراکل به عنوان رقیب سنتی SQL Server توی نسخه 23 توجه ویژه‌ای به AI و ML داشت و عملا AI Vector Search رو هم به انجین آورد.
قابلیت In-database Machine Learning که مستقیماً توی دل دیتابیس انجین قرار داده باعث میشه بتونیم مدل‌های ML رو بدون انتقال داده به سرویس خارجی اجرا کنیم.
قابلیتAutoML هم به کاربر امکان پیدا کردن خودکار بهترین مدل و تنظیمات رو برای داده‌های موجودش فراهم میکنه.
پشتیبانی از Python و SQLML: اوراکل هم از پایتون برای پیاده‌سازی مدل‌های ML پشتیبانی میکنه
🟢 ۳: سرور PostgreSQL
بین دیتابیس‌های کدباز PostgreSQL هم به عنوان انجین خوشنام و پیشرو، قابلیت‌های AI و ML رو از طریق افزونه‌ها و پلاگین‌ها فراهم میکنه:
- افزونه pgml: افزونه‌ای برای Machine Learning که امکان آموزش و اجرای مدل‌ها رو از دل دیتابیس فراهم میکنه.
- یکپارچگی Python integration) PL/Python) امکان نوشتن توابع Python و اجرا در داخل PostgreSQL ممکن میکنه.
- پشتیبانی از ابزارهای محبوب ML مثل TensorFlow و Scikit-learn که از طریق Python در دسترسه.
🟡 ۴: سرور MySQL
MySQL با وجود محبوبیت زیاد، از لحاظ قابلیت‌های بومی AI و ML از رقبا عقب‌تره! که البته از Oracle جز این انتظار نمی‌ره! از روزی که MySQL کم‌توجه بوده بهش 😏
✨ ✨ 🧞♂️ انتظارات از نسخه بعدی Microsoft SQL Server
با توجه به تمرکز مایکروسافت روی AI، میشه «حدس زد» که قابلیت‌های زیر در نسخه‌های آتی SQL Server اضافه بشه (فقط حدس منه، خبر نیست!):
- قابلیت AI-driven Query Optimization: استفاده از هوش مصنوعی برای بهبود عملکرد کوئری‌ها و کاهش زمان پاسخگویی.
- بهبود AutoML Integration: یکپارچگی بیشتر با سرویس‌های AutoML Azure و امکان آموزش مدل‌های پیچیده‌تر.
- اضافه شدن Native AI Functions: اضافه شدن توابع پیش‌فرض AI مثل توابع پیش‌بینی و دسته‌بندی به T-SQL.
- تمهیدات Data Privacy & AI: استفاده از AI برای تضمین امنیت و حریم خصوصی داده‌ها در دیتابیس.
👨💻 نظر شما چیه؟ چهارشنبه این جلسه رو میبینید؟ کاربرد AI توی دیتابیس انجین براتون جذابیت/کاربرد داره؟
صفحه رسمی رویداد
صفحه رسمی جلسات رویداد Ignite 2024
Microsoft
The SQL Server roadmap: The next generation database AI platform
In this session, we will explore the roadmap of SQL Server including future capabilities for AI applications deeply integrated into the security zone of the SQL Server engine. We will also show you AI assisted experiences to help you manage SQL Server including…
👍1
Forwarded from TechTube 𝕏 تک توب
Media is too big
VIEW IN TELEGRAM
در حالی که جگوار سرگرم لوگوی مسخره اشه، شرکت ولوو برای نشون دادن ایمنی خودروهاش چنین تبلیغاتی منتشر میکنه.
این تبلیغ توسط Hoyte Van Hoytema، فیلمبردار فیلمهای درخشان Interstellar و Oppenheimer فیلمبرداری شده!
📍 @TechTube
این تبلیغ توسط Hoyte Van Hoytema، فیلمبردار فیلمهای درخشان Interstellar و Oppenheimer فیلمبرداری شده!
📍 @TechTube
❤12👍7🔥1👌1
Forwarded from tech-afternoon (Amin Mesbahi)
🚀🚀 تست رفتارها و خطاهای API به سادگی، با Dev Proxy
—————————————————————————
تا حالا شده موقع توسعه یه اپلیکیشن، API ای که ازش استفاده می‌کردید یهو به مشکل بخوره؟ مثلاً سرور پاسخ نده، تأخیر داشته باشه، یا با خطای محدودیت نرخ (Rate Limit) روبه‌رو بشین؟ خب، اگه یه اپلیکیشن اصولی می‌سازین، باید بدونین که این اتفاقات واقعی‌ان و ممکنه تجربه کاربر رو خراب کنن.
برای اینکه این مشکلات رو قبل از اینکه وارد دنیای واقعی بشین شبیه‌سازی کنین، یه ابزار خیلی خوب به اسم Dev Proxy موجود داره برای شبیه‌سازی این مشکلات. با Dev Proxy می‌تونین رفتارهای مختلف رو شبیه‌سازی کنین و مطمئن بشین اپلیکیشن‌تون تو هر شرایطی سر بلند بیرون میاد.
♻️ کاربرد Dev Proxy: کجا به درد می‌خوره؟
در واقع Dev Proxy دقیقاً یه پروکسی شبکه است که بین اپلیکیشن شما و API قرار می‌گیره. وظیفه‌اش شبیه‌سازی شرایطیه که ممکنه یه API تو دنیای واقعی تجربه کنه. مثل:
- ایجاد تأخیر (Latency): شبیه‌سازی شرایطی که سرور کند پاسخ میده.
- خطاهای HTTP: مثل خطاهای 500 (Internal Server Error)، یا 404 (Not Found) یا حتی 429 (Too Many Requests).
- خطای Rate Limiting: مثلا وقتی که اپلیکیشن شما API رو صدا میکنه ولی با خطای محدودیت نرخ درخواست‌ها روبرو میشه چی میشه.
- حذف داده‌ها یا پاسخ‌های ناقص از طرف API
⚙️ مثال عملی:
فرض کنین یه اپلیکیشن مالی نوشتین که نرخ تبدیل ارزها رو از یه API می‌گیره. حالا، اگه API به هر دلیلی کند بشه یا خطا بده، اپلیکیشن شما نباید متوقف بشه یا داده اشتباه نشون بده. با Dev Proxy می‌تونید این سناریوها رو شبیه‌سازی کنید و رفتار اپلیکیشن رو در این شرایط بسنجین.
یکی از خوبی‌های Dev Proxy اینه که به زبان یا تکنولوژی خاصی وابسته نیست. عملا یه ابزار جمع‌وجوره که روی مک، لینوکس یا ویندوز نصب میشه و شما می‌تونید ازش برای هر اپلیکیشنی که با API از نوع HTTP REST یا gRPC کار میکنه، استفاده کنید. فرقی هم نداره اپلیکیشن دات‌نت، جاوا، پایتون، یا جاوااسکریپت باشه.
من قدیم از Mountebank استفاده می‌کردم ولی از ده سال پیش دیگه آپدیت نداد، بعدش postman mock server و مدتی از WireMock و یک سالی میشه که اکثرا از Dev Proxy استفاده می‌کنم، تقریبا از زمانی که دیگه کم‌کم به ابزار خوبی تبدیل شد، با اینکه هنوز به نسخه ۱ نرسیده ولی اکثر نیازها رو برای توسعه و تست برآورده میکنه و به راحتی توی CI/CD قرار می‌گیره.
گیت‌هاب
مستندات رسمی
نصب روی ویندوز:
winget install Microsoft.DevProxy
نصب رو مک:
brew tap microsoft/dev-proxy
brew install dev-proxy
نصب روی لینوکس:
bash -c "$(curl -sL https://aka.ms/devproxy/setup.sh)"
مثال:
برای شبیه سازی تاخیر ۲ ثانیه‌ای در پاسخ دادن:
dev-proxy --latency 2000
برای برگردوندن خطای ۵۰۰
dev-proxy --error 500
✨ نظرتون چیه؟ بعد از انتشار ویدیو aspire بریم سراغ ویدیو آموزشی براش؟
—————————————————————————
تا حالا شده موقع توسعه یه اپلیکیشن، API ای که ازش استفاده می‌کردید یهو به مشکل بخوره؟ مثلاً سرور پاسخ نده، تأخیر داشته باشه، یا با خطای محدودیت نرخ (Rate Limit) روبه‌رو بشین؟ خب، اگه یه اپلیکیشن اصولی می‌سازین، باید بدونین که این اتفاقات واقعی‌ان و ممکنه تجربه کاربر رو خراب کنن.
برای اینکه این مشکلات رو قبل از اینکه وارد دنیای واقعی بشین شبیه‌سازی کنین، یه ابزار خیلی خوب به اسم Dev Proxy موجود داره برای شبیه‌سازی این مشکلات. با Dev Proxy می‌تونین رفتارهای مختلف رو شبیه‌سازی کنین و مطمئن بشین اپلیکیشن‌تون تو هر شرایطی سر بلند بیرون میاد.
♻️ کاربرد Dev Proxy: کجا به درد می‌خوره؟
در واقع Dev Proxy دقیقاً یه پروکسی شبکه است که بین اپلیکیشن شما و API قرار می‌گیره. وظیفه‌اش شبیه‌سازی شرایطیه که ممکنه یه API تو دنیای واقعی تجربه کنه. مثل:
- ایجاد تأخیر (Latency): شبیه‌سازی شرایطی که سرور کند پاسخ میده.
- خطاهای HTTP: مثل خطاهای 500 (Internal Server Error)، یا 404 (Not Found) یا حتی 429 (Too Many Requests).
- خطای Rate Limiting: مثلا وقتی که اپلیکیشن شما API رو صدا میکنه ولی با خطای محدودیت نرخ درخواست‌ها روبرو میشه چی میشه.
- حذف داده‌ها یا پاسخ‌های ناقص از طرف API
⚙️ مثال عملی:
فرض کنین یه اپلیکیشن مالی نوشتین که نرخ تبدیل ارزها رو از یه API می‌گیره. حالا، اگه API به هر دلیلی کند بشه یا خطا بده، اپلیکیشن شما نباید متوقف بشه یا داده اشتباه نشون بده. با Dev Proxy می‌تونید این سناریوها رو شبیه‌سازی کنید و رفتار اپلیکیشن رو در این شرایط بسنجین.
یکی از خوبی‌های Dev Proxy اینه که به زبان یا تکنولوژی خاصی وابسته نیست. عملا یه ابزار جمع‌وجوره که روی مک، لینوکس یا ویندوز نصب میشه و شما می‌تونید ازش برای هر اپلیکیشنی که با API از نوع HTTP REST یا gRPC کار میکنه، استفاده کنید. فرقی هم نداره اپلیکیشن دات‌نت، جاوا، پایتون، یا جاوااسکریپت باشه.
من قدیم از Mountebank استفاده می‌کردم ولی از ده سال پیش دیگه آپدیت نداد، بعدش postman mock server و مدتی از WireMock و یک سالی میشه که اکثرا از Dev Proxy استفاده می‌کنم، تقریبا از زمانی که دیگه کم‌کم به ابزار خوبی تبدیل شد، با اینکه هنوز به نسخه ۱ نرسیده ولی اکثر نیازها رو برای توسعه و تست برآورده میکنه و به راحتی توی CI/CD قرار می‌گیره.
گیت‌هاب
مستندات رسمی
نصب روی ویندوز:
winget install Microsoft.DevProxy
نصب رو مک:
brew tap microsoft/dev-proxy
brew install dev-proxy
نصب روی لینوکس:
bash -c "$(curl -sL https://aka.ms/devproxy/setup.sh)"
مثال:
برای شبیه سازی تاخیر ۲ ثانیه‌ای در پاسخ دادن:
dev-proxy --latency 2000
برای برگردوندن خطای ۵۰۰
dev-proxy --error 500
✨ نظرتون چیه؟ بعد از انتشار ویدیو aspire بریم سراغ ویدیو آموزشی براش؟
GitHub
GitHub - dotnet/dev-proxy: Simulate API failures, throttling, and chaos — all from your command line.
Simulate API failures, throttling, and chaos — all from your command line. - dotnet/dev-proxy
👍11❤6
Forwarded from کانال مکتب‌خانه DDD
Learn Hexagonal Architecture (aka Ports and Adapters) from It's Creator
Learn from it’s creator the rules and structure of the “Hexagonal”, more correctly called the Ports & Adapters architecture. In this lecture, Dr. Cockburn will describe why he created it, its benefits and also its costs, the UML description, and also some sample code. As an extra challenge, he will invite you to write your first Ports & Adapters application in your favorite language /during/ the talk!
Outline of the lecture:
- Challenge to write a small application during the lecture
- Short form what the code looks like
- Costs, benefits, history: why was it needed
- Viewing your application as a component
- Development sequence
- Examples in Ruby & Java with needed terminology
- How to set up the folders
- The various ways to set up the architecture
- Why is it called /Hexagonal/?
- Summary, checking in with people who accepted the challenge
https://www.youtube.com/watch?v=k0ykTxw7s0Y
A more concise nick name for Hexagonal Architecture as Alistair said is: Ports and Maybe Adapters!
Learn from it’s creator the rules and structure of the “Hexagonal”, more correctly called the Ports & Adapters architecture. In this lecture, Dr. Cockburn will describe why he created it, its benefits and also its costs, the UML description, and also some sample code. As an extra challenge, he will invite you to write your first Ports & Adapters application in your favorite language /during/ the talk!
Outline of the lecture:
- Challenge to write a small application during the lecture
- Short form what the code looks like
- Costs, benefits, history: why was it needed
- Viewing your application as a component
- Development sequence
- Examples in Ruby & Java with needed terminology
- How to set up the folders
- The various ways to set up the architecture
- Why is it called /Hexagonal/?
- Summary, checking in with people who accepted the challenge
https://www.youtube.com/watch?v=k0ykTxw7s0Y
YouTube
Hexagonal Architecture (Alistair Cockburn)
Learn from it’s creator the rules and structure of the “Hexagonal”, more correctly called the Ports & Adapters architecture. In this lecture, Dr. Cockburn will describe why he created it, its benefits and also its costs, the UML description, and also some…
وقتی میگم اصالت داشته باشید دارم در مورد این صحبت می کنم :
استاد دانشگاه سر کلاس توی دوره E-commerce داره نصب Wordpress یاد میده !
اصالت در آموزش یکی از بنیادی ترین اصالت هاست به نظرم.
استاد دانشگاه سر کلاس توی دوره E-commerce داره نصب Wordpress یاد میده !
اصالت در آموزش یکی از بنیادی ترین اصالت هاست به نظرم.
👍21😁8
با انواع Test Double ها آشنایی دارید ؟
در فرآیند توسعه نرم‌افزار و تست نرم‌افزار، وقتی می‌خواهیم یک بخش از سیستم را ایزوله تست کنیم (به‌عنوان مثال یک واحد کد را بدون درگیر شدن با وابستگی‌های خارجی آن تست کنیم)، از مفهومی به نام "Test Double" استفاده می‌کنیم. Test Double یک موجودیت جایگزین برای شیء یا ماژول واقعی هست تا وابستگی‌های خارجی را در زمان تست کنترل‌پذیر و ساده‌تر بشن.
مارتین فاولر بزرگ انواع Test Double را به صورت کلی به پنج دسته تقسیم کرده است که هرکدام هدف و کاربرد خاصی دارند:
Dummy: فقط برای پر کردن جای خالی پارامترها و عدم استفاده عَملی در تست
Stub: برگرداندن پاسخ‌های ثابت و ساده برای حذف وابستگی‌های خارجی
Fake: پیاده‌سازی ساده‌شده و درون حافظه‌ای یک سرویس خارجی واقعی
Spy: مانند Stub اما با قابلیت نظارت و ثبت تعاملات برای بررسی پس از اجرا
Mock: تعریف انتظارات قبل از اجرا و کنترل دقیق تعاملات برای تست رفتار
@learning_with_m
در فرآیند توسعه نرم‌افزار و تست نرم‌افزار، وقتی می‌خواهیم یک بخش از سیستم را ایزوله تست کنیم (به‌عنوان مثال یک واحد کد را بدون درگیر شدن با وابستگی‌های خارجی آن تست کنیم)، از مفهومی به نام "Test Double" استفاده می‌کنیم. Test Double یک موجودیت جایگزین برای شیء یا ماژول واقعی هست تا وابستگی‌های خارجی را در زمان تست کنترل‌پذیر و ساده‌تر بشن.
مارتین فاولر بزرگ انواع Test Double را به صورت کلی به پنج دسته تقسیم کرده است که هرکدام هدف و کاربرد خاصی دارند:
Dummy: فقط برای پر کردن جای خالی پارامترها و عدم استفاده عَملی در تست
Stub: برگرداندن پاسخ‌های ثابت و ساده برای حذف وابستگی‌های خارجی
Fake: پیاده‌سازی ساده‌شده و درون حافظه‌ای یک سرویس خارجی واقعی
Spy: مانند Stub اما با قابلیت نظارت و ثبت تعاملات برای بررسی پس از اجرا
Mock: تعریف انتظارات قبل از اجرا و کنترل دقیق تعاملات برای تست رفتار
@learning_with_m
🙏8❤6
سبک های نوشتن Test در نرم افزار
🇺🇸 Classic(Chicago/Detroit) style TDD
این سبک که در حقیقت توسط Kent Beck توصیه میشه روشی هست که در زمان نوشتن تست ها، شما بیشتر به خروجی اهمیت میدید، نه عملکرد داخلی SUT. به همین دلیل در این روش استفاده از Stub و Fake خیلی بیشتر از Mock هست.
به عبارت دیگه، این روش تست، تمرکزش بر روی External Observed Behavior هست.
🇬🇧 Mockist (London) style TDD
در این سبک بر عکس روش Classic تمرکز بر روی رفتار ها و ارتباطات داخلی یک SUT هست و به همین دلیل در این روش ما بیشتر از Mock ها استفاده می کنیم که به دقت رفتار داخلی رو بتونیم بررسی کنیم.
@learning_with_m
❓ حالا شاید بپرسید کدوم روش بهتره؟
طبق معمول تمام جواب های صنعت نرم افزار : It Depends !
ولی به قول Udi Dahan باید Fully Formed It Depends باشه. برای همین منم سعی می کنیم شرایط رو بگم :
اگر در حال ریفکتور هستند، اگر تعاملات داخلی کد براتون مهم نیست و خروجی مهمه، اگر کدتون وابستگی پیچیده ای نداره و اگر پایداری بالایی در تست ها میخواهید روش Classic بهتر عمل می کنه.
اگر ارتباطات داخلی SUT مهمه، اگر وابستگی زیادی بین اجزا هست، اگر می خواهید بر اساس تست Design کنید، روش Mockist بهتر عملی می کنه.
قطعا میشه این روش های رو جای همدیگه هم استفاده کرد و هیییییییچ چیز در نرم افزار، قطعی نیست و همه چیز به Context بر می گرده.
پ.ن : من یه روش نا محبوب هم برای به خاطر سپاری این دو روش دارم 😝:
اگر دوست داری همه جا سرک بکشی و مستعمره داشته باشی و توی کاره همه فضولی کنی، پس توی London Style باید باشی، تیپیکال انگلستان ! یعنی Mockist.
اگر مدل وطن پرستی طور و درست کار می کنه دست بهش نزن هستی، Chicago طور هستی ! یعنی Classical.
🇺🇸 Classic(Chicago/Detroit) style TDD
این سبک که در حقیقت توسط Kent Beck توصیه میشه روشی هست که در زمان نوشتن تست ها، شما بیشتر به خروجی اهمیت میدید، نه عملکرد داخلی SUT. به همین دلیل در این روش استفاده از Stub و Fake خیلی بیشتر از Mock هست.
به عبارت دیگه، این روش تست، تمرکزش بر روی External Observed Behavior هست.
🇬🇧 Mockist (London) style TDD
در این سبک بر عکس روش Classic تمرکز بر روی رفتار ها و ارتباطات داخلی یک SUT هست و به همین دلیل در این روش ما بیشتر از Mock ها استفاده می کنیم که به دقت رفتار داخلی رو بتونیم بررسی کنیم.
@learning_with_m
❓ حالا شاید بپرسید کدوم روش بهتره؟
طبق معمول تمام جواب های صنعت نرم افزار : It Depends !
ولی به قول Udi Dahan باید Fully Formed It Depends باشه. برای همین منم سعی می کنیم شرایط رو بگم :
اگر در حال ریفکتور هستند، اگر تعاملات داخلی کد براتون مهم نیست و خروجی مهمه، اگر کدتون وابستگی پیچیده ای نداره و اگر پایداری بالایی در تست ها میخواهید روش Classic بهتر عمل می کنه.
اگر ارتباطات داخلی SUT مهمه، اگر وابستگی زیادی بین اجزا هست، اگر می خواهید بر اساس تست Design کنید، روش Mockist بهتر عملی می کنه.
قطعا میشه این روش های رو جای همدیگه هم استفاده کرد و هیییییییچ چیز در نرم افزار، قطعی نیست و همه چیز به Context بر می گرده.
پ.ن : من یه روش نا محبوب هم برای به خاطر سپاری این دو روش دارم 😝:
اگر دوست داری همه جا سرک بکشی و مستعمره داشته باشی و توی کاره همه فضولی کنی، پس توی London Style باید باشی، تیپیکال انگلستان ! یعنی Mockist.
اگر مدل وطن پرستی طور و درست کار می کنه دست بهش نزن هستی، Chicago طور هستی ! یعنی Classical.
👍8⚡1🔥1
Forwarded from tech-afternoon (Amin Mesbahi)
📌 ربع‌بندی بدهی فنی (Technical Debt Quadrant)
دیروز یه توییتی زدم که برای توضیح بهتر منظورم (که هیچ ربطی هم به نرم‌افزار نداشت)، از توصیف بدهی فنی ناآگاهانه‌ی بی‌پروا استفاده کردم، این شد که گفتم شاید بد نباشه کمی عمیق‌تر در مورد بدهی فنی گپ بزنیم...
مارتین فولر سال‌ها پیش یک ربع‌بندی (Quadrant) برای طبقه‌بندی انواع بدهی های فنی معرفی کرد که تا امروز هم قابل تعمیم و استفاده است، برای اینکه دید بهتری نسبت به بدهی فنی‌هامون داشته باشیم. برای «احمقانه»ها توجیه نتراشیم... بابت عاقلانه‌ترها هم خودمون رو بیش از حد سرزنش نکنیم.
1. بی‌پروا و غیرآگاهانه (Reckless & Inadvertent)
بدون آگاهی و بی‌برنامه ایجاد شده.
2. بی‌پروا و آگاهانه (Reckless & Deliberate)
تیم آگاهانه و به صورت بی‌پروا برای سرعت بخشیدن به کار ایجاد کرده.
3. محتاطانه و غیرآگاهانه (Prudent & Inadvertent)
به صورت تصادفی اما با رعایت اصول اولیه ایجاد شده.
4. محتاطانه و آگاهانه (Prudent & Deliberate)
آگاهانه و با برنامه‌ریزی برای دستیابی به اهداف کوتاه‌مدت ایجاد شده.
ری‌اکشن 🤓 برای اعلام تمایل برای توضیح بیشتر و مثال و...
دیروز یه توییتی زدم که برای توضیح بهتر منظورم (که هیچ ربطی هم به نرم‌افزار نداشت)، از توصیف بدهی فنی ناآگاهانه‌ی بی‌پروا استفاده کردم، این شد که گفتم شاید بد نباشه کمی عمیق‌تر در مورد بدهی فنی گپ بزنیم...
مارتین فولر سال‌ها پیش یک ربع‌بندی (Quadrant) برای طبقه‌بندی انواع بدهی های فنی معرفی کرد که تا امروز هم قابل تعمیم و استفاده است، برای اینکه دید بهتری نسبت به بدهی فنی‌هامون داشته باشیم. برای «احمقانه»ها توجیه نتراشیم... بابت عاقلانه‌ترها هم خودمون رو بیش از حد سرزنش نکنیم.
1. بی‌پروا و غیرآگاهانه (Reckless & Inadvertent)
بدون آگاهی و بی‌برنامه ایجاد شده.
2. بی‌پروا و آگاهانه (Reckless & Deliberate)
تیم آگاهانه و به صورت بی‌پروا برای سرعت بخشیدن به کار ایجاد کرده.
3. محتاطانه و غیرآگاهانه (Prudent & Inadvertent)
به صورت تصادفی اما با رعایت اصول اولیه ایجاد شده.
4. محتاطانه و آگاهانه (Prudent & Deliberate)
آگاهانه و با برنامه‌ریزی برای دستیابی به اهداف کوتاه‌مدت ایجاد شده.
ری‌اکشن 🤓 برای اعلام تمایل برای توضیح بیشتر و مثال و...
🤓23👍1
🚀 من همیشه اصول پایه ای رو دوست دارم، برای همین خیلی وقت ها برای خودم مرورشون می کنم.
امروز داشتم OOP رو مطالعه می کردم، برای همین گفتم با شما هم Share کنم :
در برنامه‌نویسی شیءگرا (Object-Oriented Programming – OOP)، مفاهیمی معرفی می‌شند که هدف‌شان ساده‌سازی طراحی، توسعه و نگهداشت کد هست که عبارت اند از :
Encapsulation: پنهان کردن جزئیات و ارائه واسط عمومی
Abstraction: ساده‌سازی و انتزاع‌سازی مفاهیم بدون نمایش جزئیات غیرضروری
Inheritance: استفاده‌ی مجدد از کد و ایجاد سلسله‌مراتب بین کلاس‌ها
Polymorphism: رفتارهای مختلف برای یک متد واحد بسته به کلاس یا نوع شیء
@learning_with_m
که می دونیم که Polymorphism دو نوع داره که شامل :
Overriding: اگر کلاس فرزند متدی را که در کلاس والد تعریف شده بازتعریف کند، بسته به نوع شیء در زمان اجرا متد مناسب صدا زده می‌شود. (Runtime polymorphism)
Overloading: در یک کلاس چند متد با نام یکسان ولی پارامترهای متفاوت تعریف می‌کنیم، و بسته به تعداد و نوع پارامترها، متد مناسب در زمان کامپایل انتخاب می‌شود. (Compile-time polymorphism)
امروز داشتم OOP رو مطالعه می کردم، برای همین گفتم با شما هم Share کنم :
در برنامه‌نویسی شیءگرا (Object-Oriented Programming – OOP)، مفاهیمی معرفی می‌شند که هدف‌شان ساده‌سازی طراحی، توسعه و نگهداشت کد هست که عبارت اند از :
Encapsulation: پنهان کردن جزئیات و ارائه واسط عمومی
Abstraction: ساده‌سازی و انتزاع‌سازی مفاهیم بدون نمایش جزئیات غیرضروری
Inheritance: استفاده‌ی مجدد از کد و ایجاد سلسله‌مراتب بین کلاس‌ها
Polymorphism: رفتارهای مختلف برای یک متد واحد بسته به کلاس یا نوع شیء
@learning_with_m
که می دونیم که Polymorphism دو نوع داره که شامل :
Overriding: اگر کلاس فرزند متدی را که در کلاس والد تعریف شده بازتعریف کند، بسته به نوع شیء در زمان اجرا متد مناسب صدا زده می‌شود. (Runtime polymorphism)
Overloading: در یک کلاس چند متد با نام یکسان ولی پارامترهای متفاوت تعریف می‌کنیم، و بسته به تعداد و نوع پارامترها، متد مناسب در زمان کامپایل انتخاب می‌شود. (Compile-time polymorphism)
❓ حالا شما به من بگید، در S.O.L.I.D، حرف L که برای Liskov Substitution Principle (LSP) هست، کدوم یکی از مفاهیم بالا رو هدف قرار داده ؟ اصلا چه ربطی بین LSP و مفاهیم بالا هست ؟
👍7❤6🤔1
در مورد OOP وقتی میگی، جای اصول مصاحبه ای عمو باب همیشه خالی میشه، یه طوری شده که انگار OOP بدونی خیلی مهم نیست، باید S.O.L.I.D رو بدونی تا درست بگی !
منم میخوام از آب گل آلود ماهی بگیرم براتون، بیایم بریم ببینیم این 5 تا حرف به چه معنی هستند :
S (Single Responsibility): هر کلاس فقط یک کار و یک دلیل برای تغییر.
O (Open/Closed): کلاس‌ها برای توسعه باز و برای تغییر بسته.
L (Liskov Substitution): زیرکلاس‌ها قابل جایگزینی با والد خود بدون ایجاد ناسازگاری.
I (Interface Segregation): Interfaceهای کوچک و متمرکز به جای Interfaceهای بزرگ و همه‌کاره.
D (Dependency Inversion): وابستگی به سمت انتزاعات باشد، نه جزئیات.
هر کدومشون بر اساس یک Pain متولد شدن و دونستن اون Pain هاست که کمک می کنه این مفاهیم رو بهتر درک بکنیم.
مهمترین Pain ای که داریم و بین همشون یه جورایی مشترکه، جلوگیری از ساختن BBOM در طول زمان هست. این یعنی آقا اگر یکیش رو نصفه نیمه انجام بدی شاید الان مشکل ایجاد نشه، ولی در آینده احتمالا به سمت BBOM بری. قطعی ؟ نه شااااید. بستگی به خیلی چیزا داره، مثلا آیا کدت تغییراتش زیاده یا نه، سطح Coupling بالاست یا نه و ... .
@learning_with_m
حالا Pain های هر کدوم چی هست ؟
❓ حالا شما به من بگید، در SRP مفهوم Responsible چیه و تا چه حد میشه Responsible بود ؟
منم میخوام از آب گل آلود ماهی بگیرم براتون، بیایم بریم ببینیم این 5 تا حرف به چه معنی هستند :
S (Single Responsibility): هر کلاس فقط یک کار و یک دلیل برای تغییر.
O (Open/Closed): کلاس‌ها برای توسعه باز و برای تغییر بسته.
L (Liskov Substitution): زیرکلاس‌ها قابل جایگزینی با والد خود بدون ایجاد ناسازگاری.
I (Interface Segregation): Interfaceهای کوچک و متمرکز به جای Interfaceهای بزرگ و همه‌کاره.
D (Dependency Inversion): وابستگی به سمت انتزاعات باشد، نه جزئیات.
هر کدومشون بر اساس یک Pain متولد شدن و دونستن اون Pain هاست که کمک می کنه این مفاهیم رو بهتر درک بکنیم.
مهمترین Pain ای که داریم و بین همشون یه جورایی مشترکه، جلوگیری از ساختن BBOM در طول زمان هست. این یعنی آقا اگر یکیش رو نصفه نیمه انجام بدی شاید الان مشکل ایجاد نشه، ولی در آینده احتمالا به سمت BBOM بری. قطعی ؟ نه شااااید. بستگی به خیلی چیزا داره، مثلا آیا کدت تغییراتش زیاده یا نه، سطح Coupling بالاست یا نه و ... .
@learning_with_m
حالا Pain های هر کدوم چی هست ؟
S (Single Responsibility): چون اگر این مورد رو رعایت نکنید، کلاس ها و متد هایی خواهید داشت که با کوچکترین تغییر در اونها،ریفکتور به یک کار عذاب آور تبدیل میشه، چون Hcase های زیادی رو مجبورید در نظر بگیرید.
O (Open/Closed): چون اگر این مورد رو رعایت نکنید، ریسک خراب شدن و درست کار نکردن کل سیستم با کوچکترین تغییری برای بهبود و یا فیچر جدیدی وجود خواهد داشت.
L (Liskov Substitution): چون اگر این مورد رو رعایت نکنید، همیشه مجبورید که خالت های خاص رو توی کد های بالا دستی چک کنید، اگر کلاسم فلان نوعه، فلان کن، اگر بهمانه بهمات کن. یک عالمه هم بخش های پیاده سازی نشده خواهید داشت.
I (Interface Segregation): چون اگر این مورد رو رعایت نکنید، یعنی احتمالا شما LSP و SRP رو هم درست انجام ندادید. احتمالا دارید God Object می سازید.
D (Dependency Inversion): چون اگر این مورد رو رعایت نکنید به قابلیت هایی مثل Unit Testing دسترسی نخواهید داشت به راحتی، همچنین OSP رو هم احتمالا درست انجام ندادید. از همه بدتر، احتمالا هم Code To Interface نیستید و هم Coupling بالایی هم ایجاد کردید.
❓ حالا شما به من بگید، در SRP مفهوم Responsible چیه و تا چه حد میشه Responsible بود ؟
🔥9❤3👍1🤔1👌1
از OOP بگی، از S.O.L.I.D بگی و از Coupling & Cohesion نگی، اشتباه کردی.
هرچه قدر استفاده از S.O.L.I.D توی مصاحبه ها زیاده و فهمش کمتر، Coupling & Cohesion مفهومیه که نه تنها بهش پرداخته نمیشه، بلکه فهمش هم مهمتره به نظرم.
حالا این دو تا بچه چی هستند ؟
Coupling
این مهفوم بسیار جذاب حرفش در مورد اتصال های بی مورد و یا نادرسته، وقتی این مفهوم رو نشناسی کلا نمی بینیش، ولی وقتی باهاش آشنا میشی همه جا میاد جلو چشمت(یه مدت مدیدی من به کاپلینگ می گفتم کوپلینگ!)
حالا حرفش چیه؟ میگه آقا انقدر همه چیز رو به هم اتصال نده، اتصال دادن خوبه ها ولی تهش بدبختیه، هرچی بیشتر وصل باشی مثل ریشه تو خاک یک درخته، بعدا نمی تونی درش بیاری، نکنه نشه، انرژی زیادی می بره.
Coupling انواع مختلفی داره که شامل موارد زیر هست، فقط حواسمون باشه که این موارد از بدتری به بهترین هستند :
Coupling یه مفهوم خیلی جالبه که بعدا بشتر در مورد انواعش صحبت می کنم و مواردی مثل Afferent و Efferent رو باز می کنم. قول می دم 😉
خب بریم سر وقت بچه بعدی، Cohesion.
حالا این مفهوم چی میگیه؟ میگه دوست من حالا که LSP رو رعایت کردی، بهتر نیست چیزایی که به هم ربط دارن رو کنار هم بزاری ؟ چرا اینو میگه ؟ چون SRP رو بهتر بتونی رعایت کنی. میبینید چطور مفاهیم بهم می تونن پیوند بخورن؟ جالب نیست؟ همینه من مفاهیم پایه ای رو دوست دارم، همشون هوای همیدگه رو دارن.
هرچه قدر استفاده از S.O.L.I.D توی مصاحبه ها زیاده و فهمش کمتر، Coupling & Cohesion مفهومیه که نه تنها بهش پرداخته نمیشه، بلکه فهمش هم مهمتره به نظرم.
حالا این دو تا بچه چی هستند ؟
Coupling
این مهفوم بسیار جذاب حرفش در مورد اتصال های بی مورد و یا نادرسته، وقتی این مفهوم رو نشناسی کلا نمی بینیش، ولی وقتی باهاش آشنا میشی همه جا میاد جلو چشمت(یه مدت مدیدی من به کاپلینگ می گفتم کوپلینگ!)
حالا حرفش چیه؟ میگه آقا انقدر همه چیز رو به هم اتصال نده، اتصال دادن خوبه ها ولی تهش بدبختیه، هرچی بیشتر وصل باشی مثل ریشه تو خاک یک درخته، بعدا نمی تونی درش بیاری، نکنه نشه، انرژی زیادی می بره.
Coupling انواع مختلفی داره که شامل موارد زیر هست، فقط حواسمون باشه که این موارد از بدتری به بهترین هستند :
Content Coupling: ماژولی مستقیماً در کد داخلی ماژول دیگر تغییر ایجاد می‌کند.
Common Coupling: ماژول‌ها متغیرهای سراسری مشترک دارند.
External Coupling: ماژول‌ها به منبع خارجی یکسانی وابسته‌اند (مثل فایل یا دستگاه مشترک).
Control Coupling: یک ماژول رفتار ماژول دیگر را از طریق پارامترهای کنترلی تعیین می‌کند.
Stamp Coupling: ماژول‌ها ساختار داده پیچیده‌ای را به اشتراک می‌گذارند، اما همیشه به کل آن نیاز ندارند.
Data Coupling: ماژول‌ها تنها داده‌های مورد نیاز را به شکل پارامترهای ساده تبادل می‌کنند (بهترین حالت).
Coupling یه مفهوم خیلی جالبه که بعدا بشتر در مورد انواعش صحبت می کنم و مواردی مثل Afferent و Efferent رو باز می کنم. قول می دم 😉
خب بریم سر وقت بچه بعدی، Cohesion.
حالا این مفهوم چی میگیه؟ میگه دوست من حالا که LSP رو رعایت کردی، بهتر نیست چیزایی که به هم ربط دارن رو کنار هم بزاری ؟ چرا اینو میگه ؟ چون SRP رو بهتر بتونی رعایت کنی. میبینید چطور مفاهیم بهم می تونن پیوند بخورن؟ جالب نیست؟ همینه من مفاهیم پایه ای رو دوست دارم، همشون هوای همیدگه رو دارن.
Coincidental Cohesion: وظایف نامرتبط به‌صورت تصادفی در یک ماژول جمع شده‌اند.❓حالا شما به من بگید، Functional Cohesion مثل کدوم مفهومی می مونه که تا الان یاد گرفتیم ؟
Logical Cohesion: وظایف مشابه از لحاظ نوع (نه هدف) در یک ماژول قرار دارند و با کلیدهای کنترلی انتخاب می‌شوند.
Temporal Cohesion: وظایف مرتبط با یک نقطه زمانی مشترک (مثلاً راه‌اندازی برنامه) در یک ماژول هستند.
Procedural Cohesion: وظایف در یک ترتیب مشخص برای رسیدن به یک هدف کلی اجرا می‌شوند، ولی داده مشترک ندارند.
Communicational Cohesion: وظایف حول یک داده یا داده‌های مرتبط مشترک عمل می‌کنند.
Sequential Cohesion: خروجی یک وظیفه ورودی وظیفه بعدی است، تشکیل زنجیره‌ای معنادار.
Functional Cohesion: تمام وظایف ماژول برای انجام یک کار واحد و مشخص به صورت متمرکز طراحی شده‌اند (بهترین حالت)
👍2🔥2👏1🤔1