مفهوم (رویکرد، الگو) zero allocation به چه چیزی اشاره می کند؟ بدفهمی این رویکرد در کجا نهفته شده است؟
خیلی پیش میاد برای خود من که جاهای مختلف به این مفهوم اشاره بشه، ولی درک درستی از آن وجود نداشته باشه در اون گفت و گو (نمونه)، که منجر به ایجاد انواع خطاها شناختی و در نهایت خطاهای تصمیم سازی می کنه.
اولین اشتباهی که رایج هست این هست که یک بد فهمی زیاد حول دو الگوی zero allocation و Object pool pattern وجود دارد. به صورت لغوی هم اگر بررسی کنیم zero به معنای دقیقا هیچ می باشد نه حتی یک تخصیص. پس قطعا reuse کردن یک مقدار allocate شده (عموما در بخشی به ساختار داده heap) در استفاده های تکراری با نگهداری آدرس مقدار تخصیص داده شده در یک pool را به عنوان zero allocation نباید در نظر گرفته شود. این رویکرد همانطور که در بالا نام برده شد، به نام Object pool pattern شناخته می شود و استفاده از آن شرایط خاصی را طلب می کند. لذا اگر به خوبی مفهوم #memory_management تسلط داشته باشیم براحتی می تونیم این اشتباه (یکی دانستن این دو الگو) را متوجه بشیم. قبلا هم بارها تاکید کردیم که بهتره از تفکرات خوبی که در چندین دهه بوجود آمده استفاده کنیم و از گمانه زنی های بی مورد در خصوص اشاره به مفاهیم قدیمی دوری کنیم. مخصوصا مفاهیمی که حول OOP وجود دارد بدلیل غنای فکری نه به صورت نحوه پیاده سازی در زبان های مدعی، بلکه به استناد مستندات اکثرا دانشگاهی، می توانند مرجع و خوراک فکری خوبی برای ما باشند.
حال چرایی ادعای کذب کتابخانه هایی مثل fasthttp در زبان Go را متوجه می شویم. همین اول بگم سوتفاهم پیش نیاد که این کتابخانه یا زبان بد هستند، اصلا اینجوری نیست و ما نمی خوایم حتی 1% این حس را منتقل کنیم. فقط منظور این هست که استفاده از رویکرد pool در یک کتابخانه مثل همین fasthttp باعث ادعای دروغین zero allocation نباید بشود که گمراهی به همراه بیاورد.
نکته مهم که باید همیشه یادمون باشه که به object life cycle باید دقت کنیم و بدون در نظر گرفتن رویکرد pool به توسعه بپردازیم. چرایی اهمیت این قضیه، باز نمونه عدم دقتش میشه کتابخانه fasthttp که بدلیل allocate کردن زیاد برای یک object که قرار reuse بشه که باعث نیاز به reinit کردن زیاد خواهد داشت. و می دونیم که وقتی allocate های ما زیاد باشه یعنی درگیری بیشتر رم بجای کش های cpu که قطعا باعث افزایش مصرف cpu با نرخ کارکرد پایین به دلیل نیاز مبرم به اجرای دستورات مقداردهی رم. لذا هر چه ما کمتر از runtime memory management استفاده کنیم بهره وری نرم افزار به شدت بالاتر خواهد بود، نه در حد چند درصد بلکه چند صد درصد.
نمونه های زیادی در زبان هایی با کنترل زیاد روی memory management مثل C یا Rust وجود داره ولی عموما در زبان های مثل Go به جز راهکارهای به شدت unsafe به هیچ عنوان امکان پیاده سازی این مفهوم zero allocation وجود ندارد.
https://github.com/rikvdh/zabuffer
https://github.com/nrc/zero/blob/master/src/lib.rs
قطعا می دونیم نمیشه توی یک پست چند خطی همه این موضوعات را باز کنیم و قصد ارائه عمق موارد، مثل همیشه نیست و صرفا #تلنگر_ذهنی و ایجاد پرسش هدف پست ها هست. و قطعا قصد ساده انگاری این موضوع را هم نداریم و می دانیم در نرم افزارهای چند نخ (thread) آن هم در user space قطعا مفاهیمی مثل stack و heap و alloc به شدت پر جزییات تر از این حرف ها، در چند خط هست.
در نهایت بیاییم با استفاده دقیق تر از کلمات، جامعه تخصصی حرفه ای تری را شکل بدهیم که نخواهیم سر پایه ای ترین موضوع یعنی توافق روی معنا و مفهوم کلمات ساعت ها وقت یکدیگر را بگیریم.
هیچ فرصتی را برای مطالعه حتی روی کلماتی که فکر می کنیم خیلی بدیهی هستند را از دست ندهیم. (تلنگر قوی حتی به خودم)
خیلی پیش میاد برای خود من که جاهای مختلف به این مفهوم اشاره بشه، ولی درک درستی از آن وجود نداشته باشه در اون گفت و گو (نمونه)، که منجر به ایجاد انواع خطاها شناختی و در نهایت خطاهای تصمیم سازی می کنه.
اولین اشتباهی که رایج هست این هست که یک بد فهمی زیاد حول دو الگوی zero allocation و Object pool pattern وجود دارد. به صورت لغوی هم اگر بررسی کنیم zero به معنای دقیقا هیچ می باشد نه حتی یک تخصیص. پس قطعا reuse کردن یک مقدار allocate شده (عموما در بخشی به ساختار داده heap) در استفاده های تکراری با نگهداری آدرس مقدار تخصیص داده شده در یک pool را به عنوان zero allocation نباید در نظر گرفته شود. این رویکرد همانطور که در بالا نام برده شد، به نام Object pool pattern شناخته می شود و استفاده از آن شرایط خاصی را طلب می کند. لذا اگر به خوبی مفهوم #memory_management تسلط داشته باشیم براحتی می تونیم این اشتباه (یکی دانستن این دو الگو) را متوجه بشیم. قبلا هم بارها تاکید کردیم که بهتره از تفکرات خوبی که در چندین دهه بوجود آمده استفاده کنیم و از گمانه زنی های بی مورد در خصوص اشاره به مفاهیم قدیمی دوری کنیم. مخصوصا مفاهیمی که حول OOP وجود دارد بدلیل غنای فکری نه به صورت نحوه پیاده سازی در زبان های مدعی، بلکه به استناد مستندات اکثرا دانشگاهی، می توانند مرجع و خوراک فکری خوبی برای ما باشند.
حال چرایی ادعای کذب کتابخانه هایی مثل fasthttp در زبان Go را متوجه می شویم. همین اول بگم سوتفاهم پیش نیاد که این کتابخانه یا زبان بد هستند، اصلا اینجوری نیست و ما نمی خوایم حتی 1% این حس را منتقل کنیم. فقط منظور این هست که استفاده از رویکرد pool در یک کتابخانه مثل همین fasthttp باعث ادعای دروغین zero allocation نباید بشود که گمراهی به همراه بیاورد.
نکته مهم که باید همیشه یادمون باشه که به object life cycle باید دقت کنیم و بدون در نظر گرفتن رویکرد pool به توسعه بپردازیم. چرایی اهمیت این قضیه، باز نمونه عدم دقتش میشه کتابخانه fasthttp که بدلیل allocate کردن زیاد برای یک object که قرار reuse بشه که باعث نیاز به reinit کردن زیاد خواهد داشت. و می دونیم که وقتی allocate های ما زیاد باشه یعنی درگیری بیشتر رم بجای کش های cpu که قطعا باعث افزایش مصرف cpu با نرخ کارکرد پایین به دلیل نیاز مبرم به اجرای دستورات مقداردهی رم. لذا هر چه ما کمتر از runtime memory management استفاده کنیم بهره وری نرم افزار به شدت بالاتر خواهد بود، نه در حد چند درصد بلکه چند صد درصد.
نمونه های زیادی در زبان هایی با کنترل زیاد روی memory management مثل C یا Rust وجود داره ولی عموما در زبان های مثل Go به جز راهکارهای به شدت unsafe به هیچ عنوان امکان پیاده سازی این مفهوم zero allocation وجود ندارد.
https://github.com/rikvdh/zabuffer
https://github.com/nrc/zero/blob/master/src/lib.rs
قطعا می دونیم نمیشه توی یک پست چند خطی همه این موضوعات را باز کنیم و قصد ارائه عمق موارد، مثل همیشه نیست و صرفا #تلنگر_ذهنی و ایجاد پرسش هدف پست ها هست. و قطعا قصد ساده انگاری این موضوع را هم نداریم و می دانیم در نرم افزارهای چند نخ (thread) آن هم در user space قطعا مفاهیمی مثل stack و heap و alloc به شدت پر جزییات تر از این حرف ها، در چند خط هست.
در نهایت بیاییم با استفاده دقیق تر از کلمات، جامعه تخصصی حرفه ای تری را شکل بدهیم که نخواهیم سر پایه ای ترین موضوع یعنی توافق روی معنا و مفهوم کلمات ساعت ها وقت یکدیگر را بگیریم.
هیچ فرصتی را برای مطالعه حتی روی کلماتی که فکر می کنیم خیلی بدیهی هستند را از دست ندهیم. (تلنگر قوی حتی به خودم)
👍13
آیا Low code, no code developing frameworks (software developing) یک ضرورت هست یا انتخاب؟
جواب خیلی کوتاه قطعا یک ضرورت. و خیلی خلاصه بخوایم بگیم توسعه بدون چارچوب اصلا امکان پذیر نمی باشد و چارچوبی خوب هست که نیاز توسعه ای اصلی (کسب و کاری) را به طور کامل پوشش دهد و انتخاب ها را تا حد ممکن محدود کند. مثلا در علوم کامپیوتر بحث انتخاب نحوه کد گزاری داده ها برای انتقال بین کامپیوترها در شبکه، می تواند شامل صدها گزینه باشد، ولی چارچوب توسعه ای خوب هست که توسعه دهنده بیزینس را به هیچ عنوان درگیر این انتخاب نکند. وقتی محدودیتی وجود دارد باز با هوشمندی عمل کند. مثلا وقتی در حال ساخت SDK برای زبانی خاص هست که از codec مورد نظر پشتیبانی نمی کند خودش بهترین گزینه را انتخاب کند.
باید اشاره شود دو عبارت Low code, no code اصلا چیزهای جدیدی نیستند و برعکس ایده های خیلی قدیمی هستند ولی بدلیل ارتقا نیازمندی ها و عدم ارتقا آن ابزارها ما عملا چندین سال اسمی از این مفاهیم را نشنیده ایم. در نظر بگیریم این دو عبارت ذاتا مسئله مهم جداسازی در توسعه به بخش های کوچک تر را شامل میشه. یعنی یک سازمان دغدغه توسعه نیازمندی های خودش را داشته باشه و سازمانی دیگر (یا تیمی دیگر در سازمان) چارچوب های توسعه را برایش فراهم کند. لذا مثل همیشه با دقت به تک تک کلمات می تونیم به اهمیت و قطعیت نیاز به چارچوب توسعه (framework) اشاره کنیم. این موضوع محدود به علوم و مهندسی کامپیوتر هم نیست، در اکثر صنایع این مهم وجود داره. مثلا چارچوب توسعه یک کارخانه تولید سیمان یا آهن نیز از توسعه واقعی خود کارخانه موضوعی کاملا جدا می باشد.
اگر بخوایم کمی عمیق تر بشویم، همیشه میگیم بخشی از توسعه نرم افزار یعنی توسعه پروتکل ها (از سیستم عامل تا شبکه و ... همه گی وابسته به پروتکل ها هستند) به شدت مشابه فرآیندهای قانون گذاری سنتی هست با این تفاوت که در قانون گذاری سنتی کارها به شدت ساده تر می باشد. مثلا در قانون نویسی براحتی انتهای یک قانون می نویسند "کلیه قوانین و مقررات عام و خاص مغایر با این قانون از تاریخ لازم اجرا شدن این قانون لغو میگردد"، شاید ما هم آرزو کنیم کاش میشد در توسعه نرم افزار هم به همین راحتی بتونیم خیلی کارها را اجرایی کنیم، هر چند در واقعیت هم متاسفانه این نوع قانون گذاری نشان از سواد به شدت پایین قانون گذاران هست نه روش صحیح قانون گذاری.
پس همانگونه که ما برای قانون گذاری نیاز به چارچوب صحیح توسعه داریم قطعا در توسعه نرم افزار هم نیاز به چارچوب خوب داریم.
رویکرد قدیم در توسعه نرم افزار در بخش هایی مانند شبکه پنهان کردن پیچیدگی ها بوده است ولی رویکرد صحیح و بهتر قطعا شناخت و انتخاب فرآیندها بر اساس نیاز می باشد. به طور مثال در پروتکل ALTO به طور مشخص به همین بحث نیاز به عدم پنهان سازی جزییات شبکه از لایه اپلیکیشن ورود کرده و باعث ایجاد گفتمان های نه چندان قوی در اکوسیستم شده است.
Specifically, in today's networks, network information such as network topologies, link availability, routing policies, and path costs are hidden from the application layer, and many applications benefited from such hiding of network complexity. However, new applications, such as application-layer overlays, can benefit from information about the underlying network infrastructure.
هر چند به این پروتکل ALTO نقدهای جدی وارد هست مثلا تصمیم به گره زدن یک پروتکل سطح پایین به کدکی مانند json رفتار به شدت عجیبی هست، در حالی که قطعا سرویس های این پروتکل پس از نهایی شدن RFC بدون تغییر خواهند بود حتی استفاده از پروتکل هایی مانند protobuf نیز بهینه نیست و بهتر از کدک های ثابت همانند option های پروتکل های قدیمی مثل IP و TCP یا فریم های QUIC استفاده شوند.
جواب خیلی کوتاه قطعا یک ضرورت. و خیلی خلاصه بخوایم بگیم توسعه بدون چارچوب اصلا امکان پذیر نمی باشد و چارچوبی خوب هست که نیاز توسعه ای اصلی (کسب و کاری) را به طور کامل پوشش دهد و انتخاب ها را تا حد ممکن محدود کند. مثلا در علوم کامپیوتر بحث انتخاب نحوه کد گزاری داده ها برای انتقال بین کامپیوترها در شبکه، می تواند شامل صدها گزینه باشد، ولی چارچوب توسعه ای خوب هست که توسعه دهنده بیزینس را به هیچ عنوان درگیر این انتخاب نکند. وقتی محدودیتی وجود دارد باز با هوشمندی عمل کند. مثلا وقتی در حال ساخت SDK برای زبانی خاص هست که از codec مورد نظر پشتیبانی نمی کند خودش بهترین گزینه را انتخاب کند.
باید اشاره شود دو عبارت Low code, no code اصلا چیزهای جدیدی نیستند و برعکس ایده های خیلی قدیمی هستند ولی بدلیل ارتقا نیازمندی ها و عدم ارتقا آن ابزارها ما عملا چندین سال اسمی از این مفاهیم را نشنیده ایم. در نظر بگیریم این دو عبارت ذاتا مسئله مهم جداسازی در توسعه به بخش های کوچک تر را شامل میشه. یعنی یک سازمان دغدغه توسعه نیازمندی های خودش را داشته باشه و سازمانی دیگر (یا تیمی دیگر در سازمان) چارچوب های توسعه را برایش فراهم کند. لذا مثل همیشه با دقت به تک تک کلمات می تونیم به اهمیت و قطعیت نیاز به چارچوب توسعه (framework) اشاره کنیم. این موضوع محدود به علوم و مهندسی کامپیوتر هم نیست، در اکثر صنایع این مهم وجود داره. مثلا چارچوب توسعه یک کارخانه تولید سیمان یا آهن نیز از توسعه واقعی خود کارخانه موضوعی کاملا جدا می باشد.
اگر بخوایم کمی عمیق تر بشویم، همیشه میگیم بخشی از توسعه نرم افزار یعنی توسعه پروتکل ها (از سیستم عامل تا شبکه و ... همه گی وابسته به پروتکل ها هستند) به شدت مشابه فرآیندهای قانون گذاری سنتی هست با این تفاوت که در قانون گذاری سنتی کارها به شدت ساده تر می باشد. مثلا در قانون نویسی براحتی انتهای یک قانون می نویسند "کلیه قوانین و مقررات عام و خاص مغایر با این قانون از تاریخ لازم اجرا شدن این قانون لغو میگردد"، شاید ما هم آرزو کنیم کاش میشد در توسعه نرم افزار هم به همین راحتی بتونیم خیلی کارها را اجرایی کنیم، هر چند در واقعیت هم متاسفانه این نوع قانون گذاری نشان از سواد به شدت پایین قانون گذاران هست نه روش صحیح قانون گذاری.
پس همانگونه که ما برای قانون گذاری نیاز به چارچوب صحیح توسعه داریم قطعا در توسعه نرم افزار هم نیاز به چارچوب خوب داریم.
رویکرد قدیم در توسعه نرم افزار در بخش هایی مانند شبکه پنهان کردن پیچیدگی ها بوده است ولی رویکرد صحیح و بهتر قطعا شناخت و انتخاب فرآیندها بر اساس نیاز می باشد. به طور مثال در پروتکل ALTO به طور مشخص به همین بحث نیاز به عدم پنهان سازی جزییات شبکه از لایه اپلیکیشن ورود کرده و باعث ایجاد گفتمان های نه چندان قوی در اکوسیستم شده است.
Specifically, in today's networks, network information such as network topologies, link availability, routing policies, and path costs are hidden from the application layer, and many applications benefited from such hiding of network complexity. However, new applications, such as application-layer overlays, can benefit from information about the underlying network infrastructure.
هر چند به این پروتکل ALTO نقدهای جدی وارد هست مثلا تصمیم به گره زدن یک پروتکل سطح پایین به کدکی مانند json رفتار به شدت عجیبی هست، در حالی که قطعا سرویس های این پروتکل پس از نهایی شدن RFC بدون تغییر خواهند بود حتی استفاده از پروتکل هایی مانند protobuf نیز بهینه نیست و بهتر از کدک های ثابت همانند option های پروتکل های قدیمی مثل IP و TCP یا فریم های QUIC استفاده شوند.
Flatlogic
Hard limits of low-code/no-code and what is an alternative solution. The Flatlogic thesis
Introduction
If you work in the internet business, especially as a software engineer, you must have heard about low-code/no-code (LCNC) tools. Popular tech p
If you work in the internet business, especially as a software engineer, you must have heard about low-code/no-code (LCNC) tools. Popular tech p
👍4
هر چند حرکت هایی برای معرفی چارچوب های قوی و کامل در جهت توسعه نرم افزار که تا جای امکان از سکوت در جزییات فاصله گرفته باشه مانند bud شروع شده است ولی باید دقت کنیم که پیچیدگی زیاد معرفی و توسعه چارچوب های کامل، خیلی سخت هست و نباید براحتی ادعاهای مطرح شده را قبول کنیم.
در نهایت ما سعی داریم چارچوبی منطقی و بدون وجود پرسش باز را در libgo پیاده سازی کنیم که صد البته این چارچوب باید بتواند در دیگر زبان ها نیز به راحتی port شود مانند پیاده سازی خودمان به نام libjs. اگر فکر می کنید نیاز شما هم هست به ما در توسعه این چارچوب کمک کنید.
بیاییم هر جا صحبت از این شد که آیا در توسعه ما نیاز به چارچوب داریم یا خیر به صورت قاطع جواب را بله بگوییم و خود و دیگران را به اشتباه نیاندازیم.
پ.ن: این اشتباه را بارها در گروه های زبان برنامه نویسی مخصوصا go و js مشاهده می کنم که افراد تازه کار یا حتی حرفه ای سوال ایجاد می کنند که برای توسعه چه چارچوبی دیگران پیشنهاد می دهند و در جواب خیلی ها میگن چارچوب توسعه نیاز نیست pure کد بزن!!
در نهایت ما سعی داریم چارچوبی منطقی و بدون وجود پرسش باز را در libgo پیاده سازی کنیم که صد البته این چارچوب باید بتواند در دیگر زبان ها نیز به راحتی port شود مانند پیاده سازی خودمان به نام libjs. اگر فکر می کنید نیاز شما هم هست به ما در توسعه این چارچوب کمک کنید.
بیاییم هر جا صحبت از این شد که آیا در توسعه ما نیاز به چارچوب داریم یا خیر به صورت قاطع جواب را بله بگوییم و خود و دیگران را به اشتباه نیاندازیم.
پ.ن: این اشتباه را بارها در گروه های زبان برنامه نویسی مخصوصا go و js مشاهده می کنم که افراد تازه کار یا حتی حرفه ای سوال ایجاد می کنند که برای توسعه چه چارچوبی دیگران پیشنهاد می دهند و در جواب خیلی ها میگن چارچوب توسعه نیاز نیست pure کد بزن!!
GitHub
GitHub - livebud/bud: The Full-Stack Web Framework for Go
The Full-Stack Web Framework for Go. Contribute to livebud/bud development by creating an account on GitHub.
👍5
درود بر همراهان همیشگی
در این روزها همه غمگینیم؛ دلشکستهایم؛ نگرانیم.
هم سرنوشتیم؛ در یک مرز و یک وطن و از یک تنیم.
کنار هم کار کردیم؛ آباد کردیم؛ از نو شروع کردیم؛ ولی خسته نشدیم.
جامعه امروز قطعا مانند گذشته نمیشود؛ همه به آیندهای روشن نیاز داریم.
ما نیز مانند دیگران از آغاز فعالیت تلاش کردیم تا راوی آگاهی، واقعیت و جریانهای اقناعی باشیم؛ روایتهایی که به ما میآموزند از راههایی که منجر به تفسیر سطحی يا نادرست از اطلاعات میشوند، عبور کنیم و در مسیر ساخت آیندهای بهتر گام برداریم.
امیدوارم در ادامه هم بتوانیم در کنار شما عزیزان باشیم و فعالیت این گروه توسعه را تقویت کنیم.
به امید شادمانی همه ما.
در این روزها همه غمگینیم؛ دلشکستهایم؛ نگرانیم.
هم سرنوشتیم؛ در یک مرز و یک وطن و از یک تنیم.
کنار هم کار کردیم؛ آباد کردیم؛ از نو شروع کردیم؛ ولی خسته نشدیم.
جامعه امروز قطعا مانند گذشته نمیشود؛ همه به آیندهای روشن نیاز داریم.
ما نیز مانند دیگران از آغاز فعالیت تلاش کردیم تا راوی آگاهی، واقعیت و جریانهای اقناعی باشیم؛ روایتهایی که به ما میآموزند از راههایی که منجر به تفسیر سطحی يا نادرست از اطلاعات میشوند، عبور کنیم و در مسیر ساخت آیندهای بهتر گام برداریم.
امیدوارم در ادامه هم بتوانیم در کنار شما عزیزان باشیم و فعالیت این گروه توسعه را تقویت کنیم.
به امید شادمانی همه ما.
❤18🔥1
سال جدید و بهبود سبک زندگی
امیدواریم سال جدید را به خوبی را شروع کرده باشید. هر چند نه می بخشیم و نه فراموش می کنیم در سال 1401 چه به ایرانیان گذشت ولی سعی می کنیم با انرژی بیشتری سال جدید را در جهت #آزادی قدم برداریم.
یکی از دلایل جشن گرفتن ایرانیان برای مناسبت هایی مثل عید نوروز تغییر در زندگی در جهت بهبود آن بوده. مثلا با تجدید دیدارها سعی در فراموش یا حل کردن اختلاف نظر های قدیمی بین افراد بوده است.
به همین مناسبت می خوام به موضوعی اشاره کنم که در جامعه فارسی زبانان حداقل داخل قلمروی جغرافیایی ایران کمتر دیده میشه که بنظرم یکی از مهمترین مسیله ای هست که در سبک زندگی جوامع مدرن به خوبی جا افتاده. تفویض اختیار! از هر دو سمت این موضوع به درستی درک نشده. مثلا یا از کمک پزشک استفاده نمی کنیم یا وقتی استفاده می کنیم دکتر را مجبور به دادن داروهایی می کنیم که حتی بخش کوچکی از جزییات علمی آن را نمی دانیم!
لغت تفویض به معنای واگذاری است و زمانی که از تفویض اختیار صحبت میکنیم منظورمان این است که یک فرد، اختیار در یک اقدام یا یک تصمیم گیری را به فرد دیگری واگذار کند. این موضوع به حدی مهم هست که در تک تک ابعاد زندگی ما همین الان هم وجود داره ولی به صورت خودآگاه ما گارد قوی برای قبول واقعیت های دنیای مدرن داریم.
🔹 به سه دلیل کارها واگذار میشه: مدیریت زمان، مدیریت تضاد منافع در تصمیم گیری ها، مدیریت سطح یادگیری و کسب دانش
مورد سوم که نشات گرفته از مورد اول هم هست، عملا به صورت خودآگاه در انسان ها داره نهادینه میشه، مثلا ما اختیار تصمیم گیری وضعیت سلامت خودمون را به پزشک مورد اعتمادمون واگذار می کنیم، یا در زمان تصمیم گیری برای سرمایه گذاری سعی می کنیم از مشاور مورد اعتماد استفاده کنیم.
🔹 یادمون باشه واگذاری باید تا حد امکان شفاف باشه برای طرفین. چون اغلب اوقات دیده میشه، افراد وظایف و مسئولیتهایی را که به درستی تعریف نشدهاند به عهده میگیرند و انتظاراتی که از آن ها می رود را روشن نمیدانند و این ایجاد مشکل می کند.
🔹 اگر میخواهیم به طور مؤثر تفویض اختیار کنیم، ابتدا زمانی را به این بیاندیشیم و به وضوح با گیرنده اختیار در مورد اینکه امیدواریم نتیجه کار چه شود، صحبت کنیم.
🔹 همچنین دقیقا باید روشن کنیم وظیفهای که محول میکنیم چگونه به اهداف بزرگتر مرتبط است.
🔹 وقتی همه این کارها را انجام دادیم، از آن شخص بخواهیم آنچه را که شنیده است و ما از او خواسته ایم را خلاصه کند. حتی میتوانیم از آنها بخواهیم خلاصهای را در یک ایمیل برای ما بفرستند تا درک آنها را بدانیم و در صورت لزوم آن را تصحیح کنیم.
بیاید بیشتر از قبل با واگذاری اختیارات خود به افراد مورد اعتماد و همینطور قبول اختیار صرفا در صورت داشتن علم کافی در زمینه مورد نظر، جامعه ای حرفه ای تر بسازیم تا کیفیت زندگی خود و دیگران را افزایش دهیم. یادمون باشه انسان ذاتا به شدت فردگرا هست ولی در طول قرن ها هم یاد گرفته برای داشتن زندگی بهتر باید قبول کنه اجتماعی زندگی کنه. هنر همیشگی زندگی خوب، درک و تعادل بین فردگرایی و بودن در جامعه هست.
#نکته #مهارت_نرم #مهارت_رفتاری
امیدواریم سال جدید را به خوبی را شروع کرده باشید. هر چند نه می بخشیم و نه فراموش می کنیم در سال 1401 چه به ایرانیان گذشت ولی سعی می کنیم با انرژی بیشتری سال جدید را در جهت #آزادی قدم برداریم.
یکی از دلایل جشن گرفتن ایرانیان برای مناسبت هایی مثل عید نوروز تغییر در زندگی در جهت بهبود آن بوده. مثلا با تجدید دیدارها سعی در فراموش یا حل کردن اختلاف نظر های قدیمی بین افراد بوده است.
به همین مناسبت می خوام به موضوعی اشاره کنم که در جامعه فارسی زبانان حداقل داخل قلمروی جغرافیایی ایران کمتر دیده میشه که بنظرم یکی از مهمترین مسیله ای هست که در سبک زندگی جوامع مدرن به خوبی جا افتاده. تفویض اختیار! از هر دو سمت این موضوع به درستی درک نشده. مثلا یا از کمک پزشک استفاده نمی کنیم یا وقتی استفاده می کنیم دکتر را مجبور به دادن داروهایی می کنیم که حتی بخش کوچکی از جزییات علمی آن را نمی دانیم!
لغت تفویض به معنای واگذاری است و زمانی که از تفویض اختیار صحبت میکنیم منظورمان این است که یک فرد، اختیار در یک اقدام یا یک تصمیم گیری را به فرد دیگری واگذار کند. این موضوع به حدی مهم هست که در تک تک ابعاد زندگی ما همین الان هم وجود داره ولی به صورت خودآگاه ما گارد قوی برای قبول واقعیت های دنیای مدرن داریم.
🔹 به سه دلیل کارها واگذار میشه: مدیریت زمان، مدیریت تضاد منافع در تصمیم گیری ها، مدیریت سطح یادگیری و کسب دانش
مورد سوم که نشات گرفته از مورد اول هم هست، عملا به صورت خودآگاه در انسان ها داره نهادینه میشه، مثلا ما اختیار تصمیم گیری وضعیت سلامت خودمون را به پزشک مورد اعتمادمون واگذار می کنیم، یا در زمان تصمیم گیری برای سرمایه گذاری سعی می کنیم از مشاور مورد اعتماد استفاده کنیم.
🔹 یادمون باشه واگذاری باید تا حد امکان شفاف باشه برای طرفین. چون اغلب اوقات دیده میشه، افراد وظایف و مسئولیتهایی را که به درستی تعریف نشدهاند به عهده میگیرند و انتظاراتی که از آن ها می رود را روشن نمیدانند و این ایجاد مشکل می کند.
🔹 اگر میخواهیم به طور مؤثر تفویض اختیار کنیم، ابتدا زمانی را به این بیاندیشیم و به وضوح با گیرنده اختیار در مورد اینکه امیدواریم نتیجه کار چه شود، صحبت کنیم.
🔹 همچنین دقیقا باید روشن کنیم وظیفهای که محول میکنیم چگونه به اهداف بزرگتر مرتبط است.
🔹 وقتی همه این کارها را انجام دادیم، از آن شخص بخواهیم آنچه را که شنیده است و ما از او خواسته ایم را خلاصه کند. حتی میتوانیم از آنها بخواهیم خلاصهای را در یک ایمیل برای ما بفرستند تا درک آنها را بدانیم و در صورت لزوم آن را تصحیح کنیم.
بیاید بیشتر از قبل با واگذاری اختیارات خود به افراد مورد اعتماد و همینطور قبول اختیار صرفا در صورت داشتن علم کافی در زمینه مورد نظر، جامعه ای حرفه ای تر بسازیم تا کیفیت زندگی خود و دیگران را افزایش دهیم. یادمون باشه انسان ذاتا به شدت فردگرا هست ولی در طول قرن ها هم یاد گرفته برای داشتن زندگی بهتر باید قبول کنه اجتماعی زندگی کنه. هنر همیشگی زندگی خوب، درک و تعادل بین فردگرایی و بودن در جامعه هست.
#نکته #مهارت_نرم #مهارت_رفتاری
👍13🔥3👌2
coordinator vs gateway pattern
همانطور که می دونیم دنیای ما بر پایه #الگوها شکل گرفته. الگوها همه جای زندگی ما هستند، حتی در مغز ما! چیزی که ما به عنوان هوشمندی نام میبریم چیزی به روش های تشخیص و تثبیت الگوها نیستند. پس بنظر میرسه یادگیری #الگوها در هر علمی باعث میشه ما بتونیم موضوعات را بهتر بشناسیم و بدون نیاز به نقد عمیق (پیشنهاد می کنم یکبار دیگه معنی نقد و تفکر نقادانه را نگاه کنید) و در اصل گرفتن زمان زیاد به جواب پرسش ها برسیم و فرآیند یادگیری را سرعت ببخشیم.
خوب مثل همیشه صرفا قصد #تلنگر_ذهنی هست و هدایت خواننده به مطالعه بیشتر از منابع خوب دیگر با کمی کنجکاوی. ولی بذارید دو الگو نام برده شده در بالای پست که از دید نگارنده مهم می باشد، را معرفی کنیم که مفهوما مختص علوم کامپیوتر نیستند و در سیاست، پزشکی، اقتصاد و ... هم مصداق دارند.
- در علم پزشکی مداخلات غیر مستقیم (دارو) پس از طی دوره اولیه فرصت به بدن جهت بهبودی تجویز میشه و مداخلات مستقیم (عمل های جراجی) پس از شکست دو مرحله قبل اتفاق میافته.
- در علم اقتصاد میگن اول اگر شرایط ایجاد بازار(کلمه پر معنا و مفهموی هست اینجا) پایدار در جامعه برای کالای باشه، باید حکومت اون جامعه صرفا داور بازی باشه (coordinator) و اصولا دخالت محدود داشته باشه.
- در علوم کامپیوتر تا جای امکان سعی در هماهنگ کننده بودن هست. مثلا در پروتکل IP تا وقتی پاکت های این پروتکل نخواد از شبکه محلی خارج بشه نیاز به عبور از gateway نیست و نودها در شبکه محلی می توانند حتی بدون حضور نود gateway با هم تبادل اطلاعات کنند. یا مثلا در پروتکل DNS نمیگه همه درخواست های تبدیل نام به IP باید حتما از یکسری root server پرسیده بشه، بلکه با تمهیداتی هر نودی در شبکه میتونه پاسخ گوی درخواست ها باشه. هر چند در قدیم مشکلات امنیتی وجود داشت ولی با تکمیل پروتکل و معرفی مواردی مثل DNSsec مشکلات تا حد زیادی حل شده است.
در طراحی معماری نرم افزار موضوعات تصمیم گیری در نحوه برخورد با نیازمندی در سطح کلان اصولا در این دو الگو نمود دارند. بدون اینکه بخوام دستوری صحبت کنم رویکردهایی که بر پایه الگوی coordinator بنا می شوند قطعا با توجه به تجربه های فراوان در علوم مختلف موفق تر خواهد بود.
در نهایت برای درک عمیق تر اهمیت مفهوم الگو، جایی متن قشنگی نوشته بود: یک اتومبیل هیچ وقت با تکیه بر اصل تکامل به یک هواپیما تبدیل نمیشود هواپیما ناشی از یک تفکر تحولگراست که بحث انتقال را بازطراحی کرده است؛ ما به یک چیز دیگر نیاز داریم و این یک چیز دیگر که همان بحث تحول واقعی است باید اتفاق بیفتد.
همانطور که می دونیم دنیای ما بر پایه #الگوها شکل گرفته. الگوها همه جای زندگی ما هستند، حتی در مغز ما! چیزی که ما به عنوان هوشمندی نام میبریم چیزی به روش های تشخیص و تثبیت الگوها نیستند. پس بنظر میرسه یادگیری #الگوها در هر علمی باعث میشه ما بتونیم موضوعات را بهتر بشناسیم و بدون نیاز به نقد عمیق (پیشنهاد می کنم یکبار دیگه معنی نقد و تفکر نقادانه را نگاه کنید) و در اصل گرفتن زمان زیاد به جواب پرسش ها برسیم و فرآیند یادگیری را سرعت ببخشیم.
خوب مثل همیشه صرفا قصد #تلنگر_ذهنی هست و هدایت خواننده به مطالعه بیشتر از منابع خوب دیگر با کمی کنجکاوی. ولی بذارید دو الگو نام برده شده در بالای پست که از دید نگارنده مهم می باشد، را معرفی کنیم که مفهوما مختص علوم کامپیوتر نیستند و در سیاست، پزشکی، اقتصاد و ... هم مصداق دارند.
- در علم پزشکی مداخلات غیر مستقیم (دارو) پس از طی دوره اولیه فرصت به بدن جهت بهبودی تجویز میشه و مداخلات مستقیم (عمل های جراجی) پس از شکست دو مرحله قبل اتفاق میافته.
- در علم اقتصاد میگن اول اگر شرایط ایجاد بازار(کلمه پر معنا و مفهموی هست اینجا) پایدار در جامعه برای کالای باشه، باید حکومت اون جامعه صرفا داور بازی باشه (coordinator) و اصولا دخالت محدود داشته باشه.
- در علوم کامپیوتر تا جای امکان سعی در هماهنگ کننده بودن هست. مثلا در پروتکل IP تا وقتی پاکت های این پروتکل نخواد از شبکه محلی خارج بشه نیاز به عبور از gateway نیست و نودها در شبکه محلی می توانند حتی بدون حضور نود gateway با هم تبادل اطلاعات کنند. یا مثلا در پروتکل DNS نمیگه همه درخواست های تبدیل نام به IP باید حتما از یکسری root server پرسیده بشه، بلکه با تمهیداتی هر نودی در شبکه میتونه پاسخ گوی درخواست ها باشه. هر چند در قدیم مشکلات امنیتی وجود داشت ولی با تکمیل پروتکل و معرفی مواردی مثل DNSsec مشکلات تا حد زیادی حل شده است.
در طراحی معماری نرم افزار موضوعات تصمیم گیری در نحوه برخورد با نیازمندی در سطح کلان اصولا در این دو الگو نمود دارند. بدون اینکه بخوام دستوری صحبت کنم رویکردهایی که بر پایه الگوی coordinator بنا می شوند قطعا با توجه به تجربه های فراوان در علوم مختلف موفق تر خواهد بود.
در نهایت برای درک عمیق تر اهمیت مفهوم الگو، جایی متن قشنگی نوشته بود: یک اتومبیل هیچ وقت با تکیه بر اصل تکامل به یک هواپیما تبدیل نمیشود هواپیما ناشی از یک تفکر تحولگراست که بحث انتقال را بازطراحی کرده است؛ ما به یک چیز دیگر نیاز داریم و این یک چیز دیگر که همان بحث تحول واقعی است باید اتفاق بیفتد.
👍6
چندین ایده جذاب و تقریبا غیر تکراری (غیر تکراری بودن مطلق ادعای بزرگی هست که ما ازش دوری می کنیم) برای نگارش #مقاله_علمی در رشته های #علوم_کامپیوتر ، #مهندسی_نرم_افزار ، #کشاورزی و #معماری_ساختمان حتی مناسب برای پایان نامه دانشگاهی (هر چند می تواند در سطح کارشناسی استفاده شود ولی بدلیل سطح نسبتا عمیق موضوعات، ترجیحا در سطح فوق لیسانس باشه قابلیت دفاع بیشتری دارد مگر اینکه دانشجو از سطح علمی خوبی برخوردار باشد) و رساله یا تز دکترا در گروه توسعه آماده شده است و شروع اولیه آنها انجام شده است. نگارش شامل حمایت مالی گروه نیز هست. ایده ها در چندین پروژه گروه در آینده پیاده سازی نیز خواهند شد.
از علاقه مندان #دعوت_به_همکاری برای پیشبرد این ایده ها و نگارش مقاله می کنیم.
کانال ارتباطی - کانال تلگرام
از علاقه مندان #دعوت_به_همکاری برای پیشبرد این ایده ها و نگارش مقاله می کنیم.
کانال ارتباطی - کانال تلگرام
🔥9👏1
Forwarded from Gopher Academy (Javad)
✅ دورهمی هفته دهم
- موضوع: Memory Management
- تاریخ و ساعت: ۱۲ خرداد ساعت ۹ شب
- اسپانسر: GoBridge
- مهمان ویژه: آقای امید حکایتی
- محل برگزاری: پلت فرم zoom (دانلود برای همه پلت فرم ها)
Meeting ID: 885 9293 2652
Passcode: 625503
🔗 Join Link: https://us02web.zoom.us/j/88592932652?pwd=QitZWkw5UmF4Z0RvU3M2OXhpZ2RDQT09
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
- موضوع: Memory Management
- تاریخ و ساعت: ۱۲ خرداد ساعت ۹ شب
- اسپانسر: GoBridge
- مهمان ویژه: آقای امید حکایتی
- محل برگزاری: پلت فرم zoom (دانلود برای همه پلت فرم ها)
Meeting ID: 885 9293 2652
Passcode: 625503
🔗 Join Link: https://us02web.zoom.us/j/88592932652?pwd=QitZWkw5UmF4Z0RvU3M2OXhpZ2RDQT09
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
🔥10⚡1👍1
همانطور که همیشه از قدیم گفته شده ما انسان ها همیشه برای حل مشکلاتمون در حال تولید مشکلات جدید هستیم و متاسفانه ارزیابی اثر تصمیماتمون اغلب به دلیل عدم وجود علم کافی یا داده کافی وقتی نمایان میشه که باز برای حل اون مشکلات مجبور به تصمیمات آنی و بدتری میشیم که این چرخه را بدون شکست ادامه میده!
در این پست به یک الگو در توسعه نرم افزار میپردازیم که موضوع بالا را نشان میده، ولی در پست بعد سعی می کنم مشکل اشتباه در ارزیابی صحیح و تصمیم سازی بهینه را با وام گرفتن از یک مطلب دیگه نشون بدم.
موضوع استفاده از الگوها عموما نشات گرفته از تبیین های خاص در علم هست. مثلا الگوی CQRS از تبیین Aggregate در رویکرد DDD از توسعه نرم افزار مطرح میشه. عدم توجه به تبیین صحیح الگو و رویکرد که نمایان در انتخاب هوشمندانه تک تک کلمات زیر هست، در اکوسیستم به وفور دیده میشه.
the goal of CQRS is to allow representation of the same data in different models.
حتی در خود این مقاله که اشاره مستقیم به تببین درست کرده باز دچار خطای شناختی شده و از همون تیپ رویکردهایی هست که قبول نکردن، مشکلی بوجود آوردیم و در حال حل مشکلات جدید هستیم بدون اینکه برگردیم عقب نگاهی بیاندازیم که آیا واقعا این الگوی طراحی از ابتدا به درستی در نیازمندی فعلی انتخاب شده است یا خیر. همانطور martin fowler هم گفته استفاده از این الگو به شدت محدود هست و نباید بدون دقت استفاده شود.
برخی از مشکلات:
- معضل سطح دسترسی. باید قبول کنیم ما براحتی نمی تونیم فیلدهای داده ای یک مدل (ماژول) را به مدل دیگری بدیم. با این کار منطق های سطح دسترسی اگر منتقل نشود، مشکلات امنیتی حتی اگر در ابتدا با دقت کافی توسعه دهنده ها نداشته باشیم در طول مسیر توسعه با تغییرات احتمالی می تونه بوجود بیاد.
- مشکل پیچیده شدن سرویس های بالادستی: مثلا فکر کنید با تجمیع مدل ها، در یک gui widget قصد نمایش داده ها را دارید، شما باید یک شرط داشته باشید که بدلیل عدم سطح دسترسی مناسب بجای گرفتن بخشی از جواب با خطا روبرو شوید. مثلا کاربر امکان مشاهده عکس یک کاربر دیگر را ندارد و شما باید تصمیم بگیرید نام کاربر را در مدل تجمیع شده بر گردانید یا کلا خطا دهید. در هر مورد سناریوهای دیگری نیز مطرح می شود.
- مشکل cache invalidation: اگر به صورت مرسوم به پیاده سازی این الگو بپردازیم داده های چند مدل در یک مدل تجمیع و کش می شوند به همین دلیل مشکل بزرگ علوم کامپیوتر که مطرح شد بوجود میاد. اگر داده ها در source of truth خودش تغییر کنه، ما نیاز به پیچیدگی های زیادی برای بروزرسانی داده های cache داریم.
- واگذاری بخشی از عملکرد یک ماژول (دامنه) به دیگر ماژول ها(دامنه ها): نیاز به توانایی پاسخگوی یک ماژول به تعداد مناسب درخواست در ذات تا جای امکان باید توسط خود آن ماژول انجام گیرد. با انتخاب درست رویکرد کش در SDK ارایه شده هر ماژول این امکان براحتی صورت میپذیرد.
در این دیاگرام نشون دادم چجوری با مفاهیم قدیمی SDK و Cache با انتخاب صحیح چند متغیر در Cache strategy می تونیم به اهداف با پیچیدگی کمتر برسیم. قطعا قصد ساده سازی مسئله نیست، خود دیاگرام شامل کلی جزییات هست که هدف این پست تبیین اون موارد نبوده و نیست.
پ.ن:
- بخشی از ایده های نگارش این پست از یک موضوع در گروه GolangEngineers بوجود اومد. که می تونید از قابلیت view replies تلگرام استفاده کنید و صحبت های پیرامون موضوع را بخونید هر چند دوستان خیلی وقت ها رعایت نمی کنند و reply نمیزنند و پیام هاشون گم میشه در بین پیام های موضوعات دیگه.
- به شوخی به یکی از دوستان گفتم میترسم در نهایت نیازمندی دیسکورد در این مقاله به داشتن لایه data services هم با تعاریف اشتباه فعلی بگن cqrs هست!!
در این پست به یک الگو در توسعه نرم افزار میپردازیم که موضوع بالا را نشان میده، ولی در پست بعد سعی می کنم مشکل اشتباه در ارزیابی صحیح و تصمیم سازی بهینه را با وام گرفتن از یک مطلب دیگه نشون بدم.
موضوع استفاده از الگوها عموما نشات گرفته از تبیین های خاص در علم هست. مثلا الگوی CQRS از تبیین Aggregate در رویکرد DDD از توسعه نرم افزار مطرح میشه. عدم توجه به تبیین صحیح الگو و رویکرد که نمایان در انتخاب هوشمندانه تک تک کلمات زیر هست، در اکوسیستم به وفور دیده میشه.
the goal of CQRS is to allow representation of the same data in different models.
حتی در خود این مقاله که اشاره مستقیم به تببین درست کرده باز دچار خطای شناختی شده و از همون تیپ رویکردهایی هست که قبول نکردن، مشکلی بوجود آوردیم و در حال حل مشکلات جدید هستیم بدون اینکه برگردیم عقب نگاهی بیاندازیم که آیا واقعا این الگوی طراحی از ابتدا به درستی در نیازمندی فعلی انتخاب شده است یا خیر. همانطور martin fowler هم گفته استفاده از این الگو به شدت محدود هست و نباید بدون دقت استفاده شود.
برخی از مشکلات:
- معضل سطح دسترسی. باید قبول کنیم ما براحتی نمی تونیم فیلدهای داده ای یک مدل (ماژول) را به مدل دیگری بدیم. با این کار منطق های سطح دسترسی اگر منتقل نشود، مشکلات امنیتی حتی اگر در ابتدا با دقت کافی توسعه دهنده ها نداشته باشیم در طول مسیر توسعه با تغییرات احتمالی می تونه بوجود بیاد.
- مشکل پیچیده شدن سرویس های بالادستی: مثلا فکر کنید با تجمیع مدل ها، در یک gui widget قصد نمایش داده ها را دارید، شما باید یک شرط داشته باشید که بدلیل عدم سطح دسترسی مناسب بجای گرفتن بخشی از جواب با خطا روبرو شوید. مثلا کاربر امکان مشاهده عکس یک کاربر دیگر را ندارد و شما باید تصمیم بگیرید نام کاربر را در مدل تجمیع شده بر گردانید یا کلا خطا دهید. در هر مورد سناریوهای دیگری نیز مطرح می شود.
- مشکل cache invalidation: اگر به صورت مرسوم به پیاده سازی این الگو بپردازیم داده های چند مدل در یک مدل تجمیع و کش می شوند به همین دلیل مشکل بزرگ علوم کامپیوتر که مطرح شد بوجود میاد. اگر داده ها در source of truth خودش تغییر کنه، ما نیاز به پیچیدگی های زیادی برای بروزرسانی داده های cache داریم.
- واگذاری بخشی از عملکرد یک ماژول (دامنه) به دیگر ماژول ها(دامنه ها): نیاز به توانایی پاسخگوی یک ماژول به تعداد مناسب درخواست در ذات تا جای امکان باید توسط خود آن ماژول انجام گیرد. با انتخاب درست رویکرد کش در SDK ارایه شده هر ماژول این امکان براحتی صورت میپذیرد.
در این دیاگرام نشون دادم چجوری با مفاهیم قدیمی SDK و Cache با انتخاب صحیح چند متغیر در Cache strategy می تونیم به اهداف با پیچیدگی کمتر برسیم. قطعا قصد ساده سازی مسئله نیست، خود دیاگرام شامل کلی جزییات هست که هدف این پست تبیین اون موارد نبوده و نیست.
پ.ن:
- بخشی از ایده های نگارش این پست از یک موضوع در گروه GolangEngineers بوجود اومد. که می تونید از قابلیت view replies تلگرام استفاده کنید و صحبت های پیرامون موضوع را بخونید هر چند دوستان خیلی وقت ها رعایت نمی کنند و reply نمیزنند و پیام هاشون گم میشه در بین پیام های موضوعات دیگه.
- به شوخی به یکی از دوستان گفتم میترسم در نهایت نیازمندی دیسکورد در این مقاله به داشتن لایه data services هم با تعاریف اشتباه فعلی بگن cqrs هست!!
Rants on Software Design
Tackling Complexity in CQRS
CQRS is a great tool. However CQRS gained itself a controversial name because of the complexity it introduces. In this post I want to show why this complexity is accidental, and 3 ways to tackle it
👍4👎1
Geniuses Group
همانطور که همیشه از قدیم گفته شده ما انسان ها همیشه برای حل مشکلاتمون در حال تولید مشکلات جدید هستیم و متاسفانه ارزیابی اثر تصمیماتمون اغلب به دلیل عدم وجود علم کافی یا داده کافی وقتی نمایان میشه که باز برای حل اون مشکلات مجبور به تصمیمات آنی و بدتری میشیم…
در ادامه پست قبل که گفتیم عدم دقت به جزییات باعث ایجاد تصمیمات اشتباه میشه، می خوایم به صورت عمومی یک خطای شناختی رایج دیگر را با یک مثال نسبتا معروف ببینیم. قبل از اینکه وارد خود مثال بشیم، بگم دوستان علاقه مند به طبیعت و فعال محیط زیست که تخصص اصلی در صنعت کامپیوتر دارن هم دچار این خطا هستند. پیشنهاد می کنم این مقاله توصیفی خوب را بخونید تا ببینید چقدر خود این متخصصان می توانند به محیط زیست کمک کنند ولی با تصمیمات که متاسفانه آثارشان را نمی دانند، به طبیعت و محیط زیست دارند آسیب میزنند!
خطای شناختی "حماقت داوطلب"
جک یک عکاس مد با در آمد معادل ساعتی پانصد دلار است. یکی از دوستانش از او میخواهد در یک فعالیت خیرخواهانه یک روز از وقتش را لانه های چوبی برای پرندگان بسازند. اگر جک واقعا دنبال ساختن دنیای بهتری است، چه جوابی باید بدهد؟ بله او باید پیشنهاد دوستش را رد کند!
دستمزد یک نجار ساعتی پنجاه دلار است. جک میتواند با یک ساعت بیشتر کار کردن، از یک نجار بخواهد در شش ساعت شش لانه ی حرفه ای بسازد و دویست دلار باقیمانده را به باشگاه پرندگان اهدا کند. با اینحال محتمل است که جک به پیشنهاد دوستش عمل کند. اقتصاد دانان به چنین پدیده ای "حماقت داوطلب" میگویند. چرا این کار منطقی نیست؟ وقتی جک خودش لانه پرنده بسازد کاری را از چند کاسب دریغ کرده، یعنی خیلی بهتر است که او بخشی از درآمدش را به امور خیریه اختصاص دهد تا خودش شخصا آنرا انجام دهد مگر زمانی که بخواهد از مهارت خودش استفاده کند مثلا عکاسی برای باشگاه پرندگان وقتی که باشگاه برای کمپینی به یک عکاس حرفه ای نیاز دارد. سوال اینست که چرا گاهی ما به فعالیتهای خیرخواهانه ای گرایش داریم که هیچ مهارت و تجربه ای در آنها نداریم؟ در حقیقت این نوعی "مدیریت خشنودی شخصی" است و نه نوع دوستی واقعی.
یک استثنا وجود دارد، وقتی افراد معروف در چنین فعالیتهایی شرکت میکنند تبلیغات آنها چیزی گرانبها به شرایط می بخشد. اما در مورد من و تو بهتر است اسکناسهایمان را خرج این امور کنیم تا کارگران مبتدی باشیم.
برگرفته از کتاب هنر شفاف اندیشیدن / رولف دوبلی
خطای شناختی "حماقت داوطلب"
جک یک عکاس مد با در آمد معادل ساعتی پانصد دلار است. یکی از دوستانش از او میخواهد در یک فعالیت خیرخواهانه یک روز از وقتش را لانه های چوبی برای پرندگان بسازند. اگر جک واقعا دنبال ساختن دنیای بهتری است، چه جوابی باید بدهد؟ بله او باید پیشنهاد دوستش را رد کند!
دستمزد یک نجار ساعتی پنجاه دلار است. جک میتواند با یک ساعت بیشتر کار کردن، از یک نجار بخواهد در شش ساعت شش لانه ی حرفه ای بسازد و دویست دلار باقیمانده را به باشگاه پرندگان اهدا کند. با اینحال محتمل است که جک به پیشنهاد دوستش عمل کند. اقتصاد دانان به چنین پدیده ای "حماقت داوطلب" میگویند. چرا این کار منطقی نیست؟ وقتی جک خودش لانه پرنده بسازد کاری را از چند کاسب دریغ کرده، یعنی خیلی بهتر است که او بخشی از درآمدش را به امور خیریه اختصاص دهد تا خودش شخصا آنرا انجام دهد مگر زمانی که بخواهد از مهارت خودش استفاده کند مثلا عکاسی برای باشگاه پرندگان وقتی که باشگاه برای کمپینی به یک عکاس حرفه ای نیاز دارد. سوال اینست که چرا گاهی ما به فعالیتهای خیرخواهانه ای گرایش داریم که هیچ مهارت و تجربه ای در آنها نداریم؟ در حقیقت این نوعی "مدیریت خشنودی شخصی" است و نه نوع دوستی واقعی.
یک استثنا وجود دارد، وقتی افراد معروف در چنین فعالیتهایی شرکت میکنند تبلیغات آنها چیزی گرانبها به شرایط می بخشد. اما در مورد من و تو بهتر است اسکناسهایمان را خرج این امور کنیم تا کارگران مبتدی باشیم.
برگرفته از کتاب هنر شفاف اندیشیدن / رولف دوبلی
Telegram
Geniuses Group
همانطور که همیشه از قدیم گفته شده ما انسان ها همیشه برای حل مشکلاتمون در حال تولید مشکلات جدید هستیم و متاسفانه ارزیابی اثر تصمیماتمون اغلب به دلیل عدم وجود علم کافی یا داده کافی وقتی نمایان میشه که باز برای حل اون مشکلات مجبور به تصمیمات آنی و بدتری میشیم…
👍10👎1
✅ از چند #متخصص با #علم کافی (قطعا کلمه کافی دارای ابهام زیادی هست ولی قبول کنیم موضوع هم پیچیدگی داره) برای موقعیت های شغلی زیر به صورت #دورکاری و ترجیحا #تمام_وقت، #دعوت_به_همکاری می نماییم. محصول به صورت تجاری در حیطه کلمات تجاری مانند ERP ولی به صورت کمی تخصصی توسعه نرم افزار با شمول دامنه های تجاری زیاد، می باشد و قطعا متناسب با تخصص شما هزینه زمان با ارزش شما پرداخت خواهد شد.
🔹 دانشمند داده (توانا در همکاری برای #مدل_سازی و پیاده سازی اطلاعات و دانش (#داده_اکتشافی) با استفاده از روش های مختلف علمی ، الگوریتم ها و فرایندها از #داده_اکتسابی دامنه های مختلف نرم افزار)
🔹 توسعه دهنده GUI (توانا در همکاری برای #مدل_سازی و پیاده سازی صفحات و ویجت های GUI مبتنی بر مدل های تجاری)
🔹 معمار نرم افزار و توسعه دهنده چارچوب های توسعه (توانا در پاسخگویی صحیح به نیازمندی های توسعه ای دیگر بخش ها با کمترین نیاز به توسعه انسان محوری که نیاز به تسلط کافی با مفاهیم زیرساختی مثل سخت افزار، سیستم عامل، شبکه، الگوریتم و مفاهیم عمومی تر مثل SDK و ... هست.)
در همه موارد بالا مهارت های زیر دارای اهمیت بالا می باشد.
‼️علاقه مند در افزایش مهارت های نرم مانند #تفکر_انتقادی، قبول مسئولیت، برنامه ریزی شخصی (داشتن زمان کافی برای انجام تسک های محول شده) و ...
‼️تسلط کافی به موضوعات پایه ای علوم و مهندسی کامپیوتر مانند Data Modeling که در جاهای مختلف مثل نوشته نگارنده این پست یا مقالات خوب و مرتبط دیگه اهمیت این موضوعات را نشان داده اند. در صورت عدم درک کافی یا عدم تمایل ذاتی به استفاده از اصول و مفاهیم لطفا تقاضای جلسه نفرمایید، واقعا قادر به همکاری نیستیم حتی برای توسعه دهنده GUI
‼️تسلط کافی یا علاقه مند به افزایش آگاهی به الگوهای رایج توسعه نرم افزار مثل MP(modular programming), FP, DDD, OOP, TDD , و ...
‼️آشنایی کافی با فرهنگ های سازمانی مانند Agile, DevOps, ...
⚠️ قابل ذکر است فرآیند اخذ #کارآموز به صورت محدود و با فرآیند نسبتا سخت انجام میشه، لطفا با دانش کافی درخواست بدید. کارآموز یعنی فردی دارای دانش ابتدایی و علاقه مند به یادگیری بیشتر به صورت #خود_آموزی در کنار #منتور. شرکت ها و مفهوم کارآموزی جایگزین #دانش_گاه (بازه ای از عمر هر انسان که درصد بسیاری بالایی از وقت و انرژی خود را جهت کسب علم می گذارد نه صرفا حضور در موسسات آموزشی) قطعا نیستند. آشنایی اولیه با کلمات کلیدی این مقاله پیش شرط ورود به مذاکره برای کارآموزی هست.
طرح سوال یا هماهنگی برای مصاحبه در تلگرام با این آیدی
🔹 دانشمند داده (توانا در همکاری برای #مدل_سازی و پیاده سازی اطلاعات و دانش (#داده_اکتشافی) با استفاده از روش های مختلف علمی ، الگوریتم ها و فرایندها از #داده_اکتسابی دامنه های مختلف نرم افزار)
🔹 توسعه دهنده GUI (توانا در همکاری برای #مدل_سازی و پیاده سازی صفحات و ویجت های GUI مبتنی بر مدل های تجاری)
🔹 معمار نرم افزار و توسعه دهنده چارچوب های توسعه (توانا در پاسخگویی صحیح به نیازمندی های توسعه ای دیگر بخش ها با کمترین نیاز به توسعه انسان محوری که نیاز به تسلط کافی با مفاهیم زیرساختی مثل سخت افزار، سیستم عامل، شبکه، الگوریتم و مفاهیم عمومی تر مثل SDK و ... هست.)
در همه موارد بالا مهارت های زیر دارای اهمیت بالا می باشد.
‼️علاقه مند در افزایش مهارت های نرم مانند #تفکر_انتقادی، قبول مسئولیت، برنامه ریزی شخصی (داشتن زمان کافی برای انجام تسک های محول شده) و ...
‼️تسلط کافی به موضوعات پایه ای علوم و مهندسی کامپیوتر مانند Data Modeling که در جاهای مختلف مثل نوشته نگارنده این پست یا مقالات خوب و مرتبط دیگه اهمیت این موضوعات را نشان داده اند. در صورت عدم درک کافی یا عدم تمایل ذاتی به استفاده از اصول و مفاهیم لطفا تقاضای جلسه نفرمایید، واقعا قادر به همکاری نیستیم حتی برای توسعه دهنده GUI
‼️تسلط کافی یا علاقه مند به افزایش آگاهی به الگوهای رایج توسعه نرم افزار مثل MP(modular programming), FP, DDD, OOP, TDD , و ...
‼️آشنایی کافی با فرهنگ های سازمانی مانند Agile, DevOps, ...
⚠️ قابل ذکر است فرآیند اخذ #کارآموز به صورت محدود و با فرآیند نسبتا سخت انجام میشه، لطفا با دانش کافی درخواست بدید. کارآموز یعنی فردی دارای دانش ابتدایی و علاقه مند به یادگیری بیشتر به صورت #خود_آموزی در کنار #منتور. شرکت ها و مفهوم کارآموزی جایگزین #دانش_گاه (بازه ای از عمر هر انسان که درصد بسیاری بالایی از وقت و انرژی خود را جهت کسب علم می گذارد نه صرفا حضور در موسسات آموزشی) قطعا نیستند. آشنایی اولیه با کلمات کلیدی این مقاله پیش شرط ورود به مذاکره برای کارآموزی هست.
طرح سوال یا هماهنگی برای مصاحبه در تلگرام با این آیدی
✍4👍1🔥1
Forwarded from شیرازلینوکس | shirazlinux
🐧 گنو/لينوكس
🗒 توسعه پايدار مفهومى است كه به واسطه پيامدهاى منفى رويكرد يک جانبه اقتصادی پس از انقلاب صنعتی و تغیر نگرش مردم نسبت به پیشرفت پدید آمده، امید حکایتی ضرورت این مفهوم رو برای ما روشن خواهد کرد.
به معنی توان کرد دعوی درست
دم بیقدم تکیهگاهی است سست
«سعدى»
🌟 با افتخار، برگزارى همايش گنو/لينوكس را به عمل مىآوريم. اين بار در شیراز، پايتخت فرهنگى ايران، مهد تمدن، فرهنگ و هنر اصيل پارسى.
🤩 تجربهاى صميمى و تكرار نشدنى براى آشنايى بيشتر با دنياى نرمافزارهای متنباز.
👈🏼 شما در فضايى قرار خواهيد گرفت كه براى تعامل طراحى شده، پس گفت و گو میكنيد، از تجربه افراد به نام استفاده خواهيد كرد و ناخودآگاه مسير موفقيت خود را روشنتر از قبل خواهيد ديد.✨
💳 درصورت تمایل به حمایت مالی از همایش کلیک کنید
🌐 ثبتنام و شرکت بصورت حضوری در همایش
🗓 ٢٢ تير ماه، شيراز
🔰 @GnuLinuxIran
🗒 توسعه پايدار مفهومى است كه به واسطه پيامدهاى منفى رويكرد يک جانبه اقتصادی پس از انقلاب صنعتی و تغیر نگرش مردم نسبت به پیشرفت پدید آمده، امید حکایتی ضرورت این مفهوم رو برای ما روشن خواهد کرد.
به معنی توان کرد دعوی درست
دم بیقدم تکیهگاهی است سست
«سعدى»
🌟 با افتخار، برگزارى همايش گنو/لينوكس را به عمل مىآوريم. اين بار در شیراز، پايتخت فرهنگى ايران، مهد تمدن، فرهنگ و هنر اصيل پارسى.
🤩 تجربهاى صميمى و تكرار نشدنى براى آشنايى بيشتر با دنياى نرمافزارهای متنباز.
👈🏼 شما در فضايى قرار خواهيد گرفت كه براى تعامل طراحى شده، پس گفت و گو میكنيد، از تجربه افراد به نام استفاده خواهيد كرد و ناخودآگاه مسير موفقيت خود را روشنتر از قبل خواهيد ديد.✨
💳 درصورت تمایل به حمایت مالی از همایش کلیک کنید
🌐 ثبتنام و شرکت بصورت حضوری در همایش
🗓 ٢٢ تير ماه، شيراز
🔰 @GnuLinuxIran
🔥8👍3❤1
در خصوص تقاضای همکاری برای توسعه دهنده GUI چندین نفر تقاضای صحبت در خصوص چرایی مطرح بودن Data Modeling و اهمیت Widget driven design در توسعه GUI بودند و پس از صحبت مشخص شد اصولا در اکوسیستم توسعه دهنده های به اصطلاح فرانت اند و حتی طراحان به اصطلاح UI/UX اصولا چارچوب توسعه مناسب وجود ندارد و خیلی از کلمات و مفاهیم برای این عزیزان اصولا شکل نگرفته است. البته که این مشکل فقط مربوط به ایران نمی شود. در این پست خواستم با یک مثال کوچک از خود نرم افزار تلگرام نشون بدم که چقدر مفهوم Data Modeling در لایه های مختلف توسعه نرم افزار مهم هست و در صورت عدم رعایت اصول علوم و مهندسی نرم افزار یک نرم افزار رو به رشد با مشکلات #طراحی و #تجربه_کاربر بدی روبرو میشه.
تلگرام به صورت مخفیانه در نسخه desktop (mouse base) به شما امکان مشاهده تعداد forward شدن های یک پیام در یک کانال را میدهد! در صورتی که اگر مدل سازی صحیح اتفاق افتاده بود، بدون تحمیل هزینه مازاد به توسعه، تمام نسخه های GUI می توانست این امکان را براحتی پیاده سازی کنند.
اگر مشتاق هستید روش بهینه توسعه در GUI را در کنار ما امتحان کنید، به این آیدی پیام بدید.
تلگرام به صورت مخفیانه در نسخه desktop (mouse base) به شما امکان مشاهده تعداد forward شدن های یک پیام در یک کانال را میدهد! در صورتی که اگر مدل سازی صحیح اتفاق افتاده بود، بدون تحمیل هزینه مازاد به توسعه، تمام نسخه های GUI می توانست این امکان را براحتی پیاده سازی کنند.
اگر مشتاق هستید روش بهینه توسعه در GUI را در کنار ما امتحان کنید، به این آیدی پیام بدید.
👍4🔥2👌2👎1👏1
Forwarded from فرانت چپتر 🥕
🥕 گفتوگو و دورهمی آزاد توسعه دهندههای فرانتاند
💠 جلسهی بیستوهشتم: الگوهای بهینهی توسعهی نرمافزار
💠 پیشگام گفتوگو: امید حکایتی
💠 تاریخ: ۷ تیر | ساعت ۱۹ الی ۲۰:۳۰
💠 جلسه در گوگل میت برگزار میشود و شرکت برای همه آزاد است.
📆 افزودن به تقویم 📆
🔗 لینک میت جلسه 🔗
فرانت چپتر؛ محیطی صمیمی برای گفتوگوی تخصصی
@FrontChapter - #frontChapter
💠 جلسهی بیستوهشتم: الگوهای بهینهی توسعهی نرمافزار
💠 پیشگام گفتوگو: امید حکایتی
💠 تاریخ: ۷ تیر | ساعت ۱۹ الی ۲۰:۳۰
💠 جلسه در گوگل میت برگزار میشود و شرکت برای همه آزاد است.
📆 افزودن به تقویم 📆
🔗 لینک میت جلسه 🔗
فرانت چپتر؛ محیطی صمیمی برای گفتوگوی تخصصی
@FrontChapter - #frontChapter
🔥9👍1
موضوعات به شدت جذاب و مهم در اکثر علوم حول کلمه #حق شکل میگیره.
اینقدر این موضوع بزرگ و جذاب هست که هر چی اینجا بیشتر توضیح بدم، فکر می کنم از لطف این کلمه کم می کنه! ولی بذارید با چند تا مثال مثل همیشه #تلنگر_ذهنی در شما بوجود بیاورم که دلیل محکمی بشه برید گوگل کنید یا از chatbot ها سوالات باحال بپرسید. مثلا در باب حق مالکیت در علوم کامپیوتر تا سال ها سکوت عجیبی حداقل در سطوح بالا وجود داشت ولی زبان Rust به شکل جالبی این موضوع را در اکوسیستم توسعه نرم افزار یا حتی سخت افزار مطرح کرد و به نوعی شروع به شدت انقلابی اتفاق افتاد در حدی که بعد از سالیان دراز اجازه ورود به رپو لینوکس را پیدا کرد! موضوع هم به قدری جذاب و نسبتا ساده هست حداقل در سطح تعاریف که پیشنهاد می کنم مستندات ownership این زبان را مطالعه کنید
در مثالی دیگر در علم اقتصاد (و شاید حقوق و خیلی علوم دیگه) "حق مالکیت" به نحوهای دیگر مطرح هست. البته بنظر برداشت های نادرست زیادی از این موضوع در جامعه های مختلف وجود داره ولی بنظر در تمام مستندات علمی، بهترین برداشت این هست که یا در جامعه ای "حق مالکیت" وجود دارد یا ندارد یعنی منطق کلاسیک! اگر طبق منطق فازی بخوایم به موضوع نگاه کنیم (نگاه رایج و به شدت مشکل دار حکومت های توتالیتر) در نهایت به یک سمت میل پیدا می کنه، که طبق تجربه و شواهد تاریخی همیشه میل به سمت عدم به رسمیت شناختن حق مالکیت هست.
در انتها اشاره کنم این موضوع مهم حق مالکیت عموما به اشتباه به علم اقتصاد نسبت داده میشه ولی موضوع قطعا در علوم مختلف مطرح هست. حتی حق های دیگر ارتباط تنگاتنگ با این حق مالکیت دارند، مثل حق حیات که متاسفانه براحتی با منطق های آبکی و بدتر از آن با سو استفاده از آیین های دینی این حق اساسی در جوامع سلب میشه.
دلیل نگارش این پست کوتاه هم خواندن مقاله ای جالب از رونالد کوز، اقتصاددان برنده جایزه نوبل است. پیشنهاد می کنم حتما مطالعه کنید.
https://donya-e-eqtesad.com/fa/tiny/news-3980881
«مادامی که حق مالکیت به رسمیت شناخته شود، منابع در اختیار کسانی قرار میگیرد که برای آنها بیشترین ارزش را دارد.» این جمله خلاصه نظریه رونالد کوز، اقتصاددان برنده جایزه نوبل است.
اینقدر این موضوع بزرگ و جذاب هست که هر چی اینجا بیشتر توضیح بدم، فکر می کنم از لطف این کلمه کم می کنه! ولی بذارید با چند تا مثال مثل همیشه #تلنگر_ذهنی در شما بوجود بیاورم که دلیل محکمی بشه برید گوگل کنید یا از chatbot ها سوالات باحال بپرسید. مثلا در باب حق مالکیت در علوم کامپیوتر تا سال ها سکوت عجیبی حداقل در سطوح بالا وجود داشت ولی زبان Rust به شکل جالبی این موضوع را در اکوسیستم توسعه نرم افزار یا حتی سخت افزار مطرح کرد و به نوعی شروع به شدت انقلابی اتفاق افتاد در حدی که بعد از سالیان دراز اجازه ورود به رپو لینوکس را پیدا کرد! موضوع هم به قدری جذاب و نسبتا ساده هست حداقل در سطح تعاریف که پیشنهاد می کنم مستندات ownership این زبان را مطالعه کنید
در مثالی دیگر در علم اقتصاد (و شاید حقوق و خیلی علوم دیگه) "حق مالکیت" به نحوهای دیگر مطرح هست. البته بنظر برداشت های نادرست زیادی از این موضوع در جامعه های مختلف وجود داره ولی بنظر در تمام مستندات علمی، بهترین برداشت این هست که یا در جامعه ای "حق مالکیت" وجود دارد یا ندارد یعنی منطق کلاسیک! اگر طبق منطق فازی بخوایم به موضوع نگاه کنیم (نگاه رایج و به شدت مشکل دار حکومت های توتالیتر) در نهایت به یک سمت میل پیدا می کنه، که طبق تجربه و شواهد تاریخی همیشه میل به سمت عدم به رسمیت شناختن حق مالکیت هست.
در انتها اشاره کنم این موضوع مهم حق مالکیت عموما به اشتباه به علم اقتصاد نسبت داده میشه ولی موضوع قطعا در علوم مختلف مطرح هست. حتی حق های دیگر ارتباط تنگاتنگ با این حق مالکیت دارند، مثل حق حیات که متاسفانه براحتی با منطق های آبکی و بدتر از آن با سو استفاده از آیین های دینی این حق اساسی در جوامع سلب میشه.
دلیل نگارش این پست کوتاه هم خواندن مقاله ای جالب از رونالد کوز، اقتصاددان برنده جایزه نوبل است. پیشنهاد می کنم حتما مطالعه کنید.
https://donya-e-eqtesad.com/fa/tiny/news-3980881
«مادامی که حق مالکیت به رسمیت شناخته شود، منابع در اختیار کسانی قرار میگیرد که برای آنها بیشترین ارزش را دارد.» این جمله خلاصه نظریه رونالد کوز، اقتصاددان برنده جایزه نوبل است.
روزنامه دنیای اقتصاد
نظریه کوز و فرجام کنترلهای ارزی
«مادامی که حق مالکیت به رسمیت شناخته شود، منابع در اختیار کسانی قرار میگیرد که برای آنها بیشترین ارزش را دارد.» این جمله خلاصه نظریه رونالد کوز، اقتصاددان برنده جایزه نوبل است. رونالد کوز و اقتصاددانان دیگر استفادههای متعددی از این مفهوم بنیادین کردهاند…
👍6🔥2
هر چند لینک در بیو این کانال هم موجود هست ولی بنظر بد نیست یادآوری کنیم بخش زیادی از فعالیت دوستان در دیسکورد ما شکل میگیره. هر چند تلگرام هم خصوصیت تاپیک را داره ولی ترجیح ما بر اساس فاکتورهای دیگه این بود که بخشی از فعالیت را در دیسکورد هم داشته باشیم.
پس اگر دوست دارید بیشتر در موضوعات مختلف و در جلسات صوتی حضور داشته باشید و استفاده کنید، در سرور ما در دیسکورد هم عضو شوید
https://discord.gg/BZg2Xkmwku
پس اگر دوست دارید بیشتر در موضوعات مختلف و در جلسات صوتی حضور داشته باشید و استفاده کنید، در سرور ما در دیسکورد هم عضو شوید
https://discord.gg/BZg2Xkmwku
Discord
Join the Geniuses.Group Discord Server!
گروهی هدفمند و انتفاعی برای توسعه انواع پروژه ها در بخش های مختلف اجتماع با رویکرد بالاترین سطح پایداری | 355 members
🔥4👍1