میکروسرویس‌ها چی هستند؟
https://mcsh.github.io/fa/microservice/2018/06/06/microservice1.html
در مورد چی حرف میزنیم؟
تو دنیای امروز یکی از buzz wordها کلمه microservice هست. کلمه‌ای که شاید زیاد شنیده باشیدش یک نوع طراحی سیستم هست که در اون اجزای مختلف اصطلاحا loosely coupled هستن و هر کدوم به تنهایی قابلیت scale شدن رو دارن.
داستان از اونجایی شروع میشه که ما هر وقت سیستممون نمی‌کشه میایم و ارتقا میدیم. سرعت پردازنده رو زیاد می‌کنیم، رم رو افزایش میدیم یا فضای هارد بیشتری خریداری می‌کنیم، اما واقعیت اینه که بالاخره هر چقدر هم قوی کنیم سیستم رو تعداد کاربرها که زیاد بشن باز کم میاریم. خب پس چاره چیه؟
یکی از راه حل‌ها scale کردن سیستم هست. به این معننا که شما به جای یک کامپیوتر خیلی قوی و خفن میای ۱۰ تا کامپیوتر نسبتا قوی میزاری، یکیش به عنوان load balance یا master یا هر اسم دیگه‌ای که دوست دارین که کارش میشه تقسیم درخواست‌ها بین ۹ سیستم دیگه. این روش خیلی خوب عمل کرد و الگوریتم‌های جدیدی تعریف شد برای استفاده بهینه ازش و کلی مسئله برامون به وجود اومد مثل مسائل race condition و transaction. اما باز مشکل خوردیم! هزینه کامپیوترهای نسبتا قوی هم کم نیستن و با افزایش کاربرها این هزینه خیلی سریع زیاد میشه.
اینجا بود که بعضی از مهندسا به این نتیجه رسیدن که نیازی نیست کل سیستم رو scale کرد و کافیه بخشی از اون scale شه. مثلا بخش مربوط به ایمیل زدن تبریک تولد به کاربرها نیازی نیست روی همه سرورها اجرا بشه و روی بعضی از اون‌ها کفایت میکنه، و از طرفی بخش مربوط به جواب دادن به api محبوب cat recognizer به شدت مورد استفاده قرار می‌گیره باید روی تعداد بیشتری سرور اجرا بشه. اینجا مهندس‌ها شروع کردن به بخش کردن نرم‌افزارهاشون به سرویس‌های کوچکتری که با هم صحبت می‌کنند و این شروعی از میکروسرویس‌هاست.
بحث دیگه‌ای که در زمینه میکروسرویس‌هاست بحث توسعه هست. تو تیم‌های بزرگ و نرم‌افزارهای پیچیده تغییر دادن چیزهای نامربوط ممکنه باعث خرابی کل سیستم بشه. اما توسعه ماژولار بسیار کمک میکنه که این مشکل‌ها کمتر پیش بیان. میکروسرویس‌ها که به نوعی خودشون ماژول‌ها هستن تو این زمینه به شدت به کمک توسعه دهنده‌ها میان.
تو این پست و پست‌های بعدی این سری میخوام در مورد این که چه مسائلی تو زمینه میکروسرویس‌ها هست و هرکدوم چه راهکارهایی دارن براتون بنویسم. بیشتر این مسائل از تجربه شخصیم تو پروژه‌های متفاوت حاصل شده، اگر جاییش مشکلی هست حتما بهم بگید اصلاح می‌کنم!
چه چیزی باید سرویس باشه؟
سوال بسیار جالبی هست. تو فلسفه یونیکس گفته میشه هر نرم‌افزار باید یک کار، و فقط یک کار، را انجام دهد و آن را به خوبی انجام دهد. این حرف شاید برای نرم‌افزارهای کامندلاین یونیکس مناسب باشه اما برای سرویس‌ها واقعا مناسب نیست. هر میکروسرویس هزینه توسعه جدایی داره و وجودش سربار برای سیستم تولید میکنه. هزینه پشتیبانی و مانیتورینگ و غیره بماند.
خب پس چه کار باید کرد؟ راهکار اینه که actionهایی که برای کاربرها تعریف می‌کنید رو گروه بندی کرد.
اولین رویکرد نزدیکی سیستمی هست مثلا وارد شدن به سیستم و ثبت‌نام کردن نزدیکی زیادی به هم دارن، هم از کتابخونه‌های یکسانی استفاده می‌کنند(برای رمزنگاری و تایید رمز)، هم سرویس های مشترکی رو(دیتابیس).
رویکرد دوم نزدیکی از لحاظ بار و فشار سیستم هست. مثلا سرویس ثبت‌نام و آپلود عکس کاربری معمولا با هم استفاده میشن و اگه تعداد زیادی کاربر یکهو تصمیم بگیرند ثبت‌نام کنند (مثلا بعد آگهی تلویزیونی در آخر یک سریال محبوب) شما کافیه این سرویس رو scale کنید.
تجربه من نشون داده رویکرد دوم معمولا عملکرد بهتری داره، تو پست بعدی در مورد این که چطوری این گروه‌ها رو تشخیص بدیم بیشتر صحبت می‌کنم.
https://mcsh.github.io/fa/microservice/2018/06/06/microservice1.html
در مورد چی حرف میزنیم؟
تو دنیای امروز یکی از buzz wordها کلمه microservice هست. کلمه‌ای که شاید زیاد شنیده باشیدش یک نوع طراحی سیستم هست که در اون اجزای مختلف اصطلاحا loosely coupled هستن و هر کدوم به تنهایی قابلیت scale شدن رو دارن.
داستان از اونجایی شروع میشه که ما هر وقت سیستممون نمی‌کشه میایم و ارتقا میدیم. سرعت پردازنده رو زیاد می‌کنیم، رم رو افزایش میدیم یا فضای هارد بیشتری خریداری می‌کنیم، اما واقعیت اینه که بالاخره هر چقدر هم قوی کنیم سیستم رو تعداد کاربرها که زیاد بشن باز کم میاریم. خب پس چاره چیه؟
یکی از راه حل‌ها scale کردن سیستم هست. به این معننا که شما به جای یک کامپیوتر خیلی قوی و خفن میای ۱۰ تا کامپیوتر نسبتا قوی میزاری، یکیش به عنوان load balance یا master یا هر اسم دیگه‌ای که دوست دارین که کارش میشه تقسیم درخواست‌ها بین ۹ سیستم دیگه. این روش خیلی خوب عمل کرد و الگوریتم‌های جدیدی تعریف شد برای استفاده بهینه ازش و کلی مسئله برامون به وجود اومد مثل مسائل race condition و transaction. اما باز مشکل خوردیم! هزینه کامپیوترهای نسبتا قوی هم کم نیستن و با افزایش کاربرها این هزینه خیلی سریع زیاد میشه.
اینجا بود که بعضی از مهندسا به این نتیجه رسیدن که نیازی نیست کل سیستم رو scale کرد و کافیه بخشی از اون scale شه. مثلا بخش مربوط به ایمیل زدن تبریک تولد به کاربرها نیازی نیست روی همه سرورها اجرا بشه و روی بعضی از اون‌ها کفایت میکنه، و از طرفی بخش مربوط به جواب دادن به api محبوب cat recognizer به شدت مورد استفاده قرار می‌گیره باید روی تعداد بیشتری سرور اجرا بشه. اینجا مهندس‌ها شروع کردن به بخش کردن نرم‌افزارهاشون به سرویس‌های کوچکتری که با هم صحبت می‌کنند و این شروعی از میکروسرویس‌هاست.
بحث دیگه‌ای که در زمینه میکروسرویس‌هاست بحث توسعه هست. تو تیم‌های بزرگ و نرم‌افزارهای پیچیده تغییر دادن چیزهای نامربوط ممکنه باعث خرابی کل سیستم بشه. اما توسعه ماژولار بسیار کمک میکنه که این مشکل‌ها کمتر پیش بیان. میکروسرویس‌ها که به نوعی خودشون ماژول‌ها هستن تو این زمینه به شدت به کمک توسعه دهنده‌ها میان.
تو این پست و پست‌های بعدی این سری میخوام در مورد این که چه مسائلی تو زمینه میکروسرویس‌ها هست و هرکدوم چه راهکارهایی دارن براتون بنویسم. بیشتر این مسائل از تجربه شخصیم تو پروژه‌های متفاوت حاصل شده، اگر جاییش مشکلی هست حتما بهم بگید اصلاح می‌کنم!
چه چیزی باید سرویس باشه؟
سوال بسیار جالبی هست. تو فلسفه یونیکس گفته میشه هر نرم‌افزار باید یک کار، و فقط یک کار، را انجام دهد و آن را به خوبی انجام دهد. این حرف شاید برای نرم‌افزارهای کامندلاین یونیکس مناسب باشه اما برای سرویس‌ها واقعا مناسب نیست. هر میکروسرویس هزینه توسعه جدایی داره و وجودش سربار برای سیستم تولید میکنه. هزینه پشتیبانی و مانیتورینگ و غیره بماند.
خب پس چه کار باید کرد؟ راهکار اینه که actionهایی که برای کاربرها تعریف می‌کنید رو گروه بندی کرد.
اولین رویکرد نزدیکی سیستمی هست مثلا وارد شدن به سیستم و ثبت‌نام کردن نزدیکی زیادی به هم دارن، هم از کتابخونه‌های یکسانی استفاده می‌کنند(برای رمزنگاری و تایید رمز)، هم سرویس های مشترکی رو(دیتابیس).
رویکرد دوم نزدیکی از لحاظ بار و فشار سیستم هست. مثلا سرویس ثبت‌نام و آپلود عکس کاربری معمولا با هم استفاده میشن و اگه تعداد زیادی کاربر یکهو تصمیم بگیرند ثبت‌نام کنند (مثلا بعد آگهی تلویزیونی در آخر یک سریال محبوب) شما کافیه این سرویس رو scale کنید.
تجربه من نشون داده رویکرد دوم معمولا عملکرد بهتری داره، تو پست بعدی در مورد این که چطوری این گروه‌ها رو تشخیص بدیم بیشتر صحبت می‌کنم.
mcsh.github.io
میکروسرویس‌ها چی هستند؟
در مورد چی حرف میزنیم؟ تو دنیای امروز یکی از buzz wordها کلمه microservice هست. کلمه‌ای که شاید زیاد شنیده باشیدش یک نوع طراحی سیستم هست که در اون اجزای مختل...
چگونه برنامه خود را به میکروسرویس‌ها بشکونیم؟
https://mcsh.github.io/fa/microservice/2018/06/14/breaking_services.html
چندین روش مختلف برای تقسیم کردن برنامه‌ها و سرویس‌ها به میکروسرویس‌ها وجود داره. شاید راحت‌ترین روش «میلی» باشه به طوری که شما بدون هدف و از روی غریزه یک سری میکروسرویس معرفی می‌کنید. واضحه که این روش اصلا مناسب نیست و ممکنه حتی باعث دردسر بشه. خب باید چیکار کرد؟ چند راهکار مختلف هست که تجربه به من یادشون داده:
تقسیم بندی بر اساس تیم‌ها
وقتی Gerstner ریاست IBM رو برعهده گرفت حرف جالبی زد «با نگاه کردن داخل یکی از کامپیوترهای IBM شما میتونید تیم‌های ما رو ببینید» این حرف که در واقع نقدی بر طراحی قبلی بود میتونه به شما کمک کنه. اگر تیم‌های زیادی همزمان با هم به توسعه محصول شما می‌پردازن تقسیم کردن سرویس‌ها با توجه به تیم‌ها میتونه بهتون کمک کنه تا کمترین تداخل رو داشته باشید. اینطوری هر تیم روی پروژه کوچکی کار میکنه که بر اساس یک schema بزرگتر که طراح سیستم (شما!) با بقیه اجزای سیستم کار می‌کند.
تقسیم بندی بر اساس کاربرد
در این روش شما ابتدا تمامی اعمال کاربر رو لیست می‌کنید. اعمالی مثل «لاگین/ریجستر/ایجاد پست جدید/لایک کردن پست دیگران/ایجاد کامنت/ آپلود عکس» رو مشخص می‌کنید سپس یکی از دو روش زیر رو در نظر می‌گیرید:
۱- با استدلال اعمال بالا رو دسته بندی کنید. مثلا به نظر می‌رسه افراد بعد از ریجستر کردن اقدام به آپلود عکس کنن. پس باید این دو عمل در یک سرویس قرار بگیرن تا وقتی تعداد زیادی کاربر ثبت‌نام می‌کنند شما تنها با scale کردن این سرویس مشکل رو حل کنید.
۲- ابتدا یک سرویس کلی بنویسید که همه چیز را لاگ می‌کند (توصیه می‌کنم از ELK استفاده کنید!) و سپس با تحلیل لاگ‌ها بین اعمال بالا ارتباط پیدا کنید و آن بخش‌ها را جدا کنید. این روش به خصوص وقتی به کار می‌آید که شما برنامه فعلیتان به صورت مونولتیک توسعه داده شده است و میخواهید به میکروسرویس‌ها سوییچ کنید. ممکن است مثلا با تحلیل لاگ‌ها به این نتیجه برسید که ریجستر کردن و ایجاد کامنت ارتباط نزدیک‌تری دارند تا ریجستر کردن و آپلود عکس!
تقسیم بندی بر اساس پیش‌نیازها
روش دیگه تقسیم بندی بر اساس نیازهای هر سیستم هست. مثلا سرویس لاگین و ریجستر هر دو به دیتابیس یوزرها نیاز دارند اما سرویس آپلود عکس نیاز به دسترسی به ftp server شما دارد.
نتیجه گیری
اساسا این که سرویس‌هاتون رو چطور تقسیم بندی کنید بستگی به این داره که چرا میخواهید از میکروسرویس ها استفاده کنید. احتمالا روش نهایی شما ترکیبی از همه روش‌های بالاست!
https://mcsh.github.io/fa/microservice/2018/06/14/breaking_services.html
چندین روش مختلف برای تقسیم کردن برنامه‌ها و سرویس‌ها به میکروسرویس‌ها وجود داره. شاید راحت‌ترین روش «میلی» باشه به طوری که شما بدون هدف و از روی غریزه یک سری میکروسرویس معرفی می‌کنید. واضحه که این روش اصلا مناسب نیست و ممکنه حتی باعث دردسر بشه. خب باید چیکار کرد؟ چند راهکار مختلف هست که تجربه به من یادشون داده:
تقسیم بندی بر اساس تیم‌ها
وقتی Gerstner ریاست IBM رو برعهده گرفت حرف جالبی زد «با نگاه کردن داخل یکی از کامپیوترهای IBM شما میتونید تیم‌های ما رو ببینید» این حرف که در واقع نقدی بر طراحی قبلی بود میتونه به شما کمک کنه. اگر تیم‌های زیادی همزمان با هم به توسعه محصول شما می‌پردازن تقسیم کردن سرویس‌ها با توجه به تیم‌ها میتونه بهتون کمک کنه تا کمترین تداخل رو داشته باشید. اینطوری هر تیم روی پروژه کوچکی کار میکنه که بر اساس یک schema بزرگتر که طراح سیستم (شما!) با بقیه اجزای سیستم کار می‌کند.
تقسیم بندی بر اساس کاربرد
در این روش شما ابتدا تمامی اعمال کاربر رو لیست می‌کنید. اعمالی مثل «لاگین/ریجستر/ایجاد پست جدید/لایک کردن پست دیگران/ایجاد کامنت/ آپلود عکس» رو مشخص می‌کنید سپس یکی از دو روش زیر رو در نظر می‌گیرید:
۱- با استدلال اعمال بالا رو دسته بندی کنید. مثلا به نظر می‌رسه افراد بعد از ریجستر کردن اقدام به آپلود عکس کنن. پس باید این دو عمل در یک سرویس قرار بگیرن تا وقتی تعداد زیادی کاربر ثبت‌نام می‌کنند شما تنها با scale کردن این سرویس مشکل رو حل کنید.
۲- ابتدا یک سرویس کلی بنویسید که همه چیز را لاگ می‌کند (توصیه می‌کنم از ELK استفاده کنید!) و سپس با تحلیل لاگ‌ها بین اعمال بالا ارتباط پیدا کنید و آن بخش‌ها را جدا کنید. این روش به خصوص وقتی به کار می‌آید که شما برنامه فعلیتان به صورت مونولتیک توسعه داده شده است و میخواهید به میکروسرویس‌ها سوییچ کنید. ممکن است مثلا با تحلیل لاگ‌ها به این نتیجه برسید که ریجستر کردن و ایجاد کامنت ارتباط نزدیک‌تری دارند تا ریجستر کردن و آپلود عکس!
تقسیم بندی بر اساس پیش‌نیازها
روش دیگه تقسیم بندی بر اساس نیازهای هر سیستم هست. مثلا سرویس لاگین و ریجستر هر دو به دیتابیس یوزرها نیاز دارند اما سرویس آپلود عکس نیاز به دسترسی به ftp server شما دارد.
نتیجه گیری
اساسا این که سرویس‌هاتون رو چطور تقسیم بندی کنید بستگی به این داره که چرا میخواهید از میکروسرویس ها استفاده کنید. احتمالا روش نهایی شما ترکیبی از همه روش‌های بالاست!
mcsh.github.io
چگونه برنامه خود را به میکروسرویس‌ها بشکونیم؟
چندین روش مختلف برای تقسیم کردن برنامه‌ها و سرویس‌ها به میکروسرویس‌ها وجود داره. شاید راحت‌ترین روش «میلی» باشه به طوری که شما بدون هدف و از روی غریزه یک سری...
به بهانه هیولای اسپاگتی - راسل
آقای برترند راسل ریاضی‌دان فوق‌العاده قرن بیستم و پایه گذار علم منطق عقاید جالبی درباره خدا و وجودش دارد. وی، برای مردم عادی، خود را خدا ناباور و برای مخاطبین فلسفی، ندانم گرا معرفی می‌کند...
ادامه مطلب:
https://mcsh.github.io/fa/god/logic/2018/12/03/FSM_Russell.html
آقای برترند راسل ریاضی‌دان فوق‌العاده قرن بیستم و پایه گذار علم منطق عقاید جالبی درباره خدا و وجودش دارد. وی، برای مردم عادی، خود را خدا ناباور و برای مخاطبین فلسفی، ندانم گرا معرفی می‌کند...
ادامه مطلب:
https://mcsh.github.io/fa/god/logic/2018/12/03/FSM_Russell.html
Article 13 - بند سیزدهم و آزادی اینترنت
بند ۱۳م دستورالعمل کپی رایت در بازار واحد دیجیتال، یا به اختصار بند ۱۳م، چند وقتی هست که باعث سر و صدای زیادی در شبکه‌های اجتماعی شده. از سایت‌هایی مثل ردیت و فورچن تا سایت‌هایی مثل توییتر و یوتیوب و فیسبوک، همه و همه کاربرانشون به صورت یک صدا با این قانون مخالف هستن و کار به جایی رسیده که CEO یوتیوب در وبلاگ گوگل می‌نویسد «رویکرد پارلمان از جهات زیادی واقع‌گرایانه نیست»
ادامه مطلب:
https://mcsh.github.io/fa/2019/03/22/article_13.html
بند ۱۳م دستورالعمل کپی رایت در بازار واحد دیجیتال، یا به اختصار بند ۱۳م، چند وقتی هست که باعث سر و صدای زیادی در شبکه‌های اجتماعی شده. از سایت‌هایی مثل ردیت و فورچن تا سایت‌هایی مثل توییتر و یوتیوب و فیسبوک، همه و همه کاربرانشون به صورت یک صدا با این قانون مخالف هستن و کار به جایی رسیده که CEO یوتیوب در وبلاگ گوگل می‌نویسد «رویکرد پارلمان از جهات زیادی واقع‌گرایانه نیست»
ادامه مطلب:
https://mcsh.github.io/fa/2019/03/22/article_13.html
mcsh.github.io
Article 13 - بند سیزدهم و آزادی اینترنت
بند ۱۳م دستورالعمل کپی رایت در بازار واحد دیجیتال، یا به اختصار بند ۱۳م، چند وقتی هست که باعث سر و صدای زیادی در شبکه‌های اجتماعی شده. از سایت‌هایی مثل ردیت ...
whataboutism پس‌چه‌ایسم
اخیرا چند وقتیا که whataboutism یا پس‌چه‌ایسم در بین ایرانی‌ها رایج شده که میتونه صدمات جبران ناپذیری به سلامت جامعه ما بزنه. تو این پست میخوام چند نمونه از اون‌ها و راه حل پاسخ دادن بهشون رو بررسی کنیم.
ادامه مطلب:
https://mcsh.github.io/fa/society/2019/03/23/whataboutism.html
اخیرا چند وقتیا که whataboutism یا پس‌چه‌ایسم در بین ایرانی‌ها رایج شده که میتونه صدمات جبران ناپذیری به سلامت جامعه ما بزنه. تو این پست میخوام چند نمونه از اون‌ها و راه حل پاسخ دادن بهشون رو بررسی کنیم.
ادامه مطلب:
https://mcsh.github.io/fa/society/2019/03/23/whataboutism.html
mcsh.github.io
whataboutism پس‌چه‌ایسم
اخیرا چند وقتیا که whataboutism یا پس‌چه‌ایسم در بین ایرانی‌ها رایج شده که میتونه صدمات جبران ناپذیری به سلامت جامعه ما بزنه. تو این پست میخوام چند نمونه از...
آدم‌ها دارن به سمتی میرن که کمترین میزان تصمیم گیری رو داشته باشن و به حد زیادی به دستیارهای مصنوعیمون وابسته شدیم.
الآن چی گوش کنم؟ بذار ببینم *فلان سرویس موسیقی* چی برام گذاشته.
الآن چی بخونم؟ بذار ببینم *فلان سرویس محتوا* چی داره.
چیکار کنم؟ بذار ببینم رو *فلان سرویس تقویم* چی دارم.
آیا این وابستگی لزوما بده؟ نه. مغز انسان توانایی‌های زیادی داره ولی محدودیت تمرکز داره. هر موردی رو که برون‌سپاری کنه فضای بیشتری برای تمرکز و خلاقیت باز میشه.
خیلی از روانشناس‌ها پیشنهاد می‌کنن افکار مزاحم و کارهایی که میخواهید انجام بدید رو بنویسید. دلیلش چیه؟ این که تا وقتی اون‌ها رو مکتوب نکنید اون‌ها ذهنتون رو مشغول می‌کنن، اما وقتی جایی مکتوب بشن میتونید با آرامش به کارهای دیگه‌ای که دارید برسید. کاری که ماها - شاید ناخودآگاه - کردیم اینه که این درگیری‌های ذهنیمون رو به کامپیوتر سپردیم. چند نمونه دیگه‌اش رو ببینیم:
فیسبوک برای ما تصمیم می‌گیره کدوم پست از کدوم دوستمون رو ببینیم.
گوگل برای ما تصمیم می‌گیره وقتی دنبال چیزی هستیم چه مطالبی رو درباره‌اش ببینیم.
آمازون برای ما تصمیم می‌گیره وقتی نظرات راجع به یک محصول رو می‌خونیم کدوم نظرها رو ببینیم.
این دسته تصمیم گیری‌ها می‌تونن خیلی مفید باشن. یادآور تولد فیسبوک در دهه اخیر تعداد افرادی که به هم تولد رو تبریک می‌گن رو چندین برابر کرده. اما از طرف دیگه تو انتخابات دوره قبل آمریکا هم دست برده. گوگل باعث شده ما راحت‌تر به چیزی که می‌خوایم برسیم، نتایج جستوجوی یک دولوپر با یک فرد عادی وقتی در مورد fork جستوجو می‌کنند فرق میکنه، اما از طرف دیگه گوگل قبلا به صلاح خودش یا به دستور مقامات قضایی محتواهای خاصی رو از نتایج جستوجو پاک کرده. آمازون میتونه بهترین نظرات رو به ما نشون بده، برای ما نظرات تک کلمه‌ای مثل «خوبه» مهم نیست، اونی مهمه که با جزئیات به بررسی محصول پرداخته و آمازون کار بسیار خوبی میکنه برای جداسازی این نظرات، اما به کرات پیش اومده که آمازون (یا نمونه‌های ایرانیش) نظرهای منفی رو حذف کرده.
چیزی که باید بهش توجه کنیم اینه که سرویس‌های آزاد محدودیت‌های خیلی کمتری دارن، مخصوصا اگر توسط خودتون اداره بشن. بیاید و یواش یواش به جای استفاده از محصولات شرکت‌های دیگه به استفاده از محصولات آزاد رو بیاریم، که هم ذهنمون آزاد باشه هم کسی فکر نکنه صلاحمون رو بهتر از خودمون می‌دونه!
الآن چی گوش کنم؟ بذار ببینم *فلان سرویس موسیقی* چی برام گذاشته.
الآن چی بخونم؟ بذار ببینم *فلان سرویس محتوا* چی داره.
چیکار کنم؟ بذار ببینم رو *فلان سرویس تقویم* چی دارم.
آیا این وابستگی لزوما بده؟ نه. مغز انسان توانایی‌های زیادی داره ولی محدودیت تمرکز داره. هر موردی رو که برون‌سپاری کنه فضای بیشتری برای تمرکز و خلاقیت باز میشه.
خیلی از روانشناس‌ها پیشنهاد می‌کنن افکار مزاحم و کارهایی که میخواهید انجام بدید رو بنویسید. دلیلش چیه؟ این که تا وقتی اون‌ها رو مکتوب نکنید اون‌ها ذهنتون رو مشغول می‌کنن، اما وقتی جایی مکتوب بشن میتونید با آرامش به کارهای دیگه‌ای که دارید برسید. کاری که ماها - شاید ناخودآگاه - کردیم اینه که این درگیری‌های ذهنیمون رو به کامپیوتر سپردیم. چند نمونه دیگه‌اش رو ببینیم:
فیسبوک برای ما تصمیم می‌گیره کدوم پست از کدوم دوستمون رو ببینیم.
گوگل برای ما تصمیم می‌گیره وقتی دنبال چیزی هستیم چه مطالبی رو درباره‌اش ببینیم.
آمازون برای ما تصمیم می‌گیره وقتی نظرات راجع به یک محصول رو می‌خونیم کدوم نظرها رو ببینیم.
این دسته تصمیم گیری‌ها می‌تونن خیلی مفید باشن. یادآور تولد فیسبوک در دهه اخیر تعداد افرادی که به هم تولد رو تبریک می‌گن رو چندین برابر کرده. اما از طرف دیگه تو انتخابات دوره قبل آمریکا هم دست برده. گوگل باعث شده ما راحت‌تر به چیزی که می‌خوایم برسیم، نتایج جستوجوی یک دولوپر با یک فرد عادی وقتی در مورد fork جستوجو می‌کنند فرق میکنه، اما از طرف دیگه گوگل قبلا به صلاح خودش یا به دستور مقامات قضایی محتواهای خاصی رو از نتایج جستوجو پاک کرده. آمازون میتونه بهترین نظرات رو به ما نشون بده، برای ما نظرات تک کلمه‌ای مثل «خوبه» مهم نیست، اونی مهمه که با جزئیات به بررسی محصول پرداخته و آمازون کار بسیار خوبی میکنه برای جداسازی این نظرات، اما به کرات پیش اومده که آمازون (یا نمونه‌های ایرانیش) نظرهای منفی رو حذف کرده.
چیزی که باید بهش توجه کنیم اینه که سرویس‌های آزاد محدودیت‌های خیلی کمتری دارن، مخصوصا اگر توسط خودتون اداره بشن. بیاید و یواش یواش به جای استفاده از محصولات شرکت‌های دیگه به استفاده از محصولات آزاد رو بیاریم، که هم ذهنمون آزاد باشه هم کسی فکر نکنه صلاحمون رو بهتر از خودمون می‌دونه!
پست اولم رو در Dev Community نوشتم،
How to make "smarter" chatbots, Pt 1
https://dev.to/mcsh/how-to-make-smarter-chatbots-pt-1-g7g
How to make "smarter" chatbots, Pt 1
https://dev.to/mcsh/how-to-make-smarter-chatbots-pt-1-g7g
The DEV Community
How to make "smarter" chatbots, Pt 1
. Tagged with AI, Chatbot, machinelearning, NLP.
صورت مسئله: ما به یک روش برای مدیریت حساب‌هایی که تعلق به فرد خاصی ندارن نیاز داریم، برای مثال حساب‌های متعلق به NGOها یا لاگ‌ها. اعضا باید بتوانند هر تغییری در روال اجرای برنامه مدیریت کننده بدهند، اما قدرت نباید در اختیار یک فرد باشد.
پیش‌فرض‌ها: یک هاست امین داریم که در تصمیم‌ها دخالت نمی‌کند.
راه حل #۱:
بر روی یک بستر همانند گیتلب یا گیتهاب ریپوی خاصی هاست می‌شود. در این ریپو باتی هست که MR های خود را بررسی می‌کند. بر روی هر ریپو یک تگ Vote می‌گذارد و کاربران رای مثبت یا منفی با reaction دادن به پست می‌دهند. بات در یک بازه ۲۴ ساعته در صورت رای آوردن، آن را مرج می‌کند و در غیر اینصورت رد می‌کند.
بات توسط یک ایمیج داکر ساخته می‌شود، اطلاعات حساس همانند توکن‌ها، توسط هاست از طریق متغییرهای محیطی به بات داده می‌شوند. هاست تنها برای تغییر این اطلاعات و یا در صورت کرش برای roll back به نسخه قبلی به هاست متصل می‌شود.
کاربردها:
از این بات برای اعلام اعلانات در شبکه‌های اجتماعی، برگذاری نظرسنجی، نمایش وبسایت، و.... استفاده خواهد شد.
ایده‌های لازم برای ارتقا:
* عدم وابستگی به یک هاست
* ایجاد مکانیزم برای جلوگیری از حمله اسپمرها
برای بحث بیشتر به @pi_developer_discuss مراجعه کنید.
پیش‌فرض‌ها: یک هاست امین داریم که در تصمیم‌ها دخالت نمی‌کند.
راه حل #۱:
بر روی یک بستر همانند گیتلب یا گیتهاب ریپوی خاصی هاست می‌شود. در این ریپو باتی هست که MR های خود را بررسی می‌کند. بر روی هر ریپو یک تگ Vote می‌گذارد و کاربران رای مثبت یا منفی با reaction دادن به پست می‌دهند. بات در یک بازه ۲۴ ساعته در صورت رای آوردن، آن را مرج می‌کند و در غیر اینصورت رد می‌کند.
بات توسط یک ایمیج داکر ساخته می‌شود، اطلاعات حساس همانند توکن‌ها، توسط هاست از طریق متغییرهای محیطی به بات داده می‌شوند. هاست تنها برای تغییر این اطلاعات و یا در صورت کرش برای roll back به نسخه قبلی به هاست متصل می‌شود.
کاربردها:
از این بات برای اعلام اعلانات در شبکه‌های اجتماعی، برگذاری نظرسنجی، نمایش وبسایت، و.... استفاده خواهد شد.
ایده‌های لازم برای ارتقا:
* عدم وابستگی به یک هاست
* ایجاد مکانیزم برای جلوگیری از حمله اسپمرها
برای بحث بیشتر به @pi_developer_discuss مراجعه کنید.
خب گل سر سبد این هفته، کتابفروشی ماکروسافت به زودی تعطیل میشه و کتب خریداری شده دیگه قابل خوندن نیستن.
از DRM دوری کنید!
درسته که پولش بر می‌گرده، ولی شما کتاب رو خریدید. شما صاحب اون کتاب باید بشید، حتا برگشت وجه هم قابل قبول نیست!
یادتون هم باشه که رایگان و رایگان با DRM فرق داره. بله!
https://twitter.com/Sajjad_Heydari/status/1144375218053373952?s=19
از DRM دوری کنید!
درسته که پولش بر می‌گرده، ولی شما کتاب رو خریدید. شما صاحب اون کتاب باید بشید، حتا برگشت وجه هم قابل قبول نیست!
یادتون هم باشه که رایگان و رایگان با DRM فرق داره. بله!
https://twitter.com/Sajjad_Heydari/status/1144375218053373952?s=19
Twitter
Sajjad Heydari
خب گل سر سبد این هفته، کتابفروشی ماکروسافت به زودی تعطیل میشه و کتب خریداری شده دیگه قابل خوندن نیستن. از DRM دوری کنید!
وقفه‌ها
دو تا استاکر داریم. آلیس و بتی هر دو به کریس علاقه دارن و می‌خوان هر تغییری در شبکه‌های مجازی اون رو زیر نظر بگیرن تا بهش نزدیک بشن.
آلیس هر ۵ دقیقه همه شبکه‌های کریس رو چک میکنه تا ببینه آیا پست جدیدی گذاشته؟ آیا عکسش رو عوض کرده؟ و به طور کلی همه تغییرات رو زیر نظر می‌گیره.
بتی اما باهوش‌تره، به جای دستی چک کردن کریس،...
ادامه مطلب:
https://mcsh.github.io/fa/cs/2019/07/03/interrupt.html
دو تا استاکر داریم. آلیس و بتی هر دو به کریس علاقه دارن و می‌خوان هر تغییری در شبکه‌های مجازی اون رو زیر نظر بگیرن تا بهش نزدیک بشن.
آلیس هر ۵ دقیقه همه شبکه‌های کریس رو چک میکنه تا ببینه آیا پست جدیدی گذاشته؟ آیا عکسش رو عوض کرده؟ و به طور کلی همه تغییرات رو زیر نظر می‌گیره.
بتی اما باهوش‌تره، به جای دستی چک کردن کریس،...
ادامه مطلب:
https://mcsh.github.io/fa/cs/2019/07/03/interrupt.html
devand.me
وقفه‌ها
دو تا استاکر داریم. آلیس و بتی هر دو به کریس علاقه دارن و می‌خوان هر تغییری در شبکه‌های مجازی اون رو زیر نظر بگیرن تا بهش نزدیک بشن.
«به بهانه خدا - هاوکینگ»
https://blog.heydaris.com/fa/god/logic/2019/08/20/hawking.html
در این نویسه:
...هاوکینگ، یکی از بزرگ‌ترین فیزیک‌دانان معاصر، باورهای جالبی برای خدا داره. او عمیقا باور داشت به عنوان یک محقق نباید عقایدش روی کار اثر بگذاره و تنها بر مبنای شواهد و محاسبات باید کارهاش رو انجام بده...
...در اوایل زندگیش به خاطر متولد شدن در انگلستان در قرن بیستم، اعتقادات مسیحی رو داشت اما بعدها صراحتا گفته که آتئیست هست، خدا رو باور نداره و زندگی پس از مرگ رو تلاشی برای آروم کردن انسان‌هایی می‌دونه که از تاریکی می‌ترسن. اما از دید فلسفی هاوکینگ یک آگناستیک هست،...
...نظریه واحدی وجود نداره و ما دنباله‌ای از تئوری‌ها خواهیم داشت که هر کدوم در حیطه‌ای دقت بیشتری دارن اما همچنان خطا دارن. و ما هرگز بدون خطا نمی‌تونیم آینده رو پیش‌بینی کنیم. به قول ریاضی‌دان‌ها دنباله‌ای از نظریه‌ها داریم که به درستی میل می‌کنن اما بهش نمی‌رسن...
https://blog.heydaris.com/fa/god/logic/2019/08/20/hawking.html
در این نویسه:
...هاوکینگ، یکی از بزرگ‌ترین فیزیک‌دانان معاصر، باورهای جالبی برای خدا داره. او عمیقا باور داشت به عنوان یک محقق نباید عقایدش روی کار اثر بگذاره و تنها بر مبنای شواهد و محاسبات باید کارهاش رو انجام بده...
...در اوایل زندگیش به خاطر متولد شدن در انگلستان در قرن بیستم، اعتقادات مسیحی رو داشت اما بعدها صراحتا گفته که آتئیست هست، خدا رو باور نداره و زندگی پس از مرگ رو تلاشی برای آروم کردن انسان‌هایی می‌دونه که از تاریکی می‌ترسن. اما از دید فلسفی هاوکینگ یک آگناستیک هست،...
...نظریه واحدی وجود نداره و ما دنباله‌ای از تئوری‌ها خواهیم داشت که هر کدوم در حیطه‌ای دقت بیشتری دارن اما همچنان خطا دارن. و ما هرگز بدون خطا نمی‌تونیم آینده رو پیش‌بینی کنیم. به قول ریاضی‌دان‌ها دنباله‌ای از نظریه‌ها داریم که به درستی میل می‌کنن اما بهش نمی‌رسن...
«باد»
داستان تعاملی جدیدیه که نوشتم، بخش اولشه. خوشحال میشم نظر بدید بهم:
https://blog.heydaris.com/fa/story/wind/01/
داستان تعاملی جدیدیه که نوشتم، بخش اولشه. خوشحال میشم نظر بدید بهم:
https://blog.heydaris.com/fa/story/wind/01/
نویسه جدید: «هوش مصنوعی چیست؟»
این پست الآن نزدیک ۸ ۹ ماه هست که توی درفتم بوده، تصمیم گرفتم بالاخره منتشرش کنم. خوشحال میشم بخونید، نظر بدید و بازنشر کنید بقیه هم ببینن!
https://blog.heydaris.com/fa/ai/2019/08/25/AI.html
در این نویسه:
* هوش مصنوعی چیست؟
* انواعش چی هست؟
* آزمایش تورینگ
* نوشتن یک Boiler Plate برای یک مسئله هوش مصنوعی
این پست الآن نزدیک ۸ ۹ ماه هست که توی درفتم بوده، تصمیم گرفتم بالاخره منتشرش کنم. خوشحال میشم بخونید، نظر بدید و بازنشر کنید بقیه هم ببینن!
https://blog.heydaris.com/fa/ai/2019/08/25/AI.html
در این نویسه:
* هوش مصنوعی چیست؟
* انواعش چی هست؟
* آزمایش تورینگ
* نوشتن یک Boiler Plate برای یک مسئله هوش مصنوعی