Md Daily – Telegram
Md Daily
729 subscribers
239 photos
15 videos
21 files
283 links
راجب مقالات و مستندات فنی یا غیر فنی که میخونم و علایقم اینجا مینویسم :)


گروه کانال: https://news.1rj.ru/str/MdDailyGap

کورس ها: https://news.1rj.ru/str/MdDaily/395

وبلاگ: https://mddaily.ir
Download Telegram
قسمت اول: چرا هر برنامه‌نویسی به یک ژورنال کدنویسی نیاز داره؟ نه، حافظه‌تون کافی نیست


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

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

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


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

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

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

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


قبل از راه حل بریم ببینیم مشکل از کجا میاد. ما همه چیز رو مستند می‌کنیم به جز سفر خودمون: تلاش‌های ناموفق، بردهای کوچیک، راه‌حل‌های سریع و درس‌هایی که به روش سخت یاد گرفتیم. ما برای بقیه فایل 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

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

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

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

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

* «من 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
1032👻2🙏1
قسمت سوم: چرا هر برنامه‌نویسی به یک ژورنال کدنویسی نیاز داره؟ نه، حافظه‌تون کافی نیس
قسمت دوم
قسمت اول

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> ۲۲ اردیبهشت

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

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

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

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

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

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

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

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

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

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

—-

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

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

🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
72🙏1👻1
مجموعه پست ژورنال کدنویسی از چیزی که فکرشو میکردم گسترده تر شد مبحثش و use case هایی میشد براش اورد و مثال زد که دلم نیومد برای مختصر کردن پست چیزی رو حذف کنم چون به نظرم خیلی کاربردین ولی درنهایت قسمت بعدی قسمت آخر و نهاییه.

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

فعلا open router رو بردم زیر تست . نتیجش رو توی همون پست خواهم گفت.

خلاصه که کنجکاو بمونید. دنیا به برنامه نویس های بیشتری که مفهوم و ساختار رو درک میکنن نیاز داره :)
❤‍🔥9🙏1👻1
Please open Telegram to view this post
VIEW IN TELEGRAM
فضای لینکدین یه طوری شده (مخصوصا فارسی) پست های مردم توی 🤖 جلوشون محتوای فاخر حساب میشن :)


🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
8🤣5👻2
قسمت چهارم: چرا هر برنامه‌نویسی به یک ژورنال کدنویسی نیاز داره؟ نه، حافظه‌تون کافی نیس
قسمت سوم
قسمت دوم
قسمت اول

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

منابع:
Source 1
Source 2

—-

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

🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
72❤‍🔥1👻1
Audio
پادکست مجموعه سری چرا هر برنامه‌نویسی به یک ژورنال کدنویسی نیاز داره؟ نه، حافظه‌تون کافی نیس

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

—-

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

🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
❤‍🔥31👻1
داشتم تو یه پروژه های گیت هاب میگشتم رسیدم به این شاهکار :)

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

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

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

🌐 وبسایت:

https://vert.sh/

👩‍💻 گیت هاب:

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



—-

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

🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
👍118👻221
هوش مصنوعی تو کدنویسی: تجربه بی‌تعارف!

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

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

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

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

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

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

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

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

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


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

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

—-

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

🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍1211👌1👻1
به نظرم فرایند نوشتن change logs و لیست تغییرات پروژه اضافه کاریه یه "مشکلات قبلیو حل کردیم و مشکلات جدیدی بوجود اوردیم که بعدا حلش کنیم" بنویسید بره دیگه :)


🆔 @MdDaily
😁5🤣41👎1👻1
🖤👑🖤
درود به همگی

امیدوارم هرجایی هستید در سلامتی باشید و خیلی مراقب خودتون باشید.


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

🕊به امید دنیایی بدون جنگ و در صلح
Please open Telegram to view this post
VIEW IN TELEGRAM
10👎2👍1🕊1👻1
یکی از مشکلاتی که این چند وقته برای اتصال به اینترنت داشتم این بود که مثلا بعضی وقتا من قطع بودم بقیه وصل بودن و بعضی وقتا من وصل بودم ولی بقیه قطع بودن و دنبال راهی بودم که بشه کانفیگ هامون رو باهم به اشتراک بگذاریم. به دلیل مسائلی مثل حریم شخصی هم ترجیحم استفاده از سرویس های آنلاین موجود نبود.

