DevTwitter | توییت برنامه نویسی

فکر کنم این پیام برای خیلی‌هامون آشنا و البته رو مخ باشه! وسط کار و دیپلوی روی ریپو هستی که یهو ایمیل میاد: «۲۰۰۰ دقیقه رایگان GitHub Actions شما تموم شد!» حالا یا باید بی‌خیال پایپ‌لاین بشی تا ماه بعد ریست بشه، یا با کلی دردسر پرداخت ارزی انجام بدی، یا بری سراغ راه‌اندازی Self-hosted runner که خودش کلی کانفیگ و دردسرهای امنیتی و نگهداری داره. خلاصه این موضوع باعث شد dgrunner رو بسازم. حالا dgrunner چیکار می‌کنه؟ خیلی ساده و بی‌دردسر بهتون کمک می‌کنه رانرهای خودتون رو (بر پایه Docker / به صورت ایزوله و تمیز) بالا بیارید و بدون اینکه نگران محدودیت دقایق گیت‌هاب باشید، پایپ‌لاین‌های CI/CD رو روی سرور یا سیستم خودتون!! اجرا کنید. چرا سراغش برید؟ خداحافظی با محدودیت ۲۰۰۰ دقیقه Github Actions - راه‌اندازی فوق‌العاده سریع و سبک بدون درگیری با کانفیگ‌های پیچیده. - اجرای تمیز و ایزوله جاب‌ها - کاهش شدید هزینه‌های CI/CD برای تیم‌ها و پروژه‌های شخصی کلی وقت پاش گذاشتم تا یه چیز تر و تمیز دربیاد که کار بقیه رو هم راه بندازه. اگه شما هم با GitHub Actions کار می‌کنید، خوشحال میشم یه سر به ریپو بزنید، تستش کنید و اگه خوشتون اومد با یه Star به دیده شدن پروژه کمک کنید. دمتون گرم https://github.com/UpstandPlatform/dgrunner @DevTwitter | <Morteza/>

مایکروسافت، ابزار جدید، اُپن و رایگان sqlsimtools را با هدف تسهیل مهندسی و شبیه سازیِ «حجم کار[1]» مبتنی بر SQL Server، معرفی نمود. با استفاده از این ابزار، میتوان انواع آزمون های حجیم، سنگین، و پُرفشار را روی انواع حالات استقرار SQL Server اجرا کرد. این ابزار به چهار روش در اختیار مهندسان میباشد: - ابزار محاوره ای sqlsim Studio مختص کاربران ویندوز - ابزار خط فرمان بومی sqlsim CLI جهت کاربران ویندوز و لینوکس - ابزار خط فرمان اسکریپتی sqlpysim جهت توسعه دهندگان پایتون در تمامی پلتفرم ها - ابزار «هوشواره پسند[2]» Workload Bulder جهت کاربران Github Copilot قابل ذکر است این ابزار فعلا بصورت «پیش-نمایش عمومی[3]» در دسترس قراردارد و نسخه نهایی نیست. - خبر رسمی در بلاگ مایکروسافت: https://techcommunity.microsoft.com/blog/sqlserver/introducing-sqlsimtools/4563955 - سایت رسمی: https://microsoft.github.io/sqlsimtools/ - ریپوی رسمی در گیتهاب: https://github.com/microsoft/sqlsimtools @DevTwitter | <Arash Laylazi/>

