Developer Advocate

الوعده وفا 🎉 https://www.youtube.com/watch?v=BGlBjeKhcNU5 @DeveloperAdvocate 🥑

Software Mistakes and Tradeoffs: How to make good programming decisions 1st Edition اشتباهات و توازن‌های مهندسی نرم‌افزار کتاب "اشتباهات و توازن‌های مهندسی نرم‌افزار" به شما کمک می‌کند تصمیمات طراحی سیستم خود را بهینه کرده و از اشتباهات رایج و تصمیمات عمدی متخصصان در این حوزه درس بگیرید. ### آنچه در این کتاب خواهید آموخت: - چگونه درباره سیستم‌های خود به طور شهودی و منطقی تصمیم‌گیری کنید. - پیامدها را درک کرده و توازن میان نیازهای متناقض را مدیریت کنید. - بهترین کتابخانه‌ها را برای حل مشکلات خود انتخاب کنید. - وابستگی‌های سرویس خود را به‌دقت تحلیل کنید. - معماری توزیع‌شده را با توجه به تأثیر معنای تحویل (Delivery Semantics) طراحی کنید. - تست‌های عملکردی طراحی و اجرا کنید تا نقاط بحرانی (Hot Paths) کد خود را شناسایی و بهینه‌سازی کنید. - مدل داده‌ای مناسب برای مدیریت زمان و تاریخ انتخاب کنید تا از اشتباهات رایج جلوگیری شود. - در مورد سازگاری و نسخه‌بندی فکر کنید تا مشکلات غیرمنتظره برای کاربران API ایجاد نشود. - بین گره‌های محکم و سست (Tight/Loose Coupling) توازن ایجاد کنید تا کار تیمی تسهیل شود. - نیازها را به وضوح تعریف کنید تا به آسانی پیاده‌سازی و تست شوند. - APIهای خود را برای تجربه کاربری بهتر بهینه کنید. ### درباره تکنولوژی: هر مرحله از یک پروژه نرم‌افزاری شامل توازن میان عوامل مختلفی مثل سرعت، امنیت، هزینه، زمان تحویل، و ویژگی‌ها است. تصمیمات معقولی که در زمان طراحی گرفته می‌شوند، ممکن است در تولید مشکلاتی به وجود آورند. بینش‌های تخصصی و تجربیات واقعی در این کتاب به شما کمک می‌کنند تا از اشتباهات رایج دوری کنید و تصمیمات بهتری بگیرید. ### درباره کتاب: کتاب "اشتباهات و توازن‌های مهندسی نرم‌افزار" با ارائه مثال‌هایی واقعی از تصمیمات اشتباه و نحوه اجتناب از آن‌ها، شما را با رویکردهای سیستماتیک در تصمیم‌گیری آشنا می‌کند. نویسندگان کتاب، تومَش لِک و جان اسکیت**، با دهه‌ها تجربه در مهندسی نرم‌افزار، درس‌هایی ارزشمند از اشتباهات و راهکارهای خود به اشتراک گذاشته‌اند. ### نکات کلیدی: - چگونگی تحلیل سیستماتیک نرم‌افزار - نحوه انتخاب ابزارها، کتابخانه‌ها و فریم‌ورک‌ها - تأثیر گره‌های محکم و سست بر هماهنگی تیم‌ها - نیازهایی که دقیق، آسان برای پیاده‌سازی و تست هستند ### برای چه کسانی؟ این کتاب برای توسعه‌دهندگان و معماران سطح میانی و ارشد مناسب است که درباره طراحی و پیاده‌سازی نرم‌افزار تصمیم‌گیری می‌کنند. ### درباره نویسندگان: - **تومَش لِک: متخصص معماری سرویس‌ها و زبان‌های JVM - جان اسکیت: مهندس گوگل، نویسنده کتاب C# in Depth و یکی از برترین مشارکت‌کنندگان در Stack Overflow ### فهرست مطالب: 1. مقدمه 2. تکرار کد همیشه بد نیست: تکرار کد در مقابل انعطاف‌پذیری 3. استثناها در مقابل الگوهای دیگر برای مدیریت خطا 4. توازن میان انعطاف‌پذیری و پیچیدگی 5. بهینه‌سازی زودهنگام در مقابل بهینه‌سازی مسیرهای بحرانی 6. سادگی در مقابل هزینه نگهداری API 7. کار با داده‌های تاریخ و زمان 8. استفاده بهینه از داده‌های محلی و حافظه ماشین‌ها 9. کتابخانه‌های شخص ثالث: کتابخانه‌هایی که استفاده می‌کنید بخشی از کد شما می‌شوند 10. انسجام و اتمیک بودن در سیستم‌های توزیع‌شده 11. معنای تحویل (Delivery Semantics) در سیستم‌های توزیع‌شده 12. مدیریت نسخه‌بندی و سازگاری 13. به‌روز ماندن با روندها در مقابل هزینه نگهداری کد @DeveloperAdvocate 🥑