برای همین پروژه ی subgen رو نوشتم. فقط کافیه رو یک سرور ایران اجراش کنید و بهتون یه نسخه ی cli برای مدیریت ادمین ها میده و در نهایت یه پنل ادمین تحت وب برای مدیریت کانفیگ هاتون. در آخر بهتون یه لینک ساب میده که uuid اشم میتونید تغییر بدید و در اختیار دوستاتون بذارید.

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

👩‍💻 https://github.com/mdpe-ir/subgen

پیشنهاد میشه به دلیل وضعیت بد سرور های ایران در ارتباط با خارج روی سیستم خودتون بیلد اش رو بگیرید و به همراه فایل های assets زیپ کنید و آپلود کنید توی سرورتون


—-

💡 مثل همیشه کنجکاو بمونید :)
🕊به امید دنیایی بدون جنگ و در صلح

🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
🕊84🔥1👻1
واقعا خلاقیت :)

قضیه از این قراره که این دوستمون داشته یه مستند از Supabase تماشا می‌کرده که به یه چیز عجیب و غریب برمی‌خوره: یه کافی‌شاپ ترمینالی به اسم @terminaldotshop که کلاً باید با SSH توش می‌چرخیدی.

همین موضوع عجیب و باحال، یه ایده‌ای رو تو سرش می‌ندازه:
«چی می‌شه اگه یه نمونه کار (پورتفولیو) برای دولوپرها درست کنم که طرف بتونه کامل از تو ترمینال بازش کنه؟»

این‌جوری می‌شه terminalfolio.xyz رو می‌سازه. یعنی شما می‌تونید با این دستور بهش وصل بشید:

ssh terminalfolio.xyz


نه خبری از مرورگره، نه CSS. فقط و فقط ترمینال!

با چه ابزارهایی این کار رو کرده؟

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

🧠 ‏React + Ink


اومده رابط کاربری (UI) ترمینال رو با Ink درآورده. Ink یه کتابخونه شبیه React هست که برای ساختن ابزارهای خط فرمان (CLI) تعاملی استفاده می‌شه. این‌طوری تونسته ساختار رابط کاربریش رو با کامپوننت‌های آشنای React بچینه.
فکرش رو بکنید، useState() رو با Box و Text و حتی منطق مسیریابی (routing) ترکیب کرده، اونم همه‌اش توی ترمینال!

🖥 سرور SSH با Golang


برای اینکه بشه با دستور ssh terminalfolio.xyz به اپلیکیشن دسترسی داشت، یه سرور SSH سفارشی با Go نوشته. کار این سرور اینه که اتصال رو مدیریت کنه، اپلیکیشن CLI رو اجرا کنه و به کاربرها یه تجربه‌ی روون و باحال بده، انگار که دارن با یه اپلیکیشن ترمینالی واقعی کار می‌کنن.

🧪 چالش‌هایی که داشته

* رندر کردن UI داینامیک توی ترمینال: می‌گه لایه انتزاعی (abstraction) که Ink می‌ده خیلی کمک کرده، ولی در کل طراحی تجربه کاربری (UX) برای CLI یه دنیای دیگه‌ست و ذهنیت متفاوتی می‌خواد.

* تجربه کاربری SSH: برخلاف سایت‌ها، توی SSH خبری از هاور (hover)، اسکرول راحت یا انیمیشن‌های نرم و روون نیست. باید کاری می‌کرده که حس کار با خود خط فرمان رو بده.

اصلاً چرا یه پورتفولیو ترمینالی؟


به نظرش راه باحالی بوده تا React، Golang و مفاهیم شبکه سطح پایین (low-level networking) رو با هم قاطی کنه و در کل، برای دل خودش یه پروژه فان ساخته باشه.


شبکه اجتماعی Abde Laziz:

✖️ https://x.com/gugocharade

—-

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

🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥141👻1
قبل تر ها توی کانال موضوعات مختلفیو به صورت کرش کورس میذاشتم که لیستشون رو از طریق این پیام می‌تونید ببیند :)
یکی از بچه ها پیشنهاد کرد دوباره کرش کورس ها رو داشته باشیم.

