🎶 میخواستم برای فان و بدون استفاده از AI و یا راهنمایی های موجود یه کلاینت SoundCloud با 🚀 بنویسم. پس Burp Suite عزیز رو باز کردم و شروع کردم به دیدن رکوئست هایی که داره ارسال و دریافت میشه. خبر خوب این بود که همه چیز به صورت api کار میکرد و نیازی به استفاده از چیزی مثل selenium نبود ولی توی تمام درخواست هایی که نیاز به احراز هویت داشت یه چیزی مشترک بود و اون چیزی نبود جز client_id. ولی یه نکته ای وجود داشت. توی هیچ کدوم از درخواست هایی که دریافت میشد چیزی نبود که بره client_id رو بگیره، پس احتمال دادم که client_id توی یکی از فایل های ,js مخفی شده. شروع کردم به باز کردن تک تک لینک های .js ای که توی html لود شده ی صفحه ی soundcloud.com وجود داشتن و بوم :)

چیزی که ما میخواستیم تو یکی از فایل های .js به دو صورت زیر مخفی شده بود.

"client_id=f1TFyuaI8LX1Ybd1zvQRX8GpsNYcQ3Y5" 
client_id:"f1TFyuaI8LX1Ybd1zvQRX8GpsNYcQ3Y5"

حالا وقتش بود که این فرایند رو اتوماتیک کنم. عید وقت خوبیه که اگه هنوز regex بلد نیستید، یاد بگیرید (وبسایت https://regexlearn.com/ و ریپو ی https://github.com/ziishaned/learn-regex که ترجمه فارسی هم داره و در نهایت ویدیوی https://www.youtube.com/watch?v=sXQxhojSdZM منابع خوبی برای یادگیری هستن).

سناریو ساده بود یه کد go بنویسم که بره محتوای soundcloud.com رو بگیره لینک های .js رو ازش استخراج کرده و شروع کنه توی فایل های جاوا اسکریپت با regex دنبال پترن client_id بگرده. می تونید کد رو از اینجا ببینید:

https://gist.github.com/mdpe-ir/709c3ca362fa0c2a30fa71e46ddd1f96

ولی بریم برای توضیح بخش های مهمش:

✔️ تابع fetchHTML:

func fetchHTML(url string) (string, error) {
    resp, err := http.Get(url)
    if err != nil {
        return "", fmt.Errorf("error fetching URL %s: %v", url, err)
    }
    defer resp.Body.Close()
    body, err := ioutil.ReadAll(resp.Body)
    return string(body), nil
}

این تابع یه درخواست HTTP GET به آدرس https://soundcloud.com/ می‌فرسته و کل محتوای HTML صفحه رو برمی‌گردونه.

نکته: اینجا defer resp.Body.Close() باعث می‌شه بعد از تموم شدن کار، اتصال بسته بشه تا منابع سیستم آزاد بشه.

✔️ استخراج لینک‌ها و کدهای جاوااسکریپت (extractJSSources)

این تابع HTML رو پارس می‌کنه و همه تگ‌های <noscript> رو پیدا می‌کنه. دو نوع جاوااسکریپت رو جدا می‌کنه: لینک‌های خارجی (با src) و کدهای داخلی (inline).
از پکیج golang.org/x/net/html برای پارس کردن HTML استفاده می‌کنه. لینک‌های نسبی رو با resolveURL به آدرس کامل تبدیل می‌کنه و فقط فایل‌هایی که به .js ختم می‌شن رو نگه می‌داره.

✔️ گرفتن محتوای فایل‌های جاوااسکریپت (fetchJSContent)

برای هر لینک .js که پیدا شده، یه درخواست HTTP می‌فرسته و محتوای فایل رو می‌گیره.

✔️ و در نهایت جستجوی client_id با Regex برای (findClientIDs)

پکیج regexp استفاده می‌کنه. دو الگو رو چک می‌کنه

برای فرمت پارامتری:

client_id=([A-Za-z0-9]{32})

برای فرمت object مانند:

client_id\s*:\s*["']([A-Za-z0-9]{32})["']

نکته: [A-Za-z0-9]{32} یعنی دنبال یه رشته ۳۲ کاراکتری از حروف و اعداد می‌گرده.

جمع‌بندی و نمایش نتیجه (main)

همه مراحل رو اجرا می‌کنه، client_idها رو جمع می‌کنه، تکراری‌ها رو حذف می‌کنه و چاپ می‌کنه.

توی تست هام متوجه شدم که هر client id حدودا ۷ روز معتبره. میشه یه cron job نوشت که طی یه مدت مشخص اجرا بشه و client id رو اپدیت کنه.

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

یه API داره که می‌تونیم با استفاده ازش یه خواننده رو جستجو کنیم. طبق درخواست‌ها تو Burp Suite یه endpoint سرچ چیزی شبیه اینه:

برای جستو در کاربران:

GET https://api-v2.soundcloud.com/search/users?q={query}&client_id={client_id}

برای جستجوی کلی :

GET https://api-v2.soundcloud.com/search?q={query}&client_id={client_id}

حالا فقط کافی بود برای گرفتن لیست موزیک های خواننده :

GET https://api-v2.soundcloud.com/users/{user_id}/tracks?client_id={client_id}

به عنوان مثال این اندپوینت لیست موزیک های Safir رو بر میگردونه:

https://api-v2.soundcloud.com/users/1016216608/tracks?client_id=f1TFyuaI8LX1Ybd1zvQRX8GpsNYcQ3Y5

حالا که این کار رو کردیم، می‌تونیم کلاینت رو گسترش بدیم، مثلاً یه رابط کاربری ساده باهاش بسازیم یا قابلیت دانلود ترک‌ها رو اضافه کنیم:)
---

مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

سلام سلام 💖

اول از همه 🎆🎆🎆🎆🎆. سالی پر از اتفاقات خوب و پر از Notification's واریزی💸 و از همه مهم تر حال خوب و سلامتی به همراه باگ 🪲 های کمتر براتون آرزو میکنم :)

امیدوارم وقتی آخر سال ۱۴۰۴ رسید به لیست کار هاتون که نگاه می کنید همه ی هدف هاتون رو تیک زده باشید ✅

تقریبا سه سال پیش بود که یه گروهی شیش نفره با دوستام داشتیم و خب هنوزم داریم و توی گروه مقالاتی که میخوندم و برام جالب بود رو مینوشتم بعد گفتم خب چرا براش یه کانال نزنم و عمومی ترش نکنم ؟ روزی که این کانال رو با هدف انتشار چیزایی که بلدم و میخونم زدم (۵ آذر ۱۴۰۱) اولین عضو های کانال بچه های همون گروه بودن و الان به لطف شما عزیزان و در کنارتون خانوادمون روز به روز بزرگتر شده و از همتون ممنونم ❤️

پ ن :
دوستان از چند روز قبل تذکر دادن با ۴۰۴ شوخی نکنم. منم گفتم حله با ۴۰۳ شوخی میکنم. توی ۴۰۳ همه چیز forbidden، پارتنر پیدا نکردم، ۴۰۴ هم که باهاش شوخی نمیکنیم ایشالا همین جمع ۴۰۵ .


ارادتمند شما
ماهان

---

امسال بیشتر از پارسال کنجکاو باشید :)