اگر AI بتواند کد را ۱۲ برابر سریع‌تر تولید کند، آیا Git، Code Review و CI/CD ما هم برای چنین سرعتی آماده‌اند؟ مقاله جدید Anthropic درباره بازطراحی Source Control، یک نکته مهم دارد: در عصر AI، ممکن است دیگر نوشتن کد گلوگاه اصلی توسعه نرم‌افزار نباشد؛ بلکه زیرساختی باشد که قرار است این حجم از کد را مدیریت کند. اعداد جالب‌اند: - تعداد تغییرات Merge شده در روز، از حدود ۲٬۵۰۰ در ماه مه ۲۰۲۶ به بیش از ۳۰٬۰۰۰ در سپتامبر رسید. - آن‌ها برای پاسخ به این مقیاس، سیستم کنترل نسخه داخلی خودشان به نام Scion را ساختند و طی پنج ماه، مخزن اصلی را از Git به آن منتقل کردند. - نتیجه؟ زیرساختی با مصرف CPU و حافظه حدود ۲۰۰ برابر کمتر از زیرساخت قبلی Git Mirror ها و Checkout هایی که تا دو مرتبه بزرگی سریع‌تر شده‌اند. اما به نظرم مهم‌ترین بخش مقاله، خود Scion نیست؛ بلکه تغییر نگاه به مهندسی نرم‌افزار است. ۱. شاید دیگر هر Job به یک Checkout کامل نیاز نداشته باشد. ابزار Scion برای محیطی طراحی شده که Agentها و Jobها تقریباً همیشه آنلاین‌اند. به‌جای اینکه هر کلاینت یک مخزن کامل داشته باشد، بسیاری از عملیات از طریق API و روی سرور انجام می‌شوند. فایل‌ها هم فقط در صورت نیاز دریافت می‌شوند. ۲. فرایندهای ساخته‌شده برای انسان‌ها، لزوماً برای Agentها مناسب نیستند. وقتی صدها یا هزاران تغییر هم‌زمان تولید می‌شوند، مدل سنتی Merge Queue و انتظار برای اجرای تست‌ها ممکن است دیگر کافی نباشد. Anthropic به سمت تست‌های خودکار قبل از Deploy و بعد از Merge رفته است؛ حتی اگر بعضی تعارض‌ها پس از Merge آشکار شوند. ۳. نقش مهندس حذف نمی‌شود؛ تغییر می‌کند. یکی از بخش‌های تأمل‌برانگیز مقاله این است که مهندسان تیم، Claude را در نوشتن کد از خودشان بهتر می‌دانستند؛ اما همچنان مسئول تصمیم‌های معماری، محدودیت‌های سیستم و انتخاب Trade-offها بودند. حتی گاهی مهم‌ترین کارشان این بود که به AI بگویند «نه». چون AI ممکن است راه‌حلی تولید کند که در ظاهر درست است، اما یک محدودیت معماری را نقض می‌کند یا سیستم را بی‌دلیل پیچیده‌تر می‌سازد. ۴. باید Code Review هم تغییر کند. در این تیم، تمرکز Review به‌سمت بررسی Intent و هدف تغییر حرکت کرده، نه صرفاً خواندن تک‌تک خطوط کد. البته این به معنی حذف بررسی دقیق کد نیست؛ بلکه یعنی با افزایش حجم تغییرات، باید توجه انسانی را روی تصمیم‌ها و ریسک‌های مهم‌تر متمرکز کرد. به نظرم باید از این مقاله یک نتیجه مهم بگیریم: ما نمی‌توانیم فقط AI را به فرایند فعلی توسعه نرم‌افزار اضافه کنیم و انتظار داشته باشیم همه‌چیز به همان شکل قبلی کار کند. اگر تولید کد ارزان‌تر و سریع‌تر شود، گلوگاه‌ها به جاهای دیگری منتقل می‌شوند: معماری، تست، Code Review، کنترل دسترسی، زیرساخت و حتی نحوه Merge کردن تغییرات. البته خود Anthropic هم تأکید می‌کند که Scion جایگزین عمومی Git نیست؛ این سیستم برای مقیاس بسیار بزرگی از Monorepoها و Agentها طراحی شده است. مقاله کامل: https://www.anthropic.com/engineering/redesigning-source-control @DevTwitter | <Pooya Sabramooz/>

یه اپ برای مدیریت clipboard توی مک. دیگه با خیال راحت چندین چیز رو میشه کپی کرد و انتخاب کنی کدومش paste بشه. موارد مشابه از ۱۰ دلار تا ۱۰۰ دلار قیمتشونه. ممکنه ورژن متن باز هم باشه اما این نسخه رو من کاستومایز کردم. لینک گیتهاب:‌ https://github.com/sonatina-dream/copywren @DevTwitter | <Sonata/>

خب من دوباره کلی توکن کلاد سوزوندم تا مشکل اساسی فارسی‌نویسی رو توی ترمینال ویندوز حل کنم به‌نظرم این پروژه واقعاً کاربردیه، چون تا قبل از این عملاً امکان استفاده درست‌وحسابی از ترمینال‌های ویندوز نبود https://github.com/amiralimanzar/windowsterminal-rtl @DevTwitter | <Amir Ali Manzar/>