موضوعات پیشنهادی خودتون رو توی کامنت بهم بگید.
👍3🤝1
Md Daily
قبل تر ها توی کانال موضوعات مختلفیو به صورت کرش کورس میذاشتم که لیستشون رو از طریق این پیام می‌تونید ببیند :) یکی از بچه ها پیشنهاد کرد دوباره کرش کورس ها رو داشته باشیم. موضوعات پیشنهادی خودتون رو توی کامنت بهم بگید.
از اونجایی که یکی از بچه ها پیشنهاد ansible رو داد و یکی دیگه هم گفت با go یه چیز فان پیاده کنیم.

گفتم خب بیایم این دوتا رو باهم ترکیب کنیم :)

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

میشه از طریق ربات تنظمیش کرد که هر چند وقت یک بار و تو یه چه موضوعاتی بره وصل بشه به یه ای پی یه ai ای مطالبش رو تولید (تصویر و متن) کنه. بعد بیایم توی canva یه تمپلیت درست کنیم که مطالب تولید شده بره بشینه روش و در نهایت پست بشه به اینستاگرام. حتی امار پیچ اینستاگرام هم میتونیم از رباتمون بگیریم. در نهایت هم برای اماده سازیه سرور از ansible استفاده کنیم.


نظرتون چیه؟ یا اگه ایده ای دارید خوشحال میشم بشنوم.


به نظرتون به صورت پست تلگرامی منتشر کنم یا به صورت پست وبلاگ؟


- پست تلگرامی ری اکشن 🤝
- پست وبلاگ ری اکشن
13🤝13❤‍🔥1👍1👎1👻1
#ام_دی_کورس


ترکیب Go و Ansible: محتوای AI با طعم اینستاگرام! (قسمت اول)


خب به اولین قسمت از این مجموعه آموزشی خوش آمدید. طبق پستی که توی کانال منتشر کردم . قرار شد باهم با استفاده از Go یه تولید کننده ی محتوایی اینستاگرامی بسازیم که تنظیماتش از طریق یه ربات تلگرامی قابل انجام هست و در نهایت برای دیپلوی و تنظیمات سرور از Ansible استفاده کنیم. خبر خوب برای این آموزش اینکه شما نیازی نیست حتما یک سرور داشته باشید و قرار همه چیز رو به صورت لوکال پیاده کنیم از نصب یک سرور اوبونتو روی مجازی ساز گرفته تا بقیه ی کار ها. ولی خب در صورتی هم که سرور دارید میتونید روی سرور تست کنید 🙂

قبل از اینکه بریم سراغ ربات تلگرامی و کانفیگ سرور اول از همه بیاید باهم یه mvp از چیزی که میخوایم داشته باشید اماده کنیم. هدف چیه؟ پیاده سازی یک Core با گولنگ که بتونه در مرحله ی اول وص.....


لینک مقاله:

🔗https://mddaily.ir/ترکیب-go-و-ansible-محتوای-ai-با-طعم-اینستاگرام-قس/

—-

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

🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
8😐1👻1
چند وقتیه دارم کتاب اجرای ناب (Running Lean) رو میخونم

کلا توی حوزه ی راه اندازی استارتاپ منابع اموزشی مربوط به متود lean خیلی کمک کننده هستند. به طور خلاصه این متود یک رویکرد مدیریت پروژه است که هدفش بهینه‌سازی فرآیندها و حذف موارد اضافیه.



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


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


اگه فقط یادگیری و تمرکز داشته باشید یا منابعتون تموم میشه یا رقبا ازتون میزنن جلو


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

—-

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

🆔 @MdDaily
👍21❤‍🔥1👻1
#ام_دی_کورس


ترکیب Go و Ansible: محتوای AI با طعم اینستاگرام! (قسمت دوم)