🆔 @MdDaily

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

تقسیم دنگ رو براتون انجام میده، خروجی اکسل ریز هزینه ها رو هم بهتون میده و میگه کی چه قدر باید به کی پرداخت کنه.

با js خام نوشته شده ، کد پروژه پیچیده نیست ولی کار سختیو راحت کرد :)

👩‍💻 سورس کد پروژه:

https://github.com/mdpe-ir/dongy

👩‍💻 نسخه ی دیپلوی شده:

https://dongy.mddaily.ir/

ایده های باحالی میشه روش پیاده کرد و تبدیلش کرد به PWA ولی خب فعلا داره کار میکنه.

🆔 @MdDaily

⭕️ سیزدهمین صبحانه کاری ابرها تهران

🔥 قهوه، صبحانه، ارائه و گفتگوی کاری در کنار متخصصین

🎤 ارائه‌ تجربه محور توسط مصطفی افزونی



👇👇👇
🔗 abrh.ir/enjoy 🔗
👆👆👆


در کانال ابرها عضو شوید: ✌️

📣@abrhacom

گنوم 48 با نام “Bengaluru” عرضه شده و این یکی از بزرگترین آپدیت های این میزکار دوس داشتنی حساب میشه.

تقریبا توی این چندین سالی که گنو لینوکس رو با میزکار گنوم به عنوان os اصلیم داشتم. توی این نسخه ی گنوم علاوه بر کلی فیچر باحالی که اضافه شده مثل:


- اعلان‌های مرتب‌تر: اعلان‌ها حالا به‌صورت گروهی نمایش داده میشن و مدیریتشون ساده‌تر شده.

- عملکرد بهتر: با dynamic triple buffering، انیمیشن‌ها روون و مصرف منابع کمتر شده و شاهد تجربه ی کاربری روون تری توی سیستم های ضعیف تر هستیم و همچنین لود پوشه‌ها توی Files تا ۵ برابر سریع‌تره!

- ویرایشگر تصویر جدید: برش، چرخش و زوم هوشمند به نمایشگر تصاویر اضافه شده.

- فونت‌های تازه: فونت قبلی Cantarell با Adwaita Sans جایگزین شده.

- سلامت باتری: گزینه جدید برای محدود کردن شارژ به ۸۰٪ و افزایش عمر باتری.

- پخش‌کننده جدید صوتی: اپلیکیشن مینیمال برای پخش فایل‌های صوتی با کنترل سرعت.

- تقویم هوشمند: پشتیبانی از منطقه زمانی برای رویدادها.

- و بالاخره پشتیبانی از HDR (High Dynamic Range): شروع پشتیبانی از نمایشگرهای HDR .


✔️ ولی جذاب ترین بخش این آپدیت اضافه شدن سلامت دیجیتال یا همون Digital Wellbeing به تنظیمات هست. (تصویر توی پست)

این قابلیت‌ طراحی شده تا به کاربرا کمک کنه عادت‌های سالمی موقع کار با کامپیوتر داشته باشن. شامل:

میزان استفاده از صفحه نمایش: می‌تونید ببینید هر روز چقدر پای صفحه نمایش وقت می‌گذرونید و این مقدار رو با روزها و هفته‌های قبل مقایسه کنید.

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