داشتم از روی کنجکاوی بررسی میکردم که چطور میشه جمع‌آوری و انتقال لاگ‌های لینوکس رو قابل‌ اعتمادتر کرد؛ اینکه اگر مقصد از دسترس خارج شد، داده‌ها چه وضعیتی پیدا میکنن و چطور میشه تحویلشون رو مدیریت کرد. همین کنجکاوی کم‌کم به دِئنا (daena) رسید؛ پروژه‌ای که تا الان نسخه‌ 0.2.0 پیاده‌سازی کردم. دِئنا لاگ‌ها رو از systemd journal میخونه، از یه پایپ لاین ماژولار برای پردازش، فیلتر و افزودن اطلاعات تکمیلی به رکوردها استفاده میکنه و قبل از ارسال، اونا رو با lmdb روی دیسک نگه میداره. بخش جذاب ماجرا برای من، مدل تحویل داده‌ هاس که هر مقصد (sink) وضعیت تحویل مستقل خودش رو داره؛ بنابراین اختلال یه مقصد لزوماً بقیه رو متوقف نمیکنه. ارسال مجدد با backoff مدیریت میشه و رکوردهای ناموفق هم از طریق dead-letter queue قابل بررسی و بازیابی هستن... معماری پروژه هم ماژولاره؛ سورس ها، پروسسورها و sink ها قابل توسعه‌ اند و میشه رکوردها رو به مقصدی مثل loki یا هر سرویس که روی http فرستاد. برای مدیریت و عیب‌یابی هم یه api روی grpc و یه cli پیاده کردم تا وضعیت سرویس، صف تحویل و رکوردهای ناموفق قابل بررسی باشن. برای من که این پروژه بیشتر از اینکه صرفاً یه ابزار جمع‌آوری لاگ به حساب بیاد، تجربه‌ ای برای فکر کردن به قابلیت اطمینان تو لایه‌ ایه که معمولاً بین تولید داده و زیرساخت مرکزی نادیده گرفته میشه. اگه دوست داشتین خوشحال میشم نگاهی بهش بندازید اگه مفید بود بهتون ایده بده یا ازش استفاده کنید. لینک سورس پروژه: https://src.panahifar.ir/ahp/daena @DevTwitter | <Amir Husayn Panahifar/>

❓امروزه علت و ریشه‌ی عدم ثبات و زودرنجی بازیکنان برزیلی چیه؟ ❓چرا انسان به کنش‌های منفی نسبت به کنش‌های مثبت اهمیت بیشتری میده؟ ❓آیا روشی هست تا تمرین و استمرار در یک کار، برای ما لذت‌بخش باقی بمونه؟

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

🆔 @footballaslife

مدیریت JWT در اندروید؛ Retrofit یا Ktor Client؟ در بررسی احراز هویت با JWT، یکی از نکاتی که برام جالب بود، تفاوت رویکرد Retrofit و Ktor Client در مدیریت توکن‌هاست. استفاده از Retrofit + OkHttp: برای پروژه‌های Native Android گزینه‌ای جاافتاده‌ست. با Interceptor و Authenticator می‌تونیم ارسال توکن و مدیریت پاسخ‌های 401 و فرایند Refresh رو پیاده‌سازی کنیم؛ البته بخش مهمی از این منطق به طراحی و کدنویسی خودمون نیاز داره. استفاده از Ktor Client: با پلاگین Auth و قابلیت Bearer Authentication، بخشی از این فرایند رو ساده‌تر می‌کنه. همچنین برای پروژه‌های Kotlin Multiplatform گزینه مناسبیه. البته در هر دو روش، ذخیره امن توکن‌ها، مدیریت خطاها و جلوگیری از Refresh هم‌زمان درخواست‌ها اهمیت زیادی داره. در نهایت، انتخاب منوط به نیاز پروژه‌ست؛ Retrofit برای Native Android اکوسیستم جاافتاده‌ای داره و Ktor هم با قابلیت‌های داخلی و پشتیبانی از Multiplatform انعطاف خوبی ارائه می‌ده. AndroidDevelopment Kotlin JWT Retrofit Ktor Authentication برنامه_نویسی اندروید برنامه_نویس_اندروید @DevTwitter | <Amir Hossein Jalili/>