در قسمت دوم آموزش یاد میگیریم چطور تمپلیت اینستاگرام رو با استفاده از طرح Figma آماده و سفارشی‌سازی کنیم، شامل تغییر محل نام کاربری، متن و شماره پست. با فونت «وزیر متن» برای نمایش متن فارسی کار کردیم و پروژه رو در Go با پوشه‌های assets برای فونت و تمپلیت و ماژول postgen شامل فایل‌های generator.go، image_utils.go و text_utils.go سازمان‌دهی کردیم. متغیر INSTAGRAM_USERNAME رو به فایل .env اضافه کردیم و struct جدید InstagramConfig رو در config.go تعریف کردیم. پکیج writer رو برای نوشتن متن فارسی روی تصاویر نصب و استفاده کردیم. فانکشن ParseHexColor رو برای تبدیل کد رنگ هگزادسیمال به فرمت RGBA پیاده‌سازی کردیم. با پکیج image، تصاویر رو بارگذاری و پردازش کردیم، کپی از تصویر اصلی ساختیم و متن رو با مختصات دقیق از Figma روش نوشتیم. فانکشن PostGen رو برای قرار دادن نام کاربری روی تمپلیت و ذخیره خروجی به‌صورت فایل ....



لینک مقاله:

🔗https://mddaily.ir/ansible-go-ig-ai-part2/

—-

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

🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
5👌21
🖥 قبل از کدزنی: آیا ایده SaaS تو واقعا پول‌سازه؟ (قسمت 1 از 2)

خیلی‌ها عمر و پولشون رو پای ساخت محصولاتی می‌ذارن که هیچ‌کس نمی‌خواد. داشتم مقاله ی How I'd Validate a SaaS Idea in 2025 (Without Writing Code)
رو میخوندم از یه بنیان‌گذار که می‌گفت: "کاش زودتر می‌فهمیدم چطور ایده‌هام رو اعتبارسنجی کنم، قبل از اینکه یه خط کد بنویسم." اون می‌گفت اگه الان بخواد یه ایده SaaS رو ارزیابی کنه، قبل از یک خط کد نوشتن، این کارها رو انجام می‌ده. نه ساخت لندینگ پیج، نه جمع‌آوری ایمیل. فقط ترفندهایی که آرزو می‌کرد کاش زودتر می‌دونستشون.

📌 مشکل مهم نیست، پرداخت مهمه

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


📌 تست "در قلابی (Fake Door)": روشی که واقعاً کار می‌کنه!

یه لندینگ پیج با فرم ایمیل، فقط یه عدد بی‌معنیه. بنیان‌گذار میگفت من ۲۰۰۰ ایمیل جمع کردم و فقط ۳ مشتری پولی داشتم! روش کارآمد اینه: یه صفحه ساده بساز که راه‌حل تو رو توضیح بده (نه مشکل). قیمت واقعی رو بذار. دکمه "شروع" بذار. بعد از کلیک: "ظرفیت محدوده، می‌خواید با ما تماس بگیرید تا دستی وارد سیستمتون کنیم؟" توی تماس، راستشو بگو: "ما تازه شروع کردیم و این کار رو فعلاً دستی انجام می‌دیم. در عوض، یه سرویس ویژه و شخصی می‌گیرید." اگه پاپس کشیدن؟ خب، اونا هرگز مشتری نمی‌شدن. اگه هنوز علاقه‌مند بودن؟ تبریک! اعتبارسنجی شد. اون میگفت با این روش، ۳۰٪ تماس‌ها رو به مشتری پولی تبدیل کرده، قبل از یه خط کد!


📌 اول دستی انجام بده، بعداً اتوماتیک کن

برنامه‌نویس‌ها عاشق ساختنن، ولی سریع‌ترین راه برای اعتبارسنجی اینه که خودت محصول بشی! مثلاً اگه ابزار فاکتور می‌سازی، فاکتورهای ۵ مشتری رو دستی براشون صادر کن. اگه ابزار زمان‌بندی شبکه‌های اجتماعی می‌سازی، پست‌ها رو با اکسل دستی زمان‌بندی کن. اینجوری می‌فهمی: روند واقعی کار چیه، کدوم ویژگی‌ها مهمن، و آیا وقتی مشکل حل میشه، مردم واقعاً پول میدن؟ یه نفر ۳ ماه "ربات انسانی" بود و با این روش یه SaaS با $50k درآمد سالانه رو اعتبارسنجی کرد. وقتی شروع به کد زدن کرد، دقیقاً می‌دونست چی می‌خواد.


📌 مدل MVP شخصی واقعی: چارچوب ۶ هفته‌ای

همه تئوری MVP شخصی (Concierge MVP) رو بلدن. ولی تو عمل، تقریباً هیچکی درست انجامش نمیده.

