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


🆔 @MdDaily

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

منابع:
Source 1
Source 2

—-

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

🆔 @MdDaily

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

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

—-

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

🆔 @MdDaily

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

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

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

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

🌐 وبسایت:

https://vert.sh/

👩‍💻 گیت هاب:

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



—-

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

🆔 @MdDaily

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

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

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

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

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

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

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

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

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

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

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

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

—-

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

🆔 @MdDaily

🖤👑🖤
درود به همگی

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


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

🕊به امید دنیایی بدون جنگ و در صلح

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

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

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

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

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

—-

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

🆔 @MdDaily

واقعا خلاقیت :)

قضیه از این قراره که این دوستمون داشته یه مستند از 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

#ام_دی_کورس


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

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

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

لینک مقاله:

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

—-

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

🆔 @MdDaily

#ام_دی_کورس


ترکیب 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

🖥 قبل از کدزنی: آیا ایده 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

🖥 قبل از کدزنی: آیا ایده SaaS تو واقعا پول‌سازه؟ (قسمت 2 از 2 - پایانی)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

هدف این نیست که وجود یه مشکل رو اعتبارسنجی کنی.
هدف اینه که اعتبارسنجی کنی که می‌تونی اون مشکل رو به صورت سودآور حل کنی.

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

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


—-

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

🆔 @MdDaily

اگه به حوزه ی استارتاپ علاقه دارید این منابع رو هم بهتون پیشنهاد میکنم:

📖 کتاب اجرای ناب (running lean) از ash maurya

📖 کتاب راهنمای تولید ناب از dan olsen

🎙️ پادکست Papyrus |پاپیروس | خلاصه کتاب کسب و کار تو کست باکس (https://castbox.fm/vh/6358611) | مخصوصا اپیزود نوپای ناب

🆔 @MdDaily

👨‍💻تاحالا فکر کردید چطور می‌شه توی یه پروژه از چندتا زبان برنامه‌نویسی مختلف کنار هم استفاده کرد؟ مثلاً یه تیکه کد به زبان C داشته باشیم که یه تابع از زبان Rust رو صدا بزنه؟ داشتم یه ویدیو تو یوتیوب می‌دیدم که دقیقاً همین موضوع رو با جزئیات خیلی خوبی توضیح می‌ده. اگه فکر می‌کنید کامپایلرها صرفا کد شما رو مستقیم به فایل اجرایی تبدیل می‌کنن، این ویدیو حسابی غافلگیرتون می‌کنه!

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

ویدیو توضیح می‌ده که فرآیند کامپایل یه مسیر چند مرحله‌ایه، نه یه تبدیل آنی. مثلاً برای زبان C با کامپایلر GCC این مراحل رو داریم:

⬅️ 1. پیش‌پردازش (Pre-processing): کدهای اضافی مثل کامنت‌ها حذف و ماکروها با کد اصلی جایگزین می‌شن.

⬅️ 2. کامپایل (Compilation): کد آماده‌شده به زبان اسمبلی (Assembly) ترجمه می‌شه که یه نسخه قابل فهم‌تر برای انسانه .

⬅️ 3. اسمبلی (Assembly): کد اسمبلی به زبان ماشین (کد باینری) تبدیل و یه فایل آبجکت (object file) ساخته می‌شه .

⬅️ 4. لینک (Linking): اینجاست که جادو اتفاق می‌افته! لینکر میاد فایل‌های آبجکت مختلف (که می‌تونن از زبان‌های مختلف باشن) و کتابخونه‌ها رو به هم می‌چسبونه و فایل اجرایی نهایی رو تحویل می‌ده.

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

اما چطور این زبان‌ها با هم حرف می‌زنن؟ اینجا یه مفهوم کلیدی به اسم ABI (Application Binary Interface) وارد می‌شه . ABI مثل یه قرارداد بین‌المللی برای کدهای باینریه. این قرارداد مشخص می‌کنه که توابع چطور باید داده‌ها رو به هم پاس بدن و خروجی رو برگردونن تا همه چیز درست کار کنه . زبان‌های مدرن ابزارهایی مثل extern در C و Rust یا bind در FORTRAN رو فراهم کردن تا مطمئن بشن کدی که تولید می‌کنن، از این قراردادها پیروی می‌کنه.

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

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

---

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

🆔 @MdDaily

داشتم یه پست از Nimrod Kramer میخوندم، می‌گفت:


کافیه دیگه. مهندسی پرامپت، مهندسی نیست. (Prompt engineering is not engineering)

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

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

این کار بیشتر به وِرد خوندن شبیهه تا توسعه نرم‌افزار.

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

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

بیاید به کلمات احترام بذاریم. هر چیزی که بوی تکنولوژی می‌ده، لازم نیست لباس مهندسی تنش کنه.


---

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

🆔 @MdDaily