آیا همیشه برای دریافت داده‌های ورودی به یک سرویس اختصاصی نیاز داریم ؟ معرفی RudderStack به‌عنوان مهندس داده، یکی از اولین قدم‌ها در ساخت یک خط پردازش داده، دریافت رویدادها از کلاینت‌های مختلف و انتقال سریع و قابل‌اعتماد آن‌ها به زیرساختی مثل Kafka است. بسیاری از تیم‌ها برای این کار سراغ توسعهٔ یک سرویس اختصاصی با زبان‌هایی مثل Go می‌روند؛ اما پیاده‌سازی و نگهداری SDKها، بافرگذاری، ارسال گروهی، تلاش مجدد و مقیاس‌پذیری، خودش به پروژه‌ای جداگانه تبدیل می‌شود. آیا واقعاً لازم است این بخش را از صفر بسازیم؟ معرفی RudderStack؛ درگاه ورود رویدادها به خطوط پردازش داده رادراستک (RudderStack) در اصل یک پلتفرم مدیریت داده‌های مشتریان (CDP) است که برای جمع‌آوری، پردازش و انتقال داده‌های رفتاری از وب‌سایت‌ها، اپلیکیشن‌ها و سرویس‌های مختلف به کار می‌رود. بخشی از این پلتفرم به‌صورت متن‌باز ارائه شده است. در این پست، مشخصاً Rudder Server را معرفی می‌کنیم؛ موتور سمت سرور این پلتفرم که وظیفهٔ پردازش و مسیریابی رویدادها را بر عهده دارد و می‌توان از آن به‌عنوان لایهٔ ورود رویدادها به خط پردازش داده، برای مثال پیش از Kafka، استفاده کرد. معماری پیشنهادی به کمک این ابزار، به شکل زیر خواهد بود : Client SDK → RudderStack → Kafka → Consumers → ClickHouse در این معماری، RudderStack رویدادها را از کلاینت‌های مختلف دریافت می‌کند و به Kafka تحویل می‌دهد. سپس مصرف‌کنندگان Kafka مسئول پردازش و تبدیل داده‌ها هستند و در نهایت، داده‌ها می‌توانند در ClickHouse ذخیره شوند. چه قابلیت‌هایی دارد؟ پشتیبانی از SDKهای متنوع: پشتیبانی از پلتفرم‌هایی مانند JavaScript، iOS، Android، React Native و Flutter و زبان‌هایی مثل Python، Go، Java، .NET و Rust. ارسال کارآمد: بافرگذاری و ارسال گروهی رویدادها برای کاهش سربار ارتباطات شبکه. اتصال به Kafka: پشتیبانی از ارسال گروهی پیام‌ها، فشرده‌سازی و قابلیت‌های مرتبط با قالب و اعتبارسنجی داده‌ها. مقیاس‌پذیری افقی: امکان اجرای چند نمونه پشت Load Balancer برای افزایش ظرفیت دریافت رویدادها. (هر چند نسخه رایگان آن تک نود هست اما می‌توان با اتخاذ راهکارهایی ، از چند نسخه آن پشت یک Load Balancer استفاده کرد) میزبانی مستقل: امکان استقرار نسخهٔ متن‌باز در زیرساخت خودمان. ️ چند نکتهٔ عملیاتی توان عملیاتی واقعی به سخت‌افزار، اندازهٔ رویدادها و تنظیمات وابسته است؛ بنابراین اعداد بنچمارک را باید در محیط خودمان آزمایش کنیم. همچنین اگر ترتیب رویدادهای هر کاربر اهمیت دارد، باید مسیریابی، رفتار مصرف‌کنندگان و کلید پارتیشن‌بندی Kafka را با دقت طراحی کنیم. اجرای چند نمونه به‌تنهایی تضمین‌کنندهٔ ترتیب رویدادها نیست. یک نکتهٔ تکمیلی اگر مسئلهٔ ما دریافت داده‌های تله‌متری، مانند لاگ، متریک و تریس است، OpenTelemetryCollector هم راهکار مهمی برای دریافت و انتقال این نوع داده‌هاست. اما برای رخدادهای محصول و کسب‌وکار، مانند کلیک کاربران، ثبت سفارش و فعالیت اپلیکیشن‌ها، RudderStack می‌تواند گزینه‌ای برای لایهٔ ورود رویدادها باشد. کد منبع: https://github.com/rudderlabs/rudder-server وب‌سایت: https://www.rudderstack.com/ @DevTwitter | <Mojtaba Banaie/>

سلام دوستان وقتتون بخیر امیدوارم سالم و سرحال باشین این پرسشنامه مربوط به یه کار تحقیقاتی در حوزه پت هست و نهایتاً ۴-۳ دقیقه وقت می‌بره پر کردنش؛ ممنون میشم اگر پت دارید پر کنین. در انتها هم اگر شماره‌تون رو وارد کنید یه هدیه ناقابلی برای خرید اقلام پت‌، تقدیم‌‌تون میشه 🙏🏻🌱

