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

بعد از تلاش برای باز تولید مشکل هیچ پیغام خطا یا کرش واضحی وجود نداشته. 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

قسمت اول: چرا هر برنامه‌نویسی به یک ژورنال کدنویسی نیاز داره؟ نه، حافظه‌تون کافی نیست


داشتم دوتا مقاله ی متفاوت میخوندم (ریفرنس ها رو قسمت اخر میذارم) که راجب عملکرد مغزمون تو برنامه نویسی بود. تا حالا شده کدیو ببینید بگید دیگه کدوم نابلدی این کدو نوشته بعد بفهمید کار خودتون بوده؟ یا کدی که چند وقت پیش نوشتید رو دیگه یادتون نمیاد یا هم ممکنه یه مشکلی که کلی برای حلش وقت گذاشته باشید دفعه بعدی که بهش برخوردید به یاد نیارید قبلا چیکار کرده بودید. خبر خوب اینکه تمام اینا دلایل علمی پشتشونه :)

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

به مغز انسان خوش اومدید. یه کَش پر زرق‌وبرق که هیچ لایه ذخیره‌سازی دائمی نداره :)

اصل مطلب اینه: مغز شما برای حل مسئله بهینه شده، نه برای ذخیره‌سازی.

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

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

اما راه حل چیه؟

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

بیاید این مشکل رو حل کنیم.


—-

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

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

🆔 @MdDaily

قسمت دوم: چرا هر برنامه‌نویسی به یک ژورنال کدنویسی نیاز داره؟ نه، حافظه‌تون کافی نیست

توی قسمت اول بررسی کردیم که چرا ما کد ها را فراموش میکنیم و مغزمون برای حل مسئله ساخته شده و نه نگهداری اطلاعات و رسیدیم به یک پرسش مهم! حالا راه حل چیه؟

این یه راهه برای دیباگ کردن مغزتون، مقیاس دادن به یادگیری‌تون و تبدیل شدن به اون برنامه‌نویسی که خودِ آینده‌تون از دیدنش کیف می‌کنه.

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

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

چرا این مهمه:

* دردهای تکراری رو کم می‌کنه: همون باگی که سه اسپرینت پیش رفع کردی؟ حالا می‌تونی تو یادداشت‌هات جستجو کنی به جای اینکه دوباره تو Stack Overflow دنبالش بگردی.

* خودِ آینده‌ات رو باهوش‌تر می‌کنه: شما برای امروز کد نمی‌زنید، دارید برای نسخه سه ماه بعدِ خودتون سرنخ به جا می‌ذارید.

* کانتکست یعنی طلا: گیت (Git) به شما می‌گه چی تغییر کرده. ژورنال‌تون به شما می‌گه چرا تغییر کرده.

مغزتون رو مثل RAM در نظر بگیرید. سریعه ولی فَرّاره. ژورنال‌تون مثل SSD شماست؛ نوشتن توش کندتره، اما دائمی و قابل جستجوئه.

پس به جای اینکه با هر روز مثل یه شروع تازه برخورد کنید، مثل یه کمپین باهاش رفتار کنید؛ کمپینی که توش زود به زود ذخیره می‌کنید و نمی‌ذارید مبارزه با غول آخر، کل پیشرفتتون رو پاک کنه.

چی توی ژورنال برنامه‌نویسی‌تون بنویسید که شبیه دفتر خاطرات نشه

بذارید یه چیزی رو همین اول روشن کنیم: قرار نیست بنویسید «دفتر خاطرات عزیزم، امروز دوباره با یه سمی‌کالن (;) به مشکل خوردم.»

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

این چیزهاییه که واقعاً باید یادداشت کنید:

بردهای روزانه (حتی کوچیک‌هاش)

* یه باگ کَشینگ رو رفع کردی؟ بنویس چطوری.

* کانتینر داکر بالاخره بعد از ۳ ساعت کلنجار رفتن با «آخه چرا؟» اجرا شد؟ اون تغییر کوچیک تو کانفیگ رو بنویس.

