Forwarded from Webinarfarsi | Soheib Kiani | وبینار فارسی
Forwarded from جنگولرن
اگر می خواید AI جاتون رو نگیره سعی کنید Requirement Engineering رو یاد بگیرید و بفهمید.
یک کتاب خفن در موردش
Software Requirements Third Edition - Joy Beatty
متن بالا بخشی از یه پست کانال thisisnabi بود 😁
توضیحات chatgpt:
مهندسی نیازمندیها یا Requirement Engineering بخشی از فرآیند توسعه نرمافزار است که به شناسایی، تحلیل، مستندسازی و مدیریت نیازمندیهای سیستم میپردازد. هدف از این علم، اطمینان از این است که نرمافزار در نهایت به نیازها و خواستههای کاربران و ذینفعان پاسخ میدهد.
فرآیند مهندسی نیازمندیها معمولاً شامل مراحل زیر است:
1. شناسایی نیازمندیها**: در این مرحله، نیازمندیهای واقعی سیستم شناسایی میشوند. این کار معمولاً با جمعآوری اطلاعات از ذینفعان، مصاحبهها، کارگاهها و بررسی مستندات موجود انجام میشود.
2. تحلیل نیازمندیها**: نیازمندیها تحلیل و بررسی میشوند تا مشخص شود که آیا آنها قابل فهم، کامل، قابل اندازهگیری و قابل تحقق هستند یا خیر.
3. مستندسازی نیازمندیها**: نیازمندیها باید به شکل مستند و مطابق با استانداردهای مشخصی ثبت شوند تا در آینده بتوان به آنها مراجعه کرد.
4. تایید نیازمندیها**: پس از مستندسازی، نیازمندیها باید توسط ذینفعان تأیید شوند تا از صحت و تناسب آنها اطمینان حاصل شود.
5. مدیریت نیازمندیها**: نیازمندیها باید به طور مداوم مدیریت شوند تا تغییرات و اصلاحات لازم در طول فرآیند توسعه نرمافزار اعمال شوند.
مهندسی نیازمندیها به عنوان یکی از مراحل کلیدی در توسعه نرمافزار شناخته میشود و تأثیر زیادی بر کیفیت پروژه و رضایت مشتری دارد.
یک کتاب خفن در موردش
Software Requirements Third Edition - Joy Beatty
متن بالا بخشی از یه پست کانال thisisnabi بود 😁
توضیحات chatgpt:
مهندسی نیازمندیها یا Requirement Engineering بخشی از فرآیند توسعه نرمافزار است که به شناسایی، تحلیل، مستندسازی و مدیریت نیازمندیهای سیستم میپردازد. هدف از این علم، اطمینان از این است که نرمافزار در نهایت به نیازها و خواستههای کاربران و ذینفعان پاسخ میدهد.
فرآیند مهندسی نیازمندیها معمولاً شامل مراحل زیر است:
1. شناسایی نیازمندیها**: در این مرحله، نیازمندیهای واقعی سیستم شناسایی میشوند. این کار معمولاً با جمعآوری اطلاعات از ذینفعان، مصاحبهها، کارگاهها و بررسی مستندات موجود انجام میشود.
2. تحلیل نیازمندیها**: نیازمندیها تحلیل و بررسی میشوند تا مشخص شود که آیا آنها قابل فهم، کامل، قابل اندازهگیری و قابل تحقق هستند یا خیر.
3. مستندسازی نیازمندیها**: نیازمندیها باید به شکل مستند و مطابق با استانداردهای مشخصی ثبت شوند تا در آینده بتوان به آنها مراجعه کرد.
4. تایید نیازمندیها**: پس از مستندسازی، نیازمندیها باید توسط ذینفعان تأیید شوند تا از صحت و تناسب آنها اطمینان حاصل شود.
5. مدیریت نیازمندیها**: نیازمندیها باید به طور مداوم مدیریت شوند تا تغییرات و اصلاحات لازم در طول فرآیند توسعه نرمافزار اعمال شوند.
مهندسی نیازمندیها به عنوان یکی از مراحل کلیدی در توسعه نرمافزار شناخته میشود و تأثیر زیادی بر کیفیت پروژه و رضایت مشتری دارد.
Forwarded from Linuxor ?
فکر میکنی مانیتورینگ فقط متریک CPU و رم گرفتن از سروره؟ SkyWalking میگه نه، باید بفهمی سرویس A چرا دیر جواب داد، کدوم کال ازش رد شد و چطور به سرویس C رسید. اینجاست که tracing و dependency mapش به کارت میاد.
یه ابزار لازم برای هرکسی که با معماری سرویسمحور (microservices) زیاد سرو کله میزنه، خیلی جالبه آپاچی انقدر ابزار هاش زیاده من تازه اینو دیدم :)
دانلود :
skywalking.apache.org
@Linuxor
یه ابزار لازم برای هرکسی که با معماری سرویسمحور (microservices) زیاد سرو کله میزنه، خیلی جالبه آپاچی انقدر ابزار هاش زیاده من تازه اینو دیدم :)
دانلود :
skywalking.apache.org
@Linuxor
Forwarded from Linuxor ?
ایده هاتون رو بیشتر مواقع با بقیه به اشتراک بزارید؛ ایده های پیاده نشده واقعا آنچنان ارزش ندارن؛ ولی ممکنه زود تر به این نتیجه برسید که ایده اشتباهه. یه جوری مثل Bloom Filter هستش ... شاید تضمینی برای تایید کسی بهتون نده ولی تضمین رد دقیقی ممکنه بگیرید.
بلوم فیلتر : یه چیزیه که توی دیتابیسا استفاده میکنن برای اینکه سریع بفهمن یه داده وجود نداره؛ اما اگه بگه وجود داره ممکنه اشتباه باشه.
@Linuxor
بلوم فیلتر : یه چیزیه که توی دیتابیسا استفاده میکنن برای اینکه سریع بفهمن یه داده وجود نداره؛ اما اگه بگه وجود داره ممکنه اشتباه باشه.
@Linuxor
Forwarded from Linuxor ?
بزرگترین ترس یه Developer چیه؟ اینکه کدی که با کلی زحمت نوشته، فقط روی یه پلتفرم خاص (مثلا AWS یا Azure) کار کنه و نشه راحت جابجاش کرد. Dapr با یه ایده هوشمندانه این مشکل رو حل کرده. این ابزار یه لایه انتزاعی (abstraction layer) روی سرویسهای مختلف مثل صف پیام (message queues) و دیتابیسها میکشه. یعنی تو کد خودت رو فقط برای Dapr مینویسی، و Dapr خودش با هر سرویسی که زیرش باشه (مثل RabbitMQ یا Redis) ارتباط برقرار میکنه.
این یعنی اگه امروز از سرویسهای AWS استفاده میکنی و فردا خواستی بری سراغ گوگل کلاد، لازم نیست حتی یه خط از کد اصلی اپلیکیشنت رو تغییر بدی. فقط کافیه کانفیگ Dapr رو عوض کنی. این یعنی آزادی عمل واقعی و جلوگیری از قفل شدن روی یک تکنولوژی خاص. برای تیمهایی که میخوان زیرساختشون رو در آینده راحت تغییر بدن، این ویژگی یه برگ برنده است.
مستندات و توضیحات بیشتر :
dapr.io
@Linuxor
این یعنی اگه امروز از سرویسهای AWS استفاده میکنی و فردا خواستی بری سراغ گوگل کلاد، لازم نیست حتی یه خط از کد اصلی اپلیکیشنت رو تغییر بدی. فقط کافیه کانفیگ Dapr رو عوض کنی. این یعنی آزادی عمل واقعی و جلوگیری از قفل شدن روی یک تکنولوژی خاص. برای تیمهایی که میخوان زیرساختشون رو در آینده راحت تغییر بدن، این ویژگی یه برگ برنده است.
مستندات و توضیحات بیشتر :
dapr.io
@Linuxor
یکی از قابلیتهای کمتر شناختهشده Git که میتونه زندگی کاریتون رو آسونتر کنه، 𝐠𝐢𝐭 𝐰𝐨𝐫𝐤𝐭𝐫𝐞𝐞 هست.
باهاش میتونید چندین محیط کاری جدا از هم داشته باشید، هر کدوم روی یک شاخه مستقل، ولی همه از یک ریپازیتوری.
✅ فرض کنید روی برنچ A هستید و ناگهان باید روی برنچ B کار کنید. به جای اینکه تغییرات رو stash کنید و شاخه عوض کنید، میتونید یک 𝐰𝐨𝐫𝐤𝐭𝐫𝐞𝐞 جدید بسازید:
𝐠𝐢𝐭 𝐰𝐨𝐫𝐤𝐭𝐫𝐞𝐞 𝐚𝐝𝐝 ../𝐁-𝐟𝐨𝐥𝐝𝐞𝐫 𝐁
✅ با این دستور، یک پوشه جدید به نام 𝐁-𝐟𝐨𝐥𝐝𝐞𝐫 ساخته میشه که روی برنچ B هست. الان میتونید داخل این فولدر، کد رو تغییر بدید، تست کنید و commit بزنید، بدون اینکه کاری به شاخه فعلیتون داشته باشید.
اگر اهل کار موازی روی چند فیچر یا رفع باگ هستید، این ابزار میتونه سرعتتون رو چند برابر کنه.
باهاش میتونید چندین محیط کاری جدا از هم داشته باشید، هر کدوم روی یک شاخه مستقل، ولی همه از یک ریپازیتوری.
✅ فرض کنید روی برنچ A هستید و ناگهان باید روی برنچ B کار کنید. به جای اینکه تغییرات رو stash کنید و شاخه عوض کنید، میتونید یک 𝐰𝐨𝐫𝐤𝐭𝐫𝐞𝐞 جدید بسازید:
𝐠𝐢𝐭 𝐰𝐨𝐫𝐤𝐭𝐫𝐞𝐞 𝐚𝐝𝐝 ../𝐁-𝐟𝐨𝐥𝐝𝐞𝐫 𝐁
✅ با این دستور، یک پوشه جدید به نام 𝐁-𝐟𝐨𝐥𝐝𝐞𝐫 ساخته میشه که روی برنچ B هست. الان میتونید داخل این فولدر، کد رو تغییر بدید، تست کنید و commit بزنید، بدون اینکه کاری به شاخه فعلیتون داشته باشید.
اگر اهل کار موازی روی چند فیچر یا رفع باگ هستید، این ابزار میتونه سرعتتون رو چند برابر کنه.
داکیومنت رسمی گیت درباره worktree رو میتونید از لینک زیر مطالعه کنید:منبع: لینکداین
https://git-scm.com/docs/git-worktree
از این مقاله هم میتونید برای مطالعه بیشتر و بررسی مثالها استفاده کنید:
https://mskadu.medium.com/mastering-git-worktree-a-developers-guide-to-multiple-working-directories-c30f834f79a5
Forwarded from Linuxor ?
شیش تا قانون برای نوشتن یه REST API خوب، برید توی این سایت خیلی ساده با مثال توضیح داده، اگه تازه کارید این اشتباها ممکنه بعدا کارتون رو سخت کنه، این قوانین API رو قبل پیاده سازیتون بخونید
restfulapi.net
@Linuxor
restfulapi.net
@Linuxor
Forwarded from Linuxor ?
اگه یه API ساختین برای امنیتش بیاید این چک لیستو برسی کنید نکات خوبی گفته :
github.com/shieldfy/API-Security-Checklist
@Linuxor
github.com/shieldfy/API-Security-Checklist
@Linuxor
Forwarded from TechTube 𝕏 تک توب
تا حالا فکر کردین فقط یک ثانیه چقدر میتونه مهم باشه؟
شاید برای زندگی روزمره ما یک ثانیه هیچ فرقی ایجاد نکنه، اما توی دنیای فناوری، همین یک ثانیه میتونه میلیاردها تراکنش بانکی، مسیریابی GPS، یا حتی کل عملکرد اینترنت رو تحتتأثیر بذاره. اینجاست که «ثانیه کبیسه» یا Leap Second وارد داستان میشه؛ ثانیهای که هر چند سال یکبار به ساعت جهانی اضافه یا از اون کم میشه تا زمین و ساعت اتمی دوباره همگام بشن.
ثانیه کبیسه زمانی اتفاق میفته که اختلاف بین ساعت اتمی و زمان واقعی چرخش زمین به حدود ۰٫۹ ثانیه برسه. علت این اختلاف، تغییرات جزئی اما مداوم در سرعت چرخش زمینه. عواملی مثل جزر و مد اقیانوسها، حرکت هسته زمین، تغییرات اقلیمی و حتی زلزلهها باعث میشن زمین کمی کندتر یا سریعتر بچرخه. این تغییرات هرچند خیلی ناچیزن، اما در طول سالها جمع میشن و نیاز به اصلاح پیدا میکنن.
برای انسانها، این اصلاح سادهست. ولی برای کامپیوترها و شبکهها ماجرا پیچیدهتره. در لحظه اضافه شدن لیپسکند، ساعت UTC به جای رفتن از 23:59:59 به 00:00:00، یک لحظه به 23:59:60 میره. این زمان عجیب برای خیلی از نرمافزارها تعریف نشده و باعث میشه بعضی سیستمها هنگ کنن، بعضی تراکنشها با خطا مواجه بشن و حتی برخی پایگاههای داده قفل بشن. نمونههای واقعی این مشکل در گذشته باعث خاموشی چند دقیقهای سرویسهای بزرگ شده.
اینجا بود که گوگل «Leap Smear» رو مطرح کرد؛ ایده این بود که به جای اینکه یک ثانیه ناگهانی به زمان اضافه کنه، گوگل تصمیم گرفت این تغییر رو به صورت تدریجی و نرم پخش کنه. در Leap Smear، از چند ساعت قبل، هر ثانیه کمی طولانیتر میشه. این تغییر اونقدر کوچیکه که سیستمها متوجهش نمیشن، اما تا پایان بازه زمانی، یک ثانیه کامل به ساعت اضافه شده و زمان گوگل با زمان جهانی هماهنگ میشه، بدون اینکه جهش ناگهانی رخ بده.
برای مثال، اگر قرار باشه ثانیه کبیسه نیمهشب ۳۱ دسامبر اضافه بشه، گوگل از حدود ۱۰ ساعت قبل شروع میکنه هر ثانیه رو چند میلیثانیه کش بده. این تغییرات جمع میشن و در نهایت، ساعت گوگل دقیقاً با UTC یکی میشه. در سال ۲۰۱۶ که آخرین لیپسکند اضافه شد، سرویسهای زیادی در دنیا دچار مشکل شدن، اما جیمیل، یوتیوب و موتور جستجوی گوگل بدون کوچکترین اختلال کار کردن، چون Leap Smear از قبل فعال شده بود.
این روش باعث میشه هیچ لحظه «23:59:60» در سیستمهای گوگل وجود نداشته باشه، بنابراین نیازی به تغییر نرمافزارها یا پایگاههای داده نیست. همچنین در سیستمهای حساس به زمان مثل سرورهای تراکنشهای مالی یا دیتابیسهای توزیعشده، همه چیز بدون وقفه ادامه پیدا میکنه.
موفقیت Leap Smear باعث شد غولهای فناوری دیگه هم به سمت روشهای مشابه برن. حالا آمازون، فیسبوک و حتی بعضی مراکز داده مستقل هم به جای تغییر ناگهانی، زمان رو بهصورت تدریجی اصلاح میکنن.
طبق آخرین اعلام IERS، احتمال بعدی برای اضافه شدن ثانیه کبیسه در تاریخ ۳۰ ژوئن ۲۰۲۶ مطرح شده، اما با توجه به سرعت بالاتر چرخش زمین در سالهای اخیر، این اتفاق بعیده که رخ بده. همچنین IERS اعلام کرده در پایان دسامبر ۲۰۲۵ هیچ ثانیه کبیسهای اضافه نخواهد شد. با این حال، اگر در آینده این اصلاح زمانی لازم باشه، تاریخ دقیقش توسط همین مرکز اعلام میشه.
✏️ مطلبی از ممد
🔎 Leap Smear - Google Public NTP
📍 @TechTube
شاید برای زندگی روزمره ما یک ثانیه هیچ فرقی ایجاد نکنه، اما توی دنیای فناوری، همین یک ثانیه میتونه میلیاردها تراکنش بانکی، مسیریابی GPS، یا حتی کل عملکرد اینترنت رو تحتتأثیر بذاره. اینجاست که «ثانیه کبیسه» یا Leap Second وارد داستان میشه؛ ثانیهای که هر چند سال یکبار به ساعت جهانی اضافه یا از اون کم میشه تا زمین و ساعت اتمی دوباره همگام بشن.
ثانیه کبیسه زمانی اتفاق میفته که اختلاف بین ساعت اتمی و زمان واقعی چرخش زمین به حدود ۰٫۹ ثانیه برسه. علت این اختلاف، تغییرات جزئی اما مداوم در سرعت چرخش زمینه. عواملی مثل جزر و مد اقیانوسها، حرکت هسته زمین، تغییرات اقلیمی و حتی زلزلهها باعث میشن زمین کمی کندتر یا سریعتر بچرخه. این تغییرات هرچند خیلی ناچیزن، اما در طول سالها جمع میشن و نیاز به اصلاح پیدا میکنن.
برای انسانها، این اصلاح سادهست. ولی برای کامپیوترها و شبکهها ماجرا پیچیدهتره. در لحظه اضافه شدن لیپسکند، ساعت UTC به جای رفتن از 23:59:59 به 00:00:00، یک لحظه به 23:59:60 میره. این زمان عجیب برای خیلی از نرمافزارها تعریف نشده و باعث میشه بعضی سیستمها هنگ کنن، بعضی تراکنشها با خطا مواجه بشن و حتی برخی پایگاههای داده قفل بشن. نمونههای واقعی این مشکل در گذشته باعث خاموشی چند دقیقهای سرویسهای بزرگ شده.
اینجا بود که گوگل «Leap Smear» رو مطرح کرد؛ ایده این بود که به جای اینکه یک ثانیه ناگهانی به زمان اضافه کنه، گوگل تصمیم گرفت این تغییر رو به صورت تدریجی و نرم پخش کنه. در Leap Smear، از چند ساعت قبل، هر ثانیه کمی طولانیتر میشه. این تغییر اونقدر کوچیکه که سیستمها متوجهش نمیشن، اما تا پایان بازه زمانی، یک ثانیه کامل به ساعت اضافه شده و زمان گوگل با زمان جهانی هماهنگ میشه، بدون اینکه جهش ناگهانی رخ بده.
برای مثال، اگر قرار باشه ثانیه کبیسه نیمهشب ۳۱ دسامبر اضافه بشه، گوگل از حدود ۱۰ ساعت قبل شروع میکنه هر ثانیه رو چند میلیثانیه کش بده. این تغییرات جمع میشن و در نهایت، ساعت گوگل دقیقاً با UTC یکی میشه. در سال ۲۰۱۶ که آخرین لیپسکند اضافه شد، سرویسهای زیادی در دنیا دچار مشکل شدن، اما جیمیل، یوتیوب و موتور جستجوی گوگل بدون کوچکترین اختلال کار کردن، چون Leap Smear از قبل فعال شده بود.
این روش باعث میشه هیچ لحظه «23:59:60» در سیستمهای گوگل وجود نداشته باشه، بنابراین نیازی به تغییر نرمافزارها یا پایگاههای داده نیست. همچنین در سیستمهای حساس به زمان مثل سرورهای تراکنشهای مالی یا دیتابیسهای توزیعشده، همه چیز بدون وقفه ادامه پیدا میکنه.
موفقیت Leap Smear باعث شد غولهای فناوری دیگه هم به سمت روشهای مشابه برن. حالا آمازون، فیسبوک و حتی بعضی مراکز داده مستقل هم به جای تغییر ناگهانی، زمان رو بهصورت تدریجی اصلاح میکنن.
طبق آخرین اعلام IERS، احتمال بعدی برای اضافه شدن ثانیه کبیسه در تاریخ ۳۰ ژوئن ۲۰۲۶ مطرح شده، اما با توجه به سرعت بالاتر چرخش زمین در سالهای اخیر، این اتفاق بعیده که رخ بده. همچنین IERS اعلام کرده در پایان دسامبر ۲۰۲۵ هیچ ثانیه کبیسهای اضافه نخواهد شد. با این حال، اگر در آینده این اصلاح زمانی لازم باشه، تاریخ دقیقش توسط همین مرکز اعلام میشه.
🔎 Leap Smear - Google Public NTP
📍 @TechTube
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Linuxor ?
گزینه DevTools مرورگر ها برای توسعه فرانت کار راه بندازه ولی فرانت کارا از این مرورگر اختصاصی استفاده میکنن برای اینکه همه تغییرات رو توی دستگاه های مختلف در لحظه رصد کنن
responsively.app
@Linuxor
responsively.app
@Linuxor
Forwarded from Webinarfarsi | Soheib Kiani | وبینار فارسی
یکی از محل کارش ناراضیه و میاد لینکدین همش غر میزنه.
این شخص نه جرات داره بره نارضایتیاش رو به گوش مدیراش برسونه،
و نه جرات داره استعفا بده و کارش رو عوض کنه.
من خودم هربار که فشار و مشکلی با محیط کارم داشتم یه کاغذ برداشتم و بولت پوینت انتظاراتم رو نوشتم و رفتم جلسه با مدیرعامل، بعد از جلسه اومدم بولت پوینت رو تیک یا ضربدر زدم که کدوما حل میشه و کدوما همینجور خواهد ماند. بعد بنا به اون یا استعفام رو نوشتم یا نشستم یه گوشه مثل آدم به کارم ادامه دادم.
خواستتون رو مشخص کنید، نشد، عرضه داری میری یه جای بهتر، نه همینیه که هست.
نمیشه در حد لیگ محلات بازی کنی و انتظار فوتبال اسپانیا داشته باشی که عزیز! نمیشه در حد لیگ اسپانیا بازی کنی و بمونی تو لیگ محلات غر بزنی که عزیز.
~ Andisheh Abbasian
این شخص نه جرات داره بره نارضایتیاش رو به گوش مدیراش برسونه،
و نه جرات داره استعفا بده و کارش رو عوض کنه.
من خودم هربار که فشار و مشکلی با محیط کارم داشتم یه کاغذ برداشتم و بولت پوینت انتظاراتم رو نوشتم و رفتم جلسه با مدیرعامل، بعد از جلسه اومدم بولت پوینت رو تیک یا ضربدر زدم که کدوما حل میشه و کدوما همینجور خواهد ماند. بعد بنا به اون یا استعفام رو نوشتم یا نشستم یه گوشه مثل آدم به کارم ادامه دادم.
خواستتون رو مشخص کنید، نشد، عرضه داری میری یه جای بهتر، نه همینیه که هست.
نمیشه در حد لیگ محلات بازی کنی و انتظار فوتبال اسپانیا داشته باشی که عزیز! نمیشه در حد لیگ اسپانیا بازی کنی و بمونی تو لیگ محلات غر بزنی که عزیز.
~ Andisheh Abbasian
Forwarded from Linuxor ?
Forwarded from Linuxor ?
اگه تازه وارد یه تیم جدید شدی و همه دارن دربارهی best practices کُد ریویو حرف میزنن ولی هیچکس معلوم نمیکنه دقیقاً چی درسته و چی نه، گوگل سالها تجربهی خودش توی مدیریت ریویوها رو خلاصه کرده و گذاشته اینجا. از نکات ریز مثل نامگذاری متغیر تا نحوهی فیدبک دادن مودبانه.
google.github.io/eng-practices
@Linuxor
google.github.io/eng-practices
@Linuxor