🎆 ویدئوی بعدی هم Excepion Handling هست کامل باهمدیگه روش های مختلفش رو بررسی میکنیم . بعدش میریم سراغ Service Bus MassTransit با RabbitMQ چون بیشترین رای رو اورد .⚡ https://t.me/DeveloperAdvocate/1750

"آموزش Uptime Kuma آماده شد! این ویدیو همه چیز رو درباره مانیتورینگ سرویس‌ها از صفر تا صد بهتون یاد می‌ده. از نصب تا تنظیم هشدارها و مدیریت داشبوردها. فردا تو یوتیوب منتشر می‌کنم، منتظر باشید!" @DeveloperAdvocate 🥑

🔥

DuckDB: Up and Running: Fast Data Analytics and Reporting 1st Edition DuckDB، یک پایگاه داده متن‌باز و درون‌پردازشی که برای بارهای کاری OLAP طراحی شده است، مزایای کلیدی نسبت به راهکارهای معمول OLAP ارائه می‌دهد: این پایگاه داده به‌صورت تعبیه‌شده و بهینه برای تحلیل‌های داده عمل می‌کند. همچنین، به‌خوبی با Python ادغام می‌شود و با SQL سازگار است، که این امکان را فراهم می‌کند تا عملکرد و انعطاف SQL را مستقیماً در محیط Python خود داشته باشید. این راهنمای مفید به شما نشان می‌دهد که چگونه با این ابزار قدرتمند و چندمنظوره کار خود را آغاز کنید. وی-منگ لی**، نویسنده این کتاب، توسعه‌دهندگان و متخصصان داده را با ویژگی‌ها و عملکردهای اصلی DuckDB، بهترین شیوه‌ها و مثال‌های عملی آشنا می‌کند که می‌توانید از DuckDB برای انجام وظایف مختلف تحلیلی استفاده کنید. همچنین، موضوعات خاصی از جمله وارد کردن داده به DuckDB، کار با جداول، انجام تحلیل داده اکتشافی، بصری‌سازی داده‌ها، تحلیل‌های مکانی و استفاده از DuckDB با فایل‌های JSON، **Polars و JupySQL را بررسی می‌کنید. - هدف DuckDB و عملکردهای اصلی آن را درک کنید - وظایف تحلیلی داده را با استفاده از DuckDB انجام دهید - DuckDB را با pandas**، **Polars و JupySQL ادغام کنید - داده‌های خود را با DuckDB پرس‌وجو کنید - تحلیل‌های مکانی را با استفاده از افزونه مکانی DuckDB انجام دهید - با انواع متنوع داده‌ها از جمله Parquet**، **CSV و JSON کار کنید @DeveloperAdvocate 🥑

این کتاب توی آمازون Pre-order هست. 😉