* چرا؟ اینا الان شاید جزئی به نظر برسن، اما اثرشون مرکب می‌شه. به علاوه، مرور کردنشون بعداً مثل گرفتن XP می‌مونه.

چیزایی که گیر کردی و لحظات WTF

* اون پیغام خطایی که هیچ معنی‌ای نمی‌داد؟ ثبتش کن.

* اون مسیر خرگوشی که رفتی توش و به هیچ‌جا نرسید؟ اونم ارزشمنده.

* ثبت کردن موانع به شما کمک می‌کنه نه فقط کد، بلکه الگوهای فکری خودتون رو هم دیباگ کنید.

تصمیم‌هایی که گرفتی و دلیلش

* «من Zod رو به جای Yup انتخاب کردم چون استنتاج تایپ‌اسکریپتش بهتر بود.»

* «اینجا از unit test صرف‌نظر کردم چون تست E2E پوشش‌اش می‌ده.»

* این کار باعث می‌شه خودِ آینده‌تون با عصبانیت زیر لب نگه: «این دیگه کار کی بوده...»

دستورات خفن خط فرمان و کانفیگ‌ها

* اون دستور تک‌خطی که کل محیط رو آماده می‌کنه رو می‌شناسی؟ اون دستور rsync که همیشه قاطی می‌کنی؟ اینجا ثبتش کن. دیگه خبری از ژانگولربازی با history | grep نیست.


چیزایی که مجبور شدی (دوباره) گوگل کنی

* اگه یه چیزی رو بیشتر از یه بار گوگل کردی، جاش توی ژورناله. این قانونه.

* اینجوری ژورنالت تبدیل می‌شه به Stack Overflow شخصی خودت، ولی بدون اون کامنت‌های رو مخ که می‌گن «داکیومنت‌ها رو بخون.»

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

نکته حرفه‌ای: از لیست‌های بالت‌دار (bullet points)، بلوک‌های کد و تگ‌هایی مثل #رفع‌باگ`، `#cli یا #پرفورمنس برای سازماندهی نوشته‌هاتون استفاده کنید. مارک‌داون این کار رو به شکل خوبی ساده می‌کنه.


خب، حالا با ایده موافقید. سوال اصلی اینه: این همه چیز رو کجا بنویسیم؟

برای ژورنال‌نویسی برنامه‌نویس‌ها سه روش هست: با VS Code و Git ژورنال مارک‌داون با کنترل نسخه بسازید، با Obsidian یادداشت‌های متصل با بک‌لینک و تگ‌هایی مثل #debug و #frontend داشته باشید، یا با متن ساده و cron لاگ روزانه خودکار بنویسید. یکم باحال ترش کنیم؟ بدید به notebooklm :)

حرف آخر: ابزار به اندازه خود عادت مهم نیست. هر چیزی که برای شما اصطکاک رو کمتر می‌کنه انتخاب کنید. بهترین ابزار ژورنال‌نویسی اونیه که واقعاً بازش می‌کنید.

—-

⬅️ هنوز تموم نشده و ادامه در قسمت بعدی

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

🆔 @MdDaily

قسمت سوم: چرا هر برنامه‌نویسی به یک ژورنال کدنویسی نیاز داره؟ نه، حافظه‌تون کافی نیس
قسمت دوم
قسمت اول

اون حسی رو می‌شناسید که بالاخره یه باگ رو له می‌کنید و با خودتون فکر می‌کنید: «من یه نابغه‌ام و لایق افزایش حقوقم»؟

بعد دو هفته بعد، همون باگ برمی‌گرده و شما هیچ ایده‌ای ندارید دفعه قبل چیکار کردید؟

نوشتن فقط به یادآوری کمک نمی‌کنه، بلکه به شما کمک می‌کنه بهتر فکر کنید. «لاگ‌های ذهنی» مبهم و پراکنده‌تون رو به افکار ساختاریافته تبدیل می‌کنه. وقتی به طور مداوم ژورنال می‌نویسید، شروع به دیدن الگوها می‌کنید.