یادآور استراحت: می‌تونید برای خودتون یادآور تنظیم کنید تا طبق توصیه‌های استاندارد بهداشتی، مرتب به چشم‌هاتون استراحت بدید و کمی هم بلند شید و حرکت کنید.

---

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

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

🌐 https://mddaily.web.app

به پست های منتشر شده در این وبلاگ دسترسی پیدا کنید.

ولی یه مشکلی وجود داشت و اونم مدیریت وبلاگ استاتیک بود ، برای همین تصمیم گرفتم تا از نسخه ی بعدی وبلاگ کانال رو نمایی کنم و تشکر میکنم از تیم خوب kubarcloud 🟢 که اسپانسر زیر ساخت شدند.

اولین پست وبلاگ با عنوان "یادگیری Big O یک بار برای همیشه" منتشر شده که توی پست بعدی معرفیش میکنم :)

🌐 https://mddaily.ir/
---

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

یادگیری Big O یک بار برای همیشه

کاور پست با GPT تولید شده :)

توی این پست حالت های مختلفی از Big O به همراه کد نمونه بررسی شدن. از ساده ترین حالت یعنی O(n) شروع میکنیم و قدم به قدم تا حالت های پیجیده تری مثل O(n log n) رو بررسی میکنیم.

پیچیدگی زمانی Big O چیه؟
توی علم کامپیوتر، از علامت‌گذاری Big O استفاده می‌شه تا الگوریتم‌ها رو بر اساس اینکه زمان اجرا یا میزان حافظه مورد نیازشون با بزرگ‌تر شدن ورودی چطوری زیاد می‌شه، دسته‌بندی کنن. یا به عبارت دیگه، یه راهیه برای اینکه تحلیل کنیم چقدر زمان می‌بره تا الگوریتم ما با بزرگ‌تر شدن ورودی اجرا بشه. منظور از ‘O’ کل عملیاته، و ‘n’ هم ورودی.

بیاین چند تا مثال رو ببینیم تا قضیه روشن‌تر بشه.

حالت O(n)
شاید ساده‌ترین مثالی که بشه فهمید، همون O(n) باشه، جایی که نرخ رشد خطیه.

یه آرایه نامرتب n رو در نظر بگیرین، یه تابعی بنویسین که بزرگترین مقدار رو برگردو...

لینک کامل مقاله در وبلاگ Mddaily:

🔗 https://mddaily.ir/یادگیری-big-o-یک-بار-برای-همیشه/

---

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

🤔 شاید جا های مختلفی مثل ویدیو های یوتیوب Vibe Coding رو دیده باشید ولی Vibe Coding چیه؟

این یه روش فکر جدیده برای ساختن نرم‌افزار با کمک هوش مصنوعی. این اصطلاح رو آندری کارپاتی (Andrej Karpathy) ساخته و «وایب کدینگ» رو اینجوری توصیف می‌کنه: «خودت رو بسپر به حس و حالت، پذیرای رشد نمایی باش، و اصلاً یادت بره که کدی هم وجود داره».

اما خود Andrej Karpathy کیه؟

رزومه ی کامل و پروژه هاشو میتونید از وبسایت خودش karpathy.ai ببینید ولی به طور خلاصه جزو موسس ها و بخش تحقیقاتی OpenAI بوده بعد به عنوان مدیر ارشد هوش مصنوعی میره تسلا و بعد از چند سال مجدد بر میگرده به OpenAI.

کارپاتی از یه دستیار کدنویسی هوش مصنوعی استفاده می‌کنه و فلسفه‌اش اینه که «همه چیز رو قبول کن». اون فرض می‌کنه که این دستیار هوش مصنوعی، نرم‌افزاری که داره می‌سازه رو هم می‌نویسه و هم مشکلاتش رو حل می‌کنه.

با اینکه این روش کدنویسی خیلی وسوسه‌انگیزه، ولی آیا با توجه به محدودیت‌های فعلی مدل‌های زبانی بزرگ (LLM) و این اوضاعی که همه‌چیز داره تغییر می‌کنه، نتیجه‌اش به اندازه کافی دقیق هست؟ می‌شه با وایب کدینگ یه اپلیکیشن کامل رو بدون مشکل بالا آورد؟ می‌شه ازش خواست که تست‌ها رو هم بنویسه؟ با ناهماهنگی‌ها توی طراحی چیکار می‌کنه؟ این فقط یه چیز زودگذره (فَد fad) یا یه استراتژی بلندمدت واقعیه که برنامه‌نویس‌ها باید یاد بگیرن و ازش استفاده کنن؟

اکه علاقه داشتید:

📱 پست Andrej در X:

https://x.com/karpathy/status/1886192184808149383

📱 ویدیوی یوتیوب Fireship:

https://www.youtube.com/watch?v=Tw18-4U7mts

🌐 مقاله What I Learned from Vibe Coding:

https://dev.to/erikch/what-i-learned-vibe-coding-30em


---

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

قسمت اول

داشتم رایتاپ I Thought It Was a Safe Deploy… Until Checkout Disappeared رو میخوندم نکات جالبی توش داشت. طرف مسئول بخش payments بوده. شروع میکنه به استقرار نسخه ی جدید. تست ها گرفته شده بوده و روی محیط Dev همه چی اوکی به نظر می‌رسید. همه چیز آروم بوده تا اینکه Slack اشون پر شده بود از پیام های: «صفحه چک‌اوت لود نمی‌شه.»، «صفحه سفیده هیچی نمیاد.» ، «اپل پِی (Apple Pay) کار نمی‌کنه.».

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