Designing Distributed Systems: Patterns and Paradigms for Scalable, Reliable Systems Using Kubernetes 2nd Edition هر سیستم توزیع‌شده‌ای تلاش می‌کند تا قابل‌اعتماد، کارآمد و باکیفیت باشد، اما ساخت چنین سیستمی کار دشواری است. ایجاد مجموعه‌ای از الگوهای طراحی به توسعه‌دهندگان نرم‌افزار و معماران سیستم این امکان را می‌دهد که زبان مشترکی برای توصیف سیستم‌های خود داشته باشند و از الگوها و تجربیات توسعه‌یافته توسط دیگران بهره بگیرند. رواج کانتینرها و کوبرنتیز راه را برای استفاده از الگوهای اصلی سیستم‌های توزیع‌شده و اجزای قابل‌استفاده مجدد کانتینری هموار کرده است. این راهنمای عملی مجموعه‌ای از الگوهای تکرارپذیر و عمومی را ارائه می‌دهد تا شما را در طراحی سیستم‌هایی که با استفاده از این الگوها و روش‌های رایج توسعه داده شده‌اند، راهنمایی کند. این الگوهای رایج، حتی اگر قبلاً هرگز یک سیستم توزیع‌شده نساخته باشید، ساخت سیستم‌های شما را بسیار ساده‌تر و کارآمدتر می‌کنند. برندن برنز**، نویسنده این کتاب، نشان می‌دهد که چگونه می‌توان الگوهای طراحی نرم‌افزار موجود را برای طراحی و ساخت برنامه‌های توزیع‌شده قابل‌اعتماد تطبیق داد. مهندسان سیستم و توسعه‌دهندگان برنامه‌ها یاد خواهند گرفت که چگونه این الگوهای تثبیت‌شده، زبانی مشترک و چارچوبی برای افزایش چشمگیر کیفیت سیستم‌ها ارائه می‌دهند. این ویرایش کاملاً به‌روز شده شامل فصل‌های جدیدی درباره استنتاج هوش مصنوعی، آموزش هوش مصنوعی و ساخت سیستم‌های مقاوم برای دنیای واقعی است. - درک کنید که چگونه الگوها و اجزای قابل‌استفاده مجدد، توسعه سریع سیستم‌های توزیع‌شده قابل‌اعتماد را امکان‌پذیر می‌کنند - از الگوهای **سایدکار**، **آداپتور و سفیر برای تقسیم برنامه خود به گروهی از کانتینرها در یک ماشین استفاده کنید - الگوهای توزیع‌شده با گره‌های مستقل را برای تکرار، مقیاس‌پذیری و ارتباط بین اجزا بررسی کنید - الگوهای سیستم توزیع‌شده را برای پردازش داده‌های دسته‌ای بزرگ، شامل صف‌های کاری، پردازش مبتنی بر رویداد و جریان‌های کاری هماهنگ، یاد بگیرید @DeveloperAdvocate 🥑

