به نظرتون برای گرفتن پروژه ارتباطات تاثیر بیشتری داره یا مهارت؟

یه لاگ منیجر ساده و اوپن سورس برای C و ++C که باهاش میتونید لاگ هارو با فرمت دلخواه خودتون ثبت کنید و مشخص کنید کجا ذخیره بشن مثلا توی ترمینال باشه یا فایل💯

حتی میتونید با نوشتن Handler که خودتون تعریف کردید لاگ‌ها رو توی سرور، دیتابیس و... ذخیره کنید.

🎚 همچنین میتونید Log level خودتون رو هم بسازید.

🔗 https://github.com/qgdev-ir/qolman

#c #cpp #log_manager #repo
☕️ Telegram | Website | Discord | <Qoqnus>

😼 توی Github Universe امسال چخبره؟
ایونت سالانه GitHub Universe قراره 14 روز دیگه یعنی 28 و 29 اکتبر برگزار بشه. اگر راجبش نمیدونید مراسمیه که گیت هاب توش جدیدترین قابلیت ‌ها و ابزارهاش رو معرفی می‌کنه و درباره آینده توسعه نرم‌افزار صحبت میکنه.

بعضی از بخشای ایونت:
🔹 معرفی محصولات و قابلیت‌های جدید GitHub همراه با دمو
🔹 نمایش Workflowهای واقعی برای توسعه نرم‌افزار
🔹کارگاه‌های آموزشی تخصصی برای یادگیری مهارت‌هایی که میشه توی پروژه‌های واقعی استفاده کرد

🔗 منبع

#github_universe #event
☕️ Telegram | Website | Discord

اسکن سریع پورت با RustScan

برای پیدا کردن پورت‌های باز در شبکه‌ای که مسئولش هستی، ابزار RustScan مرحلهٔ کشف رو سریعتر پیش میبره؛ یک Port Scanner نوشته‌شده با Rust که نتایج رو برای بررسی بیشتر به Nmap میسپاره.

میتونید محدوده پورت‌ها، هم‌زمانی و Timeout را تنظیم کنید تا اسکن با ظرفیت شبکه هماهنگ باشد. برای بازبینی سرویس‌های در معرض دسترس و بررسی تنظیمات فایروال کاربردیه؛ فقط روی سیستم خودت یا با مجوز اجرا کن.

این پروژه کاملا با راست نوشته شده و مثل اینکه اومده تا رقیب NMAP بشه و تا الان 20k استارز هم گرفته!

لینک گیتهاب پروژه:
https://github.com/bee-san/RustScan


#rust #project
☕️ Telegram | Website | Discord

Ⓜ️ موجو بالاخره ورژن 1.0 رو منتشر کرد و اوپن سورس شد.
زبان برنامه‌نویسی Mojo که توسط شرکت Modular توسعه داده میشه، به نسخه 1.0 رسیده و کد کامپایلر این زبان هم بصورت اوپن سورس در دسترس قرار گرفته.

خب موجو اصلا چه قابلیتایی داره؟
- برای کسایی که با سیستم پایتون آشنایی دارن این زبان با پایتون سازگاره و از کتابخونه هایی مثل NumPy و Matplotlib میتونید توش استفاده کنید
- کامپایل شدنش به کد 0 و 1 باعث میشه توی کارایی که نیاز به سرعت بالا دارن بازدهی خوبی داشته باشه
- میشه باهاش کرنل های GPU و CPU رو هم نوشت

اما توی نسخه 1.0 چه تغییراتی داشته؟🔥
- سینتکس lambda مشابه پایتون اضافه شده تا بتونید Closureهای کوتاه رو راحت‌تر تعریف کنید.
- تعریف متغیرها با var استاندارد شده، روش‌های مختلف تعریف Closure یکپارچه شدن و حالا Mojo از یک نوع Pointer استفاده میکنه.
- سرور LSP پایدارتر شده تا تجربه کدنویسی توی VS Code یا کد ادیتور های دیگه بهتر بشه.
- توی تشخیص ارور های مموری هم بهتر شده و حالا بعضی مشکلات مثل نامعتبر شدن Reference بعد از تغییر یک List رو تشخیص میده.
- استفاده از where یکدست‌تر شده و ارورها هم واضح تر شدن
- ‏AI Skills هم اضافه شده تا ایجنت ‌ها بتونن توی نوشتن پروژه‌های Mojo، نوشتن کدهای GPU و کار با مدل‌های دیگه توی پلتفرم MAX کمک کنن.

🔗 منبع

کسی از شما اینجا با موجو کار کرده؟ تو کامنتا بنویسید💬

#mojo #news
☕️ Telegram | Website | Discord

😶🤦🏻‍♂

#fun
☕️ Telegram | Website | Discord

فرض کنید یه پروژه اوپن ‌سورس منتشر کردید و مرتب هم آپدیتش کردید و میخواید بدونید کدوم آپدیت پروژه باعث شده افراد بیشتری بیان و از ریپازیتوری استفاده کنن یا بهش استار بدن. یکی از راهای پر استفاده اینه که یه نمودار از استار هایی که به پروژه داده شده داشته باشید😃

🌟 ابزارایی مثل Star History این نمودار رو طراحی میکنن براتون. اما گرفتن اطلاعات موردنیازشون از API گیت‌هاب، مخصوصا برای ریپو های محبوب تر تا قبل از آپدیت شدن API گیت هاب ساده نبود. مثلا برای ساختن تاریخچه استار های ریپازیتوری React با حدود 251,000 استار به تقریبا 2,511 درخواست نیاز بود! چون API قدیمی اطلاعات رو به شکل صفحه ‌هایی شامل حداکثر 100 کاربر برمیگردوند و ابزارها باید زمان ثبت هر Star رو از اونجا میگرفتن.

این روش علاوه بر تعداد زیاد درخواست ها، دیتابیس رو هم سنگین میکرد. از طرفی، اطلاعات کاربرا در اختیار ابزارایی قرار میگرفت که اصلا به اون نیازی نداشتن. گیت ‌هاب برای حل این مشکل، API جدیدی طراحی کرده که به جای اطلاعات تک‌ تک کاربران، تعداد استار ها رو به تاریخ هر روز برمیگردونه و توی هر درخواست میتونه داده ‌های حداکثر 30 هفته رو ارائه بده.

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

توی روش جدید اول میاد بر اساس بازه زمانی فیلترشون میکنه و بعد تعداد استار ها رو حساب میکنه که باعث میشه دیتابیس بجای پردازش دوباره کل رکورد ها فقط رکورد های مربوط به بازه زمانی مورد نیاز رو بررسی کنه.

📉 نتیجه تست روی ریپازیتوری React که خود گیت هاب توی مقالش بهش اشاره کرده این بوده که برای برگردوندن تاریخچه کامل استارهای ریپازیتوری تعداد درخواستا از 2,511 به 24 رسیده و هر رکورد توی دریافت کل نتیجه، تقریبا یه بار بررسی شده.

💡 نکته ای که این موضوع داره اینه که باید بدونیم کم ‌کردن تعداد نتایج یه کوئری لزوما باعث سریعتر شدن اون نمیشه و مهمه که قبل از اجرای پردازش های سنگین، داده‌های غیر ضروری رو که بهشون نیازی نداریم فیلتر کنیم.

#github #star #news
☕️ Telegram | Website | Discord

کامپایلر Rust دست به ماشه منتظر خطای شما:


#fun
☕️ Telegram | Website | Discord