شفافیت در پیچیدگی

گاهی اوقات شما به جواب نیاز ندارید، فقط باید از دل سردرگمی بنویسید.

ژورنال‌نویسی شما رو مجبور می‌کنه بپرسید:

* داشتم سعی می‌کردم چیکار کنم؟

* چی اشتباه پیش رفت؟

* چی رو امتحان کردم؟

* چی بالاخره جواب داد؟

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

«نوشتن، روش طبیعته برای اینکه بهت بفهمونه تفکرت چقدر گنگ و مبهمه.»

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

تا حالا برای جواب دادن به سوال «از زمانی بگو که بر یک چالش غلبه کردی...» به زحمت افتادید؟

حالا تصور کنید ژورنالتون رو باز کنید و بگید:

«اتفاقاً، اینجوری یه مشکل تایم‌اوت مکرر API رو تو یه ساختار میکروسرویس با استفاده از retry queue و exponential backoff حل کردم...»

* باید یادتون بیاد اون سرویس داخلی GraphQL چطوری ساختاردهی شده بود؟

* می‌خواید یادتون بیاد چرا اون کتابخونه احراز هویتِ رو مخ رو منسوخ کردید؟

* باید یه طرح مهاجرت رو با یه عضو جدید تیم به اشتراک بذارید؟

ژورنال‌تون هواتون رو داره و به زبان خودتون نوشته شده، نه مثل یه دفترچه راهنمای استاندارد.

برای آنبوردینگ، منتورینگ و رشد تیم

وقتی یه نفر جدید به تیم شما ملحق می‌شه، دادن دسترسی به بخش‌های تمیز شده ژورنال‌تون (یا مستنداتی که از ژورنال الهام گرفتن) می‌تونه روند یادگیری‌اش رو سریع‌تر کنه. مثل اینه که بهش راهنمای قدم به قدم شکست دادن غول آخر رو بدید به جای اینکه بگید: «موفق باشی، فقط سورس کد رو بخون.»

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

پس دفعه بعد که یکی گفت: «تو اصلاً تمام روز چیکار می‌کنی؟» شما لاگ دارید.

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

یه روز داری کامیت‌های تمیز پوش می‌کنی و با آهنگ‌های لوفای حال می‌کنی، روز بعد ۶ ساعته تو جهنم وابستگی‌ها گیر کردی و داری به تمام تصمیم‌های زندگی‌ات از زمان نصب Node.js شک می‌کنی.

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

لازم نیست همه چیز رو درست کنی. فقط باید بنویسیش تا دیگه تو سرت تکرار نشه.

اشکالی نداره اگه نوشته‌تون این باشه:

> ۲۲ اردیبهشت

> هنوز نمی‌فهمم چرا کانتینر داکر از ماشین من متنفره.

> ۳ تا ایمیج پایه مختلف رو امتحان کردم. شاید واقعاً گریه‌ام بگیره.

> می‌رم یه قهوه بزنم. با مغز تازه دیباگ می‌کنم.

همین هم قبوله.

پیدا کردن الگوها برای مراقبت از خود

وقتی وضعیت عاطفی‌تون رو در طول زمان ردیابی می‌کنید، شروع به دیدن چیزهایی مثل این می‌کنید:

* وقتی استراحت نمی‌کنید سریع‌تر فرسوده می‌شید.

* بعد از پیاده‌روی صبحگاهی بهتر کد می‌زنید.

* بعد از جلسه‌های زیاد، بیشترین کلافگی رو دارید.

این یعنی خودآگاهی. و این به عادت‌های پایدار برنامه‌نویسی منجر می‌شه.

—-

⬅️ هنوز تموم نشده و ادامه در قسمت بعدی

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

🆔 @MdDaily

فضای لینکدین یه طوری شده (مخصوصا فارسی) پست های مردم توی 🤖 جلوشون محتوای فاخر حساب میشن :)


🆔 @MdDaily