داری روی سرور جدیدت با ۵۱۲ هسته Nginx رو کانفیگ می‌کنی، همه‌چیز خوبه و خوشحالی که چه سرور خفنی داری بعد یهو nginx -s reload می‌زنی و کل سرویس‌ها از دسترس خارج می‌شن امروز موقع ریلیز یکی از پروژه‌ها متوجه شدیم که Nginx یه محدودیت کمتر شناخته‌شده داره: NGX_MAX_PROCESSES مستر برای Child Processها حداکثر 1024 تا Slot داره؛ یعنی Nginx نمی‌تونه بیشتر از این تعداد Process رو همزمان مدیریت کنه. البته این عدد کاملاً جدا از worker_connections هست که داخل nginx.conf تعیین می‌کنیم و مشخص می‌کنه هر Worker چند Connection می‌تونه داشته باشه. ضمن اینکه محدودیتی که اینجا راجع بهش صحبت می‌کنم از داخل nginx.conf قابل تغییر نیست و توی سورس Nginx تعریف شده. حالا اگه worker_processes auto داشته باشی، روی ۵۱۲ Core تقریباً ۵۱۲ تا Worker داری. موقع Reload هم Nginx اول Workerهای جدید رو بالا میاره و Workerهای قدیمی رو نگه می‌داره تا Connectionهای موجودشون تموم بشه. یعنی خیلی راحت می‌رسی به: 512 old workers + 512 new workers = 1024 حالا اگه فقط چند تا Worker از Reload قبلی هنوز Gracefully خارج نشده باشن، دیگه برای ساختن همه Workerهای جدید Slot کافی وجود نداره و اینجاست که فاجعه اتفاق می‌افته: no more than 1024 processes can be spawned روی سرورهای خیلی بزرگ، استفاده از worker_processes auto همیشه هم بهترین انتخاب نیست. پس بهتره همیشه حواسمون به کانفیگ‌هایی که در حالت auto میزان مصرف منابعشون رو بر اساس منابع موجود سرور انتخاب می‌کنن باشه؛ چون چیزی که روی یه سرور معمولی کاملاً منطقیه، روی یه سرور خیلی بزرگ ممکنه ما رو به یه Limit فاجعه‌بار برسونه @DevTwitter | <Mohammad Falahat/>

بزرگترین دیتابیس مواد غذایی فیگ‌فیت با ۱۵۰۰۰ ورودی رو به شکل رایگان منتشر کردیم: https://kaggle.com/datasets/amirparsadd/figfit-food-database خوشحال می‌شم ببینم چه چیزایی باهاش می‌سازید @DevTwitter | <Amirparsa Baghdadi/>

یک تیم کامل سه‌بعدی برای Blender متن‌باز شده؛ از طراحی کانسپت و مدل‌سازی گرفته تا انیمیشن، نورپردازی، دوربین و صدا، همه در قالب یک پلاگین! معرفی Scenario Plugin؛ ابزاری که می‌تونی مستقیم داخل Blender ازش استفاده کنی یا از طریق MCP به Claude Code وصلش کنی. قابلیت‌های این پلاگین: طراح کانسپت (Concept Artist) ساخت تصاویر کانسپت از روی پرامپت و استخراج تصاویر مرجع از نمای فعلی محیط Blender. هنرمند سه‌بعدی (3D Artist) ساخت Mesh از متن یا عکس و تغییر بافت یا بازسازی مش مدل انتخاب‌شده. انیماتور (Animator) ریگ کردن کاراکتر انتخاب‌شده و تولید حرکت از روی توضیحات متنی. هنرمند متریال (Surfacing Artist) اعمال متریال‌های PBR روی اسلات‌های مختلف و ساخت نقشه‌های متریال از روی عکس. طراح صحنه (Layout Artist) ساخت بلوک‌بندی اولیه صحنه (Greybox) از روی توضیحات و تولید محیط‌ها و آسمان‌های ۳۶۰ درجه. اپراتور دوربین (Camera Operator) تعریف مسیر حرکت دوربین با یک جمله و ایجاد حرکت‌هایی مثل Orbit، Dolly، Crane و Flyover. متخصص رندر (Render Artist) تبدیل نمای محیط به تصویر نهایی باکیفیت و تبدیل Playblast به شات نهایی. طراح صدا (Sound Designer) تولید موسیقی، صداگذاری و افکت‌های صوتی و انتقال آن‌ها به Sequencer پروژه. نکته جذاب اینجاست که می‌تونی این قابلیت‌ها رو از طریق Claude Code و MCP وارد جریان کاری خودت کنی؛ یعنی به‌جای انجام دستی تک‌تک مراحل، بخشی از فرایند ساخت صحنه و ویدیو رو با دستورهای متنی مدیریت کنی. البته برای استفاده واقعی، باید قابلیت‌های هر بخش، نیازمندی‌ها و محدودیت‌های پلاگین رو بررسی کنی. مخزن GitHub : https://github.com/scenario-labs/blender-plugin @DevTwitter | <Yarad/>

