#ام_دی_کورس


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

اگه دنبال مجموعه ابزارهایی هستید که موقع توسعه کارتون رو سریع تر کنن، پس حتما dev tools رو امتحان کنید :)

مجموعه از ابزار های مختلفیو مثل :

- JSON Viewer

- QR Code Generator

- Markdown

- CRON Calculator

- Color Palette Generator

و .... رو با تمرکز روی privacy در اختیارتون میذاره.

ترکیب این سایت با CyberChef که به چاقوی سوئیسی سایبری معروفه میتونه خیلی کمک کننده باشه.

🌐 https://dev-tool.dev/


🌐 https://gchq.github.io/CyberChef/


---

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

🆔 @MdDaily

پاول دورف به مناسبت 2️⃣1️⃣ سالگی تلگرام توی کانالش نقل قول هایی جالبی از پدرش گفته :

👨‍🏫 یک ماه پیش، پدرم — که از برجسته‌ترین متخصصان ادبیات روم باستان است — ۸۰ ساله شد. از او پرسیدم چه توصیه‌ای را باید به نسل بعد منتقل کنم. او سه نکته به من گفت:

👨‍💻 ۱. با عمل رهبری کنید. مردم — به‌ویژه کودکان — آنچه انجام می‌دهید را دنبال می‌کنند، نه آنچه می‌گویید. تماشای تلاش خستگی‌ناپذیر پدرم در نگارش کتاب‌ها و مقالات علمی فراوان، به من و برادرم معنای فداکاری را نشان داد و ما را به سخت‌کوشی نیز برانگیخت.

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

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

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

یا مثلا خوشحال کردن یه نفر دیگه به خودیه خود کار قشنگیه نه اینکه کسیو خوشحال کنیم و منتظر جبرانش باشیم :)

با بی دریغ انجام دادن دنیا رو به جای بهتری تبدیل کنیم ❤️


---

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

🆔 @MdDaily

👩‍💻 نسخه‌ی جدید فلاتر، یعنی Flutter 3.35، منتشر شده و کلی قابلیت هیجان‌انگیز با خودش آورده که تمرکزشون بیشتر روی بالا بردن سرعت و کیفیت کدنویسیه. بیاید چندتا از باحال‌ترین‌هاش رو با هم ببینیم.

🔥 هات ری‌لود پایدار برای وب

اولین خبر مهم برای اوناییه که با فلاتر برای وب کد می‌زنن: Stateful Hot Reload برای وب بالاخره پایدار شد! دیگه لازم نیست برای دیدن هر تغییر کوچیکی کل صفحه رو رفرش کنید. از این به بعد، مثل اپ‌های موبایل، تغییرات رو به صورت لحظه‌ای و با حفظ state برنامه می‌بینید. این یعنی یه جهش بزرگ توی سرعت توسعه‌ی وب با فلاتر!

🖼 پیش‌نمایش زنده ویجت‌ها (Widget Previews)

قابلیت شگفت‌انگیز این نسخه، معرفی Widget Previews به صورت آزمایشیه! اگه با ابزارهایی مثل Storybook توی دنیای وب کار کرده باشید، دقیقاً می‌دونید این چیه. این قابلیت بهتون اجازه می‌ده ویجت‌هاتون رو به صورت کاملاً ایزوله و جدا از کل اپلیکیشن ببینید، تست کنید و توسعه بدید. می‌تونید یه ویجت رو همزمان توی سایزهای مختلف صفحه، با تم‌های روشن و تاریک و فونت‌های متفاوت کنار هم ببینید. برای ساختن دیزاین سیستم یا تست کردن کامپوننت‌ها فوق‌العاده‌ست!

⚙️ بهبودهای موتور رندرینگ Impeller

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

⬅️ کاهش زمان استارت اپ: برنامه‌ها سریع‌تر از قبل بالا میان.