قسمت چهارم: چرا هر برنامه‌نویسی به یک ژورنال کدنویسی نیاز داره؟ نه، حافظه‌تون کافی نیس
قسمت سوم
قسمت دوم
قسمت اول

ربات‌ها نمی‌تونن مثل شما ژورنال بنویسن

هوش مصنوعی می‌تونه کد شما رو کامل کنه، اما نمی‌تونه احساسات، تصمیم‌ها یا اینکه چرا بعد از دست زدن به CSS نزدیک بود لپ‌تاپت رو پرت کنی، ردیابی کنه. این کار شماست و یه ژورنال جای عالی برای این کاره.

بله، حتی برنامه‌نویس‌های ارشد هم باید این کار رو بکنن

شاید با خودتون فکر کنید: «من به ژورنال نیاز ندارم. من تجربه دارم.» آره... ولی هنوز یادت رفته فصل پیش چطوری اون باگ OAuth رو حل کردی.

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

ارشد بودن ≠ حافظه فوق بشری

ارشد بودن به این معنی نیست که تمام باگ‌هایی که تو سال ۱۴۰۲ رفع کردی رو یادت میاد. به این معنیه که بیشتر اشتباه کردی و ازشون درس گرفتی.

تفکر شما تبدیل به یه نقشه راه می‌شه

بهترین مهندس‌های ارشد فقط کد نمی‌نویسن — اونا راهنمایی می‌کنن، الگوهای تصمیم‌گیری رو نشون می‌دن و یه رد از کانتکست به جا می‌ذارن که بقیه بتونن دنبال کنن. یه ژورنال، مدل‌های ذهنی شما رو ثبت می‌کنه.

یه روز یکی سوال ازتون می‌پرسه. شما ژورنال‌تون رو باز می‌کنید:

> «اردیبهشت ۱۴۰۳: منطق تلاش مجدد رو بعد از مشکل race condition تو رول‌اوت کوبرنتیز اضافه کردم. قطعی ۴۰ درصد کم شد. اینم از راه‌حل...»

این یعنی به اشتراک‌گذاری دانش.

رسید برای رهبری

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

اینجوری ثابت می‌کنید که:

👈 شما اون مشکل رو از قبل پیش‌بینی کرده بودید.

👈 شما تصمیم درست رو گرفتید.

👈 شما نه فقط در کد، بلکه در شفافیت هم رشد کردید.

چطوری واقعاً این کار رو به یه عادت تبدیل کنیم

خب، تا الان احتمالاً دارید سر تکون می‌دید و می‌گید: «آره آره، ژورنال‌نویسی باحال به نظر می‌رسه، باید انجامش بدم...»

اما بیاید روراست باشیم، همه ما قبلاً اینو گفتیم.

مبارزه با غول آخر واقعی؟ ثبات قدم.

شما به یه چیزی به طرز احمقانه‌ای ساده نیاز دارید که حتی وقتی خسته و بداخلاقید هم کار کنه.

اینجوری این عادت رو بسازید بدون اینکه هفته دوم از عصبانیت ولش کنید:

با روزی ۵ دقیقه شروع کنید

هدفتون «لاگ‌های زیبا و خوش‌ساخت» نباشه. فقط هدف‌تون این باشه:

👈 روی چی کار کردم.

👈 کجا گیر کردم.

👈 چی یاد گرفتم (یا از یاد بردم).

واقعاً یه تایمر ۵ دقیقه‌ای تنظیم کنید. وقتی زنگ خورد، کارتون تمومه.

اون رو به کاری که همین الان هم انجام می‌دید بچسبونید

یه تمپلیت قابل استفاده مجدد توی کامنت ها براتون گذاشتم که ازش استفاده کنید.

اون رو سرگرم‌کننده (یا حداقل قابل تحمل) کنید

👈 میم اضافه کنید. جدی می‌گم.

👈 از اموجی برای حال و هوا استفاده کنید (😤, 🤓, 😵‍💫).

👈 لینک آهنگ‌هایی که موقع دیباگ کردن گوش می‌دادید رو بذارید.

