۱۱ تا tip کمک کننده در برنامه نویسی

۱.حفظ نکن!

یاد بگیر چطور اطلاعاتی که نیاز داری رو پیدا کنی. منظورم فقط StackOverflow و GenAI نیست. برای ابزارها و زبان‌هایی که استفاده می‌کنی، باید بدونی که مستنداتشون کجا پیدا می‌شه. کی بهترین راهنماها رو می‌نویسه؟ مهم نیست که یادت نمی‌مونه موقع استفاده از عملگر شرطی اولویت با ؟ یا : هست. مهم اینه که بدونی کی از یه عملگر شرطی استفاده کنی و کجا دقیقاً syntax رو پیدا کنی. ابزارها دائماً به‌روز می‌شن یه راهی برای به‌روز بودن پیدا کن، چه یه خبرنامه باشه چه یه دوست که عاشق CSS هست :)

۲.رو اصول اولیه عمیقاً کار کن!

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

۳.تفکر سیستمی خیلی به دردت می‌خوره!

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

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

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

۵.هر خط کد یه دردسره!

کد رو طوری بنویس که انگار یه نفر دیگه قراره اون رو فیکس کنه. (حتی اگه اون یه نفر خودت باشی تو ۶ ماه دیگه!) دلیل کارهاتو مستند کن تا بعداً یه چیزی رو ناخواسته خراب نکنی. قبل از اینکه یه ابزار رو جزئی از سیستم کنی، نظرات بقیه رو راجع بهش بخون، شاید نظرات اون ابزار با قابلیت‌هایی که نیاز داری، جور درنیاد!

۶.خوندن کد بقیه رو تمرین کن!

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

۷.تست کن و باز هم تست کن!

همونطور که Chocho تو صحبت DevNexus 2024 گفت، "کد تئوریه. نرم‌افزار عملیاته." همیشه قبل از اینکه بخوای کسی کدت رو ببینه، خودت اجراش کن و تست کن. تا جایی که می‌شه نوشتن تست رو تمرین کن. اینکه بتونی پیش‌بینی کنی چطور یه کاربر می‌تونه برنامه‌ت رو خراب کنه و به چیزی فراتر از سناریوی ایده‌آل فکر کنی، باعث می‌شه یه برنامه‌نویس بهتر بشی.

۸.تمرین کن تا نیازمندی‌ها رو به نرم‌افزار تبدیل کنی!

ایشو:

یک دکمه به صفحه اضافه کن که یه modal باز کنه و کاربر بتونه این داده رو ویرایش کنه

ازت انتظار می‌ره بتونی یه همچین نیازمندی‌ای رو به یه لیست از مرحله‌ها (list of steps) یا شبه‌کد تبدیل کنی. اگه تیکت خیلی گنگه، برای شفاف تر شدنش سوال بپرس. بعد از اینکه مرحله‌ها رو مشخص کردی، نوبت این می‌رسه که اونا رو به کد و (امیدوارم) تست برای اون کد تبدیل کنی. بعدش هم کد رو وارد version control کنی، ریویو و کنترل کیفیت بشه و توی پروسه‌ی deployment قرار بگیره. برای تمرین کردن این کار، پروژه‌های اپن سورس عالین.

۹.کامیونیتی خیلی مهمه!

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

۱۰.چیزی رو تو برنامه‌نویسی پیدا کن که ازش لذت می‌بری!

نمی‌گم عاشق شغلت بشو یا تبدیل به اون برنامه‌نویس افسانه‌ای و پرشور (Passionate Programmer) بشین. اما یادگیری مداوم یعنی اینکه خودت رو برای ناخوشایندی‌های(discomfort) مکرر آماده کنی. اگه نمی‌دونی چرا می‌خوای هر روز صبح بیدار شی و این کار رو با خودت بکنی، آسیب میبینی. می‌تونه یه دلیل کاملاً خودخواهانه باشه، اما باید دلیل خودت رو پیدا کنی.

۱۱.هرکسی تو مسیر خودش قرار داره!

تو با مسیر شغلی و محتوای بقیه رقابت نمی‌کنی. مسیر موفقیت دیگران شاید اصلاً برای تو کار نکنه. روی دیدگاه و نقاط قوت منحصربه‌فرد خودت تمرکز کن. صدات رو پیدا کن و با بقیه به اشتراک بذار. اون بیرون کسی هست که می‌خواد صدات رو بشنوه.

🆔 @MdDaily

دیتابیس SQL در مقابل NoSQL: کی چی به کارمون میاد؟

