این یه روش فکر جدیده برای ساختن نرمافزار با کمک هوش مصنوعی. این اصطلاح رو آندری کارپاتی (Andrej Karpathy) ساخته و «وایب کدینگ» رو اینجوری توصیف میکنه: «خودت رو بسپر به حس و حالت، پذیرای رشد نمایی باش، و اصلاً یادت بره که کدی هم وجود داره».
اما خود Andrej Karpathy کیه؟
رزومه ی کامل و پروژه هاشو میتونید از وبسایت خودش karpathy.ai ببینید ولی به طور خلاصه جزو موسس ها و بخش تحقیقاتی OpenAI بوده بعد به عنوان مدیر ارشد هوش مصنوعی میره تسلا و بعد از چند سال مجدد بر میگرده به OpenAI.
کارپاتی از یه دستیار کدنویسی هوش مصنوعی استفاده میکنه و فلسفهاش اینه که «همه چیز رو قبول کن». اون فرض میکنه که این دستیار هوش مصنوعی، نرمافزاری که داره میسازه رو هم مینویسه و هم مشکلاتش رو حل میکنه.
با اینکه این روش کدنویسی خیلی وسوسهانگیزه، ولی آیا با توجه به محدودیتهای فعلی مدلهای زبانی بزرگ (LLM) و این اوضاعی که همهچیز داره تغییر میکنه، نتیجهاش به اندازه کافی دقیق هست؟ میشه با وایب کدینگ یه اپلیکیشن کامل رو بدون مشکل بالا آورد؟ میشه ازش خواست که تستها رو هم بنویسه؟ با ناهماهنگیها توی طراحی چیکار میکنه؟ این فقط یه چیز زودگذره (فَد fad) یا یه استراتژی بلندمدت واقعیه که برنامهنویسها باید یاد بگیرن و ازش استفاده کنن؟
اکه علاقه داشتید:
https://x.com/karpathy/status/1886192184808149383
https://www.youtube.com/watch?v=Tw18-4U7mts
https://dev.to/erikch/what-i-learned-vibe-coding-30em
---
🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
قسمت اول
داشتم رایتاپ 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 بود. نه هیچ روش پرداخت دیگهای کار میکرد. فقط یه صفحهی سفیدِ خالی جلو چشم کاربر بود.
⚠️ اول از همه: با دیباگ کردن شروع نکنید!
قبل از اینکه وارد جزئیات بشیم، یه درس خیلی مهم هست:
چون وقتی پای کد شما وسطه، مغزتون اتوماتیک میره تو این فاز که:
«خب، باگ کجاست؟ چی خراب شده؟ باید زود پیداش کنم و درستش کنم.»
ولی نکته اینجاست: دیباگ کردن زمانبره.
و در تمام مدتی که شما دارین لاگها رو زیر و رو میکنین و فرضیههای مختلف رو تست میکنین، کاربرهای واقعی اون بیرون گیر افتادن و نمیتونن کارشون رو انجام بدن.
درآمد شرکت داره کم میشه و از همه مهمتر، کاربرها دارن یه تجربهی خیلی بد رو از سر میگذرونن.
مگه اینکه دقیقاً بدونین مشکل چیه و صددرصد مطمئن باشین که راه حلش امنه و میشه خیلی سریع دیپلویاش کرد، وگرنه بهترین و عاقلانهترین کار اینه:
کامیتی که باعث مشکل شده رو برگردونین عقب (Revert). کد قبلی رو دوباره دیپلوی کنین (Redeploy). اوضاع رو پایدار کنین.
شاید این کار خیلی قهرمانانه به نظر نرسه، ولی این مسئولانهترین و درستترین کاریه که در اون لحظه میتونین انجام بدین.هدف اصلی تو اون شرایط این نیست که زیر فشار و استرس دیباگ کنین. هدف اینه که جلوی ضرر بیشتر رو بگیرین بعدش، وقتی بحران تموم شد، اون موقع با خیال راحت وقت دارین که برین و دقیق بفهمین که واقعاً چی خراب شده بود.
این ها هم دقیقا همین کارو کردن اون کامیت مشکلساز رو رولبک کردن و اون صفحهی سفید خالی غیبش زد. بخش چکاوت دوباره برگشت سر جاش. کاربرا دوباره میتونستن پرداختهاشون رو انجام بدن. حالا وقشته که کشف کرد دلیلش چی بود. شروع کردن به بررسی لاگها، تست کردن مرورگرها، و تلاش برای بازتولید مشکل تو یه محیط کنترلشده...
—-
⬅️ ادامه در قسمت بعدی
💡 تا قسمت بعدی مثل همیشه کنجکاو بمونید :)
🆔 @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
Please open Telegram to view this post
VIEW IN TELEGRAM
Md Daily
قسمت اول داشتم رایتاپ I Thought It Was a Safe Deploy… Until Checkout Disappeared رو میخوندم نکات جالبی توش داشت. طرف مسئول بخش payments بوده. شروع میکنه به استقرار نسخه ی جدید. تست ها گرفته شده بوده و روی محیط Dev همه چی اوکی به نظر میرسید. همه چیز آروم…
قسمت دوم (پایانی)
بعد از تلاش برای باز تولید مشکل هیچ پیغام خطا یا کرش واضحی وجود نداشته. stack trace مشخصی هم روی صفحه دیده نمیشده. فقط سکوت محض تا لحظه پیدا شدن یه خطای runtime error که از لایههای عمیق اون SDK آپدیتشدهی Apple Pay سرچشمه میگرفت.داشته سعی میکرده از یه method خاص استفاده کنه که توی محیط بعضی از مرورگرهای قدیمیتر اصلاً پشتیبانی نمیشده. نکتش اینجاس که Apple Pay فقط روی سافاری کار میکنه پس این خطا فقط روی نسخه های قدیمی سافاری خودشو نشون میداده. SDK موقع بالا اومدن و مقداردهی اولیه از یه تابع استفاده می کرده که باعث کرش میشده. نه فقط برای خود Apple Pay، بلکه برای همه چی! از همون باگهای موذی که موقع توسعه از زیر دست در میره و دیده نمیشه.
فقط درست کردن باگ مهم نیست؛ بحث سرِ قبول مسئولیت کاره
خب، باگ پیدا و کد هم به نسخه قبل برگردونده شده بود ولی خب کار اینجا تموم نمیشه. چون یه مهندس خوب بودن، فقط به این نیست که مشکل کاربر رو موقتاً حل کنی.مسئولیت اصلی اونجاست که یه قدم میری عقب و از خودت میپرسی:
- این خرابی و قطعی، واقعاً چه معنی و تجربهای برای کاربر داشت؟
- این قطعی چقدر برای کل کسبوکار هزینه برداشت؟
- آیا میشد این مشکل رو زودتر تشخیصش داد؟
- ممکنه دوباره همچین اتفاقی بیفته؟
ما اینجا نیستیم که فقط مثل ربات به آلارمها واکنش نشون بدیم و کدها رو سرسری وصلهپینه کنیم و ما کدنویسهایی نیستیم که بشه مثل ChatGPT بهمون پرامپت داد و انتظار داشت مشکل غیب بشه. اینجاییم که عمیق فکر کنیم، مسئولیت کامل نتایج کارهامون رو به عهده بگیریم و فعالانه جلوی آسیبهای آینده رو بگیریم.
پس برای مستند کردن چه چیز هایی رو میتونیم بنویسیم؟
- چی رو تغییر داده بودیم
- اصلاً چرا تغییرش داده بودیم
- چی و کجا خراب شد
- چطور شد که این مشکل از زیر دست تیم QA در رفت و دیده نشد
- چه چیزهایی توی monitoring ما از قلم افتاده بود که زودتر نفهمیدیم
این کار رو نه به خاطر اینکه کسی خواسته انجام بدیم، بلکه به این دلیل انجام بدیم که شاید خودِ آینده (یا یکی از همتیمیهای آینده) به مشکل مشابهی بر بخوره و اونها بتونن خیلی سریعتر به جواب و راه حل برسن.
این قطعی و اوتایج ها فقط بهمون یاد نمیده که چی اشتباه شده بود یا کجای کار میلنگید. باعث میشه از خودمون بپرسیم: اگه دوباره همچین اتفاقی بیفته، این بار چه کارهایی رو متفاوت انجام میدیم؟
جمعبندی و حرف آخر
راستش هیچکس به آدم نمیگه اولین باری که یه مشکل جدی و یه «آتیشسوزی» تو محیط پروداکشن درست میکنی، دقیقاً چه حسی داره. فوقالعاده پراسترسه و بله، گاهی وقتا هم واقعاً تقصیر کدیه که شما نوشتین.
ولی خب، آدم یاد میگیره.
یاد میگیری که «قبول کردن کامل مسئولیت» واقعاً یعنی چی.
یاد میگیری که چطور یه قدم بری عقبتر و دید وسیعتری پیدا کنی (zoom out کنی)؛ دیگه فقط به این فکر نکنی که «چی خراب شد؟»، بلکه بری سراغ اینکه «این خرابی روی چه کسایی تأثیر گذاشت؟».
یاد میگیری که یه مهندس خوب بودن، به معنی نوشتن کدِ بیعیبونقص و عالی نیست؛ بلکه به اینه که چطور بحران رو مدیریت میکنی، وقتی که اوضاع اصلاً خوب و عالی نیست.
یه چکلیست برای وقتی که این اتفاق برای شما میفته:
- سریع نپرین سراغ دیباگ کردن: اگه مشکل جدیه و روی کاربرها تأثیر مستقیم گذاشته، اولین قدم اینه که کد رو برگردونین به نسخهی قبلی. بعدش با خیال راحتتر برین دنبال دلیل مشکل بگردین.
- زود و شفاف اطلاعرسانی کنین: حتی یه پیام کوتاه مثل «دوستان دارم بررسی میکنم» توی کانالهای ارتباطی خیلی تأثیر مثبتی داره و به آروم شدن فضا کمک میکنه.
- سعی کنین مشکل رو توی محیطهای کنترلشده و ایزوله باز تولید کنین: یعنی دقیقاً با همون شرایطی که مشکل پیش اومده (مثلاً همون مرورگر، همون نسخه و ...).
- لاگها، درخواستهای شبکه، و نحوهی مدیریت خطاها رو با دقت چک کنین: هیچوقت فرض نکنین که اگه مشکلی باشه، حتماً سیستم با سر و صدای زیاد کرش میکنه و سریع متوجه میشین! گاهی مشکلات خیلی بیسر و صدا اتفاق میافتن.
- آستانهی هشدارهای سیستم پایش و مانیتورینگ رو دوباره یه نگاهی بندازین: آیا واقعاً جوری تنظیم شدن که خرابیهای کوچیک، نامحسوس یا تدریجی رو هم زود تشخیص بدن؟
- اتفاقی که افتاده رو با زبون ساده و واضح مستند کنین: این کار رو فقط برای بقیه اعضای تیم انجام ندین، بلکه برای خودتون در آینده هم انجام بدین. حافظه یاری نمیکنه!
- به تأثیر مشکل روی کسبوکار (business impact) فکر کنین: حدوداً چند تا کاربر تحت تأثیر قرار گرفتن؟ و این مشکل برای چه مدت زمانی ادامه داشت؟
- اگه در حین بررسی، به الگوها یا نکتههای کلیدی رسیدین، حتماً یادداشتشون کنین: این نکتهها برای بحران بعدی فوقالعاده ارزشمندن.
—-
💡 مثل همیشه کنجکاو بمونید :)
🆔 @MdDaily
بعد از تلاش برای باز تولید مشکل هیچ پیغام خطا یا کرش واضحی وجود نداشته. stack trace مشخصی هم روی صفحه دیده نمیشده. فقط سکوت محض تا لحظه پیدا شدن یه خطای runtime error که از لایههای عمیق اون SDK آپدیتشدهی Apple Pay سرچشمه میگرفت.داشته سعی میکرده از یه method خاص استفاده کنه که توی محیط بعضی از مرورگرهای قدیمیتر اصلاً پشتیبانی نمیشده. نکتش اینجاس که Apple Pay فقط روی سافاری کار میکنه پس این خطا فقط روی نسخه های قدیمی سافاری خودشو نشون میداده. SDK موقع بالا اومدن و مقداردهی اولیه از یه تابع استفاده می کرده که باعث کرش میشده. نه فقط برای خود Apple Pay، بلکه برای همه چی! از همون باگهای موذی که موقع توسعه از زیر دست در میره و دیده نمیشه.
فقط درست کردن باگ مهم نیست؛ بحث سرِ قبول مسئولیت کاره
خب، باگ پیدا و کد هم به نسخه قبل برگردونده شده بود ولی خب کار اینجا تموم نمیشه. چون یه مهندس خوب بودن، فقط به این نیست که مشکل کاربر رو موقتاً حل کنی.مسئولیت اصلی اونجاست که یه قدم میری عقب و از خودت میپرسی:
- این خرابی و قطعی، واقعاً چه معنی و تجربهای برای کاربر داشت؟
- این قطعی چقدر برای کل کسبوکار هزینه برداشت؟
- آیا میشد این مشکل رو زودتر تشخیصش داد؟
- ممکنه دوباره همچین اتفاقی بیفته؟
ما اینجا نیستیم که فقط مثل ربات به آلارمها واکنش نشون بدیم و کدها رو سرسری وصلهپینه کنیم و ما کدنویسهایی نیستیم که بشه مثل ChatGPT بهمون پرامپت داد و انتظار داشت مشکل غیب بشه. اینجاییم که عمیق فکر کنیم، مسئولیت کامل نتایج کارهامون رو به عهده بگیریم و فعالانه جلوی آسیبهای آینده رو بگیریم.
پس برای مستند کردن چه چیز هایی رو میتونیم بنویسیم؟
- چی رو تغییر داده بودیم
- اصلاً چرا تغییرش داده بودیم
- چی و کجا خراب شد
- چطور شد که این مشکل از زیر دست تیم QA در رفت و دیده نشد
- چه چیزهایی توی monitoring ما از قلم افتاده بود که زودتر نفهمیدیم
این کار رو نه به خاطر اینکه کسی خواسته انجام بدیم، بلکه به این دلیل انجام بدیم که شاید خودِ آینده (یا یکی از همتیمیهای آینده) به مشکل مشابهی بر بخوره و اونها بتونن خیلی سریعتر به جواب و راه حل برسن.
این قطعی و اوتایج ها فقط بهمون یاد نمیده که چی اشتباه شده بود یا کجای کار میلنگید. باعث میشه از خودمون بپرسیم: اگه دوباره همچین اتفاقی بیفته، این بار چه کارهایی رو متفاوت انجام میدیم؟
جمعبندی و حرف آخر
راستش هیچکس به آدم نمیگه اولین باری که یه مشکل جدی و یه «آتیشسوزی» تو محیط پروداکشن درست میکنی، دقیقاً چه حسی داره. فوقالعاده پراسترسه و بله، گاهی وقتا هم واقعاً تقصیر کدیه که شما نوشتین.
ولی خب، آدم یاد میگیره.
یاد میگیری که «قبول کردن کامل مسئولیت» واقعاً یعنی چی.
یاد میگیری که چطور یه قدم بری عقبتر و دید وسیعتری پیدا کنی (zoom out کنی)؛ دیگه فقط به این فکر نکنی که «چی خراب شد؟»، بلکه بری سراغ اینکه «این خرابی روی چه کسایی تأثیر گذاشت؟».
یاد میگیری که یه مهندس خوب بودن، به معنی نوشتن کدِ بیعیبونقص و عالی نیست؛ بلکه به اینه که چطور بحران رو مدیریت میکنی، وقتی که اوضاع اصلاً خوب و عالی نیست.
یه چکلیست برای وقتی که این اتفاق برای شما میفته:
- سریع نپرین سراغ دیباگ کردن: اگه مشکل جدیه و روی کاربرها تأثیر مستقیم گذاشته، اولین قدم اینه که کد رو برگردونین به نسخهی قبلی. بعدش با خیال راحتتر برین دنبال دلیل مشکل بگردین.
- زود و شفاف اطلاعرسانی کنین: حتی یه پیام کوتاه مثل «دوستان دارم بررسی میکنم» توی کانالهای ارتباطی خیلی تأثیر مثبتی داره و به آروم شدن فضا کمک میکنه.
- سعی کنین مشکل رو توی محیطهای کنترلشده و ایزوله باز تولید کنین: یعنی دقیقاً با همون شرایطی که مشکل پیش اومده (مثلاً همون مرورگر، همون نسخه و ...).
- لاگها، درخواستهای شبکه، و نحوهی مدیریت خطاها رو با دقت چک کنین: هیچوقت فرض نکنین که اگه مشکلی باشه، حتماً سیستم با سر و صدای زیاد کرش میکنه و سریع متوجه میشین! گاهی مشکلات خیلی بیسر و صدا اتفاق میافتن.
- آستانهی هشدارهای سیستم پایش و مانیتورینگ رو دوباره یه نگاهی بندازین: آیا واقعاً جوری تنظیم شدن که خرابیهای کوچیک، نامحسوس یا تدریجی رو هم زود تشخیص بدن؟
- اتفاقی که افتاده رو با زبون ساده و واضح مستند کنین: این کار رو فقط برای بقیه اعضای تیم انجام ندین، بلکه برای خودتون در آینده هم انجام بدین. حافظه یاری نمیکنه!
- به تأثیر مشکل روی کسبوکار (business impact) فکر کنین: حدوداً چند تا کاربر تحت تأثیر قرار گرفتن؟ و این مشکل برای چه مدت زمانی ادامه داشت؟
- اگه در حین بررسی، به الگوها یا نکتههای کلیدی رسیدین، حتماً یادداشتشون کنین: این نکتهها برای بحران بعدی فوقالعاده ارزشمندن.
—-
🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
شرکت OpenAI میگه هر بار به chatgpt میگید لطفا یا ازش تشکر میکنید براشون میلیون ها دلار هزینه داره.
پ ن:
وا کاری نداره که فقط کافیه این خط کدو اضافه کنند:
میلیون ها دلار صرفه جویی شد،
بعدا از من تشکر کنید :)
🆔 @MdDaily
پ ن:
وا کاری نداره که فقط کافیه این خط کدو اضافه کنند:
if (prompt.toLower() == “thank you”) return “You’re welcome”
میلیون ها دلار صرفه جویی شد،
بعدا از من تشکر کنید :)
🆔 @MdDaily
🤣29👍4😁1🐳1
داشتم یه ویدیو تو یوتیوب تحت عنوان 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
اولین چیزی که ویدیو بهش میپردازه، اینه که تابع sleep چطور توی دنیای واقعی کار میکنه. میره سراغ سختافزار و نشون میده که چطور با استفاده از فلیپفلاپها (یه جور مدار الکترونیکی که مثل سلولهای حافظه کار میکنن) میشه یه تایمر ساخت.
این تایمرها توی سیپییو مثل یه ساعت شنی دیجیتال عمل میکنن: یه عدد اولیه میگیرن و با هر تیک ساعت، شمارش معکوس میکنن تا به صفر برسن. وقتی یه برنامه sleep رو صدا میزنه، سیستمعامل با یه system call این تایمر رو تنظیم میکنه و وقتی تایمر به صفر رسید، با یه interrupt برنامه رو بیدار میکنه.
ولی یه چالش بزرگ وجود داره: تعداد تایمرهای سختافزاری توی یه چیپ محدوده. مثلاً اگه فقط دو تا تایمر داشته باشیم و سه تا برنامه بخوان sleep کنن، یکی باید منتظر بمونه! اینجا نرمافزار وارد بازی میشه. ویدیو توضیح میده که چطور سیستمعامل با یه تکنیک هوشمندانه، فقط با یه تایمر میتونه چندین برنامه رو مدیریت کنه. برنامههایی که sleep صدا میزنن، توی یه «صف خواب» میرن و سیستمعامل با یه تایمر و یه سری محاسبات، مطمئن میشه که هر کدوم سر وقت بیدار بشن.
بعدش، ویدیو یه روش قدیمیتر به اسم busy waiting رو بررسی میکنه که توی اون، برنامه با یه حلقهی بیفایده، پردازنده رو مشغول نگه میداشت تا زمان بگذره. این روش نه تنها دقت پایینی داره (چون به سرعت پردازنده و نوع دستورات بستگی داره)، بلکه کلی از منابع سیستم رو هدر میده و حتی میتونه سیستم رو قفل کنه! خوشبختانه، سیستمعاملهای مدرن با استفاده از برنامهریزی پردازنده (CPU scheduling) این مشکل رو حل کردن. وقتی برنامه sleep رو صدا میزنه، عملاً به سیستمعامل میگه: «من برای یه مدت نمیخوام پردازنده رو اشغال کنم، بذار بقیه کار کنن.»
یه نکتهی جالب دیگه اینه که دقت sleep همیشه ۱۰۰٪ نیست. چون بعد از بیدار شدن، برنامه میره توی صف آماده و اگه سیستم شلوغ باشه، ممکنه یه کم بیشتر منتظر بمونه. برای همین، وقتی از sleep استفاده میکنید، زمان دادهشده یه حداقل تضمینشدهست، نه یه عدد دقیق. این موضوع توی سیستمهای عمومی (غیر real-time) کاملاً عادیه و ویدیو خیلی خوب توضیح میده که چرا نباید انتظار دقت میکروثانیهای داشته باشیم.
در نهایت، ویدیو به این میرسه که چرا اسم این تابع «sleep» هست. «wait» میتونه گنگ باشه و به هر نوع انتظاری اشاره کنه (مثل busy waiting)، ولی «sleep» یعنی برنامه کاملاً غیرفعال میشه، منابع رو آزاد میکنه و مثل وقتی که ما میخوابیم، منتظر میمونه تا بیدار بشه. این اسم حسابی به ماهیت این تابع میخوره!
اگه کنجکاو شدید که جزئیات بیشتری دربارهی این موضوع بدونید، این ویدیو پر از توضیحات باحال و انیمیشنهای جذابه که مفاهیم پیچیده رو ساده میکنه. حتماً یه سر بزنید و خودتون ببینید:
—-
🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
What Happens When a Program Calls Sleeps?
Use code coredumped at the link below to get an exclusive 60% off an annual Incogni plan:
https://incogni.com/coredumped
Join CodeCrafters and learn by creating your own: Redis, Git, Http server, Interpreter, Grep... in your favorite programming language:…
https://incogni.com/coredumped
Join CodeCrafters and learn by creating your own: Redis, Git, Http server, Interpreter, Grep... in your favorite programming language:…
👍12🐳2👏1🙏1🆒1
در حال گشتزنی توی ❤️ ردیت به پروژهی GoXray برخوردم. با توجه به اینکه Nekoray دیگه بهروزرسانی نمیشه و توی لینوکس برای تونل کردن کل سیستم مشکل داشتم، این پروژه با پیادهسازی کامل قابلیتهای XRay تو Go این مشکل رو برطرف کرده. هم نسخهی GUI داره که با Fyne توسعه داده شده، هم نسخهی CLI که اگه دنبال یه ابزار سبک و سریع هستید، به نظرم گزینهی عالیایه. برای لینوکس و مک هم نسخههای مخصوص داره.
گیت هاب پروژه:
👩💻 https://github.com/goxray
برای استفاده از نسخه ی CLI اش توی لینوکس فقط کافیه اخرین نسخه رو از https://github.com/goxray/tun/releases بگیرید و بعد:
1- اول دسترسی اجرا به فایلش بدید:
و برای اتصال :
و برای قطع اتصال هم فقط CTRL+C رو بزنید :)
—-
💡 مثل همیشه کنجکاو بمونید :)
🆔 @MdDaily
گیت هاب پروژه:
برای استفاده از نسخه ی CLI اش توی لینوکس فقط کافیه اخرین نسخه رو از https://github.com/goxray/tun/releases بگیرید و بعد:
1- اول دسترسی اجرا به فایلش بدید:
chmod +x goxray_cli_linux_amd64
و برای اتصال :
sudo ./goxray_cli_linux_amd64 "YOUR CONFIG"
و برای قطع اتصال هم فقط CTRL+C رو بزنید :)
—-
🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12👍3❤🔥2
چند وقت پیش یه خبری ترند شد که یه نفر اومده بود توی فایل 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
این پروژه از 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
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7
قسمت اول
داشتم یه مقاله میخوندم عنوانش جالب بود 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% 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
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7
Md Daily
قسمت اول داشتم یه مقاله میخوندم عنوانش جالب بود XYZ% of Code is Now Written by AI... Who Care. میگه فکر کن XYZ درصد کُدها رو دیگه هوش مصنوعی مینویسه... خب که چی؟ ساتیا نادلا، مدیرعامل مایکروسافت، گفته که «تا ۳۰ درصد کدهای شرکت رو الان دیگه هوش مصنوعی مینویسه»…
قسمت اول
قسمت دوم: ساختن نرمافزار که فقط کد نوشتن نیست!
اصل داستان، یکپارچهسازی و تحویل دادنِ کده. اصلاً شما میدونستید که یه زمانی مایکروسافت هر سه سال یکبار نسخه جدید ویندوز رو منتشر میکرد و «به طور متوسط، آماده شدن هر نسخه از ایده اولیه تا تکمیل نهایی حدود سه سال طول میکشید، اما فقط حدود شش تا نه ماه از این زمان صرف توسعه کدهای «جدید» میشد؟ بقیه زمان صرف یکپارچهسازی، تست، و دورههای آلفا و بتا (نسخههای آزمایشی اولیه) میشد» منبع
نوشتن کد فقط یه بخش خیلی مهمه، ولی تنها بخش ماجرا نیست. اصلاً خبر داشتید که (طبق یه تحقیق جدید خود مایکروسافت) توسعهدهندهها فقط ۲۰ درصد از وقتشون رو صرف کدنویسی یا بازنویسی و مرتبسازی کد (که بهش میگن رفکتورینگ) میکنن؟ (همونجایی که اون آمار XYZ درصدی تولید کد توسط هوش مصنوعی مطرح میشه و به این بخش مربوطه).
وقتی با تیمها و مشتریها سر و کار داریم و نرمافزار میسازیم، خیلی جاها میبینم که هوش مصنوعی به زور میتونه کمکی بکنه.
فکرشو بکنید، اگه ذینفعان پروژه (همونهایی که پروژه براشون مهمه و توش نقش دارن) دیگه جواب تلفن و ایمیل شما رو ندن، درگیر بازیهای سیاسی داخلی شرکت خودشون بشن، و نتونن تکلیفشون رو با نیازمندیهای پروژه روشن کنن چی؟ آیا ChatGPT (یا هر «ایجنت» خفن دیگهای که فکرشو بکنید) میتونه بیفته دنبال مشتری، تمام تناقضات توی نیازمندیها رو پیدا کنه و به رخشون بکشه، با کل تیم ارتباط برقرار کنه و ریسکهای اصلی پروژه رو کم کنه؟
حتی اگه نیازمندیهایی داشته باشید که به نظر خیلی دقیق و پالایش شده میان... چقدر طول میکشه تا هر کدوم از اعضای تیم واقعاً متوجه بشن اون «چیزی» که دارن برای رسیدن بهش تلاش میکنن، دقیقاً چیه؟ چقدر طول میکشه تا تیم به یه توافق داخلی برسه که چطور باید دور اون هدف اصلی سازماندهی بشن، محدوده کار رو چطور خُرد کنن، و چطور نیازمندیهای بیزینسی رو به جزئیات فنی و پیادهسازی ربط بدن؟ آیا ابزارهای هوش مصنوعی مولد (Gen-AI) میتونن اونقدر به دینامیک تیم سرعت بدن که تیم به جای چند هفته، فقط تو چند روز از مراحل اولیه شکلگیری و بحث و جدل (forming and storming) عبور کنه و سریع به هماهنگی و عملکرد بالا (norming and performing) برسه؟
من اینو همیشه به چشم میبینم: آدما ذاتاً تو فکر کردن کُند هستن، مغز ما تو اینکه چقدر اطلاعات میتونه پردازش کنه، یا اینکه چقدر ارتباطات اجتماعی میتونیم بسازیم و حفظ کنیم، محدودیتهای طبیعی داره. اینکه یه عالمه متن تولید کنیم که کمتر کسی حوصله خوندنش رو داره (و تعداد خیلی کمتری هم سعی میکنن واقعاً بفهمنش) هیچ مشکلی رو حل نمیکنه.
با توجه به وضعیت فعلی و مسیری که ابزارهای هوش مصنوعی تو توسعه نرمافزار دارن پیش میرن، من اونا رو بیشتر شبیه ابزارهای افزایش بهرهوریِ جدا افتاده میبینم که تهش، این آدمیزاده که گلوگاه کاره. پیشرفت خیلی کمی تو این زمینه شده که ایجنتهای هوش مصنوعی بتونن تمام اون کارهای ریز و درشتی رو که یه کارمند آدم تو کارای روزمرهاش انجام میده، پوشش بدن. حتی اگه هوش مصنوعی خیلی خیلی مستقلتر هم بشه (autonomy بالاتری پیدا کنه)، آدما هنوزم نیاز به زمان دارن تا تصمیم بگیرن، دیدگاههاشون رو کاملتر کنن و تغییر بدن، با هم حرف بزنن، و به توافق برسن.
بهرهوری
آخرش، کسبوکارها دنبال اینن که کار بیشتری با تلاش و هزینه کمتری انجام بشه. اینکه هوش مصنوعی رو بیاریم تو تیمهای توسعه و بعد هزینهها یا تعداد نیروها رو با یه عدد جادویی (که نمیدونم چرا همیشه بین ۲۰ تا ۳۰ درصده!) کم کنیم – به نظر نمیاد این روش خیلی جواب بده. هنوز تا یه جهش و تغییر خفن بزرگ تو بهرهوری توسعهدهندهها تو کل این صنعت فاصله داریم.
—-
💡 مثل همیشه کنجکاو بمونید :)
🆔 @MdDaily
قسمت دوم: ساختن نرمافزار که فقط کد نوشتن نیست!
اصل داستان، یکپارچهسازی و تحویل دادنِ کده. اصلاً شما میدونستید که یه زمانی مایکروسافت هر سه سال یکبار نسخه جدید ویندوز رو منتشر میکرد و «به طور متوسط، آماده شدن هر نسخه از ایده اولیه تا تکمیل نهایی حدود سه سال طول میکشید، اما فقط حدود شش تا نه ماه از این زمان صرف توسعه کدهای «جدید» میشد؟ بقیه زمان صرف یکپارچهسازی، تست، و دورههای آلفا و بتا (نسخههای آزمایشی اولیه) میشد» منبع
نوشتن کد فقط یه بخش خیلی مهمه، ولی تنها بخش ماجرا نیست. اصلاً خبر داشتید که (طبق یه تحقیق جدید خود مایکروسافت) توسعهدهندهها فقط ۲۰ درصد از وقتشون رو صرف کدنویسی یا بازنویسی و مرتبسازی کد (که بهش میگن رفکتورینگ) میکنن؟ (همونجایی که اون آمار XYZ درصدی تولید کد توسط هوش مصنوعی مطرح میشه و به این بخش مربوطه).
وقتی با تیمها و مشتریها سر و کار داریم و نرمافزار میسازیم، خیلی جاها میبینم که هوش مصنوعی به زور میتونه کمکی بکنه.
فکرشو بکنید، اگه ذینفعان پروژه (همونهایی که پروژه براشون مهمه و توش نقش دارن) دیگه جواب تلفن و ایمیل شما رو ندن، درگیر بازیهای سیاسی داخلی شرکت خودشون بشن، و نتونن تکلیفشون رو با نیازمندیهای پروژه روشن کنن چی؟ آیا ChatGPT (یا هر «ایجنت» خفن دیگهای که فکرشو بکنید) میتونه بیفته دنبال مشتری، تمام تناقضات توی نیازمندیها رو پیدا کنه و به رخشون بکشه، با کل تیم ارتباط برقرار کنه و ریسکهای اصلی پروژه رو کم کنه؟
حتی اگه نیازمندیهایی داشته باشید که به نظر خیلی دقیق و پالایش شده میان... چقدر طول میکشه تا هر کدوم از اعضای تیم واقعاً متوجه بشن اون «چیزی» که دارن برای رسیدن بهش تلاش میکنن، دقیقاً چیه؟ چقدر طول میکشه تا تیم به یه توافق داخلی برسه که چطور باید دور اون هدف اصلی سازماندهی بشن، محدوده کار رو چطور خُرد کنن، و چطور نیازمندیهای بیزینسی رو به جزئیات فنی و پیادهسازی ربط بدن؟ آیا ابزارهای هوش مصنوعی مولد (Gen-AI) میتونن اونقدر به دینامیک تیم سرعت بدن که تیم به جای چند هفته، فقط تو چند روز از مراحل اولیه شکلگیری و بحث و جدل (forming and storming) عبور کنه و سریع به هماهنگی و عملکرد بالا (norming and performing) برسه؟
من اینو همیشه به چشم میبینم: آدما ذاتاً تو فکر کردن کُند هستن، مغز ما تو اینکه چقدر اطلاعات میتونه پردازش کنه، یا اینکه چقدر ارتباطات اجتماعی میتونیم بسازیم و حفظ کنیم، محدودیتهای طبیعی داره. اینکه یه عالمه متن تولید کنیم که کمتر کسی حوصله خوندنش رو داره (و تعداد خیلی کمتری هم سعی میکنن واقعاً بفهمنش) هیچ مشکلی رو حل نمیکنه.
با توجه به وضعیت فعلی و مسیری که ابزارهای هوش مصنوعی تو توسعه نرمافزار دارن پیش میرن، من اونا رو بیشتر شبیه ابزارهای افزایش بهرهوریِ جدا افتاده میبینم که تهش، این آدمیزاده که گلوگاه کاره. پیشرفت خیلی کمی تو این زمینه شده که ایجنتهای هوش مصنوعی بتونن تمام اون کارهای ریز و درشتی رو که یه کارمند آدم تو کارای روزمرهاش انجام میده، پوشش بدن. حتی اگه هوش مصنوعی خیلی خیلی مستقلتر هم بشه (autonomy بالاتری پیدا کنه)، آدما هنوزم نیاز به زمان دارن تا تصمیم بگیرن، دیدگاههاشون رو کاملتر کنن و تغییر بدن، با هم حرف بزنن، و به توافق برسن.
بهرهوری
آخرش، کسبوکارها دنبال اینن که کار بیشتری با تلاش و هزینه کمتری انجام بشه. اینکه هوش مصنوعی رو بیاریم تو تیمهای توسعه و بعد هزینهها یا تعداد نیروها رو با یه عدد جادویی (که نمیدونم چرا همیشه بین ۲۰ تا ۳۰ درصده!) کم کنیم – به نظر نمیاد این روش خیلی جواب بده. هنوز تا یه جهش و تغییر خفن بزرگ تو بهرهوری توسعهدهندهها تو کل این صنعت فاصله داریم.
—-
🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4👨💻2🤔1
چند وقت پیش دانشگاه یه ارائه ی ai داشتم به بچه ها گفتم این چیزی که الان میبینید مال الان هست تا هفته ی دیگه مطالبی که بهتون راجب ابزار ها گفتم معتبر نیست. تا همین الان بعد از کنفرانس google io، فعال شدن ویس Grok توی نسخه ی اندروید، اپن سورس شدن گیت هاب کوپایلت و معرفی گیت هاب کوپایلت agent نصف مطالب ارائه شده راجب ابزار ها منسوخ شدن :)
🆔 @MdDaily
🆔 @MdDaily
⚡13
پست بعدی رو با محوریت حافظه ی مغزمون رو دارم می نویسیم و توی همین چند روز آماده و منتشر میشه . بخشی از مقدمه ی پست :
برای موضوع بعدی داشتم فکر میکردم راجب android reverse engineering بنویسم و یه اپ رو شروع کنیم به آنالیزش و اینکه چطوری میتونیم api هاشا پیدا کنیم و چه مراحلی رو باید پیش ببریم.
توی کامنت ها اگه اپی رو مد نظر دارید معرفی کنید تا بریم سراغش (ترجیحا اپی که بعد مشکل کپی رایت نخوریم )
ما برنامهنویسها دوست داریم باور کنیم موجودات منطقیای هستیم. مشکل حل میکنیم. سیستمهای مقیاسپذیر میسازیم. اما وقتی پای یادآوری اینکه چطوری اون مشکل لعنتی timeout ایپیآی رو ماه پیش حل کردیم میاد وسط؟ کلاً دچار فراموشی میشیم. انگار مغزمون هر اسپرینت یه rm -rf /knowledge اجرا میکنه!
برای موضوع بعدی داشتم فکر میکردم راجب android reverse engineering بنویسم و یه اپ رو شروع کنیم به آنالیزش و اینکه چطوری میتونیم api هاشا پیدا کنیم و چه مراحلی رو باید پیش ببریم.
توی کامنت ها اگه اپی رو مد نظر دارید معرفی کنید تا بریم سراغش (ترجیحا اپی که بعد مشکل کپی رایت نخوریم )
❤6👍1👻1🦄1
قسمت اول: چرا هر برنامهنویسی به یک ژورنال کدنویسی نیاز داره؟ نه، حافظهتون کافی نیست
داشتم دوتا مقاله ی متفاوت میخوندم (ریفرنس ها رو قسمت اخر میذارم) که راجب عملکرد مغزمون تو برنامه نویسی بود. تا حالا شده کدیو ببینید بگید دیگه کدوم نابلدی این کدو نوشته بعد بفهمید کار خودتون بوده؟ یا کدی که چند وقت پیش نوشتید رو دیگه یادتون نمیاد یا هم ممکنه یه مشکلی که کلی برای حلش وقت گذاشته باشید دفعه بعدی که بهش برخوردید به یاد نیارید قبلا چیکار کرده بودید. خبر خوب اینکه تمام اینا دلایل علمی پشتشونه :)
برنامهنویسی بیشتر از اینکه به حفظ کردن سینتکس ربط داشته باشه، یک فرآیند حل مسئله ست. مشاغل کمی هستن که به حافظهی طوطیوار نیاز دارن، اما در کدنویسی، مهم اینه که چطور از منطق برای رسیدن به یک هدف خاص استفاده کنی. توسعهدهندهها همیشه در حال یادگیری ابزارها، فریمورکها و روشهای جدید برای انجام کارها هستن؛ برای همین، تمرکزشون بیشتر روی حل مشکلات به بهینهترین شکل ممکنه تا به خاطر سپردن خط به خط کدها.
به مغز انسان خوش اومدید. یه کَش پر زرقوبرق که هیچ لایه ذخیرهسازی دائمی نداره :)
اصل مطلب اینه: مغز شما برای حل مسئله بهینه شده، نه برای ذخیرهسازی.
حالا فکر کن وسط این همه حل مسئله، تکنولوژی با سرعت زیادی در حال پیشرفته. زبانهای برنامهنویسی، کتابخونهها و فریمورکها مدام تغییر میکنن و این باعث میشه که توسعهدهندهها مجبور باشن همیشه خودشون رو با روشهای جدید بهروز نگه دارن. این تحول دائمی یعنی کدی که دیروز نوشتید، شاید امروز دیگه کاربردی نداشته باشه. برای برنامهنویسها، یادگیری اینکه چطور با تغییرات جدید خودشون رو وفق بدن، در اولویت قرار داره تا اینکه کدهای قبلی رو به حافظه بسپارن.
مغز ما حافظه کوتاهمدت و بلندمدت رو به شکل متفاوتی مدیریت میکنه. وقتی برنامهنویسها عمیقاً در حال کدنویسی هستن، ساختار و منطق کد رو توی حافظه کوتاهمدتشون نگه میدارن. وقتی که سراغ یک پروژه جدید میرن، اون کد ممکنه به حافظه بلندمدت منتقل نشه و همین باعث میشه بعداً به یاد آوردنش سخت باشه و برنامهنویسی میتونه از نظر ذهنی خیلی خستهکننده باشه، چون مجبوری همزمان چندین وظیفه، متغیر و منطق رو توی ذهنت نگه داری. مغز فقط میتونه حجم محدودی از اطلاعات رو در یک زمان پردازش کنه. وقتی با وظایف جدیدی روبرو میشه، اطلاعات قدیمیتر (مثل کدهای قبلی) به بیرون هل داده میشن تا فضا برای حل مسائل جدید باز بشه.
اما راه حل چیه؟
قبل از راه حل بریم ببینیم مشکل از کجا میاد. ما همه چیز رو مستند میکنیم به جز سفر خودمون: تلاشهای ناموفق، بردهای کوچیک، راهحلهای سریع و درسهایی که به روش سخت یاد گرفتیم. ما برای بقیه فایل
بیاید این مشکل رو حل کنیم.
—-
⬅️ ادامه در قسمت بعدی
💡 تا قسمت بعدی مثل همیشه کنجکاو بمونید :)
🆔 @MdDaily
داشتم دوتا مقاله ی متفاوت میخوندم (ریفرنس ها رو قسمت اخر میذارم) که راجب عملکرد مغزمون تو برنامه نویسی بود. تا حالا شده کدیو ببینید بگید دیگه کدوم نابلدی این کدو نوشته بعد بفهمید کار خودتون بوده؟ یا کدی که چند وقت پیش نوشتید رو دیگه یادتون نمیاد یا هم ممکنه یه مشکلی که کلی برای حلش وقت گذاشته باشید دفعه بعدی که بهش برخوردید به یاد نیارید قبلا چیکار کرده بودید. خبر خوب اینکه تمام اینا دلایل علمی پشتشونه :)
برنامهنویسی بیشتر از اینکه به حفظ کردن سینتکس ربط داشته باشه، یک فرآیند حل مسئله ست. مشاغل کمی هستن که به حافظهی طوطیوار نیاز دارن، اما در کدنویسی، مهم اینه که چطور از منطق برای رسیدن به یک هدف خاص استفاده کنی. توسعهدهندهها همیشه در حال یادگیری ابزارها، فریمورکها و روشهای جدید برای انجام کارها هستن؛ برای همین، تمرکزشون بیشتر روی حل مشکلات به بهینهترین شکل ممکنه تا به خاطر سپردن خط به خط کدها.
به مغز انسان خوش اومدید. یه کَش پر زرقوبرق که هیچ لایه ذخیرهسازی دائمی نداره :)
اصل مطلب اینه: مغز شما برای حل مسئله بهینه شده، نه برای ذخیرهسازی.
حالا فکر کن وسط این همه حل مسئله، تکنولوژی با سرعت زیادی در حال پیشرفته. زبانهای برنامهنویسی، کتابخونهها و فریمورکها مدام تغییر میکنن و این باعث میشه که توسعهدهندهها مجبور باشن همیشه خودشون رو با روشهای جدید بهروز نگه دارن. این تحول دائمی یعنی کدی که دیروز نوشتید، شاید امروز دیگه کاربردی نداشته باشه. برای برنامهنویسها، یادگیری اینکه چطور با تغییرات جدید خودشون رو وفق بدن، در اولویت قرار داره تا اینکه کدهای قبلی رو به حافظه بسپارن.
مغز ما حافظه کوتاهمدت و بلندمدت رو به شکل متفاوتی مدیریت میکنه. وقتی برنامهنویسها عمیقاً در حال کدنویسی هستن، ساختار و منطق کد رو توی حافظه کوتاهمدتشون نگه میدارن. وقتی که سراغ یک پروژه جدید میرن، اون کد ممکنه به حافظه بلندمدت منتقل نشه و همین باعث میشه بعداً به یاد آوردنش سخت باشه و برنامهنویسی میتونه از نظر ذهنی خیلی خستهکننده باشه، چون مجبوری همزمان چندین وظیفه، متغیر و منطق رو توی ذهنت نگه داری. مغز فقط میتونه حجم محدودی از اطلاعات رو در یک زمان پردازش کنه. وقتی با وظایف جدیدی روبرو میشه، اطلاعات قدیمیتر (مثل کدهای قبلی) به بیرون هل داده میشن تا فضا برای حل مسائل جدید باز بشه.
اما راه حل چیه؟
قبل از راه حل بریم ببینیم مشکل از کجا میاد. ما همه چیز رو مستند میکنیم به جز سفر خودمون: تلاشهای ناموفق، بردهای کوچیک، راهحلهای سریع و درسهایی که به روش سخت یاد گرفتیم. ما برای بقیه فایل
README.md مینویسیم... اما هیچوقت برای خودمون نه.بیاید این مشکل رو حل کنیم.
—-
🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8🆒2🙏1👻1🦄1
قسمت دوم: چرا هر برنامهنویسی به یک ژورنال کدنویسی نیاز داره؟ نه، حافظهتون کافی نیست
توی قسمت اول بررسی کردیم که چرا ما کد ها را فراموش میکنیم و مغزمون برای حل مسئله ساخته شده و نه نگهداری اطلاعات و رسیدیم به یک پرسش مهم! حالا راه حل چیه؟
این یه راهه برای دیباگ کردن مغزتون، مقیاس دادن به یادگیریتون و تبدیل شدن به اون برنامهنویسی که خودِ آیندهتون از دیدنش کیف میکنه.
هر روز شما مشکلات رو حل میکنید، با موارد خاص آشنا میشید، خطاهای عجیب و غریب رو دیباگ میکنید و به ترفندهای باحالی برمیخورید. اما اگه پیشرفتتون رو ذخیره نکنید، میشه مثل یه پروسه که توی `top` کیل شده.
یه ژورنال برنامهنویسی، سیستم ذخیرهسازی شخصی شماست که قرار نیست توش مقاله بنویسید. قراره اون زمینه و کانتکست رو حفظ کنید؛ یعنی روند فکری، دلیلی که یه کتابخونه رو به اون یکی ترجیح دادی.
چرا این مهمه:
* دردهای تکراری رو کم میکنه: همون باگی که سه اسپرینت پیش رفع کردی؟ حالا میتونی تو یادداشتهات جستجو کنی به جای اینکه دوباره تو Stack Overflow دنبالش بگردی.
* خودِ آیندهات رو باهوشتر میکنه: شما برای امروز کد نمیزنید، دارید برای نسخه سه ماه بعدِ خودتون سرنخ به جا میذارید.
* کانتکست یعنی طلا: گیت (Git) به شما میگه چی تغییر کرده. ژورنالتون به شما میگه چرا تغییر کرده.
مغزتون رو مثل RAM در نظر بگیرید. سریعه ولی فَرّاره. ژورنالتون مثل SSD شماست؛ نوشتن توش کندتره، اما دائمی و قابل جستجوئه.
پس به جای اینکه با هر روز مثل یه شروع تازه برخورد کنید، مثل یه کمپین باهاش رفتار کنید؛ کمپینی که توش زود به زود ذخیره میکنید و نمیذارید مبارزه با غول آخر، کل پیشرفتتون رو پاک کنه.
چی توی ژورنال برنامهنویسیتون بنویسید که شبیه دفتر خاطرات نشه
بذارید یه چیزی رو همین اول روشن کنیم: قرار نیست بنویسید «دفتر خاطرات عزیزم، امروز دوباره با یه سمیکالن (;) به مشکل خوردم.»
یه ژورنال برنامهنویسی در مورد احساسات نیست. هدفش ثبت سرنخهای فنیه تا بتونید از سردردهای آینده جلوگیری کنید، سرعت کارتون رو بالا ببرید و دیگه هر ماه مجبور نشید همون جواب رو از نو پیدا کنید.
این چیزهاییه که واقعاً باید یادداشت کنید:
بردهای روزانه (حتی کوچیکهاش)
* یه باگ کَشینگ رو رفع کردی؟ بنویس چطوری.
* کانتینر داکر بالاخره بعد از ۳ ساعت کلنجار رفتن با «آخه چرا؟» اجرا شد؟ اون تغییر کوچیک تو کانفیگ رو بنویس.
* چرا؟ اینا الان شاید جزئی به نظر برسن، اما اثرشون مرکب میشه. به علاوه، مرور کردنشون بعداً مثل گرفتن XP میمونه.
چیزایی که گیر کردی و لحظات WTF
* اون پیغام خطایی که هیچ معنیای نمیداد؟ ثبتش کن.
* اون مسیر خرگوشی که رفتی توش و به هیچجا نرسید؟ اونم ارزشمنده.
* ثبت کردن موانع به شما کمک میکنه نه فقط کد، بلکه الگوهای فکری خودتون رو هم دیباگ کنید.
تصمیمهایی که گرفتی و دلیلش
* «من
* «اینجا از unit test صرفنظر کردم چون تست E2E پوششاش میده.»
* این کار باعث میشه خودِ آیندهتون با عصبانیت زیر لب نگه: «این دیگه کار کی بوده...»
دستورات خفن خط فرمان و کانفیگها
* اون دستور تکخطی که کل محیط رو آماده میکنه رو میشناسی؟ اون دستور
چیزایی که مجبور شدی (دوباره) گوگل کنی
* اگه یه چیزی رو بیشتر از یه بار گوگل کردی، جاش توی ژورناله. این قانونه.
* اینجوری ژورنالت تبدیل میشه به Stack Overflow شخصی خودت، ولی بدون اون کامنتهای رو مخ که میگن «داکیومنتها رو بخون.»
خلاصه، ساختاریافته و قابل جستجو نگه داشتنش باعث میشه مفید باشه. این یه وبلاگ نیست. این لاگ دیباگ شما تو زندگی واقعیه.
نکته حرفهای: از لیستهای بالتدار (bullet points)، بلوکهای کد و تگهایی مثل
خب، حالا با ایده موافقید. سوال اصلی اینه: این همه چیز رو کجا بنویسیم؟
برای ژورنالنویسی برنامهنویسها سه روش هست: با VS Code و Git ژورنال مارکداون با کنترل نسخه بسازید، با Obsidian یادداشتهای متصل با بکلینک و تگهایی مثل
حرف آخر: ابزار به اندازه خود عادت مهم نیست. هر چیزی که برای شما اصطکاک رو کمتر میکنه انتخاب کنید. بهترین ابزار ژورنالنویسی اونیه که واقعاً بازش میکنید.
—-
⬅️ هنوز تموم نشده و ادامه در قسمت بعدی
💡 تا قسمت بعدی مثل همیشه کنجکاو بمونید :)
🆔 @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
Please open Telegram to view this post
VIEW IN TELEGRAM
❤10
قسمت سوم: چرا هر برنامهنویسی به یک ژورنال کدنویسی نیاز داره؟ نه، حافظهتون کافی نیس
قسمت دوم
قسمت اول
اون حسی رو میشناسید که بالاخره یه باگ رو له میکنید و با خودتون فکر میکنید: «من یه نابغهام و لایق افزایش حقوقم»؟
بعد دو هفته بعد، همون باگ برمیگرده و شما هیچ ایدهای ندارید دفعه قبل چیکار کردید؟
نوشتن فقط به یادآوری کمک نمیکنه، بلکه به شما کمک میکنه بهتر فکر کنید. «لاگهای ذهنی» مبهم و پراکندهتون رو به افکار ساختاریافته تبدیل میکنه. وقتی به طور مداوم ژورنال مینویسید، شروع به دیدن الگوها میکنید.
شفافیت در پیچیدگی
گاهی اوقات شما به جواب نیاز ندارید، فقط باید از دل سردرگمی بنویسید.
ژورنالنویسی شما رو مجبور میکنه بپرسید:
* داشتم سعی میکردم چیکار کنم؟
* چی اشتباه پیش رفت؟
* چی رو امتحان کردم؟
* چی بالاخره جواب داد؟
به مرور زمان، ژورنالتون تبدیل به یه گراف دانش از مغز خودتون میشه. متوجه میشید چه نوع مشکلاتی بهتون انرژی میده، سراغ چه ابزارهایی مدام میرید و معمولاً کجاها گیر میکنید و اگه دارید به برنامهنویسهای تازهکار کمک میکنید یا یه تصمیم رو برای تیم توضیح میدید؟ بفرمایید، اینم از اسناد و مدارک تو ژورنالتون.
«نوشتن، روش طبیعته برای اینکه بهت بفهمونه تفکرت چقدر گنگ و مبهمه.»
مغز شما باگ داره. ژورنالنویسی دیباگر شماست. وقتی درست انجام بشه، ژورنال شما خیلی بیشتر از یه سری لاگ و درس میشه؛ تبدیل میشه به پایگاه دانش زنده شما، خاطرات فنی شما و بله، حتی یه رزومه مخفی که هیچکس دیگهای بهش دسترسی نداره (به جز شاید خودِ آیندهتون موقع مصاحبه شغلی).
تا حالا برای جواب دادن به سوال «از زمانی بگو که بر یک چالش غلبه کردی...» به زحمت افتادید؟
حالا تصور کنید ژورنالتون رو باز کنید و بگید:
«اتفاقاً، اینجوری یه مشکل تایماوت مکرر API رو تو یه ساختار میکروسرویس با استفاده از retry queue و exponential backoff حل کردم...»
* باید یادتون بیاد اون سرویس داخلی GraphQL چطوری ساختاردهی شده بود؟
* میخواید یادتون بیاد چرا اون کتابخونه احراز هویتِ رو مخ رو منسوخ کردید؟
* باید یه طرح مهاجرت رو با یه عضو جدید تیم به اشتراک بذارید؟
ژورنالتون هواتون رو داره و به زبان خودتون نوشته شده، نه مثل یه دفترچه راهنمای استاندارد.
برای آنبوردینگ، منتورینگ و رشد تیم
وقتی یه نفر جدید به تیم شما ملحق میشه، دادن دسترسی به بخشهای تمیز شده ژورنالتون (یا مستنداتی که از ژورنال الهام گرفتن) میتونه روند یادگیریاش رو سریعتر کنه. مثل اینه که بهش راهنمای قدم به قدم شکست دادن غول آخر رو بدید به جای اینکه بگید: «موفق باشی، فقط سورس کد رو بخون.»
ردیابی رشد، موانع و بردهاتون به شما مدرک واقعی در طول جلسات یکبهیک یا دورههای ارزیابی میده. لازم نیست برای پیدا کردن مثال دست و پا بزنید، همهشون همونجان.
پس دفعه بعد که یکی گفت: «تو اصلاً تمام روز چیکار میکنی؟» شما لاگ دارید.
بیاید روراست باشیم: کدنویسی حال میده تا وقتی که دیگه حال نده.
یه روز داری کامیتهای تمیز پوش میکنی و با آهنگهای لوفای حال میکنی، روز بعد ۶ ساعته تو جهنم وابستگیها گیر کردی و داری به تمام تصمیمهای زندگیات از زمان نصب Node.js شک میکنی.
فقط نوشتن اینکه چی اشتباه شد، چی داره اذیتت میکنه یا چرا احساس میکنی گیر کردی، میتونه بار شناختی رو از دوشت برداره.
لازم نیست همه چیز رو درست کنی. فقط باید بنویسیش تا دیگه تو سرت تکرار نشه.
اشکالی نداره اگه نوشتهتون این باشه:
> ۲۲ اردیبهشت
> هنوز نمیفهمم چرا کانتینر داکر از ماشین من متنفره.
> ۳ تا ایمیج پایه مختلف رو امتحان کردم. شاید واقعاً گریهام بگیره.
> میرم یه قهوه بزنم. با مغز تازه دیباگ میکنم.
همین هم قبوله.
پیدا کردن الگوها برای مراقبت از خود
وقتی وضعیت عاطفیتون رو در طول زمان ردیابی میکنید، شروع به دیدن چیزهایی مثل این میکنید:
* وقتی استراحت نمیکنید سریعتر فرسوده میشید.
* بعد از پیادهروی صبحگاهی بهتر کد میزنید.
* بعد از جلسههای زیاد، بیشترین کلافگی رو دارید.
این یعنی خودآگاهی. و این به عادتهای پایدار برنامهنویسی منجر میشه.
—-
⬅️ هنوز تموم نشده و ادامه در قسمت بعدی
💡 تا قسمت بعدی مثل همیشه کنجکاو بمونید :)
🆔 @MdDaily
قسمت دوم
قسمت اول
اون حسی رو میشناسید که بالاخره یه باگ رو له میکنید و با خودتون فکر میکنید: «من یه نابغهام و لایق افزایش حقوقم»؟
بعد دو هفته بعد، همون باگ برمیگرده و شما هیچ ایدهای ندارید دفعه قبل چیکار کردید؟
نوشتن فقط به یادآوری کمک نمیکنه، بلکه به شما کمک میکنه بهتر فکر کنید. «لاگهای ذهنی» مبهم و پراکندهتون رو به افکار ساختاریافته تبدیل میکنه. وقتی به طور مداوم ژورنال مینویسید، شروع به دیدن الگوها میکنید.
شفافیت در پیچیدگی
گاهی اوقات شما به جواب نیاز ندارید، فقط باید از دل سردرگمی بنویسید.
ژورنالنویسی شما رو مجبور میکنه بپرسید:
* داشتم سعی میکردم چیکار کنم؟
* چی اشتباه پیش رفت؟
* چی رو امتحان کردم؟
* چی بالاخره جواب داد؟
به مرور زمان، ژورنالتون تبدیل به یه گراف دانش از مغز خودتون میشه. متوجه میشید چه نوع مشکلاتی بهتون انرژی میده، سراغ چه ابزارهایی مدام میرید و معمولاً کجاها گیر میکنید و اگه دارید به برنامهنویسهای تازهکار کمک میکنید یا یه تصمیم رو برای تیم توضیح میدید؟ بفرمایید، اینم از اسناد و مدارک تو ژورنالتون.
«نوشتن، روش طبیعته برای اینکه بهت بفهمونه تفکرت چقدر گنگ و مبهمه.»
مغز شما باگ داره. ژورنالنویسی دیباگر شماست. وقتی درست انجام بشه، ژورنال شما خیلی بیشتر از یه سری لاگ و درس میشه؛ تبدیل میشه به پایگاه دانش زنده شما، خاطرات فنی شما و بله، حتی یه رزومه مخفی که هیچکس دیگهای بهش دسترسی نداره (به جز شاید خودِ آیندهتون موقع مصاحبه شغلی).
تا حالا برای جواب دادن به سوال «از زمانی بگو که بر یک چالش غلبه کردی...» به زحمت افتادید؟
حالا تصور کنید ژورنالتون رو باز کنید و بگید:
«اتفاقاً، اینجوری یه مشکل تایماوت مکرر API رو تو یه ساختار میکروسرویس با استفاده از retry queue و exponential backoff حل کردم...»
* باید یادتون بیاد اون سرویس داخلی GraphQL چطوری ساختاردهی شده بود؟
* میخواید یادتون بیاد چرا اون کتابخونه احراز هویتِ رو مخ رو منسوخ کردید؟
* باید یه طرح مهاجرت رو با یه عضو جدید تیم به اشتراک بذارید؟
ژورنالتون هواتون رو داره و به زبان خودتون نوشته شده، نه مثل یه دفترچه راهنمای استاندارد.
برای آنبوردینگ، منتورینگ و رشد تیم
وقتی یه نفر جدید به تیم شما ملحق میشه، دادن دسترسی به بخشهای تمیز شده ژورنالتون (یا مستنداتی که از ژورنال الهام گرفتن) میتونه روند یادگیریاش رو سریعتر کنه. مثل اینه که بهش راهنمای قدم به قدم شکست دادن غول آخر رو بدید به جای اینکه بگید: «موفق باشی، فقط سورس کد رو بخون.»
ردیابی رشد، موانع و بردهاتون به شما مدرک واقعی در طول جلسات یکبهیک یا دورههای ارزیابی میده. لازم نیست برای پیدا کردن مثال دست و پا بزنید، همهشون همونجان.
پس دفعه بعد که یکی گفت: «تو اصلاً تمام روز چیکار میکنی؟» شما لاگ دارید.
بیاید روراست باشیم: کدنویسی حال میده تا وقتی که دیگه حال نده.
یه روز داری کامیتهای تمیز پوش میکنی و با آهنگهای لوفای حال میکنی، روز بعد ۶ ساعته تو جهنم وابستگیها گیر کردی و داری به تمام تصمیمهای زندگیات از زمان نصب Node.js شک میکنی.
فقط نوشتن اینکه چی اشتباه شد، چی داره اذیتت میکنه یا چرا احساس میکنی گیر کردی، میتونه بار شناختی رو از دوشت برداره.
لازم نیست همه چیز رو درست کنی. فقط باید بنویسیش تا دیگه تو سرت تکرار نشه.
اشکالی نداره اگه نوشتهتون این باشه:
> ۲۲ اردیبهشت
> هنوز نمیفهمم چرا کانتینر داکر از ماشین من متنفره.
> ۳ تا ایمیج پایه مختلف رو امتحان کردم. شاید واقعاً گریهام بگیره.
> میرم یه قهوه بزنم. با مغز تازه دیباگ میکنم.
همین هم قبوله.
پیدا کردن الگوها برای مراقبت از خود
وقتی وضعیت عاطفیتون رو در طول زمان ردیابی میکنید، شروع به دیدن چیزهایی مثل این میکنید:
* وقتی استراحت نمیکنید سریعتر فرسوده میشید.
* بعد از پیادهروی صبحگاهی بهتر کد میزنید.
* بعد از جلسههای زیاد، بیشترین کلافگی رو دارید.
این یعنی خودآگاهی. و این به عادتهای پایدار برنامهنویسی منجر میشه.
—-
🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7
مجموعه پست ژورنال کدنویسی از چیزی که فکرشو میکردم گسترده تر شد مبحثش و use case هایی میشد براش اورد و مثال زد که دلم نیومد برای مختصر کردن پست چیزی رو حذف کنم چون به نظرم خیلی کاربردین ولی درنهایت قسمت بعدی قسمت آخر و نهاییه.
احتمالا پست بعد ترش قرار راجب گیت هاب کوپایلت و اینکه چطوری دو هفته مونده بود به پایان اشتراکم حسابم رو معمولی کرد بنویسم و اینکه تو تیکت ها گردن گیرشونم خیلی خرابه و خلاصه راجب ابزار های ai یکم قرار نکات منفی کمتر گفته شدش رو بر حسب تجربه ی این دوسال برم سراغش.
فعلا open router رو بردم زیر تست . نتیجش رو توی همون پست خواهم گفت.
خلاصه که کنجکاو بمونید. دنیا به برنامه نویس های بیشتری که مفهوم و ساختار رو درک میکنن نیاز داره :)
احتمالا پست بعد ترش قرار راجب گیت هاب کوپایلت و اینکه چطوری دو هفته مونده بود به پایان اشتراکم حسابم رو معمولی کرد بنویسم و اینکه تو تیکت ها گردن گیرشونم خیلی خرابه و خلاصه راجب ابزار های ai یکم قرار نکات منفی کمتر گفته شدش رو بر حسب تجربه ی این دوسال برم سراغش.
فعلا open router رو بردم زیر تست . نتیجش رو توی همون پست خواهم گفت.
خلاصه که کنجکاو بمونید. دنیا به برنامه نویس های بیشتری که مفهوم و ساختار رو درک میکنن نیاز داره :)
❤🔥9🙏1👻1
فضای لینکدین یه طوری شده (مخصوصا فارسی) پست های مردم توی 🤖 جلوشون محتوای فاخر حساب میشن :)
🆔 @MdDaily
🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
قسمت چهارم: چرا هر برنامهنویسی به یک ژورنال کدنویسی نیاز داره؟ نه، حافظهتون کافی نیس
قسمت سوم
قسمت دوم
قسمت اول
رباتها نمیتونن مثل شما ژورنال بنویسن
هوش مصنوعی میتونه کد شما رو کامل کنه، اما نمیتونه احساسات، تصمیمها یا اینکه چرا بعد از دست زدن به CSS نزدیک بود لپتاپت رو پرت کنی، ردیابی کنه. این کار شماست و یه ژورنال جای عالی برای این کاره.
بله، حتی برنامهنویسهای ارشد هم باید این کار رو بکنن
شاید با خودتون فکر کنید: «من به ژورنال نیاز ندارم. من تجربه دارم.» آره... ولی هنوز یادت رفته فصل پیش چطوری اون باگ OAuth رو حل کردی.
ژورنالنویسی فقط برای تازهکارها نیست، یه ضریب فزاینده است، فرقی نمیکنه در چه سطحی باشید. در واقع، هرچی باتجربهتر باشید، افکارتون ارزشمندتر میشه.
ارشد بودن ≠ حافظه فوق بشری
ارشد بودن به این معنی نیست که تمام باگهایی که تو سال ۱۴۰۲ رفع کردی رو یادت میاد. به این معنیه که بیشتر اشتباه کردی و ازشون درس گرفتی.
تفکر شما تبدیل به یه نقشه راه میشه
بهترین مهندسهای ارشد فقط کد نمینویسن — اونا راهنمایی میکنن، الگوهای تصمیمگیری رو نشون میدن و یه رد از کانتکست به جا میذارن که بقیه بتونن دنبال کنن. یه ژورنال، مدلهای ذهنی شما رو ثبت میکنه.
یه روز یکی سوال ازتون میپرسه. شما ژورنالتون رو باز میکنید:
> «اردیبهشت ۱۴۰۳: منطق تلاش مجدد رو بعد از مشکل race condition تو رولاوت کوبرنتیز اضافه کردم. قطعی ۴۰ درصد کم شد. اینم از راهحل...»
این یعنی به اشتراکگذاری دانش.
رسید برای رهبری
وقتی تو جلسات استراتژی هستید یا گزارشهای فصلی رو مینویسید، ژورنالتون تبدیل به منبع حقیقت شما میشه. نه برد جیراتون، نه اسلک.
اینجوری ثابت میکنید که:
👈 شما اون مشکل رو از قبل پیشبینی کرده بودید.
👈 شما تصمیم درست رو گرفتید.
👈 شما نه فقط در کد، بلکه در شفافیت هم رشد کردید.
چطوری واقعاً این کار رو به یه عادت تبدیل کنیم
خب، تا الان احتمالاً دارید سر تکون میدید و میگید: «آره آره، ژورنالنویسی باحال به نظر میرسه، باید انجامش بدم...»
اما بیاید روراست باشیم، همه ما قبلاً اینو گفتیم.
مبارزه با غول آخر واقعی؟ ثبات قدم.
شما به یه چیزی به طرز احمقانهای ساده نیاز دارید که حتی وقتی خسته و بداخلاقید هم کار کنه.
اینجوری این عادت رو بسازید بدون اینکه هفته دوم از عصبانیت ولش کنید:
با روزی ۵ دقیقه شروع کنید
هدفتون «لاگهای زیبا و خوشساخت» نباشه. فقط هدفتون این باشه:
👈 روی چی کار کردم.
👈 کجا گیر کردم.
👈 چی یاد گرفتم (یا از یاد بردم).
واقعاً یه تایمر ۵ دقیقهای تنظیم کنید. وقتی زنگ خورد، کارتون تمومه.
اون رو به کاری که همین الان هم انجام میدید بچسبونید
یه تمپلیت قابل استفاده مجدد توی کامنت ها براتون گذاشتم که ازش استفاده کنید.
اون رو سرگرمکننده (یا حداقل قابل تحمل) کنید
👈 میم اضافه کنید. جدی میگم.
👈 از اموجی برای حال و هوا استفاده کنید (😤, 🤓, 😵💫).
👈 لینک آهنگهایی که موقع دیباگ کردن گوش میدادید رو بذارید.
👈 با ژورنالتون مثل چنجلاگ شخصیتون رفتار کنید.
ثبات قدم به معنی بینقص بودن نیست. به معنی حاضر شدنه. حتی یه بالت پوینت هم از هیچی بهتره.
خودِ آیندهتون از شما تشکر میکنه.
نتیجهگیری: وقتی بیشتر مینویسید، بهتر کد میزنید
📖 اینم خلاصه کلام برای اونایی که حال نداشتن بخونن (TL;DR):
مغزتون ۳ روز دیگه همهچیو فراموش میکنه، مگه اینکه ژورنال بنویسید:
مغز شما گیت نیست پس:
👈 تغییرات رو ردیابی نمیکنه.
👈 کانتکست رو ذخیره نمیکنه.
👈 و قطعاً از ریبوت شدن جون سالم به در نمیبره.
یه ژورنال برنامهنویسی یه نمایش بهرهوری نیست، یه ابزار بقاست. به شما کمک میکنه:
👈 یادتون بمونه چطور و چرا مشکلات رو حل کردید.
👈 تفکر خودتون رو دیباگ کنید.
👈 رشدتون رو در طول زمان ردیابی کنید.
👈 فرسودگی شغلی رو مدیریت کنید.
👈 استک اورفلو شخصی و قابل جستجوی خودتون رو بسازید.
👈 همتیمی، منتور و معمار بهتری بشید.
فرقی نمیکنه تازهکار باشید یا مدیر، فول-استک باشید یا فرانت-اند؛ نوشتن شما رو تیزتر میکنه. اینجاست که تصمیمها، اشتباهات و موفقیتهای بزرگتون دیگه در خلأ محو نمیشن.
حتی اگه هیچکس دیگهای اون رو نبینه، ژورنال شما مدرکیه که نشون میده شما حاضر بودید، با پیچیدگی دست و پنجه نرم کردید و چیزی یاد گرفتید.
و وقتی باگ بعدی از راه برسه یا مصاحبه بعدی پیش بیاد، شما فقط کد نخواهید داشت، کانتکست هم خواهید داشت.
پس امتحانش کنید. ۷ روز.
فقط روزی یک ورودی. لازم نیست فانتزی باشه. لازم نیست بینقص باشه.
فقط یه فایل باز کنید و بنویسید.
چون بهترین برنامهنویسها فقط کد تحویل نمیدن؛
اونا سفر رو ثبت میکنن.
منابع:
Source 1
Source 2
—-
💡 مثل همیشه کنجکاو بمونید :)
🆔 @MdDaily
قسمت سوم
قسمت دوم
قسمت اول
رباتها نمیتونن مثل شما ژورنال بنویسن
هوش مصنوعی میتونه کد شما رو کامل کنه، اما نمیتونه احساسات، تصمیمها یا اینکه چرا بعد از دست زدن به CSS نزدیک بود لپتاپت رو پرت کنی، ردیابی کنه. این کار شماست و یه ژورنال جای عالی برای این کاره.
بله، حتی برنامهنویسهای ارشد هم باید این کار رو بکنن
شاید با خودتون فکر کنید: «من به ژورنال نیاز ندارم. من تجربه دارم.» آره... ولی هنوز یادت رفته فصل پیش چطوری اون باگ OAuth رو حل کردی.
ژورنالنویسی فقط برای تازهکارها نیست، یه ضریب فزاینده است، فرقی نمیکنه در چه سطحی باشید. در واقع، هرچی باتجربهتر باشید، افکارتون ارزشمندتر میشه.
ارشد بودن ≠ حافظه فوق بشری
ارشد بودن به این معنی نیست که تمام باگهایی که تو سال ۱۴۰۲ رفع کردی رو یادت میاد. به این معنیه که بیشتر اشتباه کردی و ازشون درس گرفتی.
تفکر شما تبدیل به یه نقشه راه میشه
بهترین مهندسهای ارشد فقط کد نمینویسن — اونا راهنمایی میکنن، الگوهای تصمیمگیری رو نشون میدن و یه رد از کانتکست به جا میذارن که بقیه بتونن دنبال کنن. یه ژورنال، مدلهای ذهنی شما رو ثبت میکنه.
یه روز یکی سوال ازتون میپرسه. شما ژورنالتون رو باز میکنید:
> «اردیبهشت ۱۴۰۳: منطق تلاش مجدد رو بعد از مشکل race condition تو رولاوت کوبرنتیز اضافه کردم. قطعی ۴۰ درصد کم شد. اینم از راهحل...»
این یعنی به اشتراکگذاری دانش.
رسید برای رهبری
وقتی تو جلسات استراتژی هستید یا گزارشهای فصلی رو مینویسید، ژورنالتون تبدیل به منبع حقیقت شما میشه. نه برد جیراتون، نه اسلک.
اینجوری ثابت میکنید که:
چطوری واقعاً این کار رو به یه عادت تبدیل کنیم
خب، تا الان احتمالاً دارید سر تکون میدید و میگید: «آره آره، ژورنالنویسی باحال به نظر میرسه، باید انجامش بدم...»
اما بیاید روراست باشیم، همه ما قبلاً اینو گفتیم.
مبارزه با غول آخر واقعی؟ ثبات قدم.
شما به یه چیزی به طرز احمقانهای ساده نیاز دارید که حتی وقتی خسته و بداخلاقید هم کار کنه.
اینجوری این عادت رو بسازید بدون اینکه هفته دوم از عصبانیت ولش کنید:
با روزی ۵ دقیقه شروع کنید
هدفتون «لاگهای زیبا و خوشساخت» نباشه. فقط هدفتون این باشه:
واقعاً یه تایمر ۵ دقیقهای تنظیم کنید. وقتی زنگ خورد، کارتون تمومه.
اون رو به کاری که همین الان هم انجام میدید بچسبونید
یه تمپلیت قابل استفاده مجدد توی کامنت ها براتون گذاشتم که ازش استفاده کنید.
اون رو سرگرمکننده (یا حداقل قابل تحمل) کنید
ثبات قدم به معنی بینقص بودن نیست. به معنی حاضر شدنه. حتی یه بالت پوینت هم از هیچی بهتره.
خودِ آیندهتون از شما تشکر میکنه.
نتیجهگیری: وقتی بیشتر مینویسید، بهتر کد میزنید
مغزتون ۳ روز دیگه همهچیو فراموش میکنه، مگه اینکه ژورنال بنویسید:
مغز شما گیت نیست پس:
یه ژورنال برنامهنویسی یه نمایش بهرهوری نیست، یه ابزار بقاست. به شما کمک میکنه:
فرقی نمیکنه تازهکار باشید یا مدیر، فول-استک باشید یا فرانت-اند؛ نوشتن شما رو تیزتر میکنه. اینجاست که تصمیمها، اشتباهات و موفقیتهای بزرگتون دیگه در خلأ محو نمیشن.
حتی اگه هیچکس دیگهای اون رو نبینه، ژورنال شما مدرکیه که نشون میده شما حاضر بودید، با پیچیدگی دست و پنجه نرم کردید و چیزی یاد گرفتید.
و وقتی باگ بعدی از راه برسه یا مصاحبه بعدی پیش بیاد، شما فقط کد نخواهید داشت، کانتکست هم خواهید داشت.
پس امتحانش کنید. ۷ روز.
فقط روزی یک ورودی. لازم نیست فانتزی باشه. لازم نیست بینقص باشه.
فقط یه فایل باز کنید و بنویسید.
چون بهترین برنامهنویسها فقط کد تحویل نمیدن؛
اونا سفر رو ثبت میکنن.
منابع:
Source 1
Source 2
—-
🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7
Audio
پادکست مجموعه سری چرا هر برنامهنویسی به یک ژورنال کدنویسی نیاز داره؟ نه، حافظهتون کافی نیس
تولید شده توسط notebooklm
—-
💡 مثل همیشه کنجکاو بمونید :)
🆔 @MdDaily
تولید شده توسط notebooklm
—-
🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥3❤1👻1
داشتم تو یه پروژه های گیت هاب میگشتم رسیدم به این شاهکار :)
تاحالا شده برای تبدیل فایل هاتون به فرمت های مختلف مجبور شده باشید برید سراغ نرم افزار های شخص ثالث یا کرکی یا سایت های آنلاینی که نگران حریم شخصیتون باشید و شامل محدودیت و تبلیغ باشند؟
پروژه VERT میاد با استفاده از وب اسمبلی و روی لوکال دستگاهتون تبدیل ها رو انجام میده.
میتونید نسخه ی شخصی خودتون رو بیارید بالا یا از https://vert.sh/ استفاده کنید.
🌐 وبسایت:
https://vert.sh/
👩💻 گیت هاب:
https://github.com/VERT-sh/VERT
—-
💡 مثل همیشه کنجکاو بمونید :)
🆔 @MdDaily
تاحالا شده برای تبدیل فایل هاتون به فرمت های مختلف مجبور شده باشید برید سراغ نرم افزار های شخص ثالث یا کرکی یا سایت های آنلاینی که نگران حریم شخصیتون باشید و شامل محدودیت و تبلیغ باشند؟
پروژه VERT میاد با استفاده از وب اسمبلی و روی لوکال دستگاهتون تبدیل ها رو انجام میده.
میتونید نسخه ی شخصی خودتون رو بیارید بالا یا از https://vert.sh/ استفاده کنید.
https://vert.sh/
https://github.com/VERT-sh/VERT
—-
🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11❤8👻2