⬅️ بهینه‌سازی رندر کردن مسیرها (Path rendering): انیمیشن‌ها و UIهای پیچیده عملکرد بهتری دارن.

⬅️ افزایش کیفیت بصری: افکت‌هایی مثل blur حالا تمیزتر و باکیفیت‌تر نمایش داده می‌شن.

👁 توجه ویژه به دسترسی‌پذیری (Accessibility)

فلاتر همیشه به فراگیر بودن اپ‌ها اهمیت می‌ده. تو این نسخه ویجت جدیدی به اسم SemanticsLabelBuilder معرفی شده. کارش اینه که بهتون کمک می‌کنه چندتا داده‌ی مختلف رو با هم ترکیب کنید و به صورت یک پیام منسجم و قابل فهم برای ابزارهای صفحه‌خوان (Screen Readers) ارائه بدید. اینجوری کاربرهایی که از این ابزارها استفاده می‌کنن، تجربه‌ی خیلی بهتری از اپ شما خواهند داشت.

🤖 هوشمندتر شدن با کمک هوش مصنوعی

با معرفی Dart and Flutter MCP Server، حالا دستیارهای هوش مصنوعی (AI Coding Assistants) می‌تونن به عمق پروژه‌تون دسترسی داشته باشن. هوش مصنوعی می‌تونه خطاهای (runtime) رو خودش پیدا و رفع کنه، بهترین پکیج رو از pub.dev پیدا و نصب کنه.


چندتا اتفاق مهم دیگه هم افتاده:

⬅️سریع‌تر شدن Analysis Server: ابزارهایی مثل dart analyze و dart fix تقریباً ۵۰٪ سریع‌تر شدن که باعث می‌شه تجربه‌ی کدنویسی روزمره‌تون خیلی روون‌تر بشه.

⬅️جداسازی کتابخونه‌های Material و Cupertino: تیم فلاتر تصمیم گرفته این دوتا کتابخونه‌ی طراحی رو از هسته‌ی اصلی جدا کنه. این کار باعث می‌شه آپدیت‌هاشون سریع‌تر و مستقل از نسخه‌های فلاتر منتشر بشه و جامعه‌ی برنامه‌نویس‌ها راحت‌تر بتونن تو توسعه‌شون مشارکت کنن.

⬅️ ویجت‌های جدید و بهبودیافته: کلی ویجت جدید مثل DropdownMenuFormField و CupertinoExpansionTile اضافه شده.


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

📱 https://medium.com/flutter/whats-new-in-flutter-3-35-c58ef72e3766

---

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

🆔 @MdDaily

📄 فهرست مدارک و گواهینامه‌های رایگانی که تو دنیای کار اعتبار دارن:

احتمالا اسم freecodecamp رو زیاد شنیده باشید و اولین مورد لیستم هست :

1. https://freecodecamp.org/learn/

2. دوره های دانشگاه هلسینکی:

👩‍💻 Python Programming
https://programming-25.mooc.fi

📊 Data Analysis with Python
https://courses.mooc.fi/org/uh-cs/courses/data-analysis-with-python-2024-2025

🤖 AI
https://elementsofai.com

👩‍💻 DevOps with Kubernetes
https://devopswithkubernetes.com

👩‍💻 Fullstack Web Development
http://fullstackopen.com

همه ی دوره هاش: https://mooc.fi/en/courses/

3. سیسکو نت‌اکد (Cisco Netacad)

👩‍💻 Python
http://netacad.com/courses/python-essentials-1

👩‍💻 JavaScript
http://netacad.com/courses/javanoscript-essentials-1

📊 Data Analytics
http://netacad.com/courses/data-analytics-essentials

😒 Ethical Hacking
http://netacad.com/courses/ethical-hacker

🌐 Networking
http://netacad.com/courses/networking-basics

4. گواهینامه‌های اوراکل (Oracle Certifications)

☁️ Cloud
📊 Data
🤖 AI