Good Code, Bad Code: Think like a software engineer کتاب Good Code, Bad Code نوشته تام لانگ، یک منبع ارزشمند برای یادگیری تکنیک‌های عملی در نوشتن کدهای باکیفیت، قابل فهم و قابل اعتماد است. این کتاب به شما کمک می‌کند کدی بنویسید که به راحتی توسط اعضای تیم نگهداری و توسعه یابد. در ادامه، نکات کلیدی و موضوعات مهم این کتاب آورده شده است: نکات کلیدی تفکر مانند یک مهندس نرم‌افزار: کتاب تأکید دارد که باید ذهنیتی ایجاد کنید که نوشتن کد قابل نگهداری و خوانا بخشی از عادت‌های روزانه شما شود. این شامل پیروی از بهترین شیوه‌ها و یادگیری از تجربیات دیگران است. خوانایی، اولویت اول: کدی که مانند جملات منظم و قابل فهم نوشته شود، راحت‌تر دیباگ، گسترش و به اشتراک گذاشته می‌شود. این شامل استفاده از نام‌گذاری واضح، ساختار منطقی و کامنت‌های مختصر و مفید است. پایداری و اطمینان: کتاب به تکنیک‌هایی برای جلوگیری از مشکلات رایج مانند استثناهای کنترل نشده یا وظایف نامشخص می‌پردازد. نوشتن کدهای دفاعی که مشکلات احتمالی را پیش‌بینی می‌کنند، می‌تواند از وقوع خطاهای زنجیره‌ای جلوگیری کند. تست واحد (Unit Testing): بخشی از کتاب به اصول و روش‌های تست واحد اختصاص دارد. این تست‌ها تضمین می‌کنند که کد شما نه تنها اکنون، بلکه در آینده نیز درست کار می‌کند. ماژولار بودن کد: تام لانگ نشان می‌دهد چگونه کدی بنویسید که ماژولار، قابل استفاده مجدد و به راحتی قابل گسترش باشد. این شامل جدا کردن وظایف، رعایت سطوح انتزاع و طراحی کدهای عمومی است. مخاطب کتاب این کتاب برای برنامه‌نویسانی که در ابتدای مسیر حرفه‌ای خود هستند و با زبان‌های شیءگرا مانند Java یا C# آشنایی دارند، مناسب است. درباره نویسنده تام لانگ، مهندس نرم‌افزار در گوگل، به‌عنوان رهبر فنی فعالیت می‌کند. او تجربیات خود در آموزش و راهنمایی برنامه‌نویسان تازه‌کار را در این کتاب به اشتراک گذاشته است. فصول کتاب بخش اول: نظریه کیفیت کد سطوح انتزاع قراردادهای کدنویسی و همکاری با دیگر مهندسان مدیریت خطاها بخش دوم: عمل 5. خوانایی کد 6. جلوگیری از شگفتی‌ها و رفتارهای غیرمنتظره 7. سخت کردن استفاده نادرست از کد 8. ماژولار بودن کد 9. قابلیت استفاده مجدد و تعمیم‌پذیری کد بخش سوم: تست واحد 10. اصول تست واحد 11. روش‌های تست واحد این کتاب نه تنها به شما کمک می‌کند تا کدهای بهتری بنویسید، بلکه باعث می‌شود بهره‌وری شما و تیم‌تان در بلندمدت افزایش یابد. @DeveloperAdvocate 🥑

چالش‌های اجرای Migration توی Docker اجرای Migration‌ها داخل Docker ایده جذابی به نظر میاد، ولی یه سری مشکلات داره که بهتره قبل از پیاده‌سازی حتماً بهش فکر کنیم. بیاین چندتا از این چالش‌ها رو با هم مرور کنیم: 1. نیاز به دسترسی به دیتابیس حین Build وقتی از دستور dotnet ef database update استفاده می‌کنیم، باید به دیتابیس وصل بشیم. این یعنی توی مرحله CD (مرحله استقرار)، باید اطلاعات دیتابیس داخل ایمیج باشه. اما این کار اصلاً امن نیست! بهتره این اطلاعات از طریق Environment Variables ارسال بشه. 2. بزرگ شدن حجم Docker Image نصب EF Core Tools و ابزارهای دیگه باعث می‌شه حجم ایمیج خیلی بیشتر بشه. نتیجه؟ زمان بیشتری برای ساخت و انتقال ایمیج نیاز داریم، که توی CI/CD می‌تونه اذیت‌کننده باشه. 3. مشکلات در کلاستر حالتی رو در نظر بگیر که چندتا نمونه (Instance) از سرویس شما توی کلاستر در حال اجرا باشن. وقتی کانتینرها بخوان همزمان Migration انجام بدن، همه منتظر می‌مونن تا یکی کارش تموم شه. این یعنی زمان استارتاپ سرویس‌ها می‌ره بالا 4. وای به روزی که Rollback لازم بشه! فرض کن Migration‌ها اجرا شدن و یهو فهمیدی یه چیزی اشتباه بوده. حالا می‌خوای Rollback کنی! واقعاً سخته برگردوندن دیتابیس به حالت قبل، مخصوصاً وقتی Migrationها خودکار اجرا شده باشن. این می‌تونه به کلی دردسر و حتی از دست رفتن دیتا منجر بشه.

