#شاید_موقت
چند وقته میخوام مقاله ی 🧠 How to be a great software engineer without using your brain. رو در قالب پست کانال خلاصه و عامیانه کنم ولی موقعی که به فارسی برمیگرده اون حالو هوای مقاله اصلی رو از دست میده :)
درکل مقاله ی جالبیه. اگه پیشنهادی دارید خوشحال میشم توی کامنت ها به اشتراک بگذارید
چند وقته میخوام مقاله ی 🧠 How to be a great software engineer without using your brain. رو در قالب پست کانال خلاصه و عامیانه کنم ولی موقعی که به فارسی برمیگرده اون حالو هوای مقاله اصلی رو از دست میده :)
درکل مقاله ی جالبیه. اگه پیشنهادی دارید خوشحال میشم توی کامنت ها به اشتراک بگذارید
DEV Community
🧠 How to be a great software engineer without using your brain.
Edit: Now also available on my blog. I choose a lazy person to do a hard job. Because a lazy person...
👍3🔥1
هنر خود آموزی: چطوری هرچیزی رو تو برنامهنویسی به خودت یاد بدی 🤓
💢 مقدمهای بر خود آموزی
ببین چی شده، شنیدی بازار کار برنامه نویسی داغه داغه؟ میری یه ویدیو تو یوتیوب پیدا میکنی یا یه دوره عجیب غریب پولی که یه چیزایی یادت میده و میگی ها! این همون چیزی بود که کم داشتم! اما فقط چند روز (یا شاید چند ساعت) طول میکشه تا بفهمی برنامه نویسی کار سختیه و دنبال کردن یه دوره الکی که تو نت پیدا کردی فقط بلدی چیزای دیگه رو کپی کنی، بعدش که میای خودت یه چیزی بنویسی فقط مات و مبهوت به صفحه خالی کامپیوترت نگاه میکنی...
ادامه پست در تلگراف:
🔗 https://telegra.ph/هنر-خود-آموزی-چطوری-هرچیزی-رو-تو-برنامهنویسی-به-خودت-یاد-بدی-05-03
🆔 @MdDaily
💢 مقدمهای بر خود آموزی
ببین چی شده، شنیدی بازار کار برنامه نویسی داغه داغه؟ میری یه ویدیو تو یوتیوب پیدا میکنی یا یه دوره عجیب غریب پولی که یه چیزایی یادت میده و میگی ها! این همون چیزی بود که کم داشتم! اما فقط چند روز (یا شاید چند ساعت) طول میکشه تا بفهمی برنامه نویسی کار سختیه و دنبال کردن یه دوره الکی که تو نت پیدا کردی فقط بلدی چیزای دیگه رو کپی کنی، بعدش که میای خودت یه چیزی بنویسی فقط مات و مبهوت به صفحه خالی کامپیوترت نگاه میکنی...
ادامه پست در تلگراف:
🔗 https://telegra.ph/هنر-خود-آموزی-چطوری-هرچیزی-رو-تو-برنامهنویسی-به-خودت-یاد-بدی-05-03
* به خاطر محدودیت های کارکتر تلگرام تو یدونه پست جا نشد، توی تلگراف نوشتم :)
🆔 @MdDaily
❤5👍2👌2
چطوری جلوی فک کردن بیش از حد (اورتینک) رو بگیریم؟
توی مدت گذشته درگیر اورتینک شده بودم و راه کار های این مقاله کمکم کردن تا حد زیادی کنترلش کنم و توی این پست قرار باهم بررسیشون کنیم و پست قرار از زبان نویسنده ی مقاله نقل بشه با سناریوی اینکه تصمیم میگیره یک هفته مقاله ننویسه و این دلیل اورتینکش میشه :)
—
من همیشه آدمی بودم که زیاد فکر و خیال می کنه. این اتفاق به دلایل مختلفی می افتاد، مثلاً:
- وقتی باید بین بین انتخاب های سخت تصمیم بگیرم.
- وقتی از یه اتفاقی که ممکنه خوب پیش نره می ترسم، مدام به عواقبش فکر می کنم.
- نگرانم که اگه یه کاری رو خراب کنم، بقیه چی فکر می کنن.
۵ تا راهکاری که انجام دادم:
این کارهایی که می خوام بگم تقریباً همون کارهایی هستن که سر کار برای اینکه دیگه الکی فکر و خیال نکنم انجام می دم. پس فکر کنم توی شرایط مختلف دیگه هم به دردتون بخوره.
۱. بنویسید
مزایا و معایب صرف نظر کردن از مقاله ام را در این هفته نوشتم.
مزایا:
- به خودم و خانوادهم بیشتر میرسم.
معایب:
- ترسناک بود که یه هفته ننویسم.
- فکر می کردم اگه یه هفته ننویسم، بعدش دیگه هیچ وقت نمی نویسم.
بعدش یه ذره عمیق تر به مزایا و معایب فکر کردم و دیدم که آیا واقعا درستن یا نه.
دلایل
چقدر طول می کشه یه مقاله بنویسم؟
تو طول هفته ۴ تا ۶ ساعت تیکه تیکه وقت گذاشتم.
چرا انقدر طول کشید؟ میشه تو نصف این زمان هم تمومش کرد؟
چرا ننوشتن مقاله بده؟
خبرنامه ام رو بیشتر از ۶ ماهه که دارم می گردونم. پس یه عادته و یه هفته ننوشتنش باعث نمیشه از بین بره.
۲. یه ضرب الاجل تعیین کنید
به خودم چالش دادم که زیر ۲ ساعت تمومش کنم.
تو یه هفته معمولی، یه ذره وقت میذارم و از بین یه عالمه موضوعی که تا حالا جمع کردم، یکی رو انتخاب می کنم.
این بار که مرحله ۱ رو انجام دادم، دیدم که موضوعش باید اورتینک باشه!
دو تا اتفاق احتمالی رو نوشتم:
اگه تو ۲ ساعت تمومش کنم: این هفته منتشرش می کنم. یالا! این اتفاق افتاد.
اگه تموم نشه: هفته بعدش منتشرش می کنم و میگم که چطوری تصمیم گرفتم و بهش پایبند موندم.
پس یه جورایی دو سر برد بود.
۳. توجه پیوسته
برای کار فکری مثل نوشتن مقاله، به تمرکز نیاز دارم. تو هفتههای معمولی، نوشتن خبرنامه رو تو هر بار وقت کمی که پیدا میکردم، جا میدادم (بعضی وقتا حتی ۱۰ دقیقه).
برای همین مدام بین موضوعات مختلف جابجا میشدم و تمرکزم رو از دست میدادم. این کار کلی اثر منفی داشت. مثلا:
تو زمان نوشتن، بین دو سه تا موضوع پرش میکردم.
قسمتهای سخت رو برای آخر نگه میداشتم.
برای این دفعه، تصمیم گرفتم که بیشتر از ۳ سشن نداشته باشم.
سشن ۱ - ۱ ساعت: نوشتن خلاصه و پیشنویس اولیه.
سشن ۲ - ۳۰ دقیقه: بازنویسی قسمتهای بد با دید تازه. ساخت دو تا تصویر.
سشن ۳ - ۳۰ دقیقه: ویرایش نهایی و اعمال تغییرات جزئی.
نتیجه نهایی خیلی به چیزی که تصمیم گرفته بودم نزدیک بود.
🖼 تصویر
۴. مراقب کمالگرایی باشید
کمالگرایی باعث فکر کردن بیش از حد میشه! پس باید خیلی مراقب باشیم که تو دام کمالگرایی نیفتیم.
برای نوشتن خبرنامه، یه حس خوبی پیدا کردم که چی به اندازه کافی خوبه در مقابل اینکه خیلی خوبه. اما هنوزم با مرز بین خیلی خوب و فوقالعاده عالی مشکل دارم. معیار برای این مقاله این بود که به سطح «به اندازه کافی خوب» برسه. اگه تو ۲ ساعت بهش میرسیدم منتشرش میکردم وگرنه یه هفته عقبش مینداختم.
🖼 تصویر
وقتی تازه کاری رو شروع میکنید، فهمیدن اینکه «به اندازه کافی خوب» یعنی چی میتونه سخت باشه. تو این مواقع، گرفتن فیدبک زودهنگام بهتون کمک میکنه خودتون رو مچ کنید.
۵. اولویتبندی کنید
وقتی زمان محدوده، باید با دقت ازش استفاده کنید تا روی کارایی که بیشترین ارزش رو داره تمرکز کنید.
برای این مورد، P0ها و P1هارو تعریف کردم.
اولویت P0 - باید انجام بشه.
پیام اصلی و ارزش برای خواننده واضح باشه. تو این مورد: پیام اصلی = مراحلی که برای توقف اورتینک انجام شده و شما میتونید برای مبارزه با اورتینک خودتون ازش استفاده کنید.
مقاله به راحتی قابل خوندن باشه.
مقدمه جذاب و نتیجهگیری واضح داشته باشه.
اولویت P1 - خوبه که داشته باشیم.
مقدمه قویتر.
نکات عملی قویتری که سناریوهای مختلف رو پوشش بده.
تو این مورد: به اشتراک گذاشتن مثال یه مهندس نرمافزار که اکثر شما میتونید باهاش ارتباط برقرار کنید.
تصاویری با استعاره. اینا باعث میشه خواننده بگه «آها!»
بهینهسازی سئو
یادداشت پایانی
🆔 @MdDaily
توی مدت گذشته درگیر اورتینک شده بودم و راه کار های این مقاله کمکم کردن تا حد زیادی کنترلش کنم و توی این پست قرار باهم بررسیشون کنیم و پست قرار از زبان نویسنده ی مقاله نقل بشه با سناریوی اینکه تصمیم میگیره یک هفته مقاله ننویسه و این دلیل اورتینکش میشه :)
—
من همیشه آدمی بودم که زیاد فکر و خیال می کنه. این اتفاق به دلایل مختلفی می افتاد، مثلاً:
- وقتی باید بین بین انتخاب های سخت تصمیم بگیرم.
- وقتی از یه اتفاقی که ممکنه خوب پیش نره می ترسم، مدام به عواقبش فکر می کنم.
- نگرانم که اگه یه کاری رو خراب کنم، بقیه چی فکر می کنن.
۵ تا راهکاری که انجام دادم:
این کارهایی که می خوام بگم تقریباً همون کارهایی هستن که سر کار برای اینکه دیگه الکی فکر و خیال نکنم انجام می دم. پس فکر کنم توی شرایط مختلف دیگه هم به دردتون بخوره.
۱. بنویسید
مزایا و معایب صرف نظر کردن از مقاله ام را در این هفته نوشتم.
مزایا:
- به خودم و خانوادهم بیشتر میرسم.
معایب:
- ترسناک بود که یه هفته ننویسم.
- فکر می کردم اگه یه هفته ننویسم، بعدش دیگه هیچ وقت نمی نویسم.
بعدش یه ذره عمیق تر به مزایا و معایب فکر کردم و دیدم که آیا واقعا درستن یا نه.
دلایل
چقدر طول می کشه یه مقاله بنویسم؟
تو طول هفته ۴ تا ۶ ساعت تیکه تیکه وقت گذاشتم.
چرا انقدر طول کشید؟ میشه تو نصف این زمان هم تمومش کرد؟
چرا ننوشتن مقاله بده؟
خبرنامه ام رو بیشتر از ۶ ماهه که دارم می گردونم. پس یه عادته و یه هفته ننوشتنش باعث نمیشه از بین بره.
۲. یه ضرب الاجل تعیین کنید
به خودم چالش دادم که زیر ۲ ساعت تمومش کنم.
تو یه هفته معمولی، یه ذره وقت میذارم و از بین یه عالمه موضوعی که تا حالا جمع کردم، یکی رو انتخاب می کنم.
این بار که مرحله ۱ رو انجام دادم، دیدم که موضوعش باید اورتینک باشه!
دو تا اتفاق احتمالی رو نوشتم:
اگه تو ۲ ساعت تمومش کنم: این هفته منتشرش می کنم. یالا! این اتفاق افتاد.
اگه تموم نشه: هفته بعدش منتشرش می کنم و میگم که چطوری تصمیم گرفتم و بهش پایبند موندم.
پس یه جورایی دو سر برد بود.
۳. توجه پیوسته
برای کار فکری مثل نوشتن مقاله، به تمرکز نیاز دارم. تو هفتههای معمولی، نوشتن خبرنامه رو تو هر بار وقت کمی که پیدا میکردم، جا میدادم (بعضی وقتا حتی ۱۰ دقیقه).
برای همین مدام بین موضوعات مختلف جابجا میشدم و تمرکزم رو از دست میدادم. این کار کلی اثر منفی داشت. مثلا:
تو زمان نوشتن، بین دو سه تا موضوع پرش میکردم.
قسمتهای سخت رو برای آخر نگه میداشتم.
برای این دفعه، تصمیم گرفتم که بیشتر از ۳ سشن نداشته باشم.
سشن ۱ - ۱ ساعت: نوشتن خلاصه و پیشنویس اولیه.
سشن ۲ - ۳۰ دقیقه: بازنویسی قسمتهای بد با دید تازه. ساخت دو تا تصویر.
سشن ۳ - ۳۰ دقیقه: ویرایش نهایی و اعمال تغییرات جزئی.
نتیجه نهایی خیلی به چیزی که تصمیم گرفته بودم نزدیک بود.
🖼 تصویر
۴. مراقب کمالگرایی باشید
کمالگرایی باعث فکر کردن بیش از حد میشه! پس باید خیلی مراقب باشیم که تو دام کمالگرایی نیفتیم.
برای نوشتن خبرنامه، یه حس خوبی پیدا کردم که چی به اندازه کافی خوبه در مقابل اینکه خیلی خوبه. اما هنوزم با مرز بین خیلی خوب و فوقالعاده عالی مشکل دارم. معیار برای این مقاله این بود که به سطح «به اندازه کافی خوب» برسه. اگه تو ۲ ساعت بهش میرسیدم منتشرش میکردم وگرنه یه هفته عقبش مینداختم.
🖼 تصویر
وقتی تازه کاری رو شروع میکنید، فهمیدن اینکه «به اندازه کافی خوب» یعنی چی میتونه سخت باشه. تو این مواقع، گرفتن فیدبک زودهنگام بهتون کمک میکنه خودتون رو مچ کنید.
۵. اولویتبندی کنید
وقتی زمان محدوده، باید با دقت ازش استفاده کنید تا روی کارایی که بیشترین ارزش رو داره تمرکز کنید.
برای این مورد، P0ها و P1هارو تعریف کردم.
اولویت P0 - باید انجام بشه.
پیام اصلی و ارزش برای خواننده واضح باشه. تو این مورد: پیام اصلی = مراحلی که برای توقف اورتینک انجام شده و شما میتونید برای مبارزه با اورتینک خودتون ازش استفاده کنید.
مقاله به راحتی قابل خوندن باشه.
مقدمه جذاب و نتیجهگیری واضح داشته باشه.
اولویت P1 - خوبه که داشته باشیم.
مقدمه قویتر.
نکات عملی قویتری که سناریوهای مختلف رو پوشش بده.
تو این مورد: به اشتراک گذاشتن مثال یه مهندس نرمافزار که اکثر شما میتونید باهاش ارتباط برقرار کنید.
تصاویری با استعاره. اینا باعث میشه خواننده بگه «آها!»
بهینهسازی سئو
یادداشت پایانی
اورتینک هم بد نیست. اگه راجع به چیزی بیش از حد فکر میکنم، یعنی برام مهمه. البته به شرطی که به موقع متوجه فکر کردن بیش از حدم بشم و کاری در موردش انجام بدم. برای همه شما که بیش از حد فکر میکنید، امیدوارم این مقاله نکات عملی رو باهاتون به اشتراک گذاشته باشه.
🆔 @MdDaily
👌10👍2🔥2🎉1
توی نسخه ی وب X بودم دیدم به گزینه های more آیتم جدیدی به اسم Jobs درحالت Beta اضافه شده که شما میتونید با جستجوی کلید واژه های مربوط به حوزه ی کاریتون (به عنوان نمونه من golang رو نوشتم) موقعیت های شغلی مربوطش رو براتون میاره و گزینه ی Apply هم داره. به نظر میرسه با حجم داده ای که روی X هست شاید به زودی بتونه تبدیل به رقیب لینکدین بشه.
🔗 https://twitter.com/jobs
🆔 @MdDaily
🔗 https://twitter.com/jobs
🆔 @MdDaily
⚡3🦄1
درس هایی راجب برنامه نویسی از زبان Matt Butcher
یادتون باشه هر خط کدی که مینویسین باید بعدا ازش پشتیبانی کنین!
این حرف خیلی معنی داره که تو ادامه میگم:
- برنامه نویسی به عنوان صنعتگری
- چرخ رو از اول اختراع نکن
- هزینه پیچیدگی
- کاهش نیازهای آینده برای نگهداری
- چرا خود آیندتون (و دیگران) قدردان کد امروزن
برنامه نویسی به عنوان صنعتگری
«صنعتگری» به معنی تعهد به یه حرفه است، جایی که مهارت با گذشت زمان و از طریق تلاش سخت و تمرین مداوم به وجود میاد. نوشتن کد، با تمام دیباگ و تست کردن و بازنویسیهاش، یه کار کاملاً عملیه. ساختن نرمافزار خوب به مهارت، دانش و تمایل مداوم برای پیشرفت نیاز داره. وقتی کد مینویسین، وقت بذارین که کارتون رو خوب انجام بدین. درسته که «کمالگرایی دشمنه» و باید کد بزنین که کارتون راه بیفته. اما رعایت اصول درست کد نویسی، اسمگذاری درست متغیرها و فکر کردن به مشکلی که دارین حل میکنین، همه اینا باعث میشه که نگهداری از کدتون تو دراز مدت راحتتر بشه.
پشتیبانی از کد ضعیف یه درده. اما نگهداری از کد خوب، از لحاظ فکری خیلی راضیکنندهست.
چرخ رو از اول اختراع نکن
یه کتابخونه یا ابزاری هست که کار رو راه میندازه، ولی خب، ما میتونیم بهتر انجامش بدیم!
فکر میکنم هر مهندس نرمافزاری حداقل یه بار این کار رو کرده و همیشه یه جور توجیه هم هست:
کتابخونههای دیگهای هم بودن، اما سنگین/پر از باگ/پیچیده/و …
یه راه جدید دارم که بقیه بهش فکر نکرده بودن.
انجام دادنش خودم بیشتر یاد می گیرم تا اینکه از کد بقیه استفاده کنم (حرفت درسته، اما با هزینهای خیلی بیشتر از اون چیزی که فکرشو میکردی).
تو همه این موارد، دو تا چیز نادیده گرفته میشن:
چقدر بقیه زمان صرف کرده بودن که قبلاً مشکل رو حل کنن. (پختگی اون کد)
منِ آینده چقدر باید وقت بذاره واسه درست کردن و نگهداری اون کد.
پس وقتی که ابزار آماده هست، اما فکر میکنین شاید خودتون بهتر انجامش بدین، از خودتون بپرسین چقدر برای نگهداری از اون کد تو چند سال آینده اشتیاق دارین؟ آیا استثناهایی برای این قضیه وجود داره؟ بله! اما اونم بعد از اینکه واقعاً بررسی کردین که آیا راهحلهای موجود به اندازه کافی برای انجام کار خوب هستن یا نه.
هر چی کدت پیچیدهتر، دیباگش سختتره
فرض کنید یه تابع می نویسید که یه عملیاتی رو انجام میده ولی کدش پیچیدس و حالا برای دفاع از خودتون میگید تست نوشتید. و کدتون ار نظر فرمت بینقص و خیلی خوب کار میکنه. بعد یه روز یه آسیبپذیری پیدا میشه. یه هکر بتونه تابعی که نوشید رو مجبور کنه که بیشتر از حافظهی سیستم، حافظه اختصاص بده. بعد از چند سال که اصلاً به این کد دست نزدید، باید درستش کنید. وقتی کد رو میخونید، انگار یه چیز کاملاً غریبس , باید بفهمید چطور میتونید اون باگ رو درست کنید.
شاید مجبور بشین خطهای بیشتری کد بنویسین (چون کارهای پیچیده رو به تابعهای کوچیکتر تقسیم میکنین)، اما اگه نتیجهش بشه کدی که دیباگ و نگهداریش راحتتره، ارزشش رو داره.
کاهش نیازهای آینده برای پشتیبانی
هر سیستم خوبی یه سری کنترل کیفیت داره. کد هم باید همینطور باشه. باید یه استراتژی برای تست نوشتن پیدا کنید،به هر حال، مهم نیست استراتژی شما چیه، اگه الان تست نکنین، بعداً باید دیباگ کنین.
خودت آیندت یادش نمیاد که خودت الانت به چی فکر میکرده
پس همهچی رو مستند کن! آدما یه جور پیشفرض عجیب دارن. فکر میکنیم که فردا همه چیزایی که امروز اتفاق افتاده رو یادمون میمونه. خود آیندهت جزئیات ریز اینکه چرا امروز این کد رو به این شکل نوشتی، یا چرا اون متغیر رو fhr اسم گذاشتی، یا چرا کامنت // FIXME later رو رو خط ۲۳۵ جا گذاشتی، یادش نمیاد.
بهترین راهی که میتونی با محدودیتهای حافظهت مقابله کنی اینه که کدت رو واضح بنویسی. این یعنی:
کامنت بذار.
اسمها رو خوب انتخاب کن.
مستندات خوب بنویس.
کامیتمسیجهای مفید بنویس.
خود آیندهت ازت ممنون میشه. یا حداقل از دستت عصبانی نمیشه.
نتیجه گیری: اگه بقیه نتونن اونو بفهمند، همیشه مشکل شما باقی میمونه
پس طوری مستندش کن که بقیه بتونن اونو بفهمند.
اگه کدتون راحتفهم نباشه، مثل یه کابوس برمیگرده سراغتون. چون بقیه نمیتونن اونو بفهمند. کدتون رو انقدر راحتفهم کنین که یه نفر دیگه بتونه اونو درست کنه بدون اینکه حتی نیاز باشه شما بفهمین!
نتیجه گیری
این قانون رو به عنوان یه راه برای ترغیب کردن خودتون به بهبود کدتون پیشنهاد میدم:
یادتون باشه هر خط کدی که مینویسین باید بعدا ازش پشتیبانی کنین!
این کار باعث صرفهجویی در زمان و انرژی شما در آینده میشه. باعث میشه همکاراتون عصبانی نشن. تغییر دادن کد امروز به کد فردا رو راحتتر میکنه. و به احتمال زیاد باعث میشه همه فکر کنن شما هم یکی از اون برنامهنویسهای فوق حرفهای هستین.
🆔 @MdDaily
یادتون باشه هر خط کدی که مینویسین باید بعدا ازش پشتیبانی کنین!
این حرف خیلی معنی داره که تو ادامه میگم:
- برنامه نویسی به عنوان صنعتگری
- چرخ رو از اول اختراع نکن
- هزینه پیچیدگی
- کاهش نیازهای آینده برای نگهداری
- چرا خود آیندتون (و دیگران) قدردان کد امروزن
برنامه نویسی به عنوان صنعتگری
«صنعتگری» به معنی تعهد به یه حرفه است، جایی که مهارت با گذشت زمان و از طریق تلاش سخت و تمرین مداوم به وجود میاد. نوشتن کد، با تمام دیباگ و تست کردن و بازنویسیهاش، یه کار کاملاً عملیه. ساختن نرمافزار خوب به مهارت، دانش و تمایل مداوم برای پیشرفت نیاز داره. وقتی کد مینویسین، وقت بذارین که کارتون رو خوب انجام بدین. درسته که «کمالگرایی دشمنه» و باید کد بزنین که کارتون راه بیفته. اما رعایت اصول درست کد نویسی، اسمگذاری درست متغیرها و فکر کردن به مشکلی که دارین حل میکنین، همه اینا باعث میشه که نگهداری از کدتون تو دراز مدت راحتتر بشه.
پشتیبانی از کد ضعیف یه درده. اما نگهداری از کد خوب، از لحاظ فکری خیلی راضیکنندهست.
چرخ رو از اول اختراع نکن
یه کتابخونه یا ابزاری هست که کار رو راه میندازه، ولی خب، ما میتونیم بهتر انجامش بدیم!
فکر میکنم هر مهندس نرمافزاری حداقل یه بار این کار رو کرده و همیشه یه جور توجیه هم هست:
کتابخونههای دیگهای هم بودن، اما سنگین/پر از باگ/پیچیده/و …
یه راه جدید دارم که بقیه بهش فکر نکرده بودن.
انجام دادنش خودم بیشتر یاد می گیرم تا اینکه از کد بقیه استفاده کنم (حرفت درسته، اما با هزینهای خیلی بیشتر از اون چیزی که فکرشو میکردی).
تو همه این موارد، دو تا چیز نادیده گرفته میشن:
چقدر بقیه زمان صرف کرده بودن که قبلاً مشکل رو حل کنن. (پختگی اون کد)
منِ آینده چقدر باید وقت بذاره واسه درست کردن و نگهداری اون کد.
پس وقتی که ابزار آماده هست، اما فکر میکنین شاید خودتون بهتر انجامش بدین، از خودتون بپرسین چقدر برای نگهداری از اون کد تو چند سال آینده اشتیاق دارین؟ آیا استثناهایی برای این قضیه وجود داره؟ بله! اما اونم بعد از اینکه واقعاً بررسی کردین که آیا راهحلهای موجود به اندازه کافی برای انجام کار خوب هستن یا نه.
هر چی کدت پیچیدهتر، دیباگش سختتره
فرض کنید یه تابع می نویسید که یه عملیاتی رو انجام میده ولی کدش پیچیدس و حالا برای دفاع از خودتون میگید تست نوشتید. و کدتون ار نظر فرمت بینقص و خیلی خوب کار میکنه. بعد یه روز یه آسیبپذیری پیدا میشه. یه هکر بتونه تابعی که نوشید رو مجبور کنه که بیشتر از حافظهی سیستم، حافظه اختصاص بده. بعد از چند سال که اصلاً به این کد دست نزدید، باید درستش کنید. وقتی کد رو میخونید، انگار یه چیز کاملاً غریبس , باید بفهمید چطور میتونید اون باگ رو درست کنید.
شاید مجبور بشین خطهای بیشتری کد بنویسین (چون کارهای پیچیده رو به تابعهای کوچیکتر تقسیم میکنین)، اما اگه نتیجهش بشه کدی که دیباگ و نگهداریش راحتتره، ارزشش رو داره.
کاهش نیازهای آینده برای پشتیبانی
هر سیستم خوبی یه سری کنترل کیفیت داره. کد هم باید همینطور باشه. باید یه استراتژی برای تست نوشتن پیدا کنید،به هر حال، مهم نیست استراتژی شما چیه، اگه الان تست نکنین، بعداً باید دیباگ کنین.
خودت آیندت یادش نمیاد که خودت الانت به چی فکر میکرده
پس همهچی رو مستند کن! آدما یه جور پیشفرض عجیب دارن. فکر میکنیم که فردا همه چیزایی که امروز اتفاق افتاده رو یادمون میمونه. خود آیندهت جزئیات ریز اینکه چرا امروز این کد رو به این شکل نوشتی، یا چرا اون متغیر رو fhr اسم گذاشتی، یا چرا کامنت // FIXME later رو رو خط ۲۳۵ جا گذاشتی، یادش نمیاد.
بهترین راهی که میتونی با محدودیتهای حافظهت مقابله کنی اینه که کدت رو واضح بنویسی. این یعنی:
کامنت بذار.
اسمها رو خوب انتخاب کن.
مستندات خوب بنویس.
کامیتمسیجهای مفید بنویس.
خود آیندهت ازت ممنون میشه. یا حداقل از دستت عصبانی نمیشه.
نتیجه گیری: اگه بقیه نتونن اونو بفهمند، همیشه مشکل شما باقی میمونه
پس طوری مستندش کن که بقیه بتونن اونو بفهمند.
اگه کدتون راحتفهم نباشه، مثل یه کابوس برمیگرده سراغتون. چون بقیه نمیتونن اونو بفهمند. کدتون رو انقدر راحتفهم کنین که یه نفر دیگه بتونه اونو درست کنه بدون اینکه حتی نیاز باشه شما بفهمین!
نتیجه گیری
این قانون رو به عنوان یه راه برای ترغیب کردن خودتون به بهبود کدتون پیشنهاد میدم:
یادتون باشه هر خط کدی که مینویسین باید بعدا ازش پشتیبانی کنین!
این کار باعث صرفهجویی در زمان و انرژی شما در آینده میشه. باعث میشه همکاراتون عصبانی نشن. تغییر دادن کد امروز به کد فردا رو راحتتر میکنه. و به احتمال زیاد باعث میشه همه فکر کنن شما هم یکی از اون برنامهنویسهای فوق حرفهای هستین.
🆔 @MdDaily
❤🔥2👍2✍1🔥1👏1
#ام_دی_کورس
سوال مصاحبه System Design: طراحی کوتاه کننده URL
ادامه در:
🔗 https://mddaily.web.app/blog/system-design-interview-question-design-url-shortener/
🆔 @MdDaily
سوال مصاحبه System Design: طراحی کوتاه کننده URL
یه سوال مصاحبه طراحی سیستم داریم که توش باید یه ابزار کوتاه کننده URL مثل TinyURL یا Bitly رو از صفر طراحی کنیم. همه چی رو از الزامات طراحی و معماری و طراحی اجزا تا اینکه چطور میشه سیستم رو برای سرعت بالا و امنیت بیشتر ارتقا داد، بررسی میکنیم.
اول از همه باید مشخص کنیم که این سیستم چیکار باید بکنه و چیکار نباید بکنه.
از نظر کارکردی، دو تا وظیفه اصلی داره:
وقتی یه URL بلند بهش میدی، باید یه URL کوتاه بسازه.
وقتی یه URL کوتاه بهش میدی، باید کاربر رو به URL بلند ببره.
برای این سرویس دو تا چیزه خیلی مهمه: اینکه کارش رو خیلی سریع انجام بده (پاسخهای کوتاه) و اینکه همیشه در دسترس باشه (همیشه آنلاین). میشه گفت اولویت با این دوتاست.
سوالات شفاف سازی برای مصاحبه کننده
اینجا چند تا .....
ادامه در:
🔗 https://mddaily.web.app/blog/system-design-interview-question-design-url-shortener/
🆔 @MdDaily
❤🔥5👍1🔥1
Md Daily
#ام_دی_کورس سوال مصاحبه System Design: طراحی کوتاه کننده URL یه سوال مصاحبه طراحی سیستم داریم که توش باید یه ابزار کوتاه کننده URL مثل TinyURL یا Bitly رو از صفر طراحی کنیم. همه چی رو از الزامات طراحی و معماری و طراحی اجزا تا اینکه چطور میشه سیستم رو برای…
توی این قسمت از ام دی کورس خیلی ساده و خلاصه به System Design یه کوتاه کننده لینک پرداخته شده و راجب مباحثی مثل معماری، انتخاب دیتابیس مناسب، لودبالانسر، کشینگ و... صحبت شده و مثل همیشه منابعی که استفاده کردمم آخر مقاله در دسترسن :)
❤🔥5👍1
هوش مصنوعی، یار یا جاسوس؟ نگاهی به 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
هوش مصنوعی تو این چند سال حسابی سر و صدا کرده و کلی چیزای جدید و باحال بهمون داده. اما یه چیز هست که تو این هیاهو گم شده: حریم خصوصی ما!
از زمانی که مایکروسافت برای ادغام ابزارهای مبتنی بر هوش مصنوعی تو محصولاتش با 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
👍6
کوپایلت برای تلگرام ربات رسمی داده :)
ولی نیاز به تایید شماره داره که متاسفانه فعلا برای شماره های ایرانی دردسترس نیست
🔗 آدرس ربات: @CopilotOfficialBot
🔗 آدرس معرفی تو سایت مایکروسافت:
https://www.microsoft.com/en-us/edge/copilot-for-social?form=MY02F9&ch=1
🆔 @MdDaily
ولی نیاز به تایید شماره داره که متاسفانه فعلا برای شماره های ایرانی دردسترس نیست
🔗 آدرس ربات: @CopilotOfficialBot
🔗 آدرس معرفی تو سایت مایکروسافت:
https://www.microsoft.com/en-us/edge/copilot-for-social?form=MY02F9&ch=1
🆔 @MdDaily
😁5❤🔥1👍1🥰1
من معمولا از پلتفرم های دیگه مطلب توی کانال نمیذارم ولی این یکی خیلی خوب بود :)
متیو کریمی توی یک رشته پست توئیتری اومده بود چیزایی که ازش درآمد داشته رو رایگان به اشتراک گذاشته مثل دوره های آموزشیش.
لینک دورهها:
جعبه ابزار بیزنس: 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
🎁 کد تخفیف:
و آخر توئیتشون گفتند:
</متیو کریمی>
🆔 @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
👍7👎1😁1🗿1
چند Best Practice در طراحی REST API
امروزه که همه چی به هم وصله، REST APIs با طراحی خوب، پایه و اساس برنامههای کاربردی کارآمد و قابل ارتقا هستن.
نوشتن دیزاین های REST API تمیز به چند دلیل خیلی مهمه:
استفاده راحتتر: یه API با طراحی خوب، کاربرپسند و سادست، و برای توسعهدهندهها با هر سطحی قابل استفادهست. اینجوری دیگه نیازی به صرف زمان زیاد برای یادگیری نیست.
نگهداری راحتتر: کد تمیز، نگهداری رو راحتتر میکنه. با این کار پیدا کردن و رفع اشکال، اضافه کردن قابلیتهای جدید و ارتقای API سادهتر و هزینههای توسعه هم کم میشه.
کاهش زمان توسعه: با مشخصات API دقیق و مستندات شفاف، میشه خیلی سریعتر برنامهنویسی کرد چون دیگه نیازی به حدس و گمان و تستهای مفصل نیست. اینجوری هم در زمان و هم در منابع صرفهجویی میشه.
مقیاسپذیری بیشتر: یه طراحی تمیز، با ارائه یه معماری ماژولار که به راحتی قابل گسترشه، امکان مقیاسپذیری راحت رو فراهم میکنه. اینجوری API میتونه با نیازهای برنامه شما رشد کنه و مشکلی پیش نیاد.
استفاده مجدد بیشتر: یه API با طراحی خوب رو میشه تو چند برنامه دیگه هم استفاده کرد، اینجوری دیگه نیازی به تکرار کار نیست و همه چی منظمتر میشه. اینجوری توسعه برنامهها سادهتر میشه و در زمان و تلاش هم صرفهجویی میشه.
مستندات بهتر: طراحیهای تمیز، مستندسازی رو هم سادهتر میکنن و نحوه کارکرد API و نحوه استفاده درست ازش رو به طور کامل برای برنامهنویسها توضیح میدن. اینجوری همه چی شفاف میشه و استفاده از API هم راحتتر میشه.
رولز ها یا قوانین URI
ساختار یه URI به شکل زیره:
مثال:
تو دنیای URI دو نوع منبع (resource) داریم:
منابع مجموعه (Collection resources): این نوع منبع، مجموعهای از منابع دیگه رو در خودش داره. میشه اون رو به یه جدول تو دیتابیس تشبیه کرد. مثلا میشه یه منبع مجموعه به اسم users داشته باشیم که لیستی از تمام کاربرها رو در خودش داره.
منابع تکی (Singleton resources): این نوع منبع، فقط شامل یه منبع واحده. میشه اون رو به یه رکورد تو دیتابیس تشبیه کرد. مثلا میشه یه منبع تکی به اسم users/123 داشته باشیم که اطلاعات مربوط به یه کاربر خاص با شناسه ۱۲۳ رو نشون بده
نکات مهم طراحی Rest Api
۱. منابع Collection باید جمع (plural) باشن :
۲. منابع Singleton باید مفرد (singular) باشن و با شناسه یکتاشون (unique id) جایگزین بشن:
فرض کن میخوای اطلاعات یه بازیکن خاص رو نمایش بدی، بجای استفاده از players/Ronaldo بهتره از شناسه عددی یا کد اون بازیکن استفاده کنی، مثلا players/12345.
۴. برای بهتر خونده شدن، از خط تیره (-) به جای زیرخط (_) استفاده کنید:
۵. تو مسیرهای URI از حروف کوچک استفاده کنید:
۶. تو URI ها از پسوند فایل استفاده نکنید:
۷. از اسم فانکشن های CRUD تو URI استفاده نکنید:
برای عملیات ایجاد، خواندن، بروزرسانی و حذف منابع، از اسم هایی مثل create, read, update, delete تو URI استفاده نکن. بجاش از Http Method های استاندارد استفاده کن.
۸. بخش کوئری (query) تو URI فقط برای منابع Collection قابل استفاده است:
۹. از بخش کوئری برای اسکرول (paging) کردن نتایج منابع مجموعه استفاده کنید:
نسخه بندی API برای موارد زیر اهمیت داره:
حفظ سازگاری قبلی (Maintaining backward compatibility)
تضمین یک API سازگار و با طراحی خوب: استفاده از نامگذاریهای یکسان تو همه نسخهها به یه تجربه کاربری خوب کمک میکنه. تغییر endpoint این تجربه رو بهم میریزه و نسخه بندی به جلوگیری از این موضوع کمک میکنه.
چند استراتزی برای نسخه بندی API:
URI Versioning (پیشنهادی):
Header Versioning:
🆔 @MdDaily
امروزه که همه چی به هم وصله، 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
👍6🔥3❤1
توی گیت هاب CSS injection پیدا کردن :)
🔗 لینک توییت
برای تستش این پروفایل و ریپو های گیت هاب رو ببیند:
https://github.com/yacineMTB
https://github.com/vmfunc/vmfunc
https://github.com/RambIing
آپدیت: فعلا باگش فیکس شده ولی توی کامنت توییت اسکرین شات هاشون هست :)
🆔 @MdDaily
🔗 لینک توییت
برای تستش این پروفایل و ریپو های گیت هاب رو ببیند:
https://github.com/yacineMTB
https://github.com/vmfunc/vmfunc
https://github.com/RambIing
آپدیت: فعلا باگش فیکس شده ولی توی کامنت توییت اسکرین شات هاشون هست :)
🆔 @MdDaily
😁7
داشتم توی ریپو های اپن سورس گوگل میگشتم که رسیدم به پروژه 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
باهاش میتونید با استفاده از پایتون و کمترین میزان کد نویسی وپ اب بسازید و برای اپ های internal و دمو خیلی باحاله.
ویژگی هاش:
👈 پشتیبانی از Hot reload
👈 بدون نیاز به Javanoscript/CSS/HTML میتونید ui های کاستوم بسازید
👈 یادگیری آسون
👈 کامپوننت های آماده
👈 و ..
دموها:
🔗 https://google.github.io/mesop/demo/
وبسایت:
🔗 https://google.github.io/mesop/
گیت هاب:
🔗 https://github.com/google/mesop
🆔 @MdDaily
👍4🔥2
Md Daily
توی گیت هاب CSS injection پیدا کردن :) 🔗 لینک توییت برای تستش این پروفایل و ریپو های گیت هاب رو ببیند: https://github.com/yacineMTB https://github.com/vmfunc/vmfunc https://github.com/RambIing آپدیت: فعلا باگش فیکس شده ولی توی کامنت توییت اسکرین شات…
رایت آپ CSS injection گیت هاب هم منشتر شد
دقیقا چه اتفاقی افتاده بود؟
توی MathJax که گیت هاب ازش برای رندر عبارات ریاضی توی محتوای markdown استفاده میکرده یه گزارش باگ داده میشه که توی یکی از latex macros ها به اسم
درحالت نرمال انتظار میره که با همچین فرمتی استفاده بشه:
ولی این امکان وجود داشته که بین brackets ها هرچیزی وارد و رندر بشه و در نتیجه css injection به وجود بیاد :)
خلاصش اینکه هرچیزی که بین brackets ها نوشته میشده مستقیم توی style گیت هاب هم رندر میشده و به به کاربرا اجازه میداده که استایل کل صفحه رو عوض کنند.
مشکل کد mathjax این بوده که نمیتونسته درست valid و sanitize کنه.
اگه دوس داشتید جزئیات بیشتری ازش بخونید. لینک رایت آپ:
🔗 https://kennethnym.com/blog/mathjax-css-injection/
🆔 @MdDaily
دقیقا چه اتفاقی افتاده بود؟
توی 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
Kennethnym
diving into mathjax css injection attack
a write-up on the recent mathjax css injection vulnerability
👍4🔥1👏1
چند عادت خوب برنامه نویسی
ما با الگوها و عادتهایی که هر روز انجام میدیم زندگی میکنیم که این عادات بر نتایج اهداف ما تأثیر میذارن. پس اگه قرار زندگیمون رو تغییر بدیم، اولین کاری که باید انجام بدیم تغییر عادت هاست.
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
ما با الگوها و عادتهایی که هر روز انجام میدیم زندگی میکنیم که این عادات بر نتایج اهداف ما تأثیر میذارن. پس اگه قرار زندگیمون رو تغییر بدیم، اولین کاری که باید انجام بدیم تغییر عادت هاست.
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
👍6❤🔥4🔥1
مدتیه دارم روی یک اپلیکیشن کار میکنم که از زمان انتشار اولین نسخه ی mvp و گرفتن فیدبک ها تا الان تقریبا بیشتر 1 سال گذشته و حالا که داریم آماده میشیم برای اولین نسخه ی نهایی و انتشار عمومی، به نظرم خیلی فان میشه که تجربه ی این مدتم از شروع ایده که استارتش با ایده ی رادیو سید مهدی عزیز بود و چالش هایی که باهاش روبه رو بودیم تا مصاحبه هایی که با مدیران کسبوکار و استارتاپ های مختلف داشتم و حتی تکنولوژی هایی که استفاده شدن و سیستم دیزاین رو باهاتون به اشتراک بذارم و امیدوارم که کمک کننده باشه :)
پ ن ۱ :
به زودی یک پادکست هم ازش منتشر میکنیم
پ ن ۲:
پست های مربوطه با هشتگ #تجربه منتشر میشن
🆔 @MdDaily
پ ن ۱ :
به زودی یک پادکست هم ازش منتشر میکنیم
پ ن ۲:
پست های مربوطه با هشتگ #تجربه منتشر میشن
🆔 @MdDaily
🔥11❤3❤🔥2👍2👎1
#تجربه
شروع یک ایده از نیاز
تقریبا اواخر سال 2022 بود که سید مهدی عزیز ایده ی رادیو رو پیاده سازی کرد. چیزی که من راجب این کار خیلی دوس داشتم این بود که همه چیز در ساده ترین حالت ممکن بود. بجای ساخت یک محصول کامل ما پلتفرمی را داشتیم که کار اصلیش یعنی بخش موزیک رو انجام می داد. زیر ساخت این پروژه تشکیل شده بود از یه سرور که روش Icecast پیاده سازی شده بود و یک فرانت که از این سرور Icecast لیست ژانر ها را می گرفت. Icecast به این صورت عمل میکنه که شما مثلا چنتا پوشه به اسم های pop , rap , hipop دارید و با استفاده از LIQUIDSOAP که یک زبان برای استریم Audio و Video هست میتونید برنامه نویسیش کنید. یک نمونه کد LIQUIDSOAP:
در نهایت کاربر میتونست با وارد شدن به لینک 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
شروع یک ایده از نیاز
چیزی بسازید که صد نفر عاشق آن باشند نه اینکه یک میلیون نفر آن را تا حدودی دوست داشته باشند.
- 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
🔥9👍3👏2
Md Daily
#تجربه شروع یک ایده از نیاز چیزی بسازید که صد نفر عاشق آن باشند نه اینکه یک میلیون نفر آن را تا حدودی دوست داشته باشند. - Brian Chesky تقریبا اواخر سال 2022 بود که سید مهدی عزیز ایده ی رادیو رو پیاده سازی کرد. چیزی که من راجب این کار خیلی دوس داشتم…
#تجربه
از فیدبک کاربران تا اولین MVP
بعد از اینکه فیدبک کاربران رو گرفتیم متوجه شدیم که اینکه هربار لینک رادیو از سایت کپی کنند و توی مثلا VLC وارد کنند یا از پلیر وب گوش بدند، خیلی دسترسی پذیر نیست و دوست دارن که از روی نوتیفیکشن دستگاه هم بتونند موزیک ها را کنترل کنند و قطعی نداشته باشن.
خب کاری که من کردم این بود که چندین UI اپلیکیشن را برای کاربران هدف فرستادم، نظراتشون رو پرسیدم و در نهایت ما یک خروجی اولیه روی کاغذ داشتیم از اینکه کاربران چی دوست دارن.
قبل از اینکه کار را شروع کنیم چنتا قانون گذاشتیم:
1- همه چیز را در فرایند توسعه ساده نگه داریم
2- دچار چرخه ی توسعه ی بی پایان نشیم
3- تو هر مرحله فیدبک بگیریم
بیایند بخش دچار چرخه ی توسعه ی بی پایان نشیم باز تر کنیم. بار ها و بار ها توی تیم ها و پروژه های مختلف دیدم که پروژه یا ایده ها قبل از انتشار به دلیل اینکه مکررا بهشون فیچر اضافه شده و در نهایت برای مدت طولانی در حال توسعه باقی موندن شکست خوردن. مثلا شما قصد دارید یک اپلیکیشن آموزش زبان فرانسوی بسازید. اگر تعیین نکنید کاربران هدف اولیتون چه کسانی هستند، در اولین نسخه قرار چه سطحی رو پوشش بدید و چه امکاناتی داشته باشید، این اپلیکیشن هیچ وقت منتشر نخواهد شد. چون بجای اینکه دنبال خوب بودن باشید، دنبال کامل بودن هستید و مدام فیچر اضافه می کنید. بخش آموزش گرامر تموم شده، بعد با خودتون می گید خب بذار هوش مصنوعی هم اضافه کنم و وقتی هنوز بازخورد کاربران در ویژگی های core و اصلی نگرفتید، متوجه نمیشید که آیا اصلا این فیچر های جدید که اضافه کردید نیازی از کاربر رفع میکنه یا نه؟ پس در نهایت دامنه پروژه رو به وضوح باید تعریف کرد و بهش پایبند بود.
برای رفع این مشکل من اومدم توی Todoist ( اینجا Todoist رو مثال زدم چون مدت زمان زیادی هست ازش استفاده میکنم ولی شما از هر ابزار project management ای مثل ClickUp که باهاش راحت هستید میتونید استفاده کنید ) توی پروژه 5 تا بخش تعریف کردم:
👉 Next Version:
تسک ایده ها و اینکه در نسخه های آینده چیکار کنیم توی این بخش قرار گرفتن. بعد از انتشار هر نسخه نهایی بخشی از تسک های این بخش بر اساس اولویت و نیاز کاربر انتخاب و به Up next منتقل میشن
👉 Up next:
تسک های نسخه ی فعلی
👉 In progress:
تسک های درحال انجام
👉 In review:
تسک های انجام شده که درحال تست هستن و فیدبک کاربران رو دریافت میکنن
👉 Done:
تسک های انجام شده
و با این تقسیم بندی ساده موفق شدیم که گرفتار چرخه ی بی پایان توسعه نشیم و در نهایت اولین MVP ما ساخته شد.
به نظرم یکی از جالب ترین تجربه ها از اهمیت MVP مربوط به محصول DropBox هست که درو هوستون در سال 2008 یه ویدیو ساخت که نشون میداد دراپباکس چیکار میکنه. این ویدیو خیلی ساده بود، فقط نشون میداد که چطور میشه فایلها رو بین کامپیوترها همگامسازی کرد. ولی همین ویدیو ساده کلی سروصدا کرد!
خیلیها با دیدن این ویدیو و عاشق دراپباکس شدن. تعداد آدمهایی که میخواستن از دراپباکس استفاده کنن و توی لیست انتظار ثبت نام کرده بودن از ۵۰۰۰ نفر به ۷۵۰۰۰ نفر رسید! این نشون میداد که مردم عاشق ایدهی دراپباکس بودن.
دراپباکس با این ویدیو فهمید که باید چی بسازه. اونا به جای اینکه کلی پول خرج یه محصول کامل بکنن، فقط روی چیزهایی که مردم میخواستن تمرکز کردن. اینجوری دراپباکس تونست از یه استارتآپ کوچیک به یه شرکت بزرگ و معروف تبدیل بشه.
لینک مقاله How DropBox Started As A Minimal Viable Product:
🔗 https://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/
🔗 https://www.linkedin.com/pulse/how-did-dropbox-do-tech-behind-mvp-triumph-indpro-ab/
🆔 @MdDaily
از فیدبک کاربران تا اولین MVP
مفهوم MVP یا Minimum Viable Product به معنای حداقل محصول قابل ارائه هست.
فرض کنید یه ایده برای یه محصول جدید دارید. به جای اینکه زمان و پول زیادی صرف ساخت کامل محصول و بعد عرضه به بازار کنید، میتونید یه نسخه اولیه از محصول رو بسازید که فقط کارکردهای اصلی و ضروری رو داشته باشه. به این نسخه اولیه MVP میگن.
لینک های مفید:
https://amplitude.com/blog/what-is-a-minimum-viable-product-mvp
https://www.productplan.com/glossary/minimum-viable-product/
بعد از اینکه فیدبک کاربران رو گرفتیم متوجه شدیم که اینکه هربار لینک رادیو از سایت کپی کنند و توی مثلا VLC وارد کنند یا از پلیر وب گوش بدند، خیلی دسترسی پذیر نیست و دوست دارن که از روی نوتیفیکشن دستگاه هم بتونند موزیک ها را کنترل کنند و قطعی نداشته باشن.
خب کاری که من کردم این بود که چندین UI اپلیکیشن را برای کاربران هدف فرستادم، نظراتشون رو پرسیدم و در نهایت ما یک خروجی اولیه روی کاغذ داشتیم از اینکه کاربران چی دوست دارن.
قبل از اینکه کار را شروع کنیم چنتا قانون گذاشتیم:
1- همه چیز را در فرایند توسعه ساده نگه داریم
2- دچار چرخه ی توسعه ی بی پایان نشیم
3- تو هر مرحله فیدبک بگیریم
بیایند بخش دچار چرخه ی توسعه ی بی پایان نشیم باز تر کنیم. بار ها و بار ها توی تیم ها و پروژه های مختلف دیدم که پروژه یا ایده ها قبل از انتشار به دلیل اینکه مکررا بهشون فیچر اضافه شده و در نهایت برای مدت طولانی در حال توسعه باقی موندن شکست خوردن. مثلا شما قصد دارید یک اپلیکیشن آموزش زبان فرانسوی بسازید. اگر تعیین نکنید کاربران هدف اولیتون چه کسانی هستند، در اولین نسخه قرار چه سطحی رو پوشش بدید و چه امکاناتی داشته باشید، این اپلیکیشن هیچ وقت منتشر نخواهد شد. چون بجای اینکه دنبال خوب بودن باشید، دنبال کامل بودن هستید و مدام فیچر اضافه می کنید. بخش آموزش گرامر تموم شده، بعد با خودتون می گید خب بذار هوش مصنوعی هم اضافه کنم و وقتی هنوز بازخورد کاربران در ویژگی های core و اصلی نگرفتید، متوجه نمیشید که آیا اصلا این فیچر های جدید که اضافه کردید نیازی از کاربر رفع میکنه یا نه؟ پس در نهایت دامنه پروژه رو به وضوح باید تعریف کرد و بهش پایبند بود.
برای رفع این مشکل من اومدم توی Todoist ( اینجا Todoist رو مثال زدم چون مدت زمان زیادی هست ازش استفاده میکنم ولی شما از هر ابزار project management ای مثل ClickUp که باهاش راحت هستید میتونید استفاده کنید ) توی پروژه 5 تا بخش تعریف کردم:
👉 Next Version:
تسک ایده ها و اینکه در نسخه های آینده چیکار کنیم توی این بخش قرار گرفتن. بعد از انتشار هر نسخه نهایی بخشی از تسک های این بخش بر اساس اولویت و نیاز کاربر انتخاب و به Up next منتقل میشن
👉 Up next:
تسک های نسخه ی فعلی
👉 In progress:
تسک های درحال انجام
👉 In review:
تسک های انجام شده که درحال تست هستن و فیدبک کاربران رو دریافت میکنن
👉 Done:
تسک های انجام شده
و با این تقسیم بندی ساده موفق شدیم که گرفتار چرخه ی بی پایان توسعه نشیم و در نهایت اولین MVP ما ساخته شد.
به نظرم یکی از جالب ترین تجربه ها از اهمیت MVP مربوط به محصول DropBox هست که درو هوستون در سال 2008 یه ویدیو ساخت که نشون میداد دراپباکس چیکار میکنه. این ویدیو خیلی ساده بود، فقط نشون میداد که چطور میشه فایلها رو بین کامپیوترها همگامسازی کرد. ولی همین ویدیو ساده کلی سروصدا کرد!
خیلیها با دیدن این ویدیو و عاشق دراپباکس شدن. تعداد آدمهایی که میخواستن از دراپباکس استفاده کنن و توی لیست انتظار ثبت نام کرده بودن از ۵۰۰۰ نفر به ۷۵۰۰۰ نفر رسید! این نشون میداد که مردم عاشق ایدهی دراپباکس بودن.
دراپباکس با این ویدیو فهمید که باید چی بسازه. اونا به جای اینکه کلی پول خرج یه محصول کامل بکنن، فقط روی چیزهایی که مردم میخواستن تمرکز کردن. اینجوری دراپباکس تونست از یه استارتآپ کوچیک به یه شرکت بزرگ و معروف تبدیل بشه.
لینک مقاله How DropBox Started As A Minimal Viable Product:
🔗 https://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/
🔗 https://www.linkedin.com/pulse/how-did-dropbox-do-tech-behind-mvp-triumph-indpro-ab/
🆔 @MdDaily
❤🔥4🔥2❤1👏1