🔗 https://education.oracle.com/race-to-certification-2025

5. آکادمی سیلور (Saylor Academy)

👩‍💻👩‍💻 Database
👩‍💻 OS
🖥 Networking
📊 Data Science

🔗 https://learn.saylor.org/course/index.php?categoryid=9

6. دانشگاه هاروارد

🧑‍💻 Computer Science
https://cs50.harvard.edu/x/2025/

👩‍💻 Python
https://cs50.harvard.edu/python/2022/

🤖 AI
https://cs50.harvard.edu/ai/2024/

👩‍💻 Web Dev
https://cs50.harvard.edu/web/2020/

7. آکادمی هاب‌اسپات (HubSpot Academy)

می‌تونید گواهینامه‌های مربوط به سئو (SEO)، بازاریابی، فروش و کلی چیزای دیگه رو بگذرونید

🔗 https://academy.hubspot.com/certification-overview

8. Neo4j

❯ Neo4j Certified Professional
https://graphacademy.neo4j.com/certifications/neo4j-certification/

❯ Neo4j Graph Data Science Certification
https://graphacademy.neo4j.com/courses/gds-certification/

9. Hackerrank


Get certified and also earn badges for free on Hackerrank.

👩‍💻👩‍💻 SQL
👩‍💻 👩‍💻👩‍💻👩‍💻 Python, Java, JavaScript, Golang
👩‍💻👩‍💻 React, Angular
❯ DSA

🔗 https://hackerrank.com/skills-verification


10. Kaggle

👩‍💻 Python
👩‍💻👩‍💻 SQL
🤖 AI/ML, DL
📊 Data Science

🔗 https://kaggle.com/learn

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

---

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

🆔 @MdDaily

برای حل چالش بالا بردن سرعت برنامه و کاهش فشار روی منابع یکی از مکانیزم های کشینگ مورد علاقم که بسته به use case زیاد ازش استفاد میکنم LRU Cache هست.

کلمه LRU مخفف عبارت "Least Recently Used" هست. این مکانیزم به زبان ساده، داده‌هایی رو که اخیراً بیشتر استفاده شدن، نگه می‌داره و اگه حافظه پر بشه، هوشمندانه قدیمی‌ترین داده‌ای رو که بهش دست نزدیم، حذف می‌کنه تا جا برای داده‌های جدید باز بشه.

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

-----

الگوریتم پیاده‌سازی

برای فهمیدن LRU Cache و اینکه چرا انقدر کارآمد هست، باید بدونید که این سیستم از ترکیب دو تا ساختار داده اصلی ساخته شده:

⬅️ یک نقشه (Hash Map): این بخش برای جستجوی سریع داده‌ها با کلیدشون استفاده می‌شه. با این کار، پیدا کردن یک داده در کش در زمان ثابت O(1) اتفاق می‌افته و دیگه نیازی به گشتن توی کل داده‌ها نیست.

⬅️ یک لیست پیوندی دوطرفه (Doubly Linked List): این لیست وظیفه داره ترتیب استفاده از داده‌ها رو نگه داره. جدیدترین داده همیشه در ابتدای (Head) لیست قرار می‌گیره و قدیمی‌ترین داده هم در انتهای (Tail) اون. با این ساختار، می‌تونیم با سرعت بالا داده‌ها رو جابه‌جا کنیم یا قدیمی‌ها رو حذف کنیم.

حالا چطور کار می‌کنه؟

وقتی یه داده رو از کش دریافت (Get) می‌کنید، سیستم اول تو نقشه دنبال کلیدش می‌گرده. اگه پیداش کرد، اون داده رو از هر جایی که تو لیست پیوندی هست، جدا می‌کنه و به ابتدای لیست می‌بره تا "تازگی" اون به‌روز بشه.

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

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


یه نمونه ساده هم با Go پیاده کردم که توی این gist میتونید ببینید:

https://gist.github.com/mdpe-ir/bb25dac1ed506bd529292f0f52ecc929

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


منابع بیشتر

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

🌐 Interview Cake: LRU Cache



---

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

🆔 @MdDaily

امروز ۲۵۶اُمین روز سال میلادی، یعنی روز برنامه‌نویسه!

این روز رو به همه کسایی که با هر خط کد، یه ایده رو به واقعیت تبدیل می‌کنن و ساعت‌ها برای بهینه‌تر شدن یه الگوریتم وقت می‌ذارن، تبریک می‌گم. برنامه نویسی از نظر من یعنی هنر ساختن و حل مسئله.

---

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

🆔 @MdDaily

چطوری System Design رو یاد بگیریم قسمت ۱ از ۲

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

نویسنده ی مقاله که سفر یادگیریش رو باهامون به اشتراک میذاره میگه زمانی بود که هر ویدیو یا بلاگی که اسم «طراحی سیستم» (System Design) روش بود رو کلاً بی‌خیال می‌شده و با خودش میگفته اینا مال سنیور هاست نه من. بعد میره تو مصاحبه بهش میگن برای طراحی یه اپ مثل Uber باید چیکار کرد.

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

اینجاس که System Design وارد میشه.

---

1️⃣ اول از همه حالا که میدونیم چیو نمیدونیم بریم یادش بگیریم

طراحی سیستم اولش خیلی ترسناکه.

آدما یه سری کلمه میگن مثل «شاردینگ» (Sharding)، «CQRS»، «متوازن‌کننده بار» (Load Balancer)، (Eventual Consistency) و...

همه اولش احساس گم شدن دارن.

طراحی سیستم یه موضوع تکی نیست. یه «فصل» نیست که بتونی تو یه هفته تمومش کنی.

بلکه ترکیبی از ایناست:

✔️ جریان حرکت داده‌ها چطوریه؟

✔️ سرویس‌ها چطور با هم صحبت می‌کنن؟

✔️ چطور سیستم‌ها زیر بار ترافیک سنگین دوام میارن؟

✔️ و چطور می‌شه سیستم رو قابل‌اطمینان، سریع و مقاوم در برابر خطا (Fault-tolerant) ساخت؟

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

---

2️⃣ «طراحی سیستم» رو به موضوعات کوچیک تقسیم کنیم

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

بریم برای نقشه راه:

الف) اصول اولیه (The Basics)

✔️ وقتی توی مرورگر یه آدرس (URL) رو تایپ می‌کنی، چه اتفاقی می‌افته؟

✔️ مفاهیم DNS، متوازن‌کننده بار (Load Balancer) و CDN چی هستن؟

✔️ پروتکل TCP در برابر UDP، HTTP در برابر HTTPS

ب) داده و ذخیره‌سازی (Data and Storage)

✔️ دیتابیس SQL در برابر NoSQL

✔️ ایندکسینگ (Indexing)، رپلیکا (Replication)، شاردینگ (Sharding)

✔️ کی باید MongoDB رو انتخاب کنی و کی PostgreSQL؟

ج) تکنیک‌های مقیاس‌گذاری (Scaling Techniques)

✔️ مقیاس‌گذاری افقی (Horizontal) در برابر عمودی (Vertical)

✔️ کشینگ (Caching) (مثل Redis، Memcached)

✔️ متوازن‌سازی بار (Load Balancing) (مثل Round-robin، IP Hashing)

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

د) الگوهای معماری (Architecture Patterns)

✔️ مونولیت (Monolith) در برابر میکروسرویس‌ها (Microservices)

✔️ معماری مبتنی بر رویداد (Event-Driven Architecture)

✔️ مفاهیم Pub/Sub، صف‌های پیام (Message Queues) (مثل Kafka، RabbitMQ)

---

3️⃣ تماشای تفکر آدم‌های واقعی، نه فقط آموزش دادن اون‌ها

به جای دیدن ویدیوهایی که سبک آموزشی دارن، شروع کنید به دیدن مصاحبه‌های شبیه‌سازی‌شده (Mock Interviews).

و باور کنید، این کل قضیه رو عوض میکنه.

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

کانال‌هایی که خیلی کمک کننده میتونن باشن:

🎞 یوتیوب Gaurav Sen: توضیح دادن از صفر و اساس

🎞 یوتیوب Exponent: مصاحبه‌های شبیه‌سازی‌شده با کاندیداهای واقعی

🎞 یوتیوب ByteByteGo: رویکرد بصری و قصه‌گویی‌شون

بهتون یاد میده چطور:

✔️ سؤالات درست و شفاف‌کننده بپرسید.

✔️ نیازمندی‌های عملکردی (Functional) و غیرعملکردی (Non-functional) رو تعریف کنید.

✔️ مراحل طراحی API، انتخاب پایگاه داده و منطق مقیاس‌گذاری رو توضیح بدید.

✔️ و همیشه در مورد مبادله‌ها (Tradeoffs) صحبت کنید، نه فقط انتخاب‌ها.

—-

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

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

🆔 @MdDaily

چطوری System Design رو یاد بگیریم قسمت ۲ از ۲

قسمت اول

خب خب بریم برای برای ادامه‌ی مسیر: از طراحی روی کاغذ تا آموزش دادن به بقیه

4️⃣ شروع کن به رسم، حتی اگه روی کاغذ باشه!

یه چیزی که خیلی کمک کنندس: رسم کردن (Drawing) هستش.

ما آرتیست نیستیم. ولی وقتی فلو کار رو از

دیتایبیس → اپ های سرور → لود بالانسر ها → کلانیت

رسم میکنیم تازه دیدمون باز میشه.

وقتی رسم میکنیم:

✔️ فلو درخواست واقعی به نظر می‌رسه.

✔️ میبینیم که Bottlenecks کجاها ممکنه اتفاق بیفته.

✔️ میفهمیم که کش (Cache) رو کجا بذاریم یا کِی از صف (Queue) استفاده کنیم.

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

5️⃣ با حل کردن مسئله‌های واقعی تمرین کنید

وقتی توی اصول اولیه مطمئن شدید، دست از تماشا کردن بردارید و رسم کردن رو شروع کنید.

این روش تمرینی میتونه کمکتون کنه:

✔️ یه سیستم واقعی انتخاب کنید: واتساپ، یوتیوب، اسنپ‌فود، اینستاگرام.

✔️ اول نیازمندی‌های عملکردی (Functional Requirements) رو بنویسید (سیستم باید چیکار کنه).

✔️ بعد نیازمندی‌های غیرعملکردی (Non-functional Requirements) رو اضافه کنید (مقیاس‌پذیری، دسترس‌پذیری، تأخیر).

✔️ یه تخمین اولیه بزنید (تعداد کاربر، QPS، حجم DB).

✔️ یه معماری سطح بالا (High-level Architecture) طراحی کنید.

🚀 حالا وقت عمیق تر شدن رسیده:

✔️ DB schema
✔️APIs
✔️ Scaling strategies
✔️ Handling failures (مدیریت خطا ها)
✔️ Edge Cases (حالت های خاص)

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

چون توی مصاحبه‌ها و کارهای واقعی، به ندرت یه جواب کامل وجود داره. مهم اینه که بتونی توجیه کنی چرا X رو به Y ترجیح دادی.

6️⃣ وقت واقعی کردن رسیده

🔴تئوری تا وقتی پیاده نشه، بی‌فایده‌ست.

بذارید از تجربه خودم بگم. تویه شرکت داشتیم رو یه سیستمی کار میکردیم که به صورت میکروسرویس پیاده شده بود با Go و برای ارتباط داخلی سرویس ها از GRPC استفاده کرده بودیم. اوایل برای سرویس آنالیتیکس از MongoDB استفاده کرده بودیم. اما با زیاد شدن حجم داده ها و کوئری ها (رکورد ها به قدری زیاد بودن که حجم دیسک دیتابیس شده بود 15 گیگ) سیستم شروع کرد به کند شدن. یه راهکار ها این بود که بیایم چنتا نود مختلف بیاریم بالا ولی پیچیدگی ایش زیاد بود، پس شروع کردیم به R&D کردن دیتابیس هایی که به نظر برای این کار مناسب بودن. بعد از تست های اولیه و گرفتن بنچمارک متوجه شدیم که clickhouse میتونه توی مورد ما این بخش از پروژه رو نجات بده. تیم بکند دور هم جمع شدیم و فقط یه ماژیک برداشتیم و ساعت ها روی شیشه سیستم دیزاین های مختلفیو رسم و بررسی کردیم و دیدمون باز شد و در نهایت طرح نهایی. حالا که همه چیز حداقل روی کاغذ اماده بود و کار میکرد باید مهاجرت رو شروع و سیستم جدید رو پیاده میکردیم. در نهایت با یه بررسی درست، بررسی سیستم دیزاین های مختلف و داشتن دید کلی و جزئی از سیستم ، به جایی رسیدیم که میلیون ها داده رو بدون مشکل آنالیز کردیم و نزدیک Real time خروجی نشون میدیم. بعد آروم آروم رفتیم جلو و چیز های دیگه هم مثل RabbitMQ اضافه کردیم. اره الان پروژه بزرگ شده ولی این پروژه ی بزرگ حاصل قدم های کوچیکی بود که برداشتیم ولی نکتش اینکه اگه میخواستیم به آخرش فکر کنیم که همچین چیز بزرگی چطوری قراره ساخته بشه هیچ وقت شروع نمیشد :)

7️⃣ شروع کنید به یاد دادن به بقیه

این آخرین مرحله هست.

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

هر بار که یه چیزی رو توضیح میدم اینو میفهمم که:

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

درنهایت طراحی سیستم شعبده‌بازی نیست.

فقط کافیه:

✔️ از اصول اولیه شروع کنید.

✔️ به موارد استفاده‌ی دنیای واقعی فکر کنید.

✔️ یه ساختار برای خودتون بسازید.

✔️ هفته‌ای تمرین کنید.

✔️ پشت هر انتخابتون بپرسید «چرا»؟

✔️ و آروم‌آروم بهتر بشید.

حتی اگه روزی ۳۰ دقیقه هم وقت بذارید، بعد از ۳ ماه تفاوت رو می‌بینید.

حرف آخر: قضیه جواب‌ها نیست، قضیه رویکرده!

توی طراحی سیستم، اغلب احساس عدم اطمینان خواهید کرد. این طبیعیه.

چیزی که مهمه اینه که چطور به یک مسئله نزدیک می‌شید.

وقتی توضیح می‌دی مقیاس چقدره یا اگه این سرویس از کار بیفته چی می‌شه؟ اینه که شما رو به یه مهندس قوی تبدیل می‌کنه. نه تعداد دیاگرام‌هایی که حفظ کردید.

با «یک URL چطور کار می‌کنه؟» شروع کنید و به طراحی اینستاگرام ختم کنید.

تعجب خواهید کرد که قدم به قدم، چقدر پیش رفتید.

—-

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

🆔 @MdDaily

میخواستم بک گراندم رو عوض کنم و دنبال یه جایی بودم که کلی بک گراند خوب و رایگان داشته باشه، پس توی ریپو های گیت هاب سرچ کردم و رسیدم به پروژه lwalpapers . حدودا ۳ سالی هست که اپدیت نشده ولی ۱۰۰۰ تا بک گراند یونیک رو توی خودش جمع آوری کرده.

آدرس وبسایت:

🔗 https://wallpaper.castorisdead.xyz/

—-

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

🆔 @MdDaily