در مواقعی که چندین ساعت پشت سرهم کار انجام میدهیم و خسته می‌شویم، امکان این کار وجود دارد که پروژه را سریعا push کنیم و بررسی نکنیم که اصلا پروژه بیلد میشود یا نه. در Git این قابلیت وجود دارد که قبل از پوش کردن یکسری دستورات را اجرا نماییم. بنابراین میتوانیم از این قابلیت برای بیلد گرفتن از پروژه قبل از پوش کردن استفاده نماییم. برای این کار باید در پوشه .git پوشه hooks را باز نمایید و یک فایل به اسم pre-push ایجاد نمایید. سپس باید دستور مربوط به بلید گرفتن از پروژه خود را درون فایل ایجاد شده بنویسید. با این کار قبل از هر بار پوش کردن branchها دستورات درون فایل pre-push اجرا می‌شود. https://dotnetdocs.ir/Fa/Post/66/build-%DA%AF%D8%B1%D9%81%D8%AA%D9%86-%D8%A7%D8%B2-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%D9%82%D8%A8%D9%84-%D8%A7%D8%B2-%D9%BE%D9%88%D8%B4-%DA%A9%D8%B1%D8%AF%D9%86-git-commit

حالا معایبش چیه ؟ شما از چه روشی برای اجرا کردن Migration روی Production استفاده میکنید؟

این روش به شدت توصیه نمیشه ⚠️⚠️⚠️ https://devblogs.microsoft.com/dotnet/introducing-devops-friendly-ef-core-migration-bundles/

مدیریت هوشمند Migrationها در EF Core با Docker و EF Tools در این روش، شما EF Core Tools را مستقیماً داخل Docker نصب می‌کنید، که به شما امکان می‌دهد migrationها را بدون نیاز به نصب ابزارهای اضافی روی سیستم شخصی خود، کاملاً داخل کانتینر مدیریت کنید. این روش برای CI/CD و محیط‌های تولیدی عالی است، چون همه چیز ایزوله و مستقل داخل کانتینر انجام می‌شود. مراحل نصب EF Core Tools در Docker و اجرای migrationها ۱. تنظیم Dockerfile در Dockerfile، EF Core Tools را نصب می‌کنیم تا migrationها به‌طور خودکار داخل کانتینر اجرا شوند. هر بار که کانتینر ساخته و اجرا می‌شود، migrationها اعمال و دیتابیس آماده استفاده می‌شود.

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
WORKDIR /app
EXPOSE 80

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY ["YourProject/YourProject.csproj", "YourProject/"]
RUN dotnet restore "YourProject/YourProject.csproj"
COPY . .
RUN dotnet build "YourProject/YourProject.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "YourProject/YourProject.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .

# نصب EF Core Tools و اجرای migrationها
RUN dotnet tool install --global dotnet-ef
ENV PATH="$PATH:/root/.dotnet/tools"
RUN dotnet ef database update 

ENTRYPOINT ["dotnet", "YourProject.dll"]

۲. ساخت و اجرای کانتینر کافی است دستورات زیر را اجرا کنید تا کانتینر ساخته و اپلیکیشن شما اجرا شود:

docker build -t your-image-name .
docker run -d your-image-name

مزایای این روش ▫️سادگی و انعطاف در CI/CD: عملیات migrationها خودکار اجرا می‌شوند و برای محیط‌های CI/CD فوق‌العاده مناسب هستند. ▫️استقلال از محیط توسعه: نیاز به ابزارهای اضافی روی سیستم شخصی نیست؛ همه چیز داخل Docker انجام می‌شود. ▫️دیتابیس همیشه به‌روز: هر بار که کانتینر اجرا شود، migrationها اعمال می‌شوند و دیتابیس سینک می‌ماند. این روش یه راهکار راحت و ایزوله برای مدیریت migrationهاست و کار با Docker را هم ساده‌تر می‌کند. 🔗 برای مطالعه بیشتر میتوانید به این لینک مراجعه نمایید. ⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنت‌ها به اشتراک بگذارید. #هوتن_همتی (لینکدین) کانال تلگرام: @SoftwarePhilosophy ________