مدل Concierge MVP (مخفف Minimum Viable Product) به زبان ساده یعنی اینکه به جای اینکه اول یک محصول کامل و خودکار بسازی، خدمت یا راه‌حل رو به‌صورت دستی و شخصی به مشتری‌های اولیه ارائه بدی.
هدف این روش اینه که قبل از هرگونه کدنویسی یا سرمایه‌گذاری زیاد، بفهمی آیا اصلا مردم حاضرن برای این راه‌حل پول بدن و مشکلشون واقعاً حل میشه یا نه. اینجوری، هم نیازها و مشکلات واقعی مشتری رو عمیق‌تر درک می‌کنی و هم ریسک هدر رفتن وقت و پولت رو به شدت کم می‌کنی



این چارچوبی که واقعاً جواب میده:

* هفته ۱-۲: ۱۰ مشتری بالقوه پیدا کن (نه دوست و آشنا).

* هفته ۳: پیشنهاد بده مشکلشون رو دستی حل کنی، با ۵۰٪ تخفیف از قیمت نهایی.

* هفته ۴: سرویس رو ارائه بده و همه جزئیات رو یادداشت کن.

* هفته ۵: بازخورد و پول رو بگیر.

* هفته ۶: تصمیم بگیر اصلا ارزش ساختن داره یا نه.

اگه نتونستی ۱۰ نفر رو پیدا کنی که باهاشون صحبت کنی، یعنی بازارت خیلی کوچیکه.

اگه نتونستی ۳ نفر رو راضی کنی که با ۵۰٪ تخفیف امتحانش کنن، یعنی مشکلشون به اندازه کافی جدی نیست.

اگه امتحانش کردن ولی پول ندادن، یعنی راه‌حل تو کار نمی‌کنه.

بدون کد. بدون لندینگ پیج. فقط اعتبارسنجی خالص.


📌 معدن طلای "مشتری‌های رقبا"

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

—-

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

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

🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
👌92🐳1
Md Daily
🖥 قبل از کدزنی: آیا ایده SaaS تو واقعا پول‌سازه؟ (قسمت 1 از 2) خیلی‌ها عمر و پولشون رو پای ساخت محصولاتی می‌ذارن که هیچ‌کس نمی‌خواد. داشتم مقاله ی How I'd Validate a SaaS Idea in 2025 (Without Writing Code) رو میخوندم از یه بنیان‌گذار که می‌گفت: "کاش زودتر…
🖥 قبل از کدزنی: آیا ایده SaaS تو واقعا پول‌سازه؟ (قسمت 2 از 2 - پایانی)

📌 اول قیمت، بعد محصول!

این عجیب‌ترین توصیه‌ایه که بنیان گذار بهمون می‌کنه: قیمت‌گذاری رو قبل از اینکه بدونی چی می‌خوای بسازی مشخص کن.
چرا؟ چون قیمت‌گذاری همه چی رو تعیین می‌کنه:

* مشتری‌هات کیا هستن.

* چه ویژگی‌هایی مهمن.

* چقدر می‌تونی پشتیبانی بدی.

* اصلا مدل کسب و کارت جواب میده یا نه.

اگه داری به ماهی ۱۰ دلار فکر می‌کنی، به هزاران مشتری نیاز داری. این یه بازی کاملا فرق داره.
اگه داری به ماهی ۵۰۰ دلار فکر می‌کنی، فقط به چند ده مشتری نیاز داری. اعتبارسنجیش هم کلا فرق می‌کنه.
چارچوب اعتبارسنجی قیمتم:

* قیمت ۱۰ تا از رقیباتو پیدا کن.

* با ۵ تا از مشتری‌های فعلی تو این حوزه صحبت کن.

* بپرس: "قیمت فلان محصول چقدر باید باشه که انتخابش براتون بی‌چون و چرا بشه؟"

* قیمت خودتو ۷۰٪ اون عدد تعیین کن.

* بعد اعتبارسنجی کن که آیا می‌تونی با اون قیمت، ارزش مورد نظر رو بدی یا نه.

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

📌 قانون "۱۰ مشتری"