توی دنیای امروز، انتخاب بین SQL و NoSQL می‌تونه گیچ کننده باشه، مخصوصاً با این همه گزینه‌ دردسترس. از دیتابیس های relational مثل MySQL یا PostgreSQL گرفته تا دیتابیس های مدرن مبتنی بر داکیومنت مثل MongoDB یا ذخیره‌سازهای کلید-مقدار مثل DynamoDB، انتخاب بهترین گزینه برای پروژه‌هامون می‌تونه حسابی سخت باشه.

تو این پست قرار این موضوع رو ساده‌تر کنیم و بفهمیم کدومشون برای چه کاری بهتره.

دیتابیس ها SQL چی هستن؟

دیتابیس های SQL که بهشون دیتابیس ها رابطه‌ای (relational databases) هم می‌گن، سال‌هاست که تو دنیای تکنولوژی حرف اول رو می‌زنن. این دیتابیس ها ساختارشون جدولی هست و از یه زبون به اسم SQL (زبان پرس و جوی ساختاریافته) برای تعریف و دستکاری داده‌ها استفاده می‌کنن. SQL برای کارهایی که به انسجام و دقت داده و کوئری های پیچیده نیاز دارن، عالیه.

یکی از مزایای اصلی دیتابیس ها SQL مثل MySQL و PostgreSQL اینه که با استفاده از relationship ها، می‌تونن از یکپارچگی داده‌ها مطمئن بشن. دیتابیس ها SQL با تعریف یه سری قوانین از قبل، یه جوری داده‌ها رو ذخیره می‌کنن که همیشه دقیق و منظم باشن.


از SQL کجا ها استفاده کنیم؟

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

👈 گزارش‌گیری و تحلیل

👈 انبار داده: از SQL خیلی وقت‌ها برای ذخیره و تحلیل اطلاعاتی مثل اطلاعات مربوط به فروش یا رفتار مشتری‌ها استفاده می‌شه.

دیتابیس ها NoSQL

دیتابیس ها NoSQL مثل MongoDB و ElasticSearch برخلاف پایگاه‌های SQL، رویکردی منعطف‌تر و بدون اسکما (schema-less) برای داده‌ها ارائه می‌دن. این پایگاه‌ها برای مدیریت حجم زیادی از داده‌های بدون ساختار یا نیمه ساختار طراحی شدن و برای مواردی که در اونجا مقیاس‌پذیری، انعطاف‌پذیری و کارایی حرف اول رو می‌زنن، عالی هستن.

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

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

از NoSQL کجا ها استفاده کنیم؟

👈 سیستم‌های توزیع‌شده و مقیاس‌پذیر.

👈 داده‌های حجیم و Real-Time Analytics: دیتابیس های NoSQL در سناریوهایی که شامل داده‌های حجیم و تحلیل لحظه‌ای هستن و در اونجا توان عملیاتی بالا و تأخیر کم اهمیت زیادی داره، عالی عمل می‌کنن.اون‌ها به طور معمول در اپلیکیشن‌هایی مانند IoT، تحلیل شبکه‌های اجتماعی و real-time recommendation engines استفاده می‌شن.


تصورات غلط رایج

با وجود تمام نقاط قوتی که دیتابیس های SQL و NoSQL دارن، در موردشون یه سری تصورات غلط رایج وجود داره.

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

دیتابیس ها SQL نمی‌تونن به صورت horizontal مقیاس‌پذیر باشن: هر دوی دیتابیس ها SQL و NoSQL می‌تونن به صورت horizontal مقیاس‌پذیر باشن، حتی اگه روش های مقیاس پذیریشون متفاوت باشه

دیتابیس ها NoSQL از transactional پشتیبانی نمی‌کنن: بسیاری از دیتابیس ها NoSQL قابلیت‌های تراکنشی رو ارائه می‌دن، با وجود اینکه با چیزی که تو دیتابیس ها SQL به عنوان ACID شناخته می‌شه، فرق کنه.

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

نتیجه‌گیری

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

🆔 @MdDaily

#شاید_موقت

چند وقته میخوام مقاله ی 🧠 How to be a great software engineer without using your brain. رو در قالب پست کانال خلاصه و عامیانه کنم ولی موقعی که به فارسی برمیگرده اون حالو هوای مقاله اصلی رو از دست میده :)

درکل مقاله ی جالبیه. اگه پیشنهادی دارید خوشحال میشم توی کامنت ها به اشتراک بگذارید

هنر خود آموزی: چطوری هرچیزی رو تو برنامه‌نویسی به خودت یاد بدی 🤓

💢 مقدمه‌ای بر خود آموزی

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

ادامه پست در تلگراف:
🔗 https://telegra.ph/هنر-خود-آموزی-چطوری-هرچیزی-رو-تو-برنامه‌نویسی-به-خودت-یاد-بدی-05-03

* به خاطر محدودیت های کارکتر تلگرام تو یدونه پست جا نشد، توی تلگراف نوشتم :)

🆔 @MdDaily