میخوام در حوزه Tuning شمارو با یک مفهومی به نام Good Enough (بسه دیگه من خوبم 😅 ) آشنا کنم. فرض کنید میخواین یک خودی نشون بدین و بگین که ما خیلی خفنیم و کلاس رفتیم و کلی کتاب خوندیم حالا باید بگیم فلان کار رو کردیم. دمتون هم گرم. حالا میرید یک کدی پیدا می کنید که مثلا ۴ ساعت زمان میبره کلی تلاش می کنید مثلا زمانش میرسه به ۱ دقیقه. (بابا ایول چقدر شما خفنید اخه 😁 👏 ) هی منتظر میشین یکی بیاد ازتون تشکر کنه بگه دمت گرم حمیدرضا سیستممون خیلی دیگه سریع کار میکنه مثل بنز داره جواب میده. یک روز، دو روز ،سه روز صبر می کنیم بعد وقتی که میبینم نه مثل اینکه هیچ خبری نیست با کوله باری از 🤬 🤬 راهی اطلاع رسانی به شرکت میشیم. میریم شروع می کنیم به تیم توسعه میگیم ببین محمد من یک کار خفن کردم این کد رو زمانش رو اینقدر تغییر دادم. محمد :‌ تو روی این کده کار کردی؟ حمیدرضا : خوب اره. محمد : چقدر وقت گذاشتی؟ حمیدرضا :‌راستش دو روز اشک منو دراورد تا اصلاحش کردم. محمد :‌ آفرین خسته نباشید این یک گزارشی هست که هر ۴ ماه یک بار واحد X میگیره و خیلی هم زمانش براش اهمیتی نداره. 😤 😤 😡 اینجاست که انگار آب یخ روی شما ریختن. حالا تو این وسط دوجین هم ایندکس ایجاد کردین که باعث شده صدتا کد اساسی بره تو دیوار که این کد درست کار کنه. عزیزان دل، اول باید ببینید چه کدی داره چه باری میذاره و چند وقت یکبار داره بار ایجاد می کنه. دوم اینکه تا چقدر باید پیش بریم روی تیونینگ کد که خوب باشه. یک کدی اگه توی یک دقیقه هم جواب بده اکیه نیازی نیست زیادی باهاش سرو کله بزنید و دوجین ایندکس بهش اضافه کنید. یک کدی هم ۵۰ میلی ثانیه زمان میبره باید برسونیدش مثلا به ۲۰ میلی ثانیه. اینکه روی چه کدی و چقدر کار کنیم تا کجا پیش بریم و سعی کنیم بهینه اش کنیم برمیگرده به تعداد دفعات اجرا ،‌ میزان لودی که ایجاد می کنه و اهمیت دار بودن اون. کدی که قراره هر یک ماه یکبار یک گزارش بگیره این شاید به اندازه کدی که روزی ۱۰۰۰ مرتبه اجرا میشه با اهمیت نباشه(هرچند ممکنه اون ماهی یک بار برای مدیر مربوطه باشه.که اونو میشه زمانش رو یک مقداری بهینه تر کرد تا اخراج نشیم 😂 ) این مهم رو در نظر بگیرید خدایی. چون Tuning هزینه داره. الزاما ایجاد هر ایندکسی مناسب نیست. الزاما تغییر در خیلی از ساختار مناسب نیست. خیلی از رفتارها مناسب نیست و واقعا باید یک سبک و سنگین بین مزایا و معایبش اتفاق بیافته و بعد انجام بشه. خدایی چقدر ما DBA ها خفن هستیم که حواسمون به همه چیز هست مثل ... (برای خودمون نوشابه پوست بکنیم 😅 ) @Hamidreza_Sadeghian #GoodEnough #PerformanceTuning #DBA