❓امروزه علت و ریشه‌ی عدم ثبات و زودرنجی بازیکنان برزیلی چیه؟ ❓چرا انسان به کنش‌های منفی نسبت به کنش‌های مثبت اهمیت بیشتری میده؟ ❓آیا روشی هست تا تمرین و استمرار در یک کار، برای ما لذت‌بخش باقی بمونه؟

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

🆔 @footballaslife

پونصد‌ میلیون توکن رایگان برای استفاده از مدل های زیر : DeepSeek V4 Qwen3.8-27B GLM-5.3 در سایت زیر : https://discovery.intern-ai.org.cn @DevTwitter | <Reza/>

حالا یک جایگزین رایگان و متن‌باز برای CapCut وجود دارد. بدون واترمارک، بدون نیاز به حساب کاربری و بدون اشتراک. ویرایشگر ویدیوی Concat برای ویندوز، macOS، لینوکس و اندروید است و بیشتر کارهایی را پوشش می‌دهد که مردم معمولاً برای آن‌ها سراغ CapCut می‌روند: - زیرنویس خودکار، که روی کامپیوتر خودتان تولید می‌شود - تبدیل متن به گفتار، به‌علاوه کلون کردن صدا با چند ثانیه صدای نمونه - حذف پس‌زمینه برای افراد و اشیا - انیمیشن keyframe با ویرایشگر منحنی (curve editor) - بیش از ۱۷۰ افکت، فیلتر، ترنزیشن و انیمیشن متن - ویرایش چندترکی و خروجی 4K همه‌چیز به‌صورت محلی اجرا می‌شود. مدل‌های هوش مصنوعی برای زیرنویس، صداها و برش پس‌زمینه یک‌بار دانلود می‌شوند و بعد آفلاین کار می‌کنند. فوتیج‌های شما هرگز از سیستم شما خارج نمی‌شوند. این نرم‌افزار در مرحله بتا است، پس انتظار چند نقص و ناهماهنگی را داشته باشید. لینک پروژه: github.com/jub0t/concat @DevTwitter | <Yarad/>

اولین پروژه‌ای که ترافیک واقعی گرفت، یه چیزی فهمیدم: فرق بین کدی که کار می‌کنه و کدی که scale می‌شه، زمین تا آسمونه. اینجا از این فرق‌ها زیاد حرف می‌زنیم. https://t.me/+HgGHhDZPg9tlNTU0

داشتم منابع مصاحبه مهندسی داده رو بررسی می‌کردم، گفتم چرا همه مطالبی که پیدا می‌کنم رو یک‌جا جمع نکنم. این شد یه سایت ساده که ۱۹۴ درس داره و ۲۸۰۰ سوال واقعی مصاحبه رو یک‌جا جمع کرده. محتوا دو زبانه (فارسی و انگلیسی) هست. اوپن‌سورس منتشرش کردم. اگه دوست داشتید می‌تونید استار بدید یا مشارکت کنید. https://github.com/mohammadmaso/dataeng-interview به نظر خودم مسیر مطالعاتی خوبی شد، هم برای آماده شدن برای مصاحبه و هم برای یادگیری کلی مهندسی داده. @DevTwitter | <Mohammad Masoudi/>

پروژه dbBackup_manager؛ ابزاری برای بکاپ و بازیابی دیتابیس PostgreSQL به‌تازگی اولین نسخه از پروژه‌ی dbBackup_manager رو منتشر کردم؛ یک ابزار با رابط کاربری تحت وب برای تهیه‌ی بکاپ و بازیابی دیتابیس‌های PostgreSQL به‌صورت محلی. امکانات فعلی: تهیه‌ی بکاپ از دیتابیس‌های PostgreSQL بازیابی دیتابیس از بکاپ‌های موجود رابط کاربری تحت وب ذخیره‌سازی محلی اطلاعات برنامه و فایل‌های بکاپ تکنولوژی‌ها: Java 21، Spring Boot و React سورس کد و دانلود نسخه‌ی انتشار https://github.com/arshiachillguy/dbBackup-manager @DevTwitter | <Arshia/>