قانون شخصی بنیان گذار میگفت: اگه نتونم ۱۰ مشتری پولی رو تصور کنم، نمی‌سازمش. نه ۱۰ نفر علاقه‌مند، نه ۱۰ ایمیل. ۱۰ نفر با کارت بانکی آماده. باید بتونی اسمشون رو بگی. نه "کسب‌وکارهای کوچک" یا "فریلنسرها". بلکه اسم واقعی یا شرکت‌های مشخص. این مجبورت می‌کنه دقیق بشی. "مدیران پروژه شرکت‌های ۵۰ نفره SaaS که از Jira متنفرن" قابل اعتبارسنجیه. "آدم‌هایی که ابزار بهره‌وری می‌خوان" نیست.
اگه می‌تونی اسم ۱۰ تا مشتری بالقوه رو بگی و بگی چطور بهشون دسترسی پیدا می‌کنی، پس یه چیزی تو دستت داری.

📌 نپرس "آیا حاضری؟"، بپرس "آیا انجام دادی؟"

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

📌 تست "بازگشت وجه": پول پیش از محصول!

یه ترفند وقت‌گیر: محصولی که هنوز وجود نداره رو با ضمانت بازگشت وجه بفروش. مثلاً: "امروز $49 پرداخت کنید. اگه نتونستیم [نتیجه مشخص] رو تو ۳۰ روز بهتون تحویل بدیم، پولتون رو پس می‌گیرید." بعد اون نتیجه رو دستی بهشون بده. اگه نشد، پس بده. مزایاش: ۱. مجبورت می‌کنه قول‌های ملموس بدی. ۲. حساسیت به قیمت رو با پول واقعی اعتبارسنجی می‌کنه. ۳. یاد می‌گیری آیا راه‌حل تو واقعاً کار می‌کنه. اگه همه پولشون رو پس خواستن، با هزینه کم فهمیدی ایده جواب نمیده. این اعتبارسنجی ارزونه! اگه بیش از ۷۰٪ پولشون رو پس نگرفتن و ادامه دادن؟ تبریک، تو یه کسب‌وکار داری!

📌 کی باید بیخیال شد (سخت‌ترین قسمت)

اکثر ایده‌ها باید تو مرحله اعتبارسنجی بمیرن. اگه این شرایط رو داشتی، بیخیال شو: نتونستی ۱۰ نفر رو پای تلفن بیاری. کمتر از ۳۰٪ مردم به پرداخت پول علاقه‌مند بودن. نسخه دستی تو بیش از ۵۰٪ درخواست بازگشت وجه داشت. نمی‌تونی با هیچ قیمتی، سودآور باشی. مدل اقتصادیت حتی در مقیاس بزرگ هم جواب نمیده. پیوت نکن، هی تغییر نده. برو سراغ ایده بعدی. مثالی که توی مقاله اومده بود میگفت کشتن ۳ ایده در مرحله اعتبارسنجی، ۱۸ ماه وقتش رو نجات داده و این شکست نیست، زرنگیه!

📌 ابزارهای اعتبارسنجی که واقعاً کار می‌کنه

اگه قرار بود فردا یه ایده SaaS جدید رو اعتبارسنجی بشه، این برنامه دقیق ۳۰ روزه ایه که تو مقاله گفته شده بود:

* روز ۱-۵: تحقیق در مورد رقبا، پیدا کردن نقاط ضعفشون از دید مشتری.

* روز ۶-۱۰: ۲۰ مکالمه با مشتری‌های بالقوه.

* روز ۱۱-۱۵: ساختن تست "در قلابی" با قیمت‌گذاری واقعی.

* روز ۱۶-۲۰: وارد کردن ۱۰ نفر به دوره آزمایشیِ دستیِ پولی.

* روز ۲۱-۲۵: ارائه سرویس به صورت دستی، ثبت کردن همه چیز.

* روز ۲۶-۳۰: جمع‌آوری پرداخت یا کشتن ایده.

بدون کد. بدون لندینگ پیج. بدون لیست انتظار.

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

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


هر کار دیگه‌ای جز این، فقط پول حروم کردن و وقت تلف کردنه.

نکته آخر: ۹۰٪ چیزهایی که مردم در اعتبارسنجی می‌گن رو فراموش می‌کنی. هر مخالفت، هر "اگه اینطور بود..." و هر "تقریباً"، نقشه راه واقعی محصول توئه. از روز اول همه این‌ها رو ثبت کن. خود آینده‌ات ازت تشکر می‌کنه!


—-

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

🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
👏6🔥3👍1👻1