دقیقا چیشده بود؟

بخش payments از اون جاهاست که وقتی همه چی مرتب و درست کار می‌کنه، خیلی ساکت و آروم اون پشت‌صحنه به کارش ادامه می‌ده... اما وای به روزی که یه جای کارش بلنگه و یه چیزی خراب بشه؛ اونوقته که تبدیل به یه هرج و مرج می‌شه.
چند وقت پیش SDK مربوط به Apple Pay رو آپدیت کرده بودند چون نسخه‌ای که داشتن استفاده می‌کردن، دیگه توسط خود تیم اپل پشتیبانی نمی‌شد و منسوخ شده بود. نسخه‌ی جدید هم یه سری تغییرات توی API contract داشت—که بیشترش مربوط به این بود که موقع شروع کار و مقداردهی اولیه ورودی‌ها چطوری باید بهش داده بشن. اینا هم تغییرات لازم رو انجام داده بودن، همه چی رو روی محیط توسعه تست شده بود و به نظر می‌رسید همه چی ردیفه. یه مدت میگذره و میبینن هشدار های تعداد خطاهای مربوط به Apple Pay یهو خیلی بالا رفته. فهمیدن که اون SDK آپدیت‌شده، به یه تابع خاص وابسته بود که توی بعضی از مرورگرهای قدیمی‌تر پشتیبانی نمی‌شد. نتیجه‌اش این بود که همون اولِ فرآیند پرداخت، یه خطای زمان اجرا اتفاق می‌افتاد؛ یعنی انقدر زود این خطا رخ می‌داد که کلاً کل تجربه‌ی چک‌اوت رو از کار می‌نداخت. نه دیگه خبری از Apple Pay بود. نه هیچ روش پرداخت دیگه‌ای کار می‌کرد. فقط یه صفحه‌ی سفیدِ خالی جلو چشم کاربر بود.

⚠️ اول از همه: با دیباگ کردن شروع نکنید!

قبل از اینکه وارد جزئیات بشیم، یه درس خیلی مهم هست:

وقتی با یه مشکل جدی و قطعی (outage) تو محیط پروداکشن روبرو می‌شین، اولین غریزه‌تون نباید این باشه که بپرین سراغ دیباگ کردن.

چون وقتی پای کد شما وسطه، مغزتون اتوماتیک می‌ره تو این فاز که:
«خب، باگ کجاست؟ چی خراب شده؟ باید زود پیداش کنم و درستش کنم.»

ولی نکته اینجاست: دیباگ کردن زمان‌بره.

و در تمام مدتی که شما دارین لاگ‌ها رو زیر و رو می‌کنین و فرضیه‌های مختلف رو تست می‌کنین، کاربرهای واقعی اون بیرون گیر افتادن و نمی‌تونن کارشون رو انجام بدن.
درآمد شرکت داره کم می‌شه و از همه مهم‌تر، کاربرها دارن یه تجربه‌ی خیلی بد رو از سر می‌گذرونن.

مگه اینکه دقیقاً بدونین مشکل چیه و صددرصد مطمئن باشین که راه حلش امنه و می‌شه خیلی سریع دیپلوی‌اش کرد، وگرنه بهترین و عاقلانه‌ترین کار اینه:

کامیتی که باعث مشکل شده رو برگردونین عقب (Revert). کد قبلی رو دوباره دیپلوی کنین (Redeploy). اوضاع رو پایدار کنین.

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

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

—-

⬅️ ادامه در قسمت بعدی

💡 تا قسمت بعدی مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

قسمت دوم (پایانی)

بعد از تلاش برای باز تولید مشکل هیچ پیغام خطا یا کرش واضحی وجود نداشته. stack trace مشخصی هم روی صفحه دیده نمی‌شده. فقط سکوت محض تا لحظه پیدا شدن یه خطای runtime error که از لایه‌های عمیق اون SDK آپدیت‌شده‌ی Apple Pay سرچشمه می‌گرفت.داشته سعی می‌کرده از یه method خاص استفاده کنه که توی محیط بعضی از مرورگرهای قدیمی‌تر اصلاً پشتیبانی نمی‌شده. نکتش اینجاس که Apple Pay فقط روی سافاری کار می‌کنه پس این خطا فقط روی نسخه های قدیمی سافاری خودشو نشون میداده. SDK موقع بالا اومدن و مقداردهی اولیه از یه تابع استفاده می کرده که باعث کرش می‌شده. نه فقط برای خود Apple Pay، بلکه برای همه چی! از همون باگ‌های موذی که موقع توسعه از زیر دست در میره و دیده نمی‌شه.

فقط درست کردن باگ مهم نیست؛ بحث سرِ قبول مسئولیت کاره

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

- این خرابی و قطعی، واقعاً چه معنی و تجربه‌ای برای کاربر داشت؟

- این قطعی چقدر برای کل کسب‌وکار هزینه برداشت؟

- آیا می‌شد این مشکل رو زودتر تشخیصش داد؟

- ممکنه دوباره همچین اتفاقی بیفته؟