چطوری جلوی فک کردن بیش از حد (اورتینک) رو بگیریم؟ 

توی مدت گذشته درگیر اورتینک شده بودم و راه کار های این مقاله کمکم کردن تا حد زیادی کنترلش کنم و توی این پست قرار باهم بررسیشون کنیم و پست قرار از زبان نویسنده ی مقاله نقل بشه با سناریوی اینکه تصمیم میگیره یک هفته مقاله ننویسه و این دلیل اورتینکش میشه :)
—
من همیشه آدمی بودم که زیاد فکر و خیال می کنه. این اتفاق به دلایل مختلفی می افتاد، مثلاً:

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

۵ تا راهکاری که انجام دادم:

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

۱. بنویسید
مزایا و معایب صرف نظر کردن از مقاله ام را در این هفته نوشتم.

مزایا:
- به خودم و خانواده‌م بیشتر می‌رسم.

معایب:
- ترسناک بود که یه هفته ننویسم.
- فکر می کردم اگه یه هفته ننویسم، بعدش دیگه هیچ وقت نمی نویسم.

بعدش یه ذره عمیق تر به مزایا و معایب فکر کردم و دیدم که آیا واقعا درستن یا نه.

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

۲. یه ضرب الاجل تعیین کنید

به خودم چالش دادم که زیر ۲ ساعت تمومش کنم.

تو یه هفته معمولی، یه ذره وقت میذارم و از بین یه عالمه موضوعی که تا حالا جمع کردم، یکی رو انتخاب می کنم.
این بار که مرحله ۱ رو انجام دادم، دیدم که موضوعش باید اورتینک باشه!

دو تا اتفاق احتمالی رو نوشتم:
اگه تو ۲ ساعت تمومش کنم: این هفته منتشرش می کنم. یالا! این اتفاق افتاد.
اگه تموم نشه: هفته بعدش منتشرش می کنم و میگم که چطوری تصمیم گرفتم و بهش پایبند موندم.
پس یه جورایی دو سر برد بود.

۳. توجه پیوسته
برای کار فکری مثل نوشتن مقاله، به تمرکز نیاز دارم. تو هفته‌های معمولی، نوشتن خبرنامه رو تو هر بار وقت کمی که پیدا می‌کردم، جا می‌دادم (بعضی وقتا حتی ۱۰ دقیقه).
برای همین مدام بین موضوعات مختلف جابجا می‌شدم و تمرکزم رو از دست می‌دادم. این کار کلی اثر منفی داشت. مثلا:

تو زمان نوشتن، بین دو سه تا موضوع پرش میکردم.
قسمت‌های سخت رو برای آخر نگه می‌داشتم.

برای این دفعه، تصمیم گرفتم که بیشتر از ۳ سشن نداشته باشم.

سشن ۱ - ۱ ساعت: نوشتن خلاصه و پیش‌نویس اولیه.
سشن ۲ - ۳۰ دقیقه: بازنویسی قسمت‌های بد با دید تازه. ساخت دو تا تصویر.
سشن ۳ - ۳۰ دقیقه: ویرایش نهایی و اعمال تغییرات جزئی.
نتیجه نهایی خیلی به چیزی که تصمیم گرفته بودم نزدیک بود.
🖼 تصویر

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

🖼 تصویر

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

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

برای این مورد، P0ها و P1هارو تعریف کردم.

اولویت P0 - باید انجام بشه.
پیام اصلی و ارزش برای خواننده واضح باشه. تو این مورد: پیام اصلی = مراحلی که برای توقف اورتینک انجام شده و شما می‌تونید برای مبارزه با اورتینک خودتون ازش استفاده کنید.
مقاله به راحتی قابل خوندن باشه.
مقدمه جذاب و نتیجه‌گیری واضح داشته باشه.

اولویت P1 - خوبه که داشته باشیم.
مقدمه قوی‌تر.
نکات عملی قوی‌تری که سناریوهای مختلف رو پوشش بده.
تو این مورد: به اشتراک گذاشتن مثال یه مهندس نرم‌افزار که اکثر شما می‌تونید باهاش ارتباط برقرار کنید.
تصاویری با استعاره. اینا باعث می‌شه خواننده بگه «آها!»
بهینه‌سازی سئو
یادداشت پایانی

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

🆔 @MdDaily

درس هایی راجب برنامه نویسی از زبان Matt Butcher

یادتون باشه هر خط کدی که می‌نویسین باید بعدا ازش پشتیبانی کنین!

این حرف خیلی معنی داره که تو ادامه می‌گم:

- برنامه نویسی به عنوان صنعتگری
- چرخ رو از اول اختراع نکن
- هزینه پیچیدگی
- کاهش نیازهای آینده برای نگهداری
- چرا خود آیندتون (و دیگران) قدردان کد امروزن

