وقتی ابزارها از نیاز ما بزرگترند: درسهایی از Kafka و Flinkو هنر انتخاب درست
در دنیایی که هر ثانیه هزاران رویداد در سرویسها، اپلیکیشنها و سیستمهای ما جریان دارد، طبیعی است که به سراغ ابزارهای قدرتمند برویم. ابزارهایی مثل Kafka ، Flink و اسپارک که نامشان با «مقیاس عظیم»، «پردازش بلادرنگ» و «زیرساخت حرفهای» گره خورده است.
اما حقیقتی که کمتر دربارهاش حرف میزنیم این است:
✨ بیشتر ما اصلاً چنین مقیاسی نداریم.
سالهاست تیمهای کوچک و متوسط، با دادههای کم و نیازهای ساده، سراغ ابزارهایی میروند که برای غولهایی مثل اوبر، لینکدین یا نتفلیکس طراحی شدهاند. نتیجه چیست؟
پیچیدگی بیشتر. هزینه بیشتر. زمان بیشتر. و در نهایت، زیرساختی بزرگتر از نیاز واقعی.
دو مقالهای که اخیرا با عنوان «Kafka’s 80% Problem» و «Flink’s 95% Problem» منتشر شدهاند به کمک آمار و ارقام، ما را به توقفی کوتاه و تفکری جدی در این خصوص دعوت میکنند.
بیشتر خوشههای #Kafka زیر ۱ MB/s داده دارند و بیشتر کاربردهای استریم اصلاً نیازی به #Flink یا اسپارک ندارند. برای دو سوم پروژهها، یک API ساده یا یک دیتابیس تحلیلی سبک کاملاً کافی است.
👌 پیام نویسندگان این دو مقاله روشن است: قبل از انتخاب ابزار، نیاز واقعی را بسنج.
گاهی بهجای یک بیگدیتای کامل، تنها چیزی که لازم داریم یک خط پردازش داده ساده است.
چرا باید حواسمان به این انتخابها باشد؟
🔹 زیرا بیشتر تیمها درگیر «نیاز واقعی» نیستند، بلکه درگیر «تصور نیاز» شدهاند.
🔹 بیشتر خوشههای Kafka کمتر از ۱ مگابایت در ثانیه داده دارند.
🔹 بیشتر کاربردهای استریم اصلاً نیازمند پیچیدگی Flink یا اسپارک نیستند.
🔹 وقتی ابزار از نیاز بزرگتر باشد، هزینهها، پیچیدگی، زمان، نیروی انسانی و ریسک عملیاتی بیدلیل بالا میرود. انتخاب اشتباه ابزار، فقط یک مسئله فنی نیست، یک هزینه سازمانی و یک ریسک محصولی است.
بسیاری از تیمها، بدون بررسی دقیق، زیرساختهایی میسازند که برای غولهایی مثل نتفلیکس یا اوبر طراحی شده، نه برای سرویسهای متوسط.
نتیجه؟
⚠️زیرساخت سنگین برای بار سبک
⚠️هزینه مالی بالا
⚠️پیچیدگی عملیاتی غیرضروری
⚠️نیاز به تخصص خاص و دشوار
⚠️سرعت پایینتر توسعه
⚠️ و در نهایت، «مهندسی بیشازحد»
درحالیکه بسیاری از نیازها را میتوان با ابزارهایی بسیار سادهتر حل کرد: یک API، یک دیتابیس تحلیلی سبک، یا حتی یک معماری batch.
دنیای ابزارهای داده و استریمینگ خانهای بزرگ با امکانات فراوان است، اما هر ابزار قدرتمندی مناسب هر کاری نیست.
🔰 مقاله «Kafka’s 80% Problem» به ما میگوید که بسیاری از سازمانها با داده کم، زیرساخت بزرگ میسازند.
🔰 مقاله «Flink’s 95% Problem» هشدار میدهد که اغلب پروژهها نیازی به پیچیدگی فنی فلینک ندارند.
💡 پیام مشترک این دو مقاله روشن و ارزشمند است:
بهجای انتخاب ابزارهای بزرگ، نیاز کوچک خود را دقیق بفهمیم.
گاهی بهترین معماری، سادهترین معماری است، نه چون امکانات کمتری دارد، بلکه چون بیشترین همخوانی را با واقعیت دارد.آیا واقعاً به سیستمهای سنگین و «enterprise-grade» نیاز داریم، یا فقط درگیر مد روز مهندسی شدهایم؟ در معماری داده، هوشمندی در انتخاب ابزار همیشه مهمتر از بزرگی ابزار است.
پس شاید بهتر باشد از خودمان بپرسیم:
آیا واقعاً به سیستمهای سنگین و «enterprise-grade» نیاز داریم، یا فقط درگیر مد روز مهندسی شدهایم؟
در معماری داده، هوشمندی در انتخاب ابزار همیشه مهمتر از بزرگی ابزار است.
گاهی سادگی، بهترین راهحل مهندسی است.
در دنیایی که هر ثانیه هزاران رویداد در سرویسها، اپلیکیشنها و سیستمهای ما جریان دارد، طبیعی است که به سراغ ابزارهای قدرتمند برویم. ابزارهایی مثل Kafka ، Flink و اسپارک که نامشان با «مقیاس عظیم»، «پردازش بلادرنگ» و «زیرساخت حرفهای» گره خورده است.
اما حقیقتی که کمتر دربارهاش حرف میزنیم این است:
✨ بیشتر ما اصلاً چنین مقیاسی نداریم.
سالهاست تیمهای کوچک و متوسط، با دادههای کم و نیازهای ساده، سراغ ابزارهایی میروند که برای غولهایی مثل اوبر، لینکدین یا نتفلیکس طراحی شدهاند. نتیجه چیست؟
پیچیدگی بیشتر. هزینه بیشتر. زمان بیشتر. و در نهایت، زیرساختی بزرگتر از نیاز واقعی.
دو مقالهای که اخیرا با عنوان «Kafka’s 80% Problem» و «Flink’s 95% Problem» منتشر شدهاند به کمک آمار و ارقام، ما را به توقفی کوتاه و تفکری جدی در این خصوص دعوت میکنند.
بیشتر خوشههای #Kafka زیر ۱ MB/s داده دارند و بیشتر کاربردهای استریم اصلاً نیازی به #Flink یا اسپارک ندارند. برای دو سوم پروژهها، یک API ساده یا یک دیتابیس تحلیلی سبک کاملاً کافی است.
👌 پیام نویسندگان این دو مقاله روشن است: قبل از انتخاب ابزار، نیاز واقعی را بسنج.
گاهی بهجای یک بیگدیتای کامل، تنها چیزی که لازم داریم یک خط پردازش داده ساده است.
چرا باید حواسمان به این انتخابها باشد؟
🔹 زیرا بیشتر تیمها درگیر «نیاز واقعی» نیستند، بلکه درگیر «تصور نیاز» شدهاند.
🔹 بیشتر خوشههای Kafka کمتر از ۱ مگابایت در ثانیه داده دارند.
🔹 بیشتر کاربردهای استریم اصلاً نیازمند پیچیدگی Flink یا اسپارک نیستند.
🔹 وقتی ابزار از نیاز بزرگتر باشد، هزینهها، پیچیدگی، زمان، نیروی انسانی و ریسک عملیاتی بیدلیل بالا میرود. انتخاب اشتباه ابزار، فقط یک مسئله فنی نیست، یک هزینه سازمانی و یک ریسک محصولی است.
بسیاری از تیمها، بدون بررسی دقیق، زیرساختهایی میسازند که برای غولهایی مثل نتفلیکس یا اوبر طراحی شده، نه برای سرویسهای متوسط.
نتیجه؟
⚠️زیرساخت سنگین برای بار سبک
⚠️هزینه مالی بالا
⚠️پیچیدگی عملیاتی غیرضروری
⚠️نیاز به تخصص خاص و دشوار
⚠️سرعت پایینتر توسعه
⚠️ و در نهایت، «مهندسی بیشازحد»
درحالیکه بسیاری از نیازها را میتوان با ابزارهایی بسیار سادهتر حل کرد: یک API، یک دیتابیس تحلیلی سبک، یا حتی یک معماری batch.
دنیای ابزارهای داده و استریمینگ خانهای بزرگ با امکانات فراوان است، اما هر ابزار قدرتمندی مناسب هر کاری نیست.
🔰 مقاله «Kafka’s 80% Problem» به ما میگوید که بسیاری از سازمانها با داده کم، زیرساخت بزرگ میسازند.
🔰 مقاله «Flink’s 95% Problem» هشدار میدهد که اغلب پروژهها نیازی به پیچیدگی فنی فلینک ندارند.
💡 پیام مشترک این دو مقاله روشن و ارزشمند است:
بهجای انتخاب ابزارهای بزرگ، نیاز کوچک خود را دقیق بفهمیم.
گاهی بهترین معماری، سادهترین معماری است، نه چون امکانات کمتری دارد، بلکه چون بیشترین همخوانی را با واقعیت دارد.آیا واقعاً به سیستمهای سنگین و «enterprise-grade» نیاز داریم، یا فقط درگیر مد روز مهندسی شدهایم؟ در معماری داده، هوشمندی در انتخاب ابزار همیشه مهمتر از بزرگی ابزار است.
پس شاید بهتر باشد از خودمان بپرسیم:
آیا واقعاً به سیستمهای سنگین و «enterprise-grade» نیاز داریم، یا فقط درگیر مد روز مهندسی شدهایم؟
در معماری داده، هوشمندی در انتخاب ابزار همیشه مهمتر از بزرگی ابزار است.
گاهی سادگی، بهترین راهحل مهندسی است.
👍3
معرفی کتاب «چالشهای اخلاقی علم داده»
امروز در جهانی زندگی میکنیم که دادهها، آرام و بیصدا اما قدرتمند، در تار و پود زندگی ما تنیده شدهاند. از تصمیمهای ساده روزمره تا سیاستگذاریهای کلان، ردّ پای الگوریتمها را همهجا میبینیم؛ الگوریتمهایی که شاید هیچوقت آنها را نشناسیم، اما بهراحتی ما را دستهبندی میکنند، برایمان پیشنهاد میسازند، رفتارمان را پیشبینی میکنند و حتی در موقعیتهای حساس، به جای ما تصمیم میگیرند.
اما سؤال مهم این است:
⚠️ چه کسی به اخلاقِ پشتِ این سیستمها فکر میکند؟
⚠️ آیا توسعهدهندگان، تحلیلگران داده، استارتاپها، سازمانها و دولتها همیشه به پیامدهای انسانی و اجتماعی تصمیمات مبتنی بر داده آگاهاند؟
در جامعه علمی دنیا، سالهاست که اخلاق داده جدی گرفته میشود؛ همانطور که درباره محیطزیست، فلسفه اخلاق، یا اخلاق پژوهشهای انسانی ادبیات عظیمی شکل گرفته، درباره اخلاق علم داده هم پژوهشهای معتبر و چارچوبهای حرفهای ایجاد شده است.
ترجمه کتاب ارزشمند «چالشهای اخلاقی علم داده» نوشته دیوید مارتینز و ترجمهشده به همت محمدجواد جعفری دقیقاً در راستای همین موضوع و برای مخاطب ایرانی تهیه شده است:
کتابی که نهفقط یک نگاه نظری، بلکه راهنمایی عملی برای همه فعالان داده است: از تحلیلگر و مهندس داده تا مدیر محصول، پژوهشگر هوش مصنوعی و قانونگذار.
در ادامه، بر اساس سرفصلهای کتاب، نگاهی به محتوای آن و ارزشهای کلیدیاش میاندازیم.
آنچه در این کتاب میبینیم
🔰فصل اول: مقدمهای بر اخلاق علم داده
این فصل توضیح میدهد که چرا اخلاق باید بخشی جدانشدنی از چرخه توسعه سیستمهای داده باشد. در جهانی که الگوریتمها تصمیمهای مهم را شکل میدهند، رعایت عدالت، پاسخگویی و شفافیت دیگر انتخابی اختیاری نیست.
🔰فصل دوم: اخلاق جمعآوری دادهها
اینجا نویسنده یادآور میشود که جمعآوری داده، پیش از آنکه یک کار فنی باشد، مسئولیتی اخلاقی است. اینکه چه دادهای حق داریم جمع کنیم، چگونه باید حریم خصوصی را رعایت کرد و رضایت کاربر چه معنایی دارد، محور این فصل است.
🔰فصل سوم: اخلاق پردازش دادهها
این فصل نشان میدهد که پردازش نادرست داده، از پاکسازی تا ناشناسسازی، میتواند به نقض حریم خصوصی یا ایجاد سوگیریهای خطرناک منجر شود. کیفیت اخلاقی مدلها از همین مرحلههای اولیه شکل میگیرد.
🔰فصل چهارم: اخلاق مدلسازی
در این فصل به چالشهای اخلاقی هنگام ساخت مدلها میپردازیم: از تبعیض الگوریتمی تا اهمیت مدلهای توضیحپذیر و آگاه از تبعیض. پیام اصلی این است که مدلسازی باید با درک پیامدهای اجتماعی آن همراه باشد.
🔰فصل پنجم: ارزیابی اخلاقی
فصل پایانی تأکید میکند که اخلاق یک فرآیند مستمر است. سیستمهای داده باید دائماً از نظر عدالت، شفافیت و ریسک اخلاقی ارزیابی شوند و این ارزیابی باید بهصورت مسئولانه گزارش شود.
✔️ سخن پایانی
امیدوارم ترجمه و انتشار این کتاب آغازی برای جدیتر شدن بحث اخلاق داده در جامعه علمی و مهندسی ایران باشد. امروز بیش از همیشه به متخصصانی نیاز داریم که کنار توان فنی، نگاه انسانی و اخلاقی هم داشته باشند. برای محمدجواد جعفری مترجم پرتلاش این اثر، و همه دغدغهمندان این حوزه آرزوی موفقیت دارم. جامعه دادهمحور ایران به چنین گامهایی نیازمند است و این مسیر تازه آغاز شده است.
پ.ن: برای خرید و تهیه کتاب به سایت انتشارات جهاد دانشگاهی مراجعه کنید و یا به خود مترجم در لینکدین یا تلگرام @Mjafarisc پیام بدهید.
امروز در جهانی زندگی میکنیم که دادهها، آرام و بیصدا اما قدرتمند، در تار و پود زندگی ما تنیده شدهاند. از تصمیمهای ساده روزمره تا سیاستگذاریهای کلان، ردّ پای الگوریتمها را همهجا میبینیم؛ الگوریتمهایی که شاید هیچوقت آنها را نشناسیم، اما بهراحتی ما را دستهبندی میکنند، برایمان پیشنهاد میسازند، رفتارمان را پیشبینی میکنند و حتی در موقعیتهای حساس، به جای ما تصمیم میگیرند.
اما سؤال مهم این است:
⚠️ چه کسی به اخلاقِ پشتِ این سیستمها فکر میکند؟
⚠️ آیا توسعهدهندگان، تحلیلگران داده، استارتاپها، سازمانها و دولتها همیشه به پیامدهای انسانی و اجتماعی تصمیمات مبتنی بر داده آگاهاند؟
در جامعه علمی دنیا، سالهاست که اخلاق داده جدی گرفته میشود؛ همانطور که درباره محیطزیست، فلسفه اخلاق، یا اخلاق پژوهشهای انسانی ادبیات عظیمی شکل گرفته، درباره اخلاق علم داده هم پژوهشهای معتبر و چارچوبهای حرفهای ایجاد شده است.
ترجمه کتاب ارزشمند «چالشهای اخلاقی علم داده» نوشته دیوید مارتینز و ترجمهشده به همت محمدجواد جعفری دقیقاً در راستای همین موضوع و برای مخاطب ایرانی تهیه شده است:
کتابی که نهفقط یک نگاه نظری، بلکه راهنمایی عملی برای همه فعالان داده است: از تحلیلگر و مهندس داده تا مدیر محصول، پژوهشگر هوش مصنوعی و قانونگذار.
در ادامه، بر اساس سرفصلهای کتاب، نگاهی به محتوای آن و ارزشهای کلیدیاش میاندازیم.
آنچه در این کتاب میبینیم
🔰فصل اول: مقدمهای بر اخلاق علم داده
این فصل توضیح میدهد که چرا اخلاق باید بخشی جدانشدنی از چرخه توسعه سیستمهای داده باشد. در جهانی که الگوریتمها تصمیمهای مهم را شکل میدهند، رعایت عدالت، پاسخگویی و شفافیت دیگر انتخابی اختیاری نیست.
🔰فصل دوم: اخلاق جمعآوری دادهها
اینجا نویسنده یادآور میشود که جمعآوری داده، پیش از آنکه یک کار فنی باشد، مسئولیتی اخلاقی است. اینکه چه دادهای حق داریم جمع کنیم، چگونه باید حریم خصوصی را رعایت کرد و رضایت کاربر چه معنایی دارد، محور این فصل است.
🔰فصل سوم: اخلاق پردازش دادهها
این فصل نشان میدهد که پردازش نادرست داده، از پاکسازی تا ناشناسسازی، میتواند به نقض حریم خصوصی یا ایجاد سوگیریهای خطرناک منجر شود. کیفیت اخلاقی مدلها از همین مرحلههای اولیه شکل میگیرد.
🔰فصل چهارم: اخلاق مدلسازی
در این فصل به چالشهای اخلاقی هنگام ساخت مدلها میپردازیم: از تبعیض الگوریتمی تا اهمیت مدلهای توضیحپذیر و آگاه از تبعیض. پیام اصلی این است که مدلسازی باید با درک پیامدهای اجتماعی آن همراه باشد.
🔰فصل پنجم: ارزیابی اخلاقی
فصل پایانی تأکید میکند که اخلاق یک فرآیند مستمر است. سیستمهای داده باید دائماً از نظر عدالت، شفافیت و ریسک اخلاقی ارزیابی شوند و این ارزیابی باید بهصورت مسئولانه گزارش شود.
✔️ سخن پایانی
امیدوارم ترجمه و انتشار این کتاب آغازی برای جدیتر شدن بحث اخلاق داده در جامعه علمی و مهندسی ایران باشد. امروز بیش از همیشه به متخصصانی نیاز داریم که کنار توان فنی، نگاه انسانی و اخلاقی هم داشته باشند. برای محمدجواد جعفری مترجم پرتلاش این اثر، و همه دغدغهمندان این حوزه آرزوی موفقیت دارم. جامعه دادهمحور ایران به چنین گامهایی نیازمند است و این مسیر تازه آغاز شده است.
پ.ن: برای خرید و تهیه کتاب به سایت انتشارات جهاد دانشگاهی مراجعه کنید و یا به خود مترجم در لینکدین یا تلگرام @Mjafarisc پیام بدهید.
Forwarded from مدرسه مهندسی داده سپهرام
نگاهی به امکانات جدید Airflow 3 و دنیای Data Assets - آغاز عصر Data-Driven Workflows در ایرفلو
✨ در نسخه جدید Airflow 3 یک تحول اساسی رخ داده است:
این یعنی:
✔️ دیگر لازم نیست یک DAG را هر شب رأس یک ساعت مشخص اجرا کنیم؛
✔️ بلکه میتوانیم آن را براساس آماده شدن یک داده، یک خروجی، یا یک رخداد (Asset Event) اجرا کنیم.
✔️این تغییر، نقطهی اتصال دنیای Orchestration کلاسیک با Data Engineering مدرن است.
🔹و اما Data Assets در Airflow یعنی چه؟
از نسخه ۲ مفهومی به نام Asset اضافه شد، اما در Airflow 3 این قابلیت کاملاً بالغ شد و حتی یک بخش اختصاصی در UI برای مشاهده و مدیریت آن وجود دارد.
با Data Assets میتوانیم:
🔰مشخص کنیم یک DAG چه دادهای تولید میکند (Outlets)
🔰تعیین کنیم DAGها چه دادهای مصرف میکنند (Inlets)
🔰اجرای DAGها را وابسته به آماده شدن دادهها کنیم
🔰گردشکارها را بهجای schedule time-based، کاملاً event-based طراحی کنیم
🔰برای Assetها Metadata و Events تولید کنیم و رفتارهای پیشرفته بسازیم
به زبان ساده:
ایرفلو نسخه ۳ جریانهای کاری را "Data-Aware" و حتی "Data-Driven" میکند.
🎯 جلسه پنجم دوره آموزشی ایرفلو - از پارامترها تا Data-Driven Workflows
در جلسه پنجم دوره آموزش Airflow در «مدرسه مهندسی داده سپهرام»، دقیقاً روی همین موضوعات تمرکز کردهایم:
✴️ بخش اول: Parameterized Workflows
⚡️تعریف پارامتر برای DAGها
⚡️اجرای DAG از طریق API رسمی Airflow
⚡️ارسال پارامتر با curl و پایتون
⚡️استفاده از Auth و تولید token
✴️ بخش دوم: Data-Driven Workflows و داراییها
⚡️آشنایی با Assetها و معماری جدید Airflow 3
⚡️ساخت یک پایپلاین مبتنی بر Asset
⚡️استفاده از outlets و inlets در Taskها
⚡️مشاهده و مدیریت Assetها در UI
⚡️رویدادها (Asset Events)، Metadata، وابستگیهای ترکیبی و Aliases
این جلسه عملاً پلی است میان قابلیتهای قدیمی ایرفلو و معماریهای جدید Data-Driven Pipelines.
🎥 مشاهده رایگان جلسه
فیلمها و محتوای کامل جلسه پنجم برای عموم آزاد است و از این لینک میتوانید آنها را مشاهده کنید: کلیک کنید.
اگر با Airflow کار میکنید، این جلسه میتواند نگاه شما را نسبت به طراحی پایپلاینها کاملاً تغییر دهد.
پ.ن : هر چند سامانههای مدیریت جریان داده مثل Dagster در این زمینه بسیار جلوتر از ایرفلو هستند اما اگر در کنار کارهای روزانه زمانبندی شده، نیاز به دگهای داده محور هم دارید، ایرفلو امروزه این امکان را به راحتی در اختیار شما قرار میدهد.
✨ در نسخه جدید Airflow 3 یک تحول اساسی رخ داده است:
ایرفلو از یک ابزار زمانمحور برای اجرای جریانکارها، به یک سیستم دادهمحور (Data-Driven) ارتقا پیدا کرده است.
این یعنی:
✔️ دیگر لازم نیست یک DAG را هر شب رأس یک ساعت مشخص اجرا کنیم؛
✔️ بلکه میتوانیم آن را براساس آماده شدن یک داده، یک خروجی، یا یک رخداد (Asset Event) اجرا کنیم.
✔️این تغییر، نقطهی اتصال دنیای Orchestration کلاسیک با Data Engineering مدرن است.
🔹و اما Data Assets در Airflow یعنی چه؟
از نسخه ۲ مفهومی به نام Asset اضافه شد، اما در Airflow 3 این قابلیت کاملاً بالغ شد و حتی یک بخش اختصاصی در UI برای مشاهده و مدیریت آن وجود دارد.
با Data Assets میتوانیم:
🔰مشخص کنیم یک DAG چه دادهای تولید میکند (Outlets)
🔰تعیین کنیم DAGها چه دادهای مصرف میکنند (Inlets)
🔰اجرای DAGها را وابسته به آماده شدن دادهها کنیم
🔰گردشکارها را بهجای schedule time-based، کاملاً event-based طراحی کنیم
🔰برای Assetها Metadata و Events تولید کنیم و رفتارهای پیشرفته بسازیم
به زبان ساده:
ایرفلو نسخه ۳ جریانهای کاری را "Data-Aware" و حتی "Data-Driven" میکند.
🎯 جلسه پنجم دوره آموزشی ایرفلو - از پارامترها تا Data-Driven Workflows
در جلسه پنجم دوره آموزش Airflow در «مدرسه مهندسی داده سپهرام»، دقیقاً روی همین موضوعات تمرکز کردهایم:
✴️ بخش اول: Parameterized Workflows
⚡️تعریف پارامتر برای DAGها
⚡️اجرای DAG از طریق API رسمی Airflow
⚡️ارسال پارامتر با curl و پایتون
⚡️استفاده از Auth و تولید token
✴️ بخش دوم: Data-Driven Workflows و داراییها
⚡️آشنایی با Assetها و معماری جدید Airflow 3
⚡️ساخت یک پایپلاین مبتنی بر Asset
⚡️استفاده از outlets و inlets در Taskها
⚡️مشاهده و مدیریت Assetها در UI
⚡️رویدادها (Asset Events)، Metadata، وابستگیهای ترکیبی و Aliases
این جلسه عملاً پلی است میان قابلیتهای قدیمی ایرفلو و معماریهای جدید Data-Driven Pipelines.
🎥 مشاهده رایگان جلسه
فیلمها و محتوای کامل جلسه پنجم برای عموم آزاد است و از این لینک میتوانید آنها را مشاهده کنید: کلیک کنید.
اگر با Airflow کار میکنید، این جلسه میتواند نگاه شما را نسبت به طراحی پایپلاینها کاملاً تغییر دهد.
پ.ن : هر چند سامانههای مدیریت جریان داده مثل Dagster در این زمینه بسیار جلوتر از ایرفلو هستند اما اگر در کنار کارهای روزانه زمانبندی شده، نیاز به دگهای داده محور هم دارید، ایرفلو امروزه این امکان را به راحتی در اختیار شما قرار میدهد.
👍2
مهاجرت آرام و بیسروصدای MinIO به دنیای تجاری
تغییرات همیشه با اعلام رسمی شروع نمیشوند. گاهی تنها نشانه، یک کامیت ساده در گیتهاب است؛ تغییری کوچک که آینده یک اکوسیستم بزرگ را دگرگون میکند.
MinIO دقیقاً به همین شکل مسیرش را تغییر داد.
نه بیانیهای منتشر شد، نه توضیحی ارائه شد، تنها یک اصلاح در README:
❗️ کدبیس در حالت «Maintenance-only»
❗️ عدم پذیرش ویژگیها و Pull Requestهای جدید
❗️ بررسی رفع اشکالات امنیتی «بهصورت موردی»
و در کنار آن، دعوتی غیرمستقیم برای حرکت به سمت محصول تجاری:
👉 AIStor
این تصمیم، در عمل نشاندهنده یک کوچ آرام اما قطعی از مدل اوپنسورس به مدل تجاری است. تغییری که شاید بیسروصدا رخ داد، اما تأثیر آن بر زیرساخت بسیاری از سازمانها بسیار جدی خواهد بود.
✴️ پیامدهای این تغییر برای تیمهای فنی
پروژه محبوب MinIO برای سالها یکی از مهمترین انتخابها برای پیادهسازی S3-compatible storage در محیطهای production بود.
اما اکنون، هر تیمی که بر نسخه رایگان و پشتیبانی جامعه حساب کرده بود، در برابر واقعیتی جدید قرار دارد:
⚠️ توسعه متوقف شده است
⚠️ پایداری بلندمدت نامشخص است
⚠️امنیت تحت شرایط «case-by-case» قرار گرفته
بهعبارت دیگر، دوران MinIO بهعنوان یک گزینه پیشفرض، رایگان و قابل اتکا، عملاً پایان یافته است.
مسیر بعدی چیست؟
خوشبختانه امروز اکوسیستم ذخیرهسازی توزیعشده گزینههای قدرتمند و پختهای در اختیار دارد.
و حتی پروژههایی نوظهور که عملکردشان فراتر از حد انتظار است.
گزینههای جدی برای دوران پس از MinIO
🔹 RustFS
جایگزینی بسیار نزدیک، سریع و آیندهدار
در روزهای اخیر رشدی چشمگیر در فعالیت مخزن این پروژه مشاهده شده است. (برای مشاهده فعالیتها کلیک کنید.)
دلایل توجه بالای جامعه کاملاً روشن است:
🔰 سازگاری کامل با MinIO
🔰 اجرا روی همان پورتهای 9000
🔰عملکردی تا دو برابر سریعتر در بنچمارکهای اولیه
🔰کدنوشته شده با Rust؛ یعنی امنیت، سرعت و مصرف منابع بهینه
🔰جامعهای فعال که روند توسعه پرشتابی را نشان میدهد
این گزینه یعنی RustFS شاید تنها گزینهای باشد که مسیر مهاجرت از MinIO را تقریباً بدون تغییر در معماری امکانپذیر میکند.
🔹 SeaweedFS
راهکاری پخته و مناسب برای مقیاسهای بزرگ، با تمرکز بر سرعت، سادگی و توزیع مؤثر داده.
نکته: سال ۹۶ پستی را راجع به انتخاب یک فایلاستوریج که در آن Seaweedfs معرفی شده بود منتشر کردیم
🔹 Garage
انتخابی سبک و ساده برای محیطهای self-hosted و تیمهایی که به سادگی راهاندازی و نگهداری اهمیت میدهند.
🔹 Ceph
راهکاری جاافتاده برای بارهای کاری سنگین، با قابلیتهای گسترده اما پیچیدگی عملیاتی بالاتر.
تغییر مسیر MinIO شاید در ظاهر یک کامیت ساده باشد، اما برای بسیاری از تیمها یک نقطه تصمیمگیری استراتژیک خواهد بود.
اکنون زمان ارزیابی گزینهها و بازنگری در نقشه راه ذخیرهسازی است.
نظر شما برای کامیونیتی فارسی چیست ؟ چه جایگزینی را پیشنهاد میدهید؟
عکس و ایده مقاله از این پست برداشته شده است :
https://www.linkedin.com/posts/purged0_devops-minio-opensource-activity-7402619963125055488-t7VA
تغییرات همیشه با اعلام رسمی شروع نمیشوند. گاهی تنها نشانه، یک کامیت ساده در گیتهاب است؛ تغییری کوچک که آینده یک اکوسیستم بزرگ را دگرگون میکند.
MinIO دقیقاً به همین شکل مسیرش را تغییر داد.
نه بیانیهای منتشر شد، نه توضیحی ارائه شد، تنها یک اصلاح در README:
❗️ کدبیس در حالت «Maintenance-only»
❗️ عدم پذیرش ویژگیها و Pull Requestهای جدید
❗️ بررسی رفع اشکالات امنیتی «بهصورت موردی»
و در کنار آن، دعوتی غیرمستقیم برای حرکت به سمت محصول تجاری:
👉 AIStor
این تصمیم، در عمل نشاندهنده یک کوچ آرام اما قطعی از مدل اوپنسورس به مدل تجاری است. تغییری که شاید بیسروصدا رخ داد، اما تأثیر آن بر زیرساخت بسیاری از سازمانها بسیار جدی خواهد بود.
✴️ پیامدهای این تغییر برای تیمهای فنی
پروژه محبوب MinIO برای سالها یکی از مهمترین انتخابها برای پیادهسازی S3-compatible storage در محیطهای production بود.
اما اکنون، هر تیمی که بر نسخه رایگان و پشتیبانی جامعه حساب کرده بود، در برابر واقعیتی جدید قرار دارد:
⚠️ توسعه متوقف شده است
⚠️ پایداری بلندمدت نامشخص است
⚠️امنیت تحت شرایط «case-by-case» قرار گرفته
بهعبارت دیگر، دوران MinIO بهعنوان یک گزینه پیشفرض، رایگان و قابل اتکا، عملاً پایان یافته است.
مسیر بعدی چیست؟
خوشبختانه امروز اکوسیستم ذخیرهسازی توزیعشده گزینههای قدرتمند و پختهای در اختیار دارد.
و حتی پروژههایی نوظهور که عملکردشان فراتر از حد انتظار است.
گزینههای جدی برای دوران پس از MinIO
🔹 RustFS
جایگزینی بسیار نزدیک، سریع و آیندهدار
در روزهای اخیر رشدی چشمگیر در فعالیت مخزن این پروژه مشاهده شده است. (برای مشاهده فعالیتها کلیک کنید.)
دلایل توجه بالای جامعه کاملاً روشن است:
🔰 سازگاری کامل با MinIO
🔰 اجرا روی همان پورتهای 9000
🔰عملکردی تا دو برابر سریعتر در بنچمارکهای اولیه
🔰کدنوشته شده با Rust؛ یعنی امنیت، سرعت و مصرف منابع بهینه
🔰جامعهای فعال که روند توسعه پرشتابی را نشان میدهد
این گزینه یعنی RustFS شاید تنها گزینهای باشد که مسیر مهاجرت از MinIO را تقریباً بدون تغییر در معماری امکانپذیر میکند.
🔹 SeaweedFS
راهکاری پخته و مناسب برای مقیاسهای بزرگ، با تمرکز بر سرعت، سادگی و توزیع مؤثر داده.
نکته: سال ۹۶ پستی را راجع به انتخاب یک فایلاستوریج که در آن Seaweedfs معرفی شده بود منتشر کردیم
🔹 Garage
انتخابی سبک و ساده برای محیطهای self-hosted و تیمهایی که به سادگی راهاندازی و نگهداری اهمیت میدهند.
🔹 Ceph
راهکاری جاافتاده برای بارهای کاری سنگین، با قابلیتهای گسترده اما پیچیدگی عملیاتی بالاتر.
تغییر مسیر MinIO شاید در ظاهر یک کامیت ساده باشد، اما برای بسیاری از تیمها یک نقطه تصمیمگیری استراتژیک خواهد بود.
اکنون زمان ارزیابی گزینهها و بازنگری در نقشه راه ذخیرهسازی است.
نظر شما برای کامیونیتی فارسی چیست ؟ چه جایگزینی را پیشنهاد میدهید؟
عکس و ایده مقاله از این پست برداشته شده است :
https://www.linkedin.com/posts/purged0_devops-minio-opensource-activity-7402619963125055488-t7VA
❤3👍3😱1
چرا Apache DataFusion در حال تبدیلشدن به «موتور پنهان» پلتفرمهای مدرن داده است؟
در اکوسیستم داده، هر ماه پروژههای کوچک و بزرگ زیادی متولد میشوند؛ اما تنها تعداد کمی از آنها مسیر بلوغ را طی میکنند، جامعهٔ فنی را با خود همراه میسازند و آنقدر ارزشمند میشوند که در معماری سیستمهای مختلف به عنوان یک «مولفه اصلی» دیده شوند.
این استقبال گسترده معمولاً یک پیام دارد: بازار دقیقاً به چنین ابزاری نیاز داشته است.
دیتافیوژن یک Query Engine ماژولار و بسیار سریع است که با Rust نوشته شده و بهطور بومی با Apache Arrow کار میکند. آنرا مشابه با DuckDB در نظر بگیرید که به سادگی اجازه اجرای SQL را روی انواع منابع داده به شما میدهد اما مهمتر از این، نقشی است که امروز در سیستمهای تولیدی و پروژههای جدید بازی میکند:
🔹دیتابیس InfluxDB v3 – بازنویسی کامل بر پایه FDAP (Flight + DataFusion + Arrow + Parquet)
دیتابیس InfluxDB برای نسخه ۳ تصمیم گرفت موتور Query خود را کنار بگذارد و همهچیز را بر اساس DataFusion بسازد.
نتیجه؟
✨ صدبرابر سرعت بیشتر روی کوئریهای با کاردینالیتی بالا
✨ ده برابر افزایش سرعت ingest
✨ ده برابر بهبود فشردهسازی
دیتافیوژن برای آنها تبدیل شد به زیرساختی که هم SQL را انجام میدهد، هم پردازش برداری، هم پردازش real-time روی دادههای در حافظه و فایلهای Parquet.
🔹دیتابیس جریانی RisingWave – استفاده از DataFusion برای Iceberg Compaction
پروژه RisingWave یک دیتابیس استریمی منطبق با استاندارد Postgres است. اما برای حل مشکل فایلهای کوچک در Iceberg، یک انجین فشرده سازی و تجمیع جدید با DataFusion ساخت.
نتایج فوقالعاده بود:
✨ ۵.۵ برابر سریعتر از Spark
✨ بدون سربار JVM
✨ مصرف حافظه بسیار کمتر
🔹 شتابدهندهٔ اسپارک: Apache DataFusion Comet
پروژه Comet که ابتدا در اپل توسعه داده شد، برنامه اجرای کوئریها در Spark را به DataFusion ترجمه میکند و بدون تغییر کد، Spark را ۲.۲ برابر سریعتر اجرا میکند.
رقبای آن مثل Photon یا RAPIDS معمولاً محدود به سختافزار خاص هستند؛ اما Comet روی سختافزار معمولی هم عملکرد چشمگیری ارائه میدهد.
🔹پروژه Ballista – اجرای توزیعشدهٔ DataFusion
بالیستا تلاش میکند نسخهٔ توزیعشدهٔ DataFusion باشد؛ یک موتور پردازش توزیعشده با معماری Arrow-native که ۵ تا ۱۰ برابر مصرف حافظهٔ کمتری نسبت به Spark دارد. دقیقا کاری که شرکت دیپسیک با DuckDB در قالب پروژه smallpond کرد و دنیا را به شگفتی واداشت.
🔹 پروژههایی که پشت صحنه از DataFusion استفاده میکنند
پروژههای GreptimeDB و HoraeDB (تایمسری) / OpenObserve / Cube Store / GlareDB / LakeSoul ParadeDB / Seafowl / Arroyo
و دهها پروژه کوچک و بزرگ دیگر…
🌟 چرا این همه استقبال؟
چون DataFusion عملاً دارد نقش LLVM برای دنیای دیتا را بازی میکند:
🔰 توسعهدهندگان لازم نیست موتور اجرای Query بسازند
🔰 مولفههای SQL، Optimizer، Vectorized Execution و… «از پیش آماده» است
🔰 ترکیب Rust + Arrow ترکیبی است که هم سریع است و هم ایمن
🔰 اجازه میدهد هر تیم فقط روی بخش ارزشافزای پروژه خود تمرکز کند
این همان چیزی است که موج جدیدی از سیستمهای تحلیلگر، دیتابیسها و موتورهای پردازشی را ممکن کرده است.
⚡️ جمعبندی
دیتافیوژن فقط یک Query Engine نیست؛
یک زیرساخت است.
پایهای که نسل بعدی پلتفرمهای داده روی آن ساخته میشود: از دیتابیسهای تایمسری گرفته تا موتورهای استریمینگ، و حتی شتابدهندههای Spark.
اکوسیستم داده به چنین پروژههایی نیاز دارد:
ماژولار، سریع، open-source، استانداردمحور، و قابل ادغام در هر سناریوی مدرن.
در اکوسیستم داده، هر ماه پروژههای کوچک و بزرگ زیادی متولد میشوند؛ اما تنها تعداد کمی از آنها مسیر بلوغ را طی میکنند، جامعهٔ فنی را با خود همراه میسازند و آنقدر ارزشمند میشوند که در معماری سیستمهای مختلف به عنوان یک «مولفه اصلی» دیده شوند.
این استقبال گسترده معمولاً یک پیام دارد: بازار دقیقاً به چنین ابزاری نیاز داشته است.
یکی از این پروژههای ارزشمند و «استخواندار» در بنیاد آپاچی، بدون شک Apache DataFusion است؛ موتوری که این روزها در گوشهوکنار ابزارهای پردازش داده حضور دارد: گاهی در قلب یک دیتابیس، گاهی در نقش شتابدهندهٔ یک Query Engine قدیمی، و گاهی به عنوان یک زیرساخت مخفی که کسی متوجه حضورش نیست.
دیتافیوژن یک Query Engine ماژولار و بسیار سریع است که با Rust نوشته شده و بهطور بومی با Apache Arrow کار میکند. آنرا مشابه با DuckDB در نظر بگیرید که به سادگی اجازه اجرای SQL را روی انواع منابع داده به شما میدهد اما مهمتر از این، نقشی است که امروز در سیستمهای تولیدی و پروژههای جدید بازی میکند:
🔹دیتابیس InfluxDB v3 – بازنویسی کامل بر پایه FDAP (Flight + DataFusion + Arrow + Parquet)
دیتابیس InfluxDB برای نسخه ۳ تصمیم گرفت موتور Query خود را کنار بگذارد و همهچیز را بر اساس DataFusion بسازد.
نتیجه؟
✨ صدبرابر سرعت بیشتر روی کوئریهای با کاردینالیتی بالا
✨ ده برابر افزایش سرعت ingest
✨ ده برابر بهبود فشردهسازی
دیتافیوژن برای آنها تبدیل شد به زیرساختی که هم SQL را انجام میدهد، هم پردازش برداری، هم پردازش real-time روی دادههای در حافظه و فایلهای Parquet.
🔹دیتابیس جریانی RisingWave – استفاده از DataFusion برای Iceberg Compaction
پروژه RisingWave یک دیتابیس استریمی منطبق با استاندارد Postgres است. اما برای حل مشکل فایلهای کوچک در Iceberg، یک انجین فشرده سازی و تجمیع جدید با DataFusion ساخت.
نتایج فوقالعاده بود:
✨ ۵.۵ برابر سریعتر از Spark
✨ بدون سربار JVM
✨ مصرف حافظه بسیار کمتر
🔹 شتابدهندهٔ اسپارک: Apache DataFusion Comet
پروژه Comet که ابتدا در اپل توسعه داده شد، برنامه اجرای کوئریها در Spark را به DataFusion ترجمه میکند و بدون تغییر کد، Spark را ۲.۲ برابر سریعتر اجرا میکند.
رقبای آن مثل Photon یا RAPIDS معمولاً محدود به سختافزار خاص هستند؛ اما Comet روی سختافزار معمولی هم عملکرد چشمگیری ارائه میدهد.
🔹پروژه Ballista – اجرای توزیعشدهٔ DataFusion
بالیستا تلاش میکند نسخهٔ توزیعشدهٔ DataFusion باشد؛ یک موتور پردازش توزیعشده با معماری Arrow-native که ۵ تا ۱۰ برابر مصرف حافظهٔ کمتری نسبت به Spark دارد. دقیقا کاری که شرکت دیپسیک با DuckDB در قالب پروژه smallpond کرد و دنیا را به شگفتی واداشت.
🔹 پروژههایی که پشت صحنه از DataFusion استفاده میکنند
پروژههای GreptimeDB و HoraeDB (تایمسری) / OpenObserve / Cube Store / GlareDB / LakeSoul ParadeDB / Seafowl / Arroyo
و دهها پروژه کوچک و بزرگ دیگر…
🌟 چرا این همه استقبال؟
چون DataFusion عملاً دارد نقش LLVM برای دنیای دیتا را بازی میکند:
🔰 توسعهدهندگان لازم نیست موتور اجرای Query بسازند
🔰 مولفههای SQL، Optimizer، Vectorized Execution و… «از پیش آماده» است
🔰 ترکیب Rust + Arrow ترکیبی است که هم سریع است و هم ایمن
🔰 اجازه میدهد هر تیم فقط روی بخش ارزشافزای پروژه خود تمرکز کند
این همان چیزی است که موج جدیدی از سیستمهای تحلیلگر، دیتابیسها و موتورهای پردازشی را ممکن کرده است.
⚡️ جمعبندی
دیتافیوژن فقط یک Query Engine نیست؛
یک زیرساخت است.
پایهای که نسل بعدی پلتفرمهای داده روی آن ساخته میشود: از دیتابیسهای تایمسری گرفته تا موتورهای استریمینگ، و حتی شتابدهندههای Spark.
اکوسیستم داده به چنین پروژههایی نیاز دارد:
ماژولار، سریع، open-source، استانداردمحور، و قابل ادغام در هر سناریوی مدرن.
👌1
معرفی کتاب «الگوهای طراحی ابری و معماری مایکروسرویس» - ترجمه دانیال خسروی
در دنیای مهندسی نرمافزار، بعضی کتابها فقط «خواندنی» نیستند؛
نقشهراهاند.
کتابهایی که وقتی وارد پروژههای واقعی میشوید، تازه میفهمید چرا باید زودتر آنها را میخواندید.
داستان این کتاب هم همین است.
چند سال پیش، در روزهایی که مباحث معماری ابری و سیستمهای توزیعشده با سرعت سرسامآور در حال تغییر بود، دانیال خسروی، مترجم آشنا برای بسیاری از ما، تصمیم گرفت منبعی بسازد که از جنس تجربه باشد، نه صرفاً ترجمه لغتبهلغت.
او پیشتر با ترجمه کتاب «مصاحبه طراحی سیستمهای نرمافزاری» نشان داده بود که چطور میتوان مفاهیم سنگین طراحی سیستم را قابلفهم و عملیاتی ارائه کرد.
این بار، سراغ دنیایی رفته که زیرساخت نرمافزارهای مدرن روی آن بنا میشود: الگوهای طراحی ابری.
🌩 این کتاب درباره چیست؟
اگر درگیر سیستمهای بزرگ، دادههای حجیم، مقیاسپذیری، یا معماری میکروسرویس هستید، این کتاب دقیقاً همان چیزی است که همیشه دنبالش بودید ولی یکجا پیدا نمیشد.
کتاب سه ستون اصلی معماری ابری را بررسی میکند:
🟦 ۱) مدیریت داده در فضای ابری
جایی که با مفاهیمی مثل Sharding، CQRS، Event Sourcing، Cache-Aside و… یاد میگیریم چطور داده را درست توزیع کنیم و همچنان انسجام حفظ شود.
🟨 ۲) الگوهای طراحی و پیادهسازی
از BFF تا Sidecar، از Gateway Routing تا Strangler Fig، اینها همان الگوهایی هستند که وقتی وارد یک پروژه enterprise واقعی میشوید، تفاوت «سرویس معمولی» و «سرویس قابلاعتماد» را میسازند.
🟩 ۳) الگوهای پیامرسانی
قلب تپنده سیستمهای توزیعشده: Saga، Pub/Sub، Priority Queue، Claim Check، Competing Consumers و دهها الگوی دیگر.
⭐️ چرا این کتاب ارزشمند است؟
چون برای مهندسینی نوشته شده که میخواهند سیستمهایی بسازند که زنده بمانند، رشد کنند و در لحظات بحران، فرو نریزند.
کتابی که از دل تجربه معماریهای واقعی آمده، نه از دل تئوریهای آزمایشگاهی.
و مهمتر از همه:
کاملاً رایگان منتشر شده است.
📥 لینک دانلود
📘 کتاب «الگوهای طراحی ابری و معماری مایکروسرویس»
از ریپازیتوری اصلی قابل دریافت است.
https://github.com/DannyRavi/cloud_software_farsi
دانلود مستقیم : https://github.com/DannyRavi/cloud_software_farsi/releases/download/1.0.4/cloud-microservices.pdf
📗 و اگر به کتاب قبلی مترجم علاقهمندید،
«مصاحبه طراحی سیستمهای نرمافزاری» را نیز میتوانید از این لینک دانلود کنید:
https://uploadb.com/ug7rgpcgrutx
آرزوی موفقیت برای دانیال عزیز و تمام دوستانی که دل در گرو رشد دانش این مرز و بوم دارند.
در دنیای مهندسی نرمافزار، بعضی کتابها فقط «خواندنی» نیستند؛
نقشهراهاند.
کتابهایی که وقتی وارد پروژههای واقعی میشوید، تازه میفهمید چرا باید زودتر آنها را میخواندید.
داستان این کتاب هم همین است.
چند سال پیش، در روزهایی که مباحث معماری ابری و سیستمهای توزیعشده با سرعت سرسامآور در حال تغییر بود، دانیال خسروی، مترجم آشنا برای بسیاری از ما، تصمیم گرفت منبعی بسازد که از جنس تجربه باشد، نه صرفاً ترجمه لغتبهلغت.
او پیشتر با ترجمه کتاب «مصاحبه طراحی سیستمهای نرمافزاری» نشان داده بود که چطور میتوان مفاهیم سنگین طراحی سیستم را قابلفهم و عملیاتی ارائه کرد.
این بار، سراغ دنیایی رفته که زیرساخت نرمافزارهای مدرن روی آن بنا میشود: الگوهای طراحی ابری.
🌩 این کتاب درباره چیست؟
اگر درگیر سیستمهای بزرگ، دادههای حجیم، مقیاسپذیری، یا معماری میکروسرویس هستید، این کتاب دقیقاً همان چیزی است که همیشه دنبالش بودید ولی یکجا پیدا نمیشد.
کتاب سه ستون اصلی معماری ابری را بررسی میکند:
🟦 ۱) مدیریت داده در فضای ابری
جایی که با مفاهیمی مثل Sharding، CQRS، Event Sourcing، Cache-Aside و… یاد میگیریم چطور داده را درست توزیع کنیم و همچنان انسجام حفظ شود.
🟨 ۲) الگوهای طراحی و پیادهسازی
از BFF تا Sidecar، از Gateway Routing تا Strangler Fig، اینها همان الگوهایی هستند که وقتی وارد یک پروژه enterprise واقعی میشوید، تفاوت «سرویس معمولی» و «سرویس قابلاعتماد» را میسازند.
🟩 ۳) الگوهای پیامرسانی
قلب تپنده سیستمهای توزیعشده: Saga، Pub/Sub، Priority Queue، Claim Check، Competing Consumers و دهها الگوی دیگر.
⭐️ چرا این کتاب ارزشمند است؟
چون برای مهندسینی نوشته شده که میخواهند سیستمهایی بسازند که زنده بمانند، رشد کنند و در لحظات بحران، فرو نریزند.
کتابی که از دل تجربه معماریهای واقعی آمده، نه از دل تئوریهای آزمایشگاهی.
و مهمتر از همه:
کاملاً رایگان منتشر شده است.
📥 لینک دانلود
📘 کتاب «الگوهای طراحی ابری و معماری مایکروسرویس»
از ریپازیتوری اصلی قابل دریافت است.
https://github.com/DannyRavi/cloud_software_farsi
دانلود مستقیم : https://github.com/DannyRavi/cloud_software_farsi/releases/download/1.0.4/cloud-microservices.pdf
📗 و اگر به کتاب قبلی مترجم علاقهمندید،
«مصاحبه طراحی سیستمهای نرمافزاری» را نیز میتوانید از این لینک دانلود کنید:
https://uploadb.com/ug7rgpcgrutx
آرزوی موفقیت برای دانیال عزیز و تمام دوستانی که دل در گرو رشد دانش این مرز و بوم دارند.
💯4