ما اینجا نیستیم که فقط مثل ربات به آلارم‌ها واکنش نشون بدیم و کدها رو سرسری وصله‌پینه کنیم و ما کدنویس‌هایی نیستیم که بشه مثل ChatGPT بهمون پرامپت داد و انتظار داشت مشکل غیب بشه. اینجاییم که عمیق فکر کنیم، مسئولیت کامل نتایج کارهامون رو به عهده بگیریم و فعالانه جلوی آسیب‌های آینده رو بگیریم.

پس برای مستند کردن چه چیز هایی رو میتونیم بنویسیم؟

- چی رو تغییر داده بودیم

- اصلاً چرا تغییرش داده بودیم

- چی و کجا خراب شد

- چطور شد که این مشکل از زیر دست تیم QA در رفت و دیده نشد

- چه چیزهایی توی monitoring ما از قلم افتاده بود که زودتر نفهمیدیم

این کار رو نه به خاطر اینکه کسی خواسته انجام بدیم، بلکه به این دلیل انجام بدیم که شاید خودِ آینده (یا یکی از هم‌تیمی‌های آینده‌) به مشکل مشابهی بر بخوره و اون‌ها بتونن خیلی سریع‌تر به جواب و راه حل برسن.

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

جمع‌بندی و حرف آخر

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

ولی خب، آدم یاد می‌گیره.

یاد می‌گیری که «قبول کردن کامل مسئولیت» واقعاً یعنی چی.

یاد می‌گیری که چطور یه قدم بری عقب‌تر و دید وسیع‌تری پیدا کنی (zoom out کنی)؛ دیگه فقط به این فکر نکنی که «چی خراب شد؟»، بلکه بری سراغ اینکه «این خرابی روی چه کسایی تأثیر گذاشت؟».

یاد می‌گیری که یه مهندس خوب بودن، به معنی نوشتن کدِ بی‌عیب‌ونقص و عالی نیست؛ بلکه به اینه که چطور بحران رو مدیریت می‌کنی، وقتی که اوضاع اصلاً خوب و عالی نیست.

یه چک‌لیست برای وقتی که این اتفاق برای شما میفته:

- سریع نپرین سراغ دیباگ کردن: اگه مشکل جدیه و روی کاربرها تأثیر مستقیم گذاشته، اولین قدم اینه که کد رو برگردونین به نسخه‌ی قبلی. بعدش با خیال راحت‌تر برین دنبال دلیل مشکل بگردین.

- زود و شفاف اطلاع‌رسانی کنین: حتی یه پیام کوتاه مثل «دوستان دارم بررسی می‌کنم» توی کانال‌های ارتباطی خیلی تأثیر مثبتی داره و به آروم شدن فضا کمک می‌کنه.

- سعی کنین مشکل رو توی محیط‌های کنترل‌شده و ایزوله باز تولید کنین: یعنی دقیقاً با همون شرایطی که مشکل پیش اومده (مثلاً همون مرورگر، همون نسخه و ...).

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

- آستانه‌ی هشدارهای سیستم پایش و مانیتورینگ رو دوباره یه نگاهی بندازین: آیا واقعاً جوری تنظیم شدن که خرابی‌های کوچیک، نامحسوس یا تدریجی رو هم زود تشخیص بدن؟

- اتفاقی که افتاده رو با زبون ساده و واضح مستند کنین: این کار رو فقط برای بقیه اعضای تیم انجام ندین، بلکه برای خودتون در آینده هم انجام بدین. حافظه یاری نمی‌کنه!

- به تأثیر مشکل روی کسب‌وکار (business impact) فکر کنین: حدوداً چند تا کاربر تحت تأثیر قرار گرفتن؟ و این مشکل برای چه مدت زمانی ادامه داشت؟

- اگه در حین بررسی، به الگوها یا نکته‌های کلیدی رسیدین، حتماً یادداشتشون کنین: این نکته‌ها برای بحران بعدی فوق‌العاده ارزشمندن.

—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

داشتم یه ویدیو تو یوتیوب تحت عنوان What Happens When a Program Calls Sleeps میدیدم که خیلی جالب بود اگه تا حالا از تابع sleep توی برنامه‌نویسی استفاده کردید، شاید براتون سوال شده که چرا اسمش «sleep» هست و نه مثلاً «wait» یا «delay»؟ این ویدیو یه سفر جذاب به پشت صحنه‌ی این تابع ساده‌ست که پر از نکات سخت‌افزاری و نرم‌افزاریه. این تابع تقریباً توی همه زبان‌های برنامه‌نویسی هست (تو جاوااسکریپت داستانش فرق داره).

اولین چیزی که ویدیو بهش می‌پردازه، اینه که تابع sleep چطور توی دنیای واقعی کار می‌کنه. می‌ره سراغ سخت‌افزار و نشون می‌ده که چطور با استفاده از فلیپ‌فلاپ‌ها (یه جور مدار الکترونیکی که مثل سلول‌های حافظه کار می‌کنن) می‌شه یه تایمر ساخت.