👈 با ژورنال‌تون مثل چنج‌لاگ شخصی‌تون رفتار کنید.

ثبات قدم به معنی بی‌نقص بودن نیست. به معنی حاضر شدنه. حتی یه بالت پوینت هم از هیچی بهتره.

خودِ آینده‌تون از شما تشکر می‌کنه.

نتیجه‌گیری: وقتی بیشتر می‌نویسید، بهتر کد می‌زنید

📖 اینم خلاصه کلام برای اونایی که حال نداشتن بخونن (TL;DR):

مغزتون ۳ روز دیگه همه‌چیو فراموش می‌کنه، مگه اینکه ژورنال بنویسید:

مغز شما گیت نیست پس:

👈 تغییرات رو ردیابی نمی‌کنه.

👈 کانتکست رو ذخیره نمی‌کنه.

👈و قطعاً از ریبوت شدن جون سالم به در نمی‌بره.

یه ژورنال برنامه‌نویسی یه نمایش بهره‌وری نیست، یه ابزار بقاست. به شما کمک می‌کنه:

👈 یادتون بمونه چطور و چرا مشکلات رو حل کردید.

👈 تفکر خودتون رو دیباگ کنید.

👈 رشدتون رو در طول زمان ردیابی کنید.

👈 فرسودگی شغلی رو مدیریت کنید.

👈 استک اورفلو شخصی و قابل جستجوی خودتون رو بسازید.

👈 هم‌تیمی، منتور و معمار بهتری بشید.

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

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

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

پس امتحانش کنید. ۷ روز.
فقط روزی یک ورودی. لازم نیست فانتزی باشه. لازم نیست بی‌نقص باشه.

فقط یه فایل باز کنید و بنویسید.

چون بهترین برنامه‌نویس‌ها فقط کد تحویل نمی‌دن؛
اونا سفر رو ثبت می‌کنن.

منابع:
Source 1
Source 2

—-

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

🆔 @MdDaily

پادکست مجموعه سری چرا هر برنامه‌نویسی به یک ژورنال کدنویسی نیاز داره؟ نه، حافظه‌تون کافی نیس

تولید شده توسط notebooklm

—-

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

🆔 @MdDaily

داشتم تو یه پروژه های گیت هاب میگشتم رسیدم به این شاهکار :)

تاحالا شده برای تبدیل فایل هاتون به فرمت های مختلف مجبور شده باشید برید سراغ نرم افزار های شخص ثالث یا کرکی یا سایت های آنلاینی که نگران حریم شخصیتون باشید و شامل محدودیت و تبلیغ باشند؟

پروژه VERT میاد با استفاده از وب اسمبلی و روی لوکال دستگاهتون تبدیل ها رو انجام میده.

میتونید نسخه ی شخصی خودتون رو بیارید بالا یا از https://vert.sh/ استفاده کنید.

🌐 وبسایت:

https://vert.sh/

👩‍💻 گیت هاب:

https://github.com/VERT-sh/VERT



—-

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

🆔 @MdDaily

هوش مصنوعی تو کدنویسی: تجربه بی‌تعارف!

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

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

"بیخیال، بذار خودم فکر کنم!"

جز اون وقتا که یه کار واقعاً روتین دارم – کارهایی که سر و تهشون رو دقیق می‌دونم، می‌دونم چی باید چطوری نوشته بشه، و انقدر مطمئنم که اطلاعاتی که ابزار تکمیل خودکار هوش مصنوعی داره دقیقه که با زدن چندتا `Tab`، نیازی به نوشتن اون کدهای تکراری و تغییرات مشخص نیست – تو بقیه وقتا، بجز اون تکمیل خودکار پیش‌فرض و کلاسیک IDEام، بقیه ابزارهای هوش مصنوعی خاموش هستن. می‌پرسی چرا؟

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

"ساختار رو به هم نریز!"

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

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

حرف آخر و یه دید کلی

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

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

—-

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

🆔 @MdDaily