برنامه نویسی به عنوان صنعتگری

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

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

چرخ رو از اول اختراع نکن

یه کتابخونه یا ابزاری هست که کار رو راه می‌ندازه، ولی خب، ما میتونیم بهتر انجامش بدیم!
فکر می‌کنم هر مهندس نرم‌افزاری حداقل یه بار این کار رو کرده و همیشه یه جور توجیه هم هست:

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

تو همه این موارد، دو تا چیز نادیده گرفته میشن:

چقدر بقیه زمان صرف کرده بودن که قبلاً مشکل رو حل کنن. (پختگی اون کد)
منِ آینده چقدر باید وقت بذاره واسه درست کردن و نگهداری اون کد.

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

هر چی کدت پیچیده‌تر، دیباگش سخت‌تره

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

شاید مجبور بشین خط‌های بیشتری کد بنویسین (چون کارهای پیچیده رو به تابع‌های کوچیک‌تر تقسیم می‌کنین)، اما اگه نتیجه‌ش بشه کدی که دیباگ و نگهداریش راحت‌تره، ارزشش رو داره.

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

خودت آیندت یادش نمیاد که خودت الانت به چی فکر میکرده
پس همه‌چی رو مستند کن! آدما یه جور پیش‌فرض عجیب دارن. فکر می‌کنیم که فردا همه چیزایی که امروز اتفاق افتاده رو یادمون می‌مونه. خود آینده‌ت جزئیات ریز اینکه چرا امروز این کد رو به این شکل نوشتی، یا چرا اون متغیر رو fhr اسم گذاشتی، یا چرا کامنت // FIXME later رو رو خط ۲۳۵ جا گذاشتی، یادش نمیاد.

بهترین راهی که می‌تونی با محدودیت‌های حافظه‌ت مقابله کنی اینه که کدت رو واضح بنویسی. این یعنی:

کامنت بذار.
اسم‌ها رو خوب انتخاب کن.
مستندات خوب بنویس.
کامیت‌مسیج‌های مفید بنویس.

خود آینده‌ت ازت ممنون می‌شه. یا حداقل از دستت عصبانی نمی‌شه.

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

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

🆔 @MdDaily

#ام_دی_کورس

سوال مصاحبه System Design: طراحی کوتاه کننده URL

یه سوال مصاحبه طراحی سیستم داریم که توش باید یه ابزار کوتاه کننده URL مثل TinyURL یا Bitly رو از صفر طراحی کنیم. همه چی رو از الزامات طراحی و معماری و طراحی اجزا تا اینکه چطور میشه سیستم رو برای سرعت بالا و امنیت بیشتر ارتقا داد، بررسی می‌کنیم.
اول از همه باید مشخص کنیم که این سیستم چی‌کار باید بکنه و چی‌کار نباید بکنه.
از نظر کارکردی، دو تا وظیفه اصلی داره:
وقتی یه URL بلند بهش می‌دی، باید یه URL کوتاه بسازه.
وقتی یه URL کوتاه بهش می‌دی، باید کاربر رو به URL بلند ببره.
برای این سرویس دو تا چیزه خیلی مهمه: اینکه کارش رو خیلی سریع انجام بده (پاسخ‌های کوتاه) و اینکه همیشه در دسترس باشه (همیشه آنلاین). میشه گفت اولویت با این دوتاست.
سوالات شفاف سازی برای مصاحبه کننده
اینجا چند تا .....

ادامه در:
🔗 https://mddaily.web.app/blog/system-design-interview-question-design-url-shortener/

🆔 @MdDaily

توی این قسمت از ام دی کورس خیلی ساده و خلاصه به System Design یه کوتاه کننده لینک پرداخته شده و راجب مباحثی مثل معماری، انتخاب دیتابیس مناسب، لودبالانسر، کشینگ و... صحبت شده و مثل همیشه منابعی که استفاده کردمم آخر مقاله در دسترسن :)

هوش مصنوعی، یار یا جاسوس؟ نگاهی به Copilot+ PC و خطراتش برای حریم خصوصی

هوش مصنوعی تو این چند سال حسابی سر و صدا کرده و کلی چیزای جدید و باحال بهمون داده. اما یه چیز هست که تو این هیاهو گم شده: حریم خصوصی ما!

از زمانی که مایکروسافت برای ادغام ابزارهای مبتنی بر هوش مصنوعی تو محصولاتش با OpenAI همکاری کرد، به نوعی قدرت پیدا کرده و محبوب ترینشونم Copilot هست. این قضیه یه برگ برنده تو تبلیغات برای مایکروسافت شده و حالا یه خط جدید از کامپیوترها به اسم Copilot+ PC راه انداخته. شرکت‌هایی مثل دل، HP، لنوو و بقیه هم کلی لپ‌تاپ و کامپیوتر جدید دارن که قراره با پردازنده‌های سری اسنپدراگون X و یه NPU داخلی برای هوش مصنوعی عرضه بشن.

ابزار Recall که توی رویداد معرفی شد. وقتی روشنه، هر چند ثانیه یک بار از صفحه‌ اسکرین‌شات میگیره. بعد این اطلاعات رو ذخیره می‌کنه، یه جور تایم‌لاین قابل اسکرول میده که برگردی عقب و ببینی قبلا داشتی چیکار می‌کردی. مایکروسافت میگه تمام اسکرین‌شات‌های گرفته شده با Recall روی خود دستگاه ذخیره و رمزنگاری میشن. حتی اگه چند نفر از یه ویندوز استفاده کنن، باز هم نمی‌تونن به اسکرین‌شات‌های Recall بقیه دسترسی پیدا کنن، مگه اینکه از یه حساب کاربری مشترک استفاده کنن. Recall همچنین از سشن های وب‌گردی InPrivate تو مایکروسافت اج اسکرین‌شات نمیگیره. (فعلا معلوم نیست این قابلیت برای مرورگرهای دیگه هم همین‌طور باشه). این قابلیت همچنین هیچ‌کدوم از محتواهای محافظت‌شده با DRM رو ضبط نمی‌کنه، مثل محتواهای سرویس‌های استریم آنلاین. اما یه نکته‌ی منفی دیگه هم داره. Recall اطلاعات حساس مثل رمز عبور، شماره‌ی حساب‌های بانکی و غیره رو هم ضبط می‌کنه چون هیچ moderation محتوائی‌ای روش نیست. نتیجش چی میشه؟ داده های دردسترس بیشتر از شما برای malicious actors یا خرابکار ها :)

🔗 ویدیوی معرفی Copilot+ PCs

خوشبختانه میشه Recall رو از تنظیمات غیرفعال کرد، اما طبق سوالات متداول توی صفحه‌ی وب‌شون، به احتمال زیاد Recall وقتی برای اولین بار Copilot+ PC رو روشن می‌کنی به صورت پیش‌فرض فعاله.

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

🔗 تصویر منابع مورد نیاز برای ai مایکروسافت

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

مایکروسافت لازمه که قابلیت هوش مصنوعی Recall رو متن‌باز کنه تا کاربرا بهش اعتماد کنن. اما اونا نمی‌تونن این کارو بکنن، درسته؟ مهم‌تر اینکه، وقتی پای غول‌های تکنولوژی وسط باشه، هیچ‌وقت نمی‌دونی کی شرایط استفاده یا سیاست‌های حفظ حریم خصوصیشون رو عوض می‌کنن. و وقتی این کارو بکنن، ازت انتظار می‌ره یا باهاش کنار بیای یا کلا از سرویس‌شون استفاده نکنی.

به هر حال، اگه کنجکاو شدین، Copilot+ PC چند تا قابلیت دیگه هم داره. یکیش زیرنویس زنده‌ی صدا و تصویر به انگلیسی از بیش از ۴۰ زبانه، یه قابلیت به اسم Cocreator که از نوشته یا شکل‌هایی که بهش میدید استفاده می‌کنه تا هرچیزی که مشخص کردید رو تفسیر کنه و نشونتون بده. یه قابلیت دیگه به اسم Auto Super Resolution که نرخ فریم (FPS) رو تو بازی‌ها بالا می‌بره، و یه قابلیت به اسم Windows Studio Effects برای تماس‌های تصویری.

خلاصه که هوش مصنوعی یه چیز خوبه و میتونه خیلی بهمون کمک کنه. ولی با توجه به انحصار های بوجود اومده چه قدر حریم شخصیمون در آینده به خطر میوفته. نظر شما چیه؟

🆔 @MdDaily

کوپایلت برای تلگرام ربات رسمی داده :)

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

🔗 آدرس ربات: @CopilotOfficialBot

🔗 آدرس معرفی تو سایت مایکروسافت:
https://www.microsoft.com/en-us/edge/copilot-for-social?form=MY02F9&ch=1


🆔 @MdDaily

من معمولا از پلتفرم های دیگه مطلب توی کانال نمیذارم ولی این یکی خیلی خوب بود :)

متیو کریمی توی یک رشته پست توئیتری اومده بود چیزایی که ازش درآمد داشته رو رایگان به اشتراک گذاشته مثل دوره های آموزشیش.

لینک دوره‌ها:

جعبه ابزار بیزنس: https://eseminar.tv/wb13299

هزار و یک محتوا: https://eseminar.tv/wb10114

نکات کلیدی راه‌اندازی کسب‌وکار: https://eseminar.tv/wb14110

چاپ و بازاریابی و فروش کتاب: https://eseminar.tv/wb14193

موفقیت با طعم قهوه: https://eseminar.tv/wb15086

چگونه دوره آموزشی بسازیم: https://eseminar.tv/wb18476

راهکار افزایش فروش در ایران: https://eseminar.tv/wb29985

تسلط بر فریبکاری: https://eseminar.tv/wb114608

🎁 کد تخفیف: freeiranaccess2024

و آخر توئیتشون گفتند:

🖤 فقط یه خواهشی دارم اگر استفاده کردین برای عمه مرحومم که به خاطر کرونا فوت کرد دعا کنید اگر به دعا و انرژٓی مثبتتون اعتقاد دارین.

</متیو کریمی>

🆔 @MdDaily

چند Best Practice در طراحی REST API

امروزه که همه چی به هم وصله، REST APIs با طراحی خوب، پایه و اساس برنامه‌های کاربردی کارآمد و قابل ارتقا هستن.

نوشتن دیزاین های REST API تمیز به چند دلیل خیلی مهمه:

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

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

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

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

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

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


رولز ها یا قوانین URI

ساختار یه URI به شکل زیره:

scheme :// authority / path [?query][#fragment]

مثال:

https://soccer.api.org/teams/dortmund/players?name=Rona#2

تو دنیای URI دو نوع منبع (resource) داریم:

منابع مجموعه (Collection resources): این نوع منبع، مجموعه‌ای از منابع دیگه رو در خودش داره. میشه اون رو به یه جدول تو دیتابیس تشبیه کرد. مثلا میشه یه منبع مجموعه به اسم users داشته باشیم که لیستی از تمام کاربرها رو در خودش داره.

منابع تکی (Singleton resources): این نوع منبع، فقط شامل یه منبع واحده. میشه اون رو به یه رکورد تو دیتابیس تشبیه کرد. مثلا میشه یه منبع تکی به اسم users/123 داشته باشیم که اطلاعات مربوط به یه کاربر خاص با شناسه ۱‍۲‍۳ رو نشون بده

نکات مهم طراحی Rest Api

۱. منابع Collection باید جمع (plural) باشن :

✅ soccer.api.org/teams/dortmond
❌ soccer.api.org/team/dortmond

۲. منابع Singleton باید مفرد (singular) باشن و با شناسه یکتاشون (unique id) جایگزین بشن:

فرض کن میخوای اطلاعات یه بازیکن خاص رو نمایش بدی، بجای استفاده از players/Ronaldo بهتره از شناسه عددی یا کد اون بازیکن استفاده کنی، مثلا players/12345.

✅ soccer.api.org/teams/dortmond/players/58c1aaae-205a-11ef-aeea-a64c74618950

۳. اسلش ته آدرس رو حذف کنید:

✅ soccer.api.org/teams/dortmond/players
❌ soccer.api.org/teams/dortmond/players/

۴. برای بهتر خونده شدن، از خط تیره (-) به جای زیرخط (_) استفاده کنید:

✅ api.blog.com/blogs/this-is-my-blog
❌ api.blog.com/blogs/this_is_my_blog

۵. تو مسیرهای URI از حروف کوچک استفاده کنید:

✅ api.example.com/my-api/my-resource
❌ api.example.com/My-Api/My-Resource

۶. تو URI ها از پسوند فایل استفاده نکنید:

✅ api.example.com/api/resource
❌ api.example.com/api/resource.json

۷. از اسم فانکشن های CRUD تو URI استفاده نکنید:

برای عملیات ایجاد، خواندن، بروزرسانی و حذف منابع، از اسم هایی مثل create, read, update, delete تو URI استفاده نکن. بجاش از Http Method های استاندارد استفاده کن.
✅ DELETE api.example.com/api/resource
❌ GET api.example.com/api.resource/delete



✅ GET /users
❌ GET /getUsers

۸. بخش کوئری (query) تو URI فقط برای منابع Collection قابل استفاده است:

✅ GET /users?role=admin
❌ GET /users/admin

۹. از بخش کوئری برای اسکرول (paging) کردن نتایج منابع مجموعه استفاده کنید:

✅ GET /users?pageSize=25&pageStartIndex=50

نسخه بندی API (Versioning)

نسخه بندی API برای موارد زیر اهمیت داره:

حفظ سازگاری قبلی (Maintaining backward compatibility)

تضمین یک API سازگار و با طراحی خوب: استفاده از نام‌گذاری‌های یکسان تو همه نسخه‌ها به یه تجربه کاربری خوب کمک میکنه. تغییر endpoint این تجربه رو بهم میریزه و نسخه بندی به جلوگیری از این موضوع کمک میکنه.

چند استراتزی برای نسخه بندی API:

URI Versioning (پیشنهادی):

✅ GET /api/v1/users
✅ GET /api/v2/users

Header Versioning:

✅ GET /api/users
Headers: { "X-API-Version": "1" }

✅ GET /api/users
Headers: { "X-API-Version": "2" }


🆔 @MdDaily

توی گیت هاب CSS injection پیدا کردن :)

🔗 لینک توییت

برای تستش این پروفایل و ریپو های گیت هاب رو ببیند:

https://github.com/yacineMTB
https://github.com/vmfunc/vmfunc
https://github.com/RambIing

آپدیت: فعلا باگش فیکس شده ولی توی کامنت توییت اسکرین شات هاشون هست :)


🆔 @MdDaily

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

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

ویژگی هاش:

👈 پشتیبانی از Hot reload
👈 بدون نیاز به Javanoscript/CSS/HTML میتونید ui های کاستوم بسازید
👈 یادگیری آسون
👈 کامپوننت های آماده
👈 و ..

دموها:
🔗 https://google.github.io/mesop/demo/

وبسایت:
🔗 https://google.github.io/mesop/

گیت هاب:
🔗 https://github.com/google/mesop


🆔 @MdDaily

رایت آپ CSS injection گیت هاب هم منشتر شد

دقیقا چه اتفاقی افتاده بود؟

توی MathJax که گیت هاب ازش برای رندر عبارات ریاضی توی محتوای markdown استفاده میکرده یه گزارش باگ داده میشه که توی یکی از latex macros ها به اسم \unicode که اجازه میداده unicode کارکتر رندر بشه و این امکان را میداده که فونت و استایل کارکتر ها کاستوم بشن یه مشکلی وجود داشته.

درحالت نرمال انتظار میره که با همچین فرمتی استفاده بشه:

\unicode[myfont](x0000)

ولی این امکان وجود داشته که بین brackets ها هرچیزی وارد و رندر بشه و در نتیجه css injection به وجود بیاد :)

\unicode[myfont; color: red; position: fixed; top: 0](x0000)

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

مشکل کد mathjax این بوده که نمیتونسته درست valid و sanitize کنه.


اگه دوس داشتید جزئیات بیشتری ازش بخونید. لینک رایت آپ:
🔗 https://kennethnym.com/blog/mathjax-css-injection/

🆔 @MdDaily

چند عادت خوب برنامه نویسی

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


1- پیش‌قدم (Proactive) بودن

دو نوع دایره‌ توی زندگی ما وجود داره یه دایره‌ی نگرانی (Concern) که شامل چیزاییه که خارج از کنترل ما هستن و یه دایره‌ی کوچیک‌تر هم دایره‌ی نفوذ (Influence) هست که چیزایی رو شامل میشه که می‌تونیم کنترلشون کنیم.

🖼 تصویر

یه عده برنامه‌نویس واکنش‌پذیر (Reactive) هستن که سرشون گرم چیزاییه که قابل کنترل نیست، مثلا شرایط دفتر و حتی فکر می‌کنن با یه ویدیوی «تو سه ماه بهترین برنامه‌نویس شو» میشه موفق شد. از طرف دیگه برنامه‌نویسای پیش‌قدم (Proactive) هم هستن که تمرین کردن رو انتخاب می‌کنن، تو چندتا مصاحبه و مسابقه شرکت می‌کنن تا بتونن فرصت‌های شغلی برای برنامه‌نویس شدن یا هرچیزی که شغل رویایی‌شونه رو باز کنن. به عبارت دیگه، واسه پیش‌قدم بودن بدون نادیده گرفتن مسائل مهم بیرون باید روی پیدا کردن الهام از درون تمرکز و کنترل کرد بدون ، به جای اینکه فقط منتظر یه «دستورالعمل جادویی» از بقیه بود.

2- از آخر به اول شروع کردن

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

3- کارهای مهم رو اول انجام دادن

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

۴. طرز فکر برد-برد

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

5- اول سعی کن بفهمی، بعد فهمیده بشی

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

6- تیز کردن اره (Sharpen the Saw)

برای اینکه این عادت رو بفهمیم، بیایم تصور کنیم دو تا کارگر هستن که دارن چوب خرد می‌کنن. کارگر اول یه جوون بوده که کل ۸ ساعت کاری رو بدون توقف به چوب خرد کردن ادامه داده. کارگر دوم یه آدم مسن‌تر بوده که هر ساعت به یه استراحت ۱۰ دقیقه‌ای نیاز داشته، تو این بینم وقت می‌ذاشته تا ارّه‌شو تیز کنه. اگه فکر می‌کنین که پیرمرد چوب بیشتری خرد می‌کنه، پس این عادت رو فهمیدین.به عنوان یه برنامه‌نویس، با خیلی از تکنولوژی‌های جدید روبرو می‌شی. برنامه‌نویس‌های مؤثر، اهمیتِ «یادگیری مداوم» رو درک می‌کنن. تیز کردن اره شامل اینه که برای به دست آوردن مهارت‌های جدید، به‌روز موندن تو روندهای صنعت و کاوش تو تکنولوژی‌های جدید، زمان سرمایه‌گذاری کنید. برنامه‌نویس‌های مؤثر باید با تمرین کردن، شرکت تو کنفرانس‌ها، شرکت تو انجمن‌های برنامه‌نویسی و غیره، برای توسعه‌ی حرفه‌ای‌شون وقت بذارن. این عادت می‌تونه به ما تو وفق پیدا کردن با پیشرفت‌های تکنولوژی کمک کنه.

منابع:
franklincovey
The 7 Habits of Highly Effective People
7 Habits that Programmers Must Have!


🆔 @MdDaily

مدتیه دارم روی یک اپلیکیشن کار میکنم که از زمان انتشار اولین نسخه ی mvp و گرفتن فیدبک ها تا الان تقریبا بیشتر 1 سال گذشته و حالا که داریم آماده میشیم برای اولین نسخه ی نهایی و انتشار عمومی، به نظرم خیلی فان میشه که تجربه ی این مدتم از شروع ایده که استارتش با ایده ی رادیو سید مهدی عزیز بود و چالش هایی که باهاش روبه رو بودیم تا مصاحبه هایی که با مدیران کسبوکار و استارتاپ های مختلف داشتم و حتی تکنولوژی هایی که استفاده شدن و سیستم دیزاین رو باهاتون به اشتراک بذارم و امیدوارم که کمک کننده باشه :)

پ ن ۱ :
به زودی یک پادکست هم ازش منتشر میکنیم

پ ن ۲:
پست های مربوطه با هشتگ #تجربه منتشر میشن

🆔 @MdDaily

#تجربه

شروع یک ایده از نیاز

چیزی بسازید که صد نفر عاشق آن باشند نه اینکه یک میلیون نفر آن را تا حدودی دوست داشته باشند.
- Brian Chesky

تقریبا اواخر سال 2022 بود که سید مهدی عزیز ایده ی رادیو رو پیاده سازی کرد. چیزی که من راجب این کار خیلی دوس داشتم این بود که همه چیز در ساده ترین حالت ممکن بود. بجای ساخت یک محصول کامل ما پلتفرمی را داشتیم که کار اصلیش یعنی بخش موزیک رو انجام می داد. زیر ساخت این پروژه تشکیل شده بود از یه سرور که روش Icecast پیاده سازی شده بود و یک فرانت که از این سرور Icecast لیست ژانر ها را می گرفت. Icecast به این صورت عمل میکنه که شما مثلا چنتا پوشه به اسم های pop , rap , hipop دارید و با استفاده از LIQUIDSOAP که یک زبان برای استریم Audio و Video هست میتونید برنامه نویسیش کنید. یک نمونه کد LIQUIDSOAP:

# Create a playlist containing all the files in the folder
pop = playlist("/music/pop/playlist.m3u")

output.icecast(
  %mp3,
  host="icecast2",
  port=8000,
  mount="pop",
  password="1234",
  fallible=true,
  url="http://127.0.0.1:15210/pop",
  encoding = "UTF-8",
  name="Pop",
  genre="pop",
  pop
)

در نهایت کاربر میتونست با وارد شدن به لینک http://127.0.0.1:15210/pop به استریم موزیک های ژانر pop گوش کنه. یه ایده ی فان و کاربردی بود.

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

یه متدی داریم به اسم Design thinking یا به اختصار DT . خیلی ساده بخوام بگم این متد تشکیل شده از 5 مرحلس.

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

👈 مرحله ی دوم تعریف مسئله (Define): توی این مرحله مشکل رو به شکلی واضح و روشن باید بیان کرد، جوری که همه بتونن درکش کنن.

👈 مرحله ی سوم ایده پردازی (Ideate): توی این مرحله افراد بدون قضاوت ایده هاشون رو میگن و تمرکز روی تعداد ایده هاست نه کیفیتشون.

👈 مرحله ی چهارم نمونه‌سازی اولیه (Prototype): توی این مرحله باید با ساخت نمونه های اولیه دید که ایده ها توی دنیای واقعی چطوری عمل میکنن

👈 مرحله ی پنجم تست (Test): در واقع نتیجه‌گیری از این مرحله به شما اجازه میده تا مراحل قبلی رو بررسی کنید که داده های بدست اومده درست بودند یا نه.

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

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

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

🔗 The 5 Stages in the Design Thinking Process


این بود خلاصه ای از مرحله ی شروع ایده و ادامه دارد...

🆔 @MdDaily