این تایمرها توی سی‌پی‌یو مثل یه ساعت شنی دیجیتال عمل می‌کنن: یه عدد اولیه می‌گیرن و با هر تیک ساعت، شمارش معکوس می‌کنن تا به صفر برسن. وقتی یه برنامه sleep رو صدا می‌زنه، سیستم‌عامل با یه system call این تایمر رو تنظیم می‌کنه و وقتی تایمر به صفر رسید، با یه interrupt برنامه رو بیدار می‌کنه.

ولی یه چالش بزرگ وجود داره: تعداد تایمرهای سخت‌افزاری توی یه چیپ محدوده. مثلاً اگه فقط دو تا تایمر داشته باشیم و سه تا برنامه بخوان sleep کنن، یکی باید منتظر بمونه! اینجا نرم‌افزار وارد بازی می‌شه. ویدیو توضیح می‌ده که چطور سیستم‌عامل با یه تکنیک هوشمندانه، فقط با یه تایمر می‌تونه چندین برنامه رو مدیریت کنه. برنامه‌هایی که sleep صدا می‌زنن، توی یه «صف خواب» می‌رن و سیستم‌عامل با یه تایمر و یه سری محاسبات، مطمئن می‌شه که هر کدوم سر وقت بیدار بشن.

بعدش، ویدیو یه روش قدیمی‌تر به اسم busy waiting رو بررسی می‌کنه که توی اون، برنامه با یه حلقه‌ی بی‌فایده، پردازنده رو مشغول نگه می‌داشت تا زمان بگذره. این روش نه تنها دقت پایینی داره (چون به سرعت پردازنده و نوع دستورات بستگی داره)، بلکه کلی از منابع سیستم رو هدر می‌ده و حتی می‌تونه سیستم رو قفل کنه! خوشبختانه، سیستم‌عامل‌های مدرن با استفاده از برنامه‌ریزی پردازنده (CPU scheduling) این مشکل رو حل کردن. وقتی برنامه sleep رو صدا می‌زنه، عملاً به سیستم‌عامل می‌گه: «من برای یه مدت نمی‌خوام پردازنده رو اشغال کنم، بذار بقیه کار کنن.»

یه نکته‌ی جالب دیگه اینه که دقت sleep همیشه ۱۰۰٪ نیست. چون بعد از بیدار شدن، برنامه می‌ره توی صف آماده و اگه سیستم شلوغ باشه، ممکنه یه کم بیشتر منتظر بمونه. برای همین، وقتی از sleep استفاده می‌کنید، زمان داده‌شده یه حداقل تضمین‌شده‌ست، نه یه عدد دقیق. این موضوع توی سیستم‌های عمومی (غیر real-time) کاملاً عادیه و ویدیو خیلی خوب توضیح می‌ده که چرا نباید انتظار دقت میکروثانیه‌ای داشته باشیم.

در نهایت، ویدیو به این می‌رسه که چرا اسم این تابع «sleep» هست. «wait» می‌تونه گنگ باشه و به هر نوع انتظاری اشاره کنه (مثل busy waiting)، ولی «sleep» یعنی برنامه کاملاً غیرفعال می‌شه، منابع رو آزاد می‌کنه و مثل وقتی که ما می‌خوابیم، منتظر می‌مونه تا بیدار بشه. این اسم حسابی به ماهیت این تابع می‌خوره!

اگه کنجکاو شدید که جزئیات بیشتری درباره‌ی این موضوع بدونید، این ویدیو پر از توضیحات باحال و انیمیشن‌های جذابه که مفاهیم پیچیده رو ساده می‌کنه. حتماً یه سر بزنید و خودتون ببینید:

📹 https://www.youtube.com/watch?v=e5g8eYKEhMw


—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

در حال گشت‌زنی توی ❤️ ردیت به پروژه‌ی GoXray برخوردم. با توجه به اینکه Nekoray دیگه به‌روزرسانی نمی‌شه و توی لینوکس برای تونل کردن کل سیستم مشکل داشتم، این پروژه با پیاده‌سازی کامل قابلیت‌های XRay تو Go این مشکل رو برطرف کرده. هم نسخه‌ی GUI داره که با Fyne توسعه داده شده، هم نسخه‌ی CLI که اگه دنبال یه ابزار سبک و سریع هستید، به نظرم گزینه‌ی عالی‌ایه. برای لینوکس و مک هم نسخه‌های مخصوص داره.

گیت هاب پروژه:
👩‍💻 https://github.com/goxray

برای استفاده از نسخه ی CLI اش توی لینوکس فقط کافیه اخرین نسخه رو از https://github.com/goxray/tun/releases بگیرید و بعد:

1- اول دسترسی اجرا به فایلش بدید:

chmod +x goxray_cli_linux_amd64

و برای اتصال :

sudo ./goxray_cli_linux_amd64 "YOUR CONFIG"

و برای قطع اتصال هم فقط CTRL+C رو بزنید :)

—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

چند وقت پیش یه خبری ترند شد که یه نفر اومده بود توی فایل PDF بازی DOOM و گنو لینوکس رو اجرا کرده بود و جادی هم توی این پست https://news.1rj.ru/str/jadivarlog/250 بهش پرداخت. حالا یه نفر اومده یه پروژهٔ پروف آف کانپست زده که نشون بده چطوری یه مدل زبانی بزرگ کامل رو فقط و فقط توی یه فایل PDF میشه اجرا کرد.

این پروژه از Emnoscripten استفاده می‌کنه تا llama.cpp رو به asm.js کامپایل کنه. بعدش این کد asm.js رو با یه روش قدیمی تزریق جاوااسکریپت به PDF، توی فایل PDF اجرا می‌کنه با استفاده از قابلیت اجرای جاوااسکریپت در PDFها (که اول برای تکمیل خودکار فرم‌ها بود). با این روش و با جاسازی (embedding) کل فایل LLM به صورت base64 توی PDF، موفق شده کاری کنه که inference مدل LLM فقط با داشتن یه فایل PDF ممکن بشه.


نکات مهم:

فقط مدل‌های GGUF پشتیبانی میشن.

مدل‌های Q8 سریع‌تر اجرا میشن.

مدل‌های کوچک‌تر (مثلاً 135M پارامتر) عملکرد بهتری دارند (حدود ۵ ثانیه برای هر توکن).


👩‍💻 ریپوی پروژه:

https://github.com/evanzhoudev/llm.pdf

📹 ویدیوی یوتیوب:

https://www.youtube.com/watch?v=4cBom2lAx-g&feature=youtu.be

🌐 دمو:

https://evanzhoudev.github.io/llm.pdf/

—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

قسمت اول

داشتم یه مقاله میخوندم عنوانش جالب بود XYZ% of Code is Now Written by AI... Who Care. میگه فکر کن XYZ درصد کُدها رو دیگه هوش مصنوعی می‌نویسه... خب که چی؟

ساتیا نادلا، مدیرعامل مایکروسافت، گفته که «تا ۳۰ درصد کدهای شرکت رو الان دیگه هوش مصنوعی می‌نویسه» (این رو تو آوریل ۲۰۲۵ گفته).

مدیرعامل شرکت Anthropic هم پیش‌بینی کرده که «تا ۱۲ ماه دیگه، ممکنه تو دنیایی باشیم که تقریباً همه کدها رو هوش مصنوعی بنویسه» (اینم مال مارس ۲۰۲۵ هست).

اینجور تیترها یه حسی میده که انگار این عددِ XYZ یه جوری به «نرخ جایگزینی مهندس‌های نرم‌افزار» اشاره داره. یعنی کدی که هوش مصنوعی نوشته، کدیه که آدما ننوشتن، پس دیگه نیازی به اون ۳۰ درصد آدمی که بشینن پای کیبورد نداریم. با این همه سروصدایی که رسانه‌ها برای جلب توجه مخاطب راه میندازن و دنبال هیجان‌انگیز کردن ماجرا هستن، بعید نمی‌دونم که بخوان قضیه رو دراماتیک‌تر هم بکنن...

راستش اینجور گمانه‌زنی‌ها جالبه (مثلاً اینکه این مدیرعامل‌ها چطوری این آمار رو درمیارن)، ولی خیلی معنی خاصی نداره، جز اینکه بخوایم ببینیم ابزارهای کدنویسی با هوش مصنوعی چقدر سریع دارن جا میفتن و استفاده میشن...

خب، حالا یه جور دیگه به قضیه نگاه کنیم: ۱۰۰٪ کدها رو هوش مصنوعی می‌نویسه، ولی ۷۰٪ همین کدها بعد از بازبینی پاک میشه!

نویسنده ی مقاله مثال جالبی میزنه میگه میخواسته با MCP و پایتون یه پروژه ی Code Interpreter بسازه و ایده اصلی این بود که یه مفسر پایتون سفارشی، ایزوله و داخلی رو که کتابخونه smolagents از HuggingFace ارائه میده، برداره و توی یه سرور MCP مستقرش کنه.

بعد از اینکه ریپو smolagents رو کلون کرده کدهاش رو یه نگاهی انداخته و یه مثال کوچیک از استفاده جداگونه از مفسرش ساخته، به ایجنتِ Cursor دستور داده که یه پروژه MCP Server جدید براش بسازه. اون مثال رو بهش نشون داده، کد خود مفسر رو هم داده بهش و یه لینک از مستندات MCP Server که شرکت Anthropic نوشته بود هم بهش داده. ایجنت هم یه کدبیس کامل و تر و تمیز، بدون هیچ اخطار لینتری بهش تحویلم داده.

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

حالا سوال اینجاست: می‌تونیم بگم ۱۰۰٪ کدها رو هوش مصنوعی تولید کرده؟ احتمالاً آره. ولی آیا این به این معنیه که:

اصلاً تو فرآیند ساخت نرم‌افزار نیروی انسانی لازم نبود؟

یا اینکه بهره‌وری ۳۰۰ برابر شده، چون یه آدم معمولی می‌تونه مثلاً ۳۰ کلمه در دقیقه تایپ کنه ولی مدل‌های خفن هوش مصنوعی حدود ۳۰۰۰ کلمه در دقیقه کد تولید می‌کنن؟

اینم آمار پروژه:

نسخه اولیه که Claude 3.7/Cursor Agent داد: ۹ تا فایل، ۱۰۶۲ خط کد، ۴۵ تا کامنت (توضیحات)، ۱۵۸ خط خالی.

نسخه نهایی با تغییرات: ۴ تا فایل، ۳۱۸ خط کد، ۹ تا کامنت، ۷۹ خط خالی.

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

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

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

—-

⬅️ ادامه در قسمت بعدی

💡 تا قسمت بعدی مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

قسمت اول

قسمت دوم: ساختن نرم‌افزار که فقط کد نوشتن نیست!

اصل داستان، یکپارچه‌سازی و تحویل دادنِ کده. اصلاً شما می‌دونستید که یه زمانی مایکروسافت هر سه سال یکبار نسخه جدید ویندوز رو منتشر می‌کرد و «به طور متوسط، آماده شدن هر نسخه از ایده اولیه تا تکمیل نهایی حدود سه سال طول می‌کشید، اما فقط حدود شش تا نه ماه از این زمان صرف توسعه کدهای «جدید» می‌شد؟ بقیه زمان صرف یکپارچه‌سازی، تست، و دوره‌های آلفا و بتا (نسخه‌های آزمایشی اولیه) می‌شد» منبع

نوشتن کد فقط یه بخش خیلی مهمه، ولی تنها بخش ماجرا نیست. اصلاً خبر داشتید که (طبق یه تحقیق جدید خود مایکروسافت) توسعه‌دهنده‌ها فقط ۲۰ درصد از وقتشون رو صرف کدنویسی یا بازنویسی و مرتب‌سازی کد (که بهش میگن رفکتورینگ) می‌کنن؟ (همونجایی که اون آمار XYZ درصدی تولید کد توسط هوش مصنوعی مطرح میشه و به این بخش مربوطه).

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

فکرشو بکنید، اگه ذی‌نفعان پروژه (همون‌هایی که پروژه براشون مهمه و توش نقش دارن) دیگه جواب تلفن و ایمیل شما رو ندن، درگیر بازی‌های سیاسی داخلی شرکت خودشون بشن، و نتونن تکلیفشون رو با نیازمندی‌های پروژه روشن کنن چی؟ آیا ChatGPT (یا هر «ایجنت» خفن دیگه‌ای که فکرشو بکنید) می‌تونه بیفته دنبال مشتری، تمام تناقضات توی نیازمندی‌ها رو پیدا کنه و به رخشون بکشه، با کل تیم ارتباط برقرار کنه و ریسک‌های اصلی پروژه رو کم کنه؟


حتی اگه نیازمندی‌هایی داشته باشید که به نظر خیلی دقیق و پالایش شده میان... چقدر طول می‌کشه تا هر کدوم از اعضای تیم واقعاً متوجه بشن اون «چیزی» که دارن برای رسیدن بهش تلاش می‌کنن، دقیقاً چیه؟ چقدر طول می‌کشه تا تیم به یه توافق داخلی برسه که چطور باید دور اون هدف اصلی سازماندهی بشن، محدوده کار رو چطور خُرد کنن، و چطور نیازمندی‌های بیزینسی رو به جزئیات فنی و پیاده‌سازی ربط بدن؟ آیا ابزارهای هوش مصنوعی مولد (Gen-AI) می‌تونن اونقدر به دینامیک تیم سرعت بدن که تیم به جای چند هفته، فقط تو چند روز از مراحل اولیه شکل‌گیری و بحث و جدل (forming and storming) عبور کنه و سریع به هماهنگی و عملکرد بالا (norming and performing) برسه؟

من اینو همیشه به چشم می‌بینم: آدما ذاتاً تو فکر کردن کُند هستن، مغز ما تو اینکه چقدر اطلاعات می‌تونه پردازش کنه، یا اینکه چقدر ارتباطات اجتماعی می‌تونیم بسازیم و حفظ کنیم، محدودیت‌های طبیعی داره. اینکه یه عالمه متن تولید کنیم که کمتر کسی حوصله خوندنش رو داره (و تعداد خیلی کمتری هم سعی می‌کنن واقعاً بفهمنش) هیچ مشکلی رو حل نمی‌کنه.

با توجه به وضعیت فعلی و مسیری که ابزارهای هوش مصنوعی تو توسعه نرم‌افزار دارن پیش میرن، من اونا رو بیشتر شبیه ابزارهای افزایش بهره‌وریِ جدا افتاده می‌بینم که تهش، این آدمیزاده که گلوگاه کاره. پیشرفت خیلی کمی تو این زمینه شده که ایجنت‌های هوش مصنوعی بتونن تمام اون کارهای ریز و درشتی رو که یه کارمند آدم تو کارای روزمره‌اش انجام میده، پوشش بدن. حتی اگه هوش مصنوعی خیلی خیلی مستقل‌تر هم بشه (autonomy بالاتری پیدا کنه)، آدما هنوزم نیاز به زمان دارن تا تصمیم بگیرن، دیدگاه‌هاشون رو کامل‌تر کنن و تغییر بدن، با هم حرف بزنن، و به توافق برسن.


بهره‌وری

آخرش، کسب‌وکارها دنبال اینن که کار بیشتری با تلاش و هزینه کمتری انجام بشه. اینکه هوش مصنوعی رو بیاریم تو تیم‌های توسعه و بعد هزینه‌ها یا تعداد نیروها رو با یه عدد جادویی (که نمی‌دونم چرا همیشه بین ۲۰ تا ۳۰ درصده!) کم کنیم – به نظر نمیاد این روش خیلی جواب بده. هنوز تا یه جهش و تغییر خفن بزرگ تو بهره‌وری توسعه‌دهنده‌ها تو کل این صنعت فاصله داریم.


—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily