پیشنهاد کتاب: معماری نرم‌افزار
پیش‌گفتار:
زمانی که ما مدرسه می‌رفتیم منابع یادگیری که مهم‌ترین آن کتاب بود بسیار محدود بود. یادم می‌آید مادرم از پس‌انداز خانواده مبلغی که در آن زمان و با آن شرایط، مبلغ واقعن زیادی بود به من داد تا با آن کتاب بخرم. من هم مجموعه‌ی چند جلدی «به من بگو چرا« را از طریق پست به ناشر آن در تهران سفارش دادم. روزها منتظر ماندم. روزی که بسته‌ی کتاب‌ها به دستم رسید گویی دنیا را به من داده‌اند. خط به خط کتاب‌ها را بارها و بارها خواندم. روحت شاد مامان جان!
اما امروز منابع یادگیری از متن، صدا و ویدیو به حدی فراوان و در دسترس است که مساله‌ی اصلی به جای دسترسی به منابع یادگیری، پیدا کردن و انتخاب منبع درست و باکیفیت است. در همین راستا در این نوشته می‌خواهم دو کتاب برای خواندن پیشنهاد کنم که برای من بسیار آموزنده و مفید بودند. اگر آنها را تاکنون نخوانده‌اید امیدوارم فرصت خواندن آنها را پیدا کنید.
گفتار:
طی چندین ماه گذشته با گروهی از دوستان خوبم دو کتاب درباره‌ی معماری نرم‌افزار خواندیم:
– Fundamentals of Software Architecture: An Engineering Approach, 2020, by Mark Richards, Neal Ford
– Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures, 2021, by Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani
کتاب اول هم‌چنان که از عنوان آن پیداست به مبانی معماری نرم‌افزار می‌پردازد. خواندن این کتاب علاوه بر مرور آنچه که از معماری می‌دانستم، دانسته‌ها‌یم را به روز کرد و با واژگان جدیدی هم آشنا نمود. نمونه این واژگان کوانتوم و کوانتا و ارتباط آنها با سیستم‌های یک تکه یا Monolithic و سیستم‌های توزیع‌شده یا Distributed است.
بر خلاف کتاب اول، بخش‌های زیادی از کتاب دوم برای من ناآشنا و نو بود. برای من مهم‌ترین یادگیری از خواندن کتاب دوم، فهم درست‌تر و دقیق‌تر سیستم‌های توزیع‌شده و به ویژه معماری مایکرو سرویس بود. دستاورد دیگر کتاب برای من، به‌روز شدن رویکرد و روش ورود به طراحی معماری یک سیستم نرم‌افزاری بود. نویسندگان تلاش زیادی برای نزدیک کردن مباحث انتزاعی به رویکردهای عملی و قابل اجرا داشتند که از نظر من تا حد زیادی هم موفق بودند.
گزیده:
Don’t try to find the best design in software architecture; instead, strive for the least worst combination of trade-offs.
Software Architecture: The Hard Parts
https://bit.ly/3Wb5dHx
https://t.me/bibalan_com
https://bibalan.com/?p=4542
پیش‌گفتار:
زمانی که ما مدرسه می‌رفتیم منابع یادگیری که مهم‌ترین آن کتاب بود بسیار محدود بود. یادم می‌آید مادرم از پس‌انداز خانواده مبلغی که در آن زمان و با آن شرایط، مبلغ واقعن زیادی بود به من داد تا با آن کتاب بخرم. من هم مجموعه‌ی چند جلدی «به من بگو چرا« را از طریق پست به ناشر آن در تهران سفارش دادم. روزها منتظر ماندم. روزی که بسته‌ی کتاب‌ها به دستم رسید گویی دنیا را به من داده‌اند. خط به خط کتاب‌ها را بارها و بارها خواندم. روحت شاد مامان جان!
اما امروز منابع یادگیری از متن، صدا و ویدیو به حدی فراوان و در دسترس است که مساله‌ی اصلی به جای دسترسی به منابع یادگیری، پیدا کردن و انتخاب منبع درست و باکیفیت است. در همین راستا در این نوشته می‌خواهم دو کتاب برای خواندن پیشنهاد کنم که برای من بسیار آموزنده و مفید بودند. اگر آنها را تاکنون نخوانده‌اید امیدوارم فرصت خواندن آنها را پیدا کنید.
گفتار:
طی چندین ماه گذشته با گروهی از دوستان خوبم دو کتاب درباره‌ی معماری نرم‌افزار خواندیم:
– Fundamentals of Software Architecture: An Engineering Approach, 2020, by Mark Richards, Neal Ford
– Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures, 2021, by Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani
کتاب اول هم‌چنان که از عنوان آن پیداست به مبانی معماری نرم‌افزار می‌پردازد. خواندن این کتاب علاوه بر مرور آنچه که از معماری می‌دانستم، دانسته‌ها‌یم را به روز کرد و با واژگان جدیدی هم آشنا نمود. نمونه این واژگان کوانتوم و کوانتا و ارتباط آنها با سیستم‌های یک تکه یا Monolithic و سیستم‌های توزیع‌شده یا Distributed است.
بر خلاف کتاب اول، بخش‌های زیادی از کتاب دوم برای من ناآشنا و نو بود. برای من مهم‌ترین یادگیری از خواندن کتاب دوم، فهم درست‌تر و دقیق‌تر سیستم‌های توزیع‌شده و به ویژه معماری مایکرو سرویس بود. دستاورد دیگر کتاب برای من، به‌روز شدن رویکرد و روش ورود به طراحی معماری یک سیستم نرم‌افزاری بود. نویسندگان تلاش زیادی برای نزدیک کردن مباحث انتزاعی به رویکردهای عملی و قابل اجرا داشتند که از نظر من تا حد زیادی هم موفق بودند.
گزیده:
Don’t try to find the best design in software architecture; instead, strive for the least worst combination of trade-offs.
Software Architecture: The Hard Parts
https://bit.ly/3Wb5dHx
https://t.me/bibalan_com
https://bibalan.com/?p=4542
برنامه نویس کاردرست
اگه از من بپرسید برنامه‌نویس کاردرست کیست خواهم گفت «برنامه‌نویس خوبی که عادتهای ممتازی دارد».
این جمله برگرفته از سخن کنت بک (Kent Beck) درباره‌ی خودش است:
«من برنامه‌نویس ممتازی نیستم. من برنامه‌نویس خوبی هستم که عادتهای ممتازی دارم»
“I’m not a great programmer; I’m just a good programmer with great habits.”
برای من این که «عادتهای ممتاز» (great habits) در برنامه‌نویسی چیست همواره جای سوال و تحقیق بوده است.
کنت بک در جایی در توضیح این جمله‌اش گفته که «تأمل (Reflection) اساسی‌ترین و اصلی‌ترین عادت است. در یک ساعت گذشته چه کارهایی کردم؟ کدوم بخش‌اش رو می‌تونستم بهتر انجام بدم؟ دفعه بعد [توی چنین شرایطی] چه کاری می‌کنم؟ تأمل مادر همه‌ی عادتهای دیگه است»
اینها برداشت‌های من است از نکاتی که کنت بک به آنها اشاره کرده است:
«در یک ساعت گذشته چه کارهایی کردم؟»: یک ساعت گذشته را ارزیابی کنم، به آن چه گذشته، دستاوردها، مسایل و مشکلات، و این که چقدر اثربخش (effective) بوده‌ام فکر کنم.
«کدوم بخش‌اش رو می‌تونستم بهتر انجام بدم؟»: کارایی یک ساعت گذشته را بررسی کنم و نسبت به جنبه‌هایی از کارم که قابل بهبود است تفکر نقادانه داشته باشم.
«دفعه بعد [توی چنین شرایطی] چه کاری می‌کنم؟» بر اساس تجربهای که کسب کردم، کدام بخش از کار رو به شکل دیگری انجام و بهبود خواهم داد و برای انجام آن از چه تکنیک‌ها یا متدهای جدیدی استفاده خواهم کرد.
او حرف‌هایش رو به این شکل ادامه می‌دهد: «من موقعی که با وارد کانینگهام (Ward Cunningham) کار می‌کردم چیزهای فوق‌العاده‌ای به خاطر استفاده از «تامل» (Reflection) یاد گرفتم. ما هر روز صبح توی کافه‌تریا تک‌ترونیکس با هم قهوه می‌خوردیم، به تپه‌های اطراف نگاه می‌کردیم و درباره‌ی این که کارها چه جوری داره پیش می‌ره صحبت می‌کردیم.»
و در پایان کنت بک اشاره می‌کند که «اساسن کتاب‌های من این عادت‌ها را بیان می‌کنند:
- کدنویسی برای دیگران
- کار در قالب گام‌های کوچک
- استراحت کافی».
گزیده:
ما از تجربه چیزی یاد نمی‌گیریم، ما با فکر کردن و تامل (Reflection) درباره‌ی تجربهها یاد می‌گیریم.
جان دیویی فیلسوف آمریکایی
پ.ن. من کمی درباره‌ی واژه Reflection هم تحقیق کردم که بتونم برگردان مناسبی برای اون پیدا کنم. دوستانم در گروه «برابریابی برای واژه‌های تخصصی» برگردان‌های بازتاب، بازاندیشی، تعمق، تامل، غور و ژرف‌نگری را پیشنهاد کردند و من واژه‌ی تامل را از بین انتخاب کردم.
https://bit.ly/4d91AsD
https://t.me/bibalan_com
https://bibalan.com/?p=4549
اگه از من بپرسید برنامه‌نویس کاردرست کیست خواهم گفت «برنامه‌نویس خوبی که عادتهای ممتازی دارد».
این جمله برگرفته از سخن کنت بک (Kent Beck) درباره‌ی خودش است:
«من برنامه‌نویس ممتازی نیستم. من برنامه‌نویس خوبی هستم که عادتهای ممتازی دارم»
“I’m not a great programmer; I’m just a good programmer with great habits.”
برای من این که «عادتهای ممتاز» (great habits) در برنامه‌نویسی چیست همواره جای سوال و تحقیق بوده است.
کنت بک در جایی در توضیح این جمله‌اش گفته که «تأمل (Reflection) اساسی‌ترین و اصلی‌ترین عادت است. در یک ساعت گذشته چه کارهایی کردم؟ کدوم بخش‌اش رو می‌تونستم بهتر انجام بدم؟ دفعه بعد [توی چنین شرایطی] چه کاری می‌کنم؟ تأمل مادر همه‌ی عادتهای دیگه است»
اینها برداشت‌های من است از نکاتی که کنت بک به آنها اشاره کرده است:
«در یک ساعت گذشته چه کارهایی کردم؟»: یک ساعت گذشته را ارزیابی کنم، به آن چه گذشته، دستاوردها، مسایل و مشکلات، و این که چقدر اثربخش (effective) بوده‌ام فکر کنم.
«کدوم بخش‌اش رو می‌تونستم بهتر انجام بدم؟»: کارایی یک ساعت گذشته را بررسی کنم و نسبت به جنبه‌هایی از کارم که قابل بهبود است تفکر نقادانه داشته باشم.
«دفعه بعد [توی چنین شرایطی] چه کاری می‌کنم؟» بر اساس تجربهای که کسب کردم، کدام بخش از کار رو به شکل دیگری انجام و بهبود خواهم داد و برای انجام آن از چه تکنیک‌ها یا متدهای جدیدی استفاده خواهم کرد.
او حرف‌هایش رو به این شکل ادامه می‌دهد: «من موقعی که با وارد کانینگهام (Ward Cunningham) کار می‌کردم چیزهای فوق‌العاده‌ای به خاطر استفاده از «تامل» (Reflection) یاد گرفتم. ما هر روز صبح توی کافه‌تریا تک‌ترونیکس با هم قهوه می‌خوردیم، به تپه‌های اطراف نگاه می‌کردیم و درباره‌ی این که کارها چه جوری داره پیش می‌ره صحبت می‌کردیم.»
و در پایان کنت بک اشاره می‌کند که «اساسن کتاب‌های من این عادت‌ها را بیان می‌کنند:
- کدنویسی برای دیگران
- کار در قالب گام‌های کوچک
- استراحت کافی».
گزیده:
ما از تجربه چیزی یاد نمی‌گیریم، ما با فکر کردن و تامل (Reflection) درباره‌ی تجربهها یاد می‌گیریم.
جان دیویی فیلسوف آمریکایی
پ.ن. من کمی درباره‌ی واژه Reflection هم تحقیق کردم که بتونم برگردان مناسبی برای اون پیدا کنم. دوستانم در گروه «برابریابی برای واژه‌های تخصصی» برگردان‌های بازتاب، بازاندیشی، تعمق، تامل، غور و ژرف‌نگری را پیشنهاد کردند و من واژه‌ی تامل را از بین انتخاب کردم.
https://bit.ly/4d91AsD
https://t.me/bibalan_com
https://bibalan.com/?p=4549
چگونه برنامه‌نویس خوبی شوم
پرسش: چه چیزی از یک برنامه‌نویس، یک برنامه‌نویس «خوب» می‌سازه؟
کنت بک: پاسخ این پرسش راحته. «خودت باش» (Be Yourself).
تنها یه بازی [چالش] در کل دنیا وجود داره و اون هم اینه:«تمام تلاشت رو بکن» (Do Your Best). ورزش، کار، روابط انسانی فقط سایه‌هایی از همین «یه بازی»اند. برنامه‌نویسی هم همین طور.
سوال اینه که به عنوان یک برنامه‌نویس تا چه حدی تونستید از حداکثر توان و پتانسیل خودتون استفاده کنید؟ اگر می‌تونید تقریبا بخش زیادی از توان‌تون رو استفاده بکنید، شما برنامه‌نویس خوبی هستید.»
گزیده:
برنامه‌نویس خوب کسی است که موقع رد شدن از یک خیابان یک طرفه همیشه هر دو طرف را نگاه می‌کند. ☺
داگ لیندر
متن انگلیسی نوشته:
What makes a programmer “good?”
This is an easy one. Be yourself. There is only one game in the whole world. It’s called Do Your Best. Sports, careers, relationships are all shadows of the One Game. Programming, too. How close have you come to your full potential as a programmer? If you get kind of close, you’re good.
https://bit.ly/4fHYCxg
https://t.me/bibalan_com
https://bibalan.com/?p=4571
پرسش: چه چیزی از یک برنامه‌نویس، یک برنامه‌نویس «خوب» می‌سازه؟
کنت بک: پاسخ این پرسش راحته. «خودت باش» (Be Yourself).
تنها یه بازی [چالش] در کل دنیا وجود داره و اون هم اینه:«تمام تلاشت رو بکن» (Do Your Best). ورزش، کار، روابط انسانی فقط سایه‌هایی از همین «یه بازی»اند. برنامه‌نویسی هم همین طور.
سوال اینه که به عنوان یک برنامه‌نویس تا چه حدی تونستید از حداکثر توان و پتانسیل خودتون استفاده کنید؟ اگر می‌تونید تقریبا بخش زیادی از توان‌تون رو استفاده بکنید، شما برنامه‌نویس خوبی هستید.»
گزیده:
برنامه‌نویس خوب کسی است که موقع رد شدن از یک خیابان یک طرفه همیشه هر دو طرف را نگاه می‌کند. ☺
داگ لیندر
متن انگلیسی نوشته:
What makes a programmer “good?”
This is an easy one. Be yourself. There is only one game in the whole world. It’s called Do Your Best. Sports, careers, relationships are all shadows of the One Game. Programming, too. How close have you come to your full potential as a programmer? If you get kind of close, you’re good.
https://bit.ly/4fHYCxg
https://t.me/bibalan_com
https://bibalan.com/?p=4571
جزوه دوره تحلیل نیازمندی‌ها
پیش‌گفتار: دوره تحلیل نیازمندی‌ها
https://bit.ly/4fROpym
برای سالها، دوره‌ای تدریس می‌کردم با عنوان روش کاربردی تحلیل نیازمندی‌های نرم‌افزار (Software Requirements Analysis: A Practical Approach). این دوره را مثل بقیه دوره‌هایی که تدریس می‌کردم خیلی دوست داشتم. حس بسیار خوبی داشتم وقتی سر کلاس حاضر می‌شدم. دلم برای کلاس و شاگردهایم خیلی تنگ می‌شود. یادش به خیر.
در بعضی از دوره‌ها، چند تایی از دانشجویان بسیار خوش‌خط و بسیار باحوصله جزوه می‌نوشتند. پایان دوره از آنها خواهش می‌کردم اگر برای‌شان مقدور است نسخه‌ای از آن را در اختیار من هم قرار بدهند. چند روز پیش اتفاقی یکی از این جزوه‌ها را دوباره دیدم و خواندم. حس جالبی داشتم. موضوع خنده‌دار هم این بود که بخشی از مطالب دوره را فراموش کرده بودم. 😉 با خودم فکر کردم به جای آن که این فایل‌ها در فولدرهای آرشیوی کامپیوترم خاک دیجیتال بخورد، بهتر است این «برگ سبز تحفه‌ی درویش» را منتشر کنم به این امید که شاید برای عزیزی در جایی از این دنیای پهناور مفید باشد.
گفتار: جزوه درس تحلیل نیازمندی‌ها
جزوه‌ای که اینجا منتشر شده را آقای امیر سوکی نوشته‌اند. آقای سوکی عزیز، جزوه دست‌نویس‌شان را با تایپ کرده‌اند و نمودارها را با ابزار ترسیم و به آن اضافه کرده‌اند. ضمن قدردانی بسیار زیاد از این محبت و کار ارزشمند آقای سوکی و آرزوی بهترین‌ها برای‌شان، این جزوه به پیوست تقدیم شده است.
گزیده:
یادداشت‌برداری تجربهها را به خاطراتی تبدیل می‌کنند که درک و فهم ما از دنیا را شکل می‌دهند.»
والتر آیزاک‌سون، مورخ آمریکایی
پیش‌گفتار: دوره تحلیل نیازمندی‌ها
https://bit.ly/4fROpym
برای سالها، دوره‌ای تدریس می‌کردم با عنوان روش کاربردی تحلیل نیازمندی‌های نرم‌افزار (Software Requirements Analysis: A Practical Approach). این دوره را مثل بقیه دوره‌هایی که تدریس می‌کردم خیلی دوست داشتم. حس بسیار خوبی داشتم وقتی سر کلاس حاضر می‌شدم. دلم برای کلاس و شاگردهایم خیلی تنگ می‌شود. یادش به خیر.
در بعضی از دوره‌ها، چند تایی از دانشجویان بسیار خوش‌خط و بسیار باحوصله جزوه می‌نوشتند. پایان دوره از آنها خواهش می‌کردم اگر برای‌شان مقدور است نسخه‌ای از آن را در اختیار من هم قرار بدهند. چند روز پیش اتفاقی یکی از این جزوه‌ها را دوباره دیدم و خواندم. حس جالبی داشتم. موضوع خنده‌دار هم این بود که بخشی از مطالب دوره را فراموش کرده بودم. 😉 با خودم فکر کردم به جای آن که این فایل‌ها در فولدرهای آرشیوی کامپیوترم خاک دیجیتال بخورد، بهتر است این «برگ سبز تحفه‌ی درویش» را منتشر کنم به این امید که شاید برای عزیزی در جایی از این دنیای پهناور مفید باشد.
گفتار: جزوه درس تحلیل نیازمندی‌ها
جزوه‌ای که اینجا منتشر شده را آقای امیر سوکی نوشته‌اند. آقای سوکی عزیز، جزوه دست‌نویس‌شان را با تایپ کرده‌اند و نمودارها را با ابزار ترسیم و به آن اضافه کرده‌اند. ضمن قدردانی بسیار زیاد از این محبت و کار ارزشمند آقای سوکی و آرزوی بهترین‌ها برای‌شان، این جزوه به پیوست تقدیم شده است.
گزیده:
یادداشت‌برداری تجربهها را به خاطراتی تبدیل می‌کنند که درک و فهم ما از دنیا را شکل می‌دهند.»
والتر آیزاک‌سون، مورخ آمریکایی
پیراهن تیم توسعه‌ی نرم‌افزار
https://bit.ly/3z6YFlG
لوچانو اسپالتی، سرمربی تیم ملی فوتبال ایتالیا در مصاحبه‌ی اخیر خود (اینجا) در پاسخ به پرسشی در مورد دلایل ناکامی تیم ایتالیا در مسابقات یورو ۲۰۲۴ و نقش بازیکنان در این ناکامی گفته بود: «هر اتفاقی که بیفتد صددرصد به عهده من است، در این صورت ممکن است یک درصد تقصیر را به گردن کادرم بیندازم، اما بازیکنان از این موضوع معاف هستند. احتمالاً فشار زیادی به آنها وارد کردم و این فرصت را ندادم که از تجربه بازی با پیراهن ایتالیا لذت ببرند. »
جالب‌ترین بخش این مصاحبه برای من این جمله بود: «این فرصت را ندادم که از تجربه بازی با پیراهن ایتالیا لذت ببرند».
اوه! به این موضوع فکر کردم که ما هم به عنوان بازیکن یا مدیر یک تیم نرم‌افزاری فرصت لذت بردن از پیراهن تیم «توسعه‌ی نرم‌افزار» را نداریم یا به بازیکنان تیم‌مان نمی‌دهیم.
می‌دانم! می‌دانم! هزاران دلیل درست برای «نبودن»اش وجود دارد، ولی برای «بودن»اش لازم نیست دنبال دلیلی باشیم. همه‌ی ما میدانیم که «باید» باشد. پس بسم‌الله!
به یاد دارم که در کلاس‌ها در کنار محتوای دوره، یک سری ویدیوی کوتاه و نامرتبط به دوره پخش می‌کردم و از دانشجویانم می‌خواستم آن را با هم ببینیم و بعد کمی درباره‌اش با هم گپ بزنیم. یکی از این ویدیوها، سخنرانی شان آکر با عنوان «The happy secret to better work» بود. پیشنهاد می‌کنم شما هم آن را ببینید. می‌توانید ویدیو را با زیرنویس فارسی هم ببینید.
The happy secret to better work, Shawn Achor, 26,363,163 views
https://bit.ly/4ghuXeA
گزیده:
خیلی‌ها این جمله را به شما می‌گویند. از زمانی که مربی‌گری را با مربی‌گری خردسالان شروع کردم این جمله را بارها و بارها شنیده‌ام: «تنها چیزی که مهمه برنده شدنه». من مخالف این جمله‌ام. چیزی که واقعن اهمیت داره فوتبال با کیفیت بازی کردنه.
پ.ن.
پیش‌نویس این نوشته را آماده کرده بودم و می‌خواستم بعدها منتشر کنم. ولی پیروزی ایتالیا بر فرانسه در بازی امروز، انتشار آن را به جلو انداخت. 😃
منبع مصاحبه: ورزش ۳
https://bit.ly/3AV7Mq4
https://t.me/bibalan_com
https://bibalan.com/?p=4618
https://bit.ly/3z6YFlG
لوچانو اسپالتی، سرمربی تیم ملی فوتبال ایتالیا در مصاحبه‌ی اخیر خود (اینجا) در پاسخ به پرسشی در مورد دلایل ناکامی تیم ایتالیا در مسابقات یورو ۲۰۲۴ و نقش بازیکنان در این ناکامی گفته بود: «هر اتفاقی که بیفتد صددرصد به عهده من است، در این صورت ممکن است یک درصد تقصیر را به گردن کادرم بیندازم، اما بازیکنان از این موضوع معاف هستند. احتمالاً فشار زیادی به آنها وارد کردم و این فرصت را ندادم که از تجربه بازی با پیراهن ایتالیا لذت ببرند. »
جالب‌ترین بخش این مصاحبه برای من این جمله بود: «این فرصت را ندادم که از تجربه بازی با پیراهن ایتالیا لذت ببرند».
اوه! به این موضوع فکر کردم که ما هم به عنوان بازیکن یا مدیر یک تیم نرم‌افزاری فرصت لذت بردن از پیراهن تیم «توسعه‌ی نرم‌افزار» را نداریم یا به بازیکنان تیم‌مان نمی‌دهیم.
می‌دانم! می‌دانم! هزاران دلیل درست برای «نبودن»اش وجود دارد، ولی برای «بودن»اش لازم نیست دنبال دلیلی باشیم. همه‌ی ما میدانیم که «باید» باشد. پس بسم‌الله!
به یاد دارم که در کلاس‌ها در کنار محتوای دوره، یک سری ویدیوی کوتاه و نامرتبط به دوره پخش می‌کردم و از دانشجویانم می‌خواستم آن را با هم ببینیم و بعد کمی درباره‌اش با هم گپ بزنیم. یکی از این ویدیوها، سخنرانی شان آکر با عنوان «The happy secret to better work» بود. پیشنهاد می‌کنم شما هم آن را ببینید. می‌توانید ویدیو را با زیرنویس فارسی هم ببینید.
The happy secret to better work, Shawn Achor, 26,363,163 views
https://bit.ly/4ghuXeA
گزیده:
خیلی‌ها این جمله را به شما می‌گویند. از زمانی که مربی‌گری را با مربی‌گری خردسالان شروع کردم این جمله را بارها و بارها شنیده‌ام: «تنها چیزی که مهمه برنده شدنه». من مخالف این جمله‌ام. چیزی که واقعن اهمیت داره فوتبال با کیفیت بازی کردنه.
پ.ن.
پیش‌نویس این نوشته را آماده کرده بودم و می‌خواستم بعدها منتشر کنم. ولی پیروزی ایتالیا بر فرانسه در بازی امروز، انتشار آن را به جلو انداخت. 😃
منبع مصاحبه: ورزش ۳
https://bit.ly/3AV7Mq4
https://t.me/bibalan_com
https://bibalan.com/?p=4618
آقای دکتر و انتخابات ریاست جمهوری آمریکا
پیش گفتار:
بخش بزرگی از یادگیری‌های ما از تجربه است. تجربه‌هایی که در هیچ کتاب یا منبعی پیدا نمی‌شود. آموخته‌هایی که وقتی آنها را تجربه می‌کنید تازه بخش عمده‌ای از آموخته‌های نظری و تئوری جایگاه خود در مغز شما پیدا می‌کنند. در این نوشته می‌خواهم یکی از این تجربهها را بازگو کنم. تجربهای که در هیچ کتاب و کلاسی نمی‌توانستم آن را یاد بگیرم و اگر هم یاد می‌گرفتم خیلی زود فراموش می‌کردم.
انتخابات ۲۰۱۶ آمریکا:
در چنین روزهایی در سال ۲۰۱۶ برابر با ۱۳۹۵ خورشیدی، انتخابات ریاست جمهوری آمریکا برگزار شد. دو نماینده، آقای دونالد ترامپ و خانم هیلاری کلینتون با هم رقابت می‌کردند. پیش‌بینی‌ها در ایران از این حکایت از پیروزی خانم کلینتون می‌کرد. ولی به هر حال در هفته‌های پایانی رقابت شدید‌تر شده بود.
آن موقع مشاور یک نهاد مالی بودم که کارگزار بورس ایران بود. تعداد زیادی از خبرگان بازار سرمایه و تحلیل‌گران هم در آن نهاد مشغول به کار بودند یا آنجا رفت و آمد می‌کردند. تا جایی که خاطرم هست پیش‌بینی همکاران و فعالان آن نهاد مالی این بود که خانم کلینتون برنده این رقابت خواهد بود. ولی همان طور که گفتم هفته‌های پایانی همه چیز پیچیده‌تر شده بود.
در بین خبرگان بازار سرمایه و تحلیل‌گرانی که آنها را آنجا ملاقات می‌کردم انسان نازنینی بود که ایشان را در این نوشته «آقای دکتر» خواهم نامید. آقای دکتر استاد من نیز بودند که آن موقع مشغول تحصیل در رشته‌ی مدیریت مالی بودم. فرد بسیار با تجربه، با شخصیت، با سواد و با لیست بلند بالایی از سمت‌های اجرایی و علمی. از خوش‌شانسی‌های من در زندگی کاری و آموزشی‌ام، آشنایی و شاگردی آقای دکتر بود.
فردای روزی که نتایج انتخابات اعلام شد و آقای ترامپ برنده‌ی انتخاب اعلام شد، نقشه‌ی بازار (نموداری که رنگ قرمز نشان‌دهنده کاهش قیمت‌ها و سبز نشان‌دهنده‌ی افزایش قیمت است) سراسر قرمز بود! فعالان بازار در آن نهاد مالی نگران بودند هم به دلیل زیان سبد سرمایه‌گذاری‌شان و هم نگرانی از ریزش بورس در روزها، هفته‌ها و ماه‌های آینده.
عصر همان روز که نتیجه‌ی انتخابات اعلام شد و همه با نگرانی مشغول بحث و تحلیل بودند، برای کاری رفته بودم خدمت آقای دکتر. یادم نیست چه کاری با ایشان داشتم ولی در میانه‌ی صحبت از آقای دکتر پرسیدم که آیا شما هم به دلیل ریزش بورس متحمل زیان شدید؟
پاسخی که انتظار داشتم این بود که «بله، من هم مثل بقیه دچار زیان شدم و اصلن فکر نمی‌کردم که هیلاری کلینتون بازنده‌ی انتخابات بشه».
چهره‌ی آقای دکتر موقع پاسخ به سوالم هنوز در حافظه‌ام باقی مانده. با آرامش خاصی که ویژه‌ی خودشان بود شروع به صحبت کرد. گفته‌هایشان را دقیق به خاطر ندارم ولی مضمون گفته‌های ایشان این بود: «نه من تا هفته‌ی پیش همه‌ی سهم‌ها رو فروختم و فقط بیست درصدشان را نگه داشتم.» «من که تحلیل‌گر سیاسی نیستم و نمی‌دونم چه کسی رییس جمهور می‌شه» «با خودم گفتم اگه کلینتون برنده‌ی انتخابات شد و سهم‌ها گرون شد می‌رم گرون‌تر می‌خرم و بعد هم گرون‌تر می‌فروشم» و »اگه هم که ترامپ شد من ضرر نمی‌کنم»
برای لحظاتی در دنیای موازی ذهن‌ام به گفته‌های استاد فکر می‌کردم و هم‌زمان در این دنیا، مات و مبهوت این نوع نگاه «حرفه‌ای» و به دور از «توهم پیش‌بینی» آقای دکتر بودم.
همه‌ی آن چه که در کلاس درس از آقای دکتر یاد گرفته بودم به یک طرف، این لحظه‌ی تاریخی هم به یک طرف. می‌توانم چندین صفحه درباره‌ی این که این شوک ذهنی چه تعداد از آموخته‌های نظری‌ام را در جای درست در پازل یادگیری‌ام قرار داد بنویسم. آن لحظه برای من یک لحظه‌ی «تغییر پارادایم» بود!
برای استاد عزیزم، آقای دکتر نازنین، بهترین‌ها را آرزومندم و امیدوارم که هر جا که هستند تندرست، شاد و پیروز باشند.
گزیده:
برای پول درآوردن نیازی نیست بدانید که قرار است چه اتفاقی بیفتد.
ثباتی که شما به دنبال آن هستید در ذهن شماست، نه در بازار.
مایکل داگلاس،
از افراد مشهور در روان‌شناسی خرید و فروش (ترید)
https://t.me/bibalan_com
https://bibalan.com/?p=4633
https://bit.ly/3CjjgEC
پیش گفتار:
بخش بزرگی از یادگیری‌های ما از تجربه است. تجربه‌هایی که در هیچ کتاب یا منبعی پیدا نمی‌شود. آموخته‌هایی که وقتی آنها را تجربه می‌کنید تازه بخش عمده‌ای از آموخته‌های نظری و تئوری جایگاه خود در مغز شما پیدا می‌کنند. در این نوشته می‌خواهم یکی از این تجربهها را بازگو کنم. تجربهای که در هیچ کتاب و کلاسی نمی‌توانستم آن را یاد بگیرم و اگر هم یاد می‌گرفتم خیلی زود فراموش می‌کردم.
انتخابات ۲۰۱۶ آمریکا:
در چنین روزهایی در سال ۲۰۱۶ برابر با ۱۳۹۵ خورشیدی، انتخابات ریاست جمهوری آمریکا برگزار شد. دو نماینده، آقای دونالد ترامپ و خانم هیلاری کلینتون با هم رقابت می‌کردند. پیش‌بینی‌ها در ایران از این حکایت از پیروزی خانم کلینتون می‌کرد. ولی به هر حال در هفته‌های پایانی رقابت شدید‌تر شده بود.
آن موقع مشاور یک نهاد مالی بودم که کارگزار بورس ایران بود. تعداد زیادی از خبرگان بازار سرمایه و تحلیل‌گران هم در آن نهاد مشغول به کار بودند یا آنجا رفت و آمد می‌کردند. تا جایی که خاطرم هست پیش‌بینی همکاران و فعالان آن نهاد مالی این بود که خانم کلینتون برنده این رقابت خواهد بود. ولی همان طور که گفتم هفته‌های پایانی همه چیز پیچیده‌تر شده بود.
در بین خبرگان بازار سرمایه و تحلیل‌گرانی که آنها را آنجا ملاقات می‌کردم انسان نازنینی بود که ایشان را در این نوشته «آقای دکتر» خواهم نامید. آقای دکتر استاد من نیز بودند که آن موقع مشغول تحصیل در رشته‌ی مدیریت مالی بودم. فرد بسیار با تجربه، با شخصیت، با سواد و با لیست بلند بالایی از سمت‌های اجرایی و علمی. از خوش‌شانسی‌های من در زندگی کاری و آموزشی‌ام، آشنایی و شاگردی آقای دکتر بود.
فردای روزی که نتایج انتخابات اعلام شد و آقای ترامپ برنده‌ی انتخاب اعلام شد، نقشه‌ی بازار (نموداری که رنگ قرمز نشان‌دهنده کاهش قیمت‌ها و سبز نشان‌دهنده‌ی افزایش قیمت است) سراسر قرمز بود! فعالان بازار در آن نهاد مالی نگران بودند هم به دلیل زیان سبد سرمایه‌گذاری‌شان و هم نگرانی از ریزش بورس در روزها، هفته‌ها و ماه‌های آینده.
عصر همان روز که نتیجه‌ی انتخابات اعلام شد و همه با نگرانی مشغول بحث و تحلیل بودند، برای کاری رفته بودم خدمت آقای دکتر. یادم نیست چه کاری با ایشان داشتم ولی در میانه‌ی صحبت از آقای دکتر پرسیدم که آیا شما هم به دلیل ریزش بورس متحمل زیان شدید؟
پاسخی که انتظار داشتم این بود که «بله، من هم مثل بقیه دچار زیان شدم و اصلن فکر نمی‌کردم که هیلاری کلینتون بازنده‌ی انتخابات بشه».
چهره‌ی آقای دکتر موقع پاسخ به سوالم هنوز در حافظه‌ام باقی مانده. با آرامش خاصی که ویژه‌ی خودشان بود شروع به صحبت کرد. گفته‌هایشان را دقیق به خاطر ندارم ولی مضمون گفته‌های ایشان این بود: «نه من تا هفته‌ی پیش همه‌ی سهم‌ها رو فروختم و فقط بیست درصدشان را نگه داشتم.» «من که تحلیل‌گر سیاسی نیستم و نمی‌دونم چه کسی رییس جمهور می‌شه» «با خودم گفتم اگه کلینتون برنده‌ی انتخابات شد و سهم‌ها گرون شد می‌رم گرون‌تر می‌خرم و بعد هم گرون‌تر می‌فروشم» و »اگه هم که ترامپ شد من ضرر نمی‌کنم»
برای لحظاتی در دنیای موازی ذهن‌ام به گفته‌های استاد فکر می‌کردم و هم‌زمان در این دنیا، مات و مبهوت این نوع نگاه «حرفه‌ای» و به دور از «توهم پیش‌بینی» آقای دکتر بودم.
همه‌ی آن چه که در کلاس درس از آقای دکتر یاد گرفته بودم به یک طرف، این لحظه‌ی تاریخی هم به یک طرف. می‌توانم چندین صفحه درباره‌ی این که این شوک ذهنی چه تعداد از آموخته‌های نظری‌ام را در جای درست در پازل یادگیری‌ام قرار داد بنویسم. آن لحظه برای من یک لحظه‌ی «تغییر پارادایم» بود!
برای استاد عزیزم، آقای دکتر نازنین، بهترین‌ها را آرزومندم و امیدوارم که هر جا که هستند تندرست، شاد و پیروز باشند.
گزیده:
برای پول درآوردن نیازی نیست بدانید که قرار است چه اتفاقی بیفتد.
ثباتی که شما به دنبال آن هستید در ذهن شماست، نه در بازار.
مایکل داگلاس،
از افراد مشهور در روان‌شناسی خرید و فروش (ترید)
https://t.me/bibalan_com
https://bibalan.com/?p=4633
https://bit.ly/3CjjgEC
Telegram
سماموس: نوشته‌های یوسف مهرداد بی‌بالان
این کانال برای اطلاع‌رسانی نوشته‌های وبلاگ سماموس (bibalan.com) ایجاد شده است. مطالب پس از انتشار در وبلاگ، در این کانال نیز منتشر خواهد شد. امیدوارم که مطالب آن برای شما مفید باشد و خوشحال خواهم شد تا نظرات و بازخوردهای شما عزیزان را دریافت کنم.
نرم‌افزار بی‌نقص و کامل
شما نمی تونید نرم افزاری بنویسید که بی‌نقض و کامل باشه. این موضوع شما رو ناراحت می‌کنه؟ خوب، نباید ناراحت بشید. این موضوع رو به عنوان یکی از واقعیات زندگی بپذیرید. با اون کنار بیایید. با اون خوش باشید. زیرا نرم‌افزار بی‌نقص و کامل وجود نداره. هیچ کس در تاریخ کوتاه کامپیوتر، نرم‌افزاری کامل و بی‌نقص ننوشته. بعیده که شما اولین نفری باشید که این کار رو کرده. و اگه این موضوع رو به عنوان یک واقعیت نپذیرید، زمان و انرژی خودتون رو برای دنبال کردن یک رویای ناممکن تلف خواهید کرد.
اندرو هانت نویسنده کتاب The Pragmatic Programmer
https://t.me/bibalan_com
https://bibalan.com/?p=4593
شما نمی تونید نرم افزاری بنویسید که بی‌نقض و کامل باشه. این موضوع شما رو ناراحت می‌کنه؟ خوب، نباید ناراحت بشید. این موضوع رو به عنوان یکی از واقعیات زندگی بپذیرید. با اون کنار بیایید. با اون خوش باشید. زیرا نرم‌افزار بی‌نقص و کامل وجود نداره. هیچ کس در تاریخ کوتاه کامپیوتر، نرم‌افزاری کامل و بی‌نقص ننوشته. بعیده که شما اولین نفری باشید که این کار رو کرده. و اگه این موضوع رو به عنوان یک واقعیت نپذیرید، زمان و انرژی خودتون رو برای دنبال کردن یک رویای ناممکن تلف خواهید کرد.
اندرو هانت نویسنده کتاب The Pragmatic Programmer
https://t.me/bibalan_com
https://bibalan.com/?p=4593
Telegram
سماموس: نوشته‌های یوسف مهرداد بی‌بالان
این کانال برای اطلاع‌رسانی نوشته‌های وبلاگ سماموس (bibalan.com) ایجاد شده است. مطالب پس از انتشار در وبلاگ، در این کانال نیز منتشر خواهد شد. امیدوارم که مطالب آن برای شما مفید باشد و خوشحال خواهم شد تا نظرات و بازخوردهای شما عزیزان را دریافت کنم.
شوک‌های ذهنی! (بخش ۱)
پیش‌گفتار:
نمی‌دانم از چه زمانی به این نتیجه رسیدم برخی از واژگانی که در ذهنم با یکدیگر ارتباط معنایی درستی دارند، با تغییر شرایط و موضوع (کانتکست)، نه تنها ارتباط بین آنها تغییر می‌کند بلکه گاهی هیچ ارتباطی بین آنها پیدا نمی‌شود. متوجه شدم که در چنین فضایی، اصرار به حفظ ارتباط قبلی بین واژگان و مفاهیم، مرا به بیراهه خواهد برد. به گذشته که نگاه می‌کنم این بیراهه‌ها گاهی به ناکجا آباد رسیده است.
در چند نوشته آتی می‌خواهم چند نمونه از آنها را بیان کنم.
نمونه ۱: رابطه سرما و گرما
در درس فیزیک یاد گرفتم که سرما همان نبود گرما است. هستی یکی معادل با نیستی دیگری است. و یاد گرفتم که برای افزایش سرما لازم است گرما را کم کنیم. به عبارت ساده‌تر کاهش یک عامل با افزایش عامل دیگر همراه است.
شوک ۱: افزایش قطعیت منجر به کاهش عدم قطعیت نمی‌شود!
وقتی با مفهوم قطعیت و عدم قطعیت آشنا شدم رابطه بین آن را همان رابطه‌ی بین گرما و سرما می‌دیدم. برای من بدیهی بود که قطعیت و عدم قطعیت (شرایط غیرقطعی) مثل رابطه سرما و گرما است. افزایش یکی یعنی کاهش دیگری! اگه می‌خواهید میزان عدم قطعیت را کاهش دهید باید میزان قطعیت را افزایش دهید.
مدتی طول کشید تا با یک شوک بنیان کن به این نتیجه برسم که برداشت ذهنی من کاملن نادرست است. شما نمی‌توانید با افزایش قطعیت، عدم قطعیت (شرایط غیرقطعی) موجود را کاهش بدهید! (فکر کنم شما هم دچار شوک ذهنی شدید 🙂 )
برای نمونه شما نمی‌توانید با افزایش قطعیت در برنامه‌ریزی میزان عدم قطعیت آن را کاهش دهید.
پس‌گفتار:
هنوز هم نمی‌دانم درست کدام است!
گزیده:
زهی دریای بی‌ساحل پر از ماهی درون دل
چنین دریا ندیدستم چنین ماهی نمی‌دانم
https://t.me/bibalan_com
https://bibalan.com/?p=4644
پیش‌گفتار:
نمی‌دانم از چه زمانی به این نتیجه رسیدم برخی از واژگانی که در ذهنم با یکدیگر ارتباط معنایی درستی دارند، با تغییر شرایط و موضوع (کانتکست)، نه تنها ارتباط بین آنها تغییر می‌کند بلکه گاهی هیچ ارتباطی بین آنها پیدا نمی‌شود. متوجه شدم که در چنین فضایی، اصرار به حفظ ارتباط قبلی بین واژگان و مفاهیم، مرا به بیراهه خواهد برد. به گذشته که نگاه می‌کنم این بیراهه‌ها گاهی به ناکجا آباد رسیده است.
در چند نوشته آتی می‌خواهم چند نمونه از آنها را بیان کنم.
نمونه ۱: رابطه سرما و گرما
در درس فیزیک یاد گرفتم که سرما همان نبود گرما است. هستی یکی معادل با نیستی دیگری است. و یاد گرفتم که برای افزایش سرما لازم است گرما را کم کنیم. به عبارت ساده‌تر کاهش یک عامل با افزایش عامل دیگر همراه است.
شوک ۱: افزایش قطعیت منجر به کاهش عدم قطعیت نمی‌شود!
وقتی با مفهوم قطعیت و عدم قطعیت آشنا شدم رابطه بین آن را همان رابطه‌ی بین گرما و سرما می‌دیدم. برای من بدیهی بود که قطعیت و عدم قطعیت (شرایط غیرقطعی) مثل رابطه سرما و گرما است. افزایش یکی یعنی کاهش دیگری! اگه می‌خواهید میزان عدم قطعیت را کاهش دهید باید میزان قطعیت را افزایش دهید.
مدتی طول کشید تا با یک شوک بنیان کن به این نتیجه برسم که برداشت ذهنی من کاملن نادرست است. شما نمی‌توانید با افزایش قطعیت، عدم قطعیت (شرایط غیرقطعی) موجود را کاهش بدهید! (فکر کنم شما هم دچار شوک ذهنی شدید 🙂 )
برای نمونه شما نمی‌توانید با افزایش قطعیت در برنامه‌ریزی میزان عدم قطعیت آن را کاهش دهید.
پس‌گفتار:
هنوز هم نمی‌دانم درست کدام است!
گزیده:
زهی دریای بی‌ساحل پر از ماهی درون دل
چنین دریا ندیدستم چنین ماهی نمی‌دانم
https://t.me/bibalan_com
https://bibalan.com/?p=4644
Telegram
سماموس: نوشته‌های یوسف مهرداد بی‌بالان
این کانال برای اطلاع‌رسانی نوشته‌های وبلاگ سماموس (bibalan.com) ایجاد شده است. مطالب پس از انتشار در وبلاگ، در این کانال نیز منتشر خواهد شد. امیدوارم که مطالب آن برای شما مفید باشد و خوشحال خواهم شد تا نظرات و بازخوردهای شما عزیزان را دریافت کنم.
شوک‌های ذهنی! (بخش ۲)
نمونه ۲:
از مبحث بازخورد (فیدبک) در مدارهای الکتریکی آموخته بودم که که بازخورد دو نوع است: بازخورد مثبت و بازخورد منفی. بازخورد مثبت باعث افزایش و بهبود خروجی سیستم می‌شود و بازخورد منفی باعث کاهش خروجی سیستم. وقتی شما به یک فرد دیگر بازخورد می‌دهید، یا بازخوردتان مثبت است (تعریف و تمجید می‌کنید) یا بازخوردتان منفی است (نقد می‌کنید و ایراد می‌گیرید).
شوک ۲: بازخورد منفی کو؟
همان طور که گفتم بر اساس آموخته‌های درس مدارهای الکتریکی باورم این بود که بازخورد افراد به همدیگر یا بازخورد مثبت است یا بازخورد منفی! تا این که به صورت کاملن اتفاقی ویدیویی از یک کلاس آموزشی در کورسرا دیدم که استاد درس پیش از اعلام اولین تمرین درس، کمی در مورد بازخورد صحبت کرد. او می‌گفت که بازخوردهای شما یا باید مثبت باشد یا سازنده. پس از شنیدن این صحبت‌ها دچار این شوک ذهنی شدم و از خود می‌پرسیدم که پس بازخورد منفی کجا رفت! اثر این شوک ذهنی نه‌تنها بر ذهن که بر رفتار و گفتارم هم اثرات شگرف گذاشت. تازه متوجه شدم که چقدر از سختی‌هایی که در زندگی برای خودم ایجاد شده یا برای دیگران ایجاد کرده‌ام، می‌توانست با تغییر مدل ذهنی و جایگزین کردن بازخورد «سازنده» به جای بازخورد «منفی» به وجود نیاید.
پس از گذشت سالها، هنوز آن لحظه‌ای که آن خانم دکتر در کورسرا داشت در مورد روش بازخورد و تصحیح تمرین‌‌ها توضیح می‌داد را به یاد می‌آورم. می‌توانم درباره‌ی تاثیر آن ساعت‌ها صحبت کنم. آرزو می‌کردم که زمانی که کم و سن سال‌تر بودم آن را یاد می‌گرفتم.
پس گفتار:
به قول مولانا «چه دانم‌های بسیار است لیکن من نمی‌دانم»
https://t.me/bibalan_com
https://bibalan.com/?p=4650
نمونه ۲:
از مبحث بازخورد (فیدبک) در مدارهای الکتریکی آموخته بودم که که بازخورد دو نوع است: بازخورد مثبت و بازخورد منفی. بازخورد مثبت باعث افزایش و بهبود خروجی سیستم می‌شود و بازخورد منفی باعث کاهش خروجی سیستم. وقتی شما به یک فرد دیگر بازخورد می‌دهید، یا بازخوردتان مثبت است (تعریف و تمجید می‌کنید) یا بازخوردتان منفی است (نقد می‌کنید و ایراد می‌گیرید).
شوک ۲: بازخورد منفی کو؟
همان طور که گفتم بر اساس آموخته‌های درس مدارهای الکتریکی باورم این بود که بازخورد افراد به همدیگر یا بازخورد مثبت است یا بازخورد منفی! تا این که به صورت کاملن اتفاقی ویدیویی از یک کلاس آموزشی در کورسرا دیدم که استاد درس پیش از اعلام اولین تمرین درس، کمی در مورد بازخورد صحبت کرد. او می‌گفت که بازخوردهای شما یا باید مثبت باشد یا سازنده. پس از شنیدن این صحبت‌ها دچار این شوک ذهنی شدم و از خود می‌پرسیدم که پس بازخورد منفی کجا رفت! اثر این شوک ذهنی نه‌تنها بر ذهن که بر رفتار و گفتارم هم اثرات شگرف گذاشت. تازه متوجه شدم که چقدر از سختی‌هایی که در زندگی برای خودم ایجاد شده یا برای دیگران ایجاد کرده‌ام، می‌توانست با تغییر مدل ذهنی و جایگزین کردن بازخورد «سازنده» به جای بازخورد «منفی» به وجود نیاید.
پس از گذشت سالها، هنوز آن لحظه‌ای که آن خانم دکتر در کورسرا داشت در مورد روش بازخورد و تصحیح تمرین‌‌ها توضیح می‌داد را به یاد می‌آورم. می‌توانم درباره‌ی تاثیر آن ساعت‌ها صحبت کنم. آرزو می‌کردم که زمانی که کم و سن سال‌تر بودم آن را یاد می‌گرفتم.
پس گفتار:
به قول مولانا «چه دانم‌های بسیار است لیکن من نمی‌دانم»
https://t.me/bibalan_com
https://bibalan.com/?p=4650
Telegram
سماموس: نوشته‌های یوسف مهرداد بی‌بالان
این کانال برای اطلاع‌رسانی نوشته‌های وبلاگ سماموس (bibalan.com) ایجاد شده است. مطالب پس از انتشار در وبلاگ، در این کانال نیز منتشر خواهد شد. امیدوارم که مطالب آن برای شما مفید باشد و خوشحال خواهم شد تا نظرات و بازخوردهای شما عزیزان را دریافت کنم.
شوک‌های ذهنی! (بخش ۳)
نمونه ۳:
در ریاضیات یک سری گزاره‌ها یا درست هستند یا نادرست. مثلا یک عدد نمی‌تواند هم از سه بزرگ‌تر باشد و هم کوچک‌تر! این گزاره‌ها با موضوعات آمار و احتمال و حتا منطق فازی هم متفاوت هستند. این گونه گزاره‌ها نمی‌توانند هم درست باشند و هم نادرست.
شوک ۳: گزاره‌های متفاوت و متناقض ولی همه درست!
بر اساس آموخته‌های ریاضیات‌ام بر این باور بودم که وقتی در مورد یک موضوع دو نظر متفاوت وجود دارد نمی‌تواند هر دوی آنها درست باشد. اگر کمی به هم شبیه بودند باز هم می‌شد از مبحث اشتراک در مجموعه‌ها آن را بررسی کرد ولی اگر هیچ شباهتی به هم نداشته باشند و حتا در تناقض با هم باشند، ناگزیر یکی از آنها باید درست باشد. نتیجه‌ی این که باید تلاش کنید تا پاسخ درست را از بین آنها پیدا کنید.
از جمله این موضوع‌ها که نظرات متفاوت در آنها پیدا می‌شد می‌توان به یک تصمیم ساده در زندگی، تصمیم‌گیری درباره‌ی معماری یک نرم‌افزار، تصمیم در خرید یا فروش سهام، شیوه‌ی طراحی بخشی از یک سیستم نرم‌افزاری اشاره کرد. برای نمونه در بحث معماری نرم‌افزار ممکن است یک نفر باور داشته باشد که نرم‌افزار باید توزیع‌شده باشد و دیگری اعتقاد داشته باشد که نه نیازی نیست. در این شرایط، به عنوان تصمیم‌گیرنده کار سختی در پیش دارید و اگر در جایگاه مشورت هستید که باید با روش کدخدا منشی یک جوری تصمیم را ختم به خیر کنید 😉
بعدها در جایی دیدم که اگر عدد ۶ انگلیسی را بین دو نفر بگذارید که یکی از راست و دیگری از چپ به آن نگاه کند، یکی می‌گوید این عدد ۹ است و دیگری می‌گوید این عدد ۶ است. هر چند که عدد ۶ ثابت است ولی آن دو از دو منظر متفاوت به آن می‌نگرند و در نتیجه هر دو درست می‌گویند: یکی می‌گوید ۶ و دیگری می‌گوید ۹. نظر من می‌تواند کاملن مخالف نظر شما باشد ولی هر دو نظر و در یک زمان درست باشند!
زندگی سخت‌تر از گذشته شد و شاید هم راحت‌تر! سخت‌تر شد چون باید به جایی که از آن زندگی را نگاه می‌کردم توجه می‌کردم و به یاد می‌آوردم که اگر جایم تغییر می‌کرد همه چیز می‌توانست متفاوت باشد. راحت‌تر شد چون کمتر درگیر درست/نادرست بودم و بیشتر به این نتیجه می‌رسیدم که همه درست می‌گویند حتا شما دوست عزیز!
گزیده:
رها کن حرف هندو را ببین ترکان معنی را
من آن ترکم که هندو را نمی‌دانم نمی‌دانم
https://t.me/bibalan_com
https://bibalan.com/?p=4648
نمونه ۳:
در ریاضیات یک سری گزاره‌ها یا درست هستند یا نادرست. مثلا یک عدد نمی‌تواند هم از سه بزرگ‌تر باشد و هم کوچک‌تر! این گزاره‌ها با موضوعات آمار و احتمال و حتا منطق فازی هم متفاوت هستند. این گونه گزاره‌ها نمی‌توانند هم درست باشند و هم نادرست.
شوک ۳: گزاره‌های متفاوت و متناقض ولی همه درست!
بر اساس آموخته‌های ریاضیات‌ام بر این باور بودم که وقتی در مورد یک موضوع دو نظر متفاوت وجود دارد نمی‌تواند هر دوی آنها درست باشد. اگر کمی به هم شبیه بودند باز هم می‌شد از مبحث اشتراک در مجموعه‌ها آن را بررسی کرد ولی اگر هیچ شباهتی به هم نداشته باشند و حتا در تناقض با هم باشند، ناگزیر یکی از آنها باید درست باشد. نتیجه‌ی این که باید تلاش کنید تا پاسخ درست را از بین آنها پیدا کنید.
از جمله این موضوع‌ها که نظرات متفاوت در آنها پیدا می‌شد می‌توان به یک تصمیم ساده در زندگی، تصمیم‌گیری درباره‌ی معماری یک نرم‌افزار، تصمیم در خرید یا فروش سهام، شیوه‌ی طراحی بخشی از یک سیستم نرم‌افزاری اشاره کرد. برای نمونه در بحث معماری نرم‌افزار ممکن است یک نفر باور داشته باشد که نرم‌افزار باید توزیع‌شده باشد و دیگری اعتقاد داشته باشد که نه نیازی نیست. در این شرایط، به عنوان تصمیم‌گیرنده کار سختی در پیش دارید و اگر در جایگاه مشورت هستید که باید با روش کدخدا منشی یک جوری تصمیم را ختم به خیر کنید 😉
بعدها در جایی دیدم که اگر عدد ۶ انگلیسی را بین دو نفر بگذارید که یکی از راست و دیگری از چپ به آن نگاه کند، یکی می‌گوید این عدد ۹ است و دیگری می‌گوید این عدد ۶ است. هر چند که عدد ۶ ثابت است ولی آن دو از دو منظر متفاوت به آن می‌نگرند و در نتیجه هر دو درست می‌گویند: یکی می‌گوید ۶ و دیگری می‌گوید ۹. نظر من می‌تواند کاملن مخالف نظر شما باشد ولی هر دو نظر و در یک زمان درست باشند!
زندگی سخت‌تر از گذشته شد و شاید هم راحت‌تر! سخت‌تر شد چون باید به جایی که از آن زندگی را نگاه می‌کردم توجه می‌کردم و به یاد می‌آوردم که اگر جایم تغییر می‌کرد همه چیز می‌توانست متفاوت باشد. راحت‌تر شد چون کمتر درگیر درست/نادرست بودم و بیشتر به این نتیجه می‌رسیدم که همه درست می‌گویند حتا شما دوست عزیز!
گزیده:
رها کن حرف هندو را ببین ترکان معنی را
من آن ترکم که هندو را نمی‌دانم نمی‌دانم
https://t.me/bibalan_com
https://bibalan.com/?p=4648
Telegram
سماموس: نوشته‌های یوسف مهرداد بی‌بالان
این کانال برای اطلاع‌رسانی نوشته‌های وبلاگ سماموس (bibalan.com) ایجاد شده است. مطالب پس از انتشار در وبلاگ، در این کانال نیز منتشر خواهد شد. امیدوارم که مطالب آن برای شما مفید باشد و خوشحال خواهم شد تا نظرات و بازخوردهای شما عزیزان را دریافت کنم.
قانون هایروم (Hyrum’s Law)-بخش اول
طی چند سال گذشته و به دلیل همکاری‌ام برای انتقال (migration) زیرساخت‌های سطح پایین یکی از پیچیده‌ترین سیستم‌های نرم‌افزاری روی کره‌ی خاکی به نکات مهمی درباره‌ی تفاوت بین رابط (interface) و پیاده‌سازی آن (implementation) برخورد کرده‌ام. معمولن ما رابط (interface) را تجریدی (abstraction) برای ارتباط با سیستم میدانیم و پیاده‌سازی (implementation) را هم روشی میدانیم که سیستم کارش را انجام می‌دهد. برای نمونه فرمان و پدال‌های گاز و ترمز در خودرو مانند رابط عمل می‌کنند و چرخ‌ها و موتور هم مانند پیاده‌سازی هستند (ارتباط ما با خودرو از طریق فرمان و پدال‌ها است ولی خودرو به کمک موتور و چرخ‌ها کار خواسته‌شده را انجام می‌دهد). چنین مفهومی به دلایل متعددی مفید است که مهم‌ترین‌اش این است که پیچیدگی بسیاری از سیستم‌های پرکاربرد خیلی سریع به حدی می‌رسد که فهم و شناخت کامل آن برای یک فرد یا گروه دشوار می‌گردد و تجرید‌ها (abstraction) برای مدیریت این پیچیدگی بسیار مهم و حیاتی‌اند.
تعریف سطح درستِ تجرید (abstraction)، موضوع کاملن جداگانه‌ای است که در اینجا به آن نمی‌پردازیم (کتاب نفر ماه افسانه‌ای -Mythical Man-Month- را ببینید). نکته مهم این است که وقتی یک تجرید (abstraction) تعریف شد ما دوست داریم آن را غیرقابل تغییر، شفاف و تفسیرناپذیر بدانیم. به عبارت دیگر، هر رابط (interface) از دیدگاه نظری باید مرز شفافی بین استفاده‌کنندگان یک سیستم و پیاده‌سازی داخلی سیستم ترسیم کند. اما از دیدگاه عملی، با رشد تعداد استفاده‌کنندگان و استفاده از سیستم، این نظریه نقض می‌شود و استفاده‌کنندگان شروع به اعتماد و اتکا به جزییات پیاده‌سازی می‌کنند. این جزییات یا دانسته از طریق رابط (interface) به بیرون درز کرده یا خود استفاده‌کنندگان موقع استفاده از سیستم آنها را کشف کرده و فهمیده‌اند. «قانون تجریدهای دارای نشتی اسپولسکی» (Spolsky’s Law of Leaky Abstractions) توضیح می‌دهد که چگونه استفاده‌کنندگان به جزییات پیاده‌سازی اعتماد و اتکا می‌کنند.
نهایت چنین اتفاقی ما را به سوی مفهومی هدایت می‌کند که در محاوره به آن «قانون رابط‌های ضمنی یا غیرشفاف» (The Law of Implicit Interfaces) گفته می‌شود: با فرض وجود تعداد کافی از استفاده‌کنندگان، چیزی به نام پیاده‌سازی خصوصی (private implementation) وجود ندارد [پیاده‌سازی خصوصی به این معناست که استفاده‌کننده هیچ اطلاعی از نحوه و روش پیاده‌سازی داخلی سیستم ندارند].
گزیده:
وقتی داشتم این کد رو می‌نوشتم فقط من و خدا می‌فهمیدیم من دارم چه کار می‌کنم. الان دیگه فقط خدا می‌دونه! 😀
ناشناس
https://t.me/bibalan_com
https://bibalan.com/?p=4652
طی چند سال گذشته و به دلیل همکاری‌ام برای انتقال (migration) زیرساخت‌های سطح پایین یکی از پیچیده‌ترین سیستم‌های نرم‌افزاری روی کره‌ی خاکی به نکات مهمی درباره‌ی تفاوت بین رابط (interface) و پیاده‌سازی آن (implementation) برخورد کرده‌ام. معمولن ما رابط (interface) را تجریدی (abstraction) برای ارتباط با سیستم میدانیم و پیاده‌سازی (implementation) را هم روشی میدانیم که سیستم کارش را انجام می‌دهد. برای نمونه فرمان و پدال‌های گاز و ترمز در خودرو مانند رابط عمل می‌کنند و چرخ‌ها و موتور هم مانند پیاده‌سازی هستند (ارتباط ما با خودرو از طریق فرمان و پدال‌ها است ولی خودرو به کمک موتور و چرخ‌ها کار خواسته‌شده را انجام می‌دهد). چنین مفهومی به دلایل متعددی مفید است که مهم‌ترین‌اش این است که پیچیدگی بسیاری از سیستم‌های پرکاربرد خیلی سریع به حدی می‌رسد که فهم و شناخت کامل آن برای یک فرد یا گروه دشوار می‌گردد و تجرید‌ها (abstraction) برای مدیریت این پیچیدگی بسیار مهم و حیاتی‌اند.
تعریف سطح درستِ تجرید (abstraction)، موضوع کاملن جداگانه‌ای است که در اینجا به آن نمی‌پردازیم (کتاب نفر ماه افسانه‌ای -Mythical Man-Month- را ببینید). نکته مهم این است که وقتی یک تجرید (abstraction) تعریف شد ما دوست داریم آن را غیرقابل تغییر، شفاف و تفسیرناپذیر بدانیم. به عبارت دیگر، هر رابط (interface) از دیدگاه نظری باید مرز شفافی بین استفاده‌کنندگان یک سیستم و پیاده‌سازی داخلی سیستم ترسیم کند. اما از دیدگاه عملی، با رشد تعداد استفاده‌کنندگان و استفاده از سیستم، این نظریه نقض می‌شود و استفاده‌کنندگان شروع به اعتماد و اتکا به جزییات پیاده‌سازی می‌کنند. این جزییات یا دانسته از طریق رابط (interface) به بیرون درز کرده یا خود استفاده‌کنندگان موقع استفاده از سیستم آنها را کشف کرده و فهمیده‌اند. «قانون تجریدهای دارای نشتی اسپولسکی» (Spolsky’s Law of Leaky Abstractions) توضیح می‌دهد که چگونه استفاده‌کنندگان به جزییات پیاده‌سازی اعتماد و اتکا می‌کنند.
نهایت چنین اتفاقی ما را به سوی مفهومی هدایت می‌کند که در محاوره به آن «قانون رابط‌های ضمنی یا غیرشفاف» (The Law of Implicit Interfaces) گفته می‌شود: با فرض وجود تعداد کافی از استفاده‌کنندگان، چیزی به نام پیاده‌سازی خصوصی (private implementation) وجود ندارد [پیاده‌سازی خصوصی به این معناست که استفاده‌کننده هیچ اطلاعی از نحوه و روش پیاده‌سازی داخلی سیستم ندارند].
گزیده:
وقتی داشتم این کد رو می‌نوشتم فقط من و خدا می‌فهمیدیم من دارم چه کار می‌کنم. الان دیگه فقط خدا می‌دونه! 😀
ناشناس
https://t.me/bibalan_com
https://bibalan.com/?p=4652
Telegram
سماموس: نوشته‌های یوسف مهرداد بی‌بالان
این کانال برای اطلاع‌رسانی نوشته‌های وبلاگ سماموس (bibalan.com) ایجاد شده است. مطالب پس از انتشار در وبلاگ، در این کانال نیز منتشر خواهد شد. امیدوارم که مطالب آن برای شما مفید باشد و خوشحال خواهم شد تا نظرات و بازخوردهای شما عزیزان را دریافت کنم.
قانون هایروم (Hyrum’s Law)-بخش دوم
به عبارت دیگر، در صورتی که رابط (interface) به تعداد کافی استفاده‌کننده داشته باشد، مجموع استفاده‌کنندگان خواسته یا ناخواسته به بخش‌های مختلف پیاده‌سازی وابسته خواهند شد. نتیجه‌ی چنین اتفاقی، سخت‌تر شدن اعمال تغییرات در پیاده‌سازی رابط‌ها است زیرا از این نقطه به بعد، پیاده‌سازی نه تنها باید با بخش مستندشده و شفاف رابط‌ها (explicitly documented interface) تطبیق داشته باشد بلکه باید با بخش پنهان و غیرشفاف رابط‌ها (implicit interface) که ناشی از روش استفاده از آنهاست نیز هم‌خوانی داشته باشد. ما معمولن این پدیده را «سازگاری با خطا برای خطا« (bug-for-bug compatibility) می‌نامیم [«سازگاری با خطا برای خطا» یا «سازگاری با خطا» تکنیکی است که در آن خطاها یا رفتارهای نادرست نسخهی قبلی یک نرم‌افزار در نسخهی جدید آن با آگاهی و خودخواسته باقی گذاشته می‌شوند. مترجم]
شکل‌گیری رابط پنهان (implicit interface) معمولن تدریجی است و استفاده‌کنندگان رابط عمومن از شکل‌گیری آن آگاهی ندارند. برای مثال، یک رابط ممکن است هیچ تضمین یا اطلاعاتی درباره‌ی کارایی و سرعت خود اعلام نکرده باشد، با این حال استفاده‌کنندگان بر اساس تجربه‌ی خود، کم‌کم به این جمع‌بندی می‌رسند که سطح سرعت و کارایی سیستم چقدر است و از آن به بعد انتظار دارند که کارایی سیستم دست‌ِکم در همان سطح باقی بماند یا بهبود پیدا کند. این گونه انتظارات به بخشی از رابط پنهان (implicit interface) سیستم تبدیل می‌گردد و از آن پس، تغییرات سیستم باید این سطح از کارایی را پوشش دهد تا کارهای استفاده‌کنندگان دچار اختلال نگردد.
همه‌ی استفاده‌کنندگان فقط به یک رابط پنهان یکسان وابسته نمی‌شوند. با فرض وجود تعداد کافی استفاده‌کنندگان، رابط پنهان در نهایت کاملن با پیاده‌سازی مطابقت خواهد داشت. در چنین شرایطی، رابط (interface) محو می‌شود و پیاده‌سازی (implementation) جای رابط را می‌گیرد و هر گونه تغییری در آن، انتظارات استفاده‌کنندگان را مختل می‌کند. اگر خوش شانس باشیم، آزمون‌‌های جامع و خودکار می‌توانند این گونه مغایرت با انتظارات استفاده‌کنندگان را پیدا کنند ولی نمی‌توانند آنها را رفع کنند.
رابط‌های پنهان (implicit interface) نتیجه‌ی رشد طبیعی و ارگانیک سیستم‌های بزرگ هستند. هرچند آرزو می‌کنیم که چنین مشکلی برای سیستم‌ها به وجود نیاید، اما عاقلانه است که موقع ساخت و نگهداری سیستم‌های پیچیده، مهندسان و طراحان رابط‌های پنهان را مد نظر داشته باشند و به آن توجه کنند. به یاد داشته باشید که رابط‌های پنهان چگونه طراحی و تکامل سیستم‌ها را محدود می‌کنند و دقت کنید که برای هر سیستم پراستفاده‌ای، رابط (interface) مفهومی بسیار پیچیده‌تر از چیزی است که فکر می‌کنید.
هویرام کیست؟
هویرام رایت (Hyrum Wright) دانشمند ارشد (Principal Scientist) ادوبی (Adobe) است و قبل از آن، مهندس نرم‌افزار در گوگل بود. او روی ابزارها و زیرساخت مدیریت تغییر کد در مقیاس بزرگ کار می‌کند و سال‌های زیادی را صرف بهبود کتابخانه‌های زیربنایی و مبتنی بر سی‌پلاس‌پلاس گوگل کرده است. او یکی از نویسندگان کتاب Software Engineering at Google نیز است.
منبع:
www.hyrumslaw.com
گزیده:
پسری از پدر برنامه‌نویس‌اش پرسید «بابا، واسه چی خورشید از شرق طلوع می‌کنه و در غرب غروب؟»
پدرش پاسخ داد:
پسرم داره کار می‌کنه کاری به کارش نداشته باش! 😀
A son asked his father (a #programmer) why the sun rises in the east, and sets in the west. His response? It works, don’t touch!
https://t.me/bibalan_com
https://bibalan.com/?p=4652
به عبارت دیگر، در صورتی که رابط (interface) به تعداد کافی استفاده‌کننده داشته باشد، مجموع استفاده‌کنندگان خواسته یا ناخواسته به بخش‌های مختلف پیاده‌سازی وابسته خواهند شد. نتیجه‌ی چنین اتفاقی، سخت‌تر شدن اعمال تغییرات در پیاده‌سازی رابط‌ها است زیرا از این نقطه به بعد، پیاده‌سازی نه تنها باید با بخش مستندشده و شفاف رابط‌ها (explicitly documented interface) تطبیق داشته باشد بلکه باید با بخش پنهان و غیرشفاف رابط‌ها (implicit interface) که ناشی از روش استفاده از آنهاست نیز هم‌خوانی داشته باشد. ما معمولن این پدیده را «سازگاری با خطا برای خطا« (bug-for-bug compatibility) می‌نامیم [«سازگاری با خطا برای خطا» یا «سازگاری با خطا» تکنیکی است که در آن خطاها یا رفتارهای نادرست نسخهی قبلی یک نرم‌افزار در نسخهی جدید آن با آگاهی و خودخواسته باقی گذاشته می‌شوند. مترجم]
شکل‌گیری رابط پنهان (implicit interface) معمولن تدریجی است و استفاده‌کنندگان رابط عمومن از شکل‌گیری آن آگاهی ندارند. برای مثال، یک رابط ممکن است هیچ تضمین یا اطلاعاتی درباره‌ی کارایی و سرعت خود اعلام نکرده باشد، با این حال استفاده‌کنندگان بر اساس تجربه‌ی خود، کم‌کم به این جمع‌بندی می‌رسند که سطح سرعت و کارایی سیستم چقدر است و از آن به بعد انتظار دارند که کارایی سیستم دست‌ِکم در همان سطح باقی بماند یا بهبود پیدا کند. این گونه انتظارات به بخشی از رابط پنهان (implicit interface) سیستم تبدیل می‌گردد و از آن پس، تغییرات سیستم باید این سطح از کارایی را پوشش دهد تا کارهای استفاده‌کنندگان دچار اختلال نگردد.
همه‌ی استفاده‌کنندگان فقط به یک رابط پنهان یکسان وابسته نمی‌شوند. با فرض وجود تعداد کافی استفاده‌کنندگان، رابط پنهان در نهایت کاملن با پیاده‌سازی مطابقت خواهد داشت. در چنین شرایطی، رابط (interface) محو می‌شود و پیاده‌سازی (implementation) جای رابط را می‌گیرد و هر گونه تغییری در آن، انتظارات استفاده‌کنندگان را مختل می‌کند. اگر خوش شانس باشیم، آزمون‌‌های جامع و خودکار می‌توانند این گونه مغایرت با انتظارات استفاده‌کنندگان را پیدا کنند ولی نمی‌توانند آنها را رفع کنند.
رابط‌های پنهان (implicit interface) نتیجه‌ی رشد طبیعی و ارگانیک سیستم‌های بزرگ هستند. هرچند آرزو می‌کنیم که چنین مشکلی برای سیستم‌ها به وجود نیاید، اما عاقلانه است که موقع ساخت و نگهداری سیستم‌های پیچیده، مهندسان و طراحان رابط‌های پنهان را مد نظر داشته باشند و به آن توجه کنند. به یاد داشته باشید که رابط‌های پنهان چگونه طراحی و تکامل سیستم‌ها را محدود می‌کنند و دقت کنید که برای هر سیستم پراستفاده‌ای، رابط (interface) مفهومی بسیار پیچیده‌تر از چیزی است که فکر می‌کنید.
هویرام کیست؟
هویرام رایت (Hyrum Wright) دانشمند ارشد (Principal Scientist) ادوبی (Adobe) است و قبل از آن، مهندس نرم‌افزار در گوگل بود. او روی ابزارها و زیرساخت مدیریت تغییر کد در مقیاس بزرگ کار می‌کند و سال‌های زیادی را صرف بهبود کتابخانه‌های زیربنایی و مبتنی بر سی‌پلاس‌پلاس گوگل کرده است. او یکی از نویسندگان کتاب Software Engineering at Google نیز است.
منبع:
www.hyrumslaw.com
گزیده:
پسری از پدر برنامه‌نویس‌اش پرسید «بابا، واسه چی خورشید از شرق طلوع می‌کنه و در غرب غروب؟»
پدرش پاسخ داد:
پسرم داره کار می‌کنه کاری به کارش نداشته باش! 😀
A son asked his father (a #programmer) why the sun rises in the east, and sets in the west. His response? It works, don’t touch!
https://t.me/bibalan_com
https://bibalan.com/?p=4652
Telegram
سماموس: نوشته‌های یوسف مهرداد بی‌بالان
این کانال برای اطلاع‌رسانی نوشته‌های وبلاگ سماموس (bibalan.com) ایجاد شده است. مطالب پس از انتشار در وبلاگ، در این کانال نیز منتشر خواهد شد. امیدوارم که مطالب آن برای شما مفید باشد و خوشحال خواهم شد تا نظرات و بازخوردهای شما عزیزان را دریافت کنم.
قوانین نرم‌افزار: قانون کانینگهم (Cunningham’s Law)
بهترین راه برای دریافت پاسخ درست در اینترنت، پرسیدن پرسش درست نیست! بهترین راه، نوشتن پاسخ نادرست است. 😁
ورد کانینگهم (Ward Cunningham)
https://bit.ly/3VXpvoC
https://t.me/bibalan_com
https://bibalan.com/?p=4699
بهترین راه برای دریافت پاسخ درست در اینترنت، پرسیدن پرسش درست نیست! بهترین راه، نوشتن پاسخ نادرست است. 😁
ورد کانینگهم (Ward Cunningham)
https://bit.ly/3VXpvoC
https://t.me/bibalan_com
https://bibalan.com/?p=4699
نمونه کاربردهای هوش مصنوعی
به تازگی گوگل در یک وب‌نوشت، مجموعه‌ای از نمونه کاربردهای هوش مصنوعی را معرفی کرده است. این نوشته شامل ۳۲۱ نمونه‌ی کاربردی از حوزه‌های مختلفی مانند خرده‌فروشی و کالاهای مصرفی، خودرو و لجستیک، سلامت است. مرور این نوشته برای آشنایی با کابردهای هوش مصنوعی و هم‌چنین ایده گرفتن برای شناسایی کاربردهای مشابه در حوزه‌ی تخصصی می‌تواند مفید باشد.
https://cloud.google.com/transform/101-real-world-generative-ai-use-cases-from-industry-leaders
https://t.me/bibalan_com
https://bibalan.com/?p=4709
به تازگی گوگل در یک وب‌نوشت، مجموعه‌ای از نمونه کاربردهای هوش مصنوعی را معرفی کرده است. این نوشته شامل ۳۲۱ نمونه‌ی کاربردی از حوزه‌های مختلفی مانند خرده‌فروشی و کالاهای مصرفی، خودرو و لجستیک، سلامت است. مرور این نوشته برای آشنایی با کابردهای هوش مصنوعی و هم‌چنین ایده گرفتن برای شناسایی کاربردهای مشابه در حوزه‌ی تخصصی می‌تواند مفید باشد.
https://cloud.google.com/transform/101-real-world-generative-ai-use-cases-from-industry-leaders
https://t.me/bibalan_com
https://bibalan.com/?p=4709
مهم نیست که چه می‌خواهیم!
صحنه‌ای از مجموعه تلویزیونی “بازی تاج و تخت” (Game of Thrones) است که توی اون «لیتل فینگر» (شخصیت مرموز، حیله‌گر و تشنه‌ی قدرت این سریال) رو به «سانسا استارک» می‌کنه و می‌گه:
«همیشه دلم می‌خواست یه کشتی داشته باشم. ولی الان [که یه کشتی دارم] دلم می‌خواد چند تا کشتی داشته باشم. عجیبه! مگه نه؟!»
و سانسا ازش می‌پرسه: «چی عجیبه؟»
و بعد لیتل فینگر ادامه می‌ده: «مهم نیست که چی می‌خوایم. مهم اینه که وقتی به دست‌اش می‌آریم یه چیز دیگه می‌خوایم.»
https://bit.ly/3BP3a5L
https://t.me/bibalan_com
https://bibalan.com/?p=4712
صحنه‌ای از مجموعه تلویزیونی “بازی تاج و تخت” (Game of Thrones) است که توی اون «لیتل فینگر» (شخصیت مرموز، حیله‌گر و تشنه‌ی قدرت این سریال) رو به «سانسا استارک» می‌کنه و می‌گه:
«همیشه دلم می‌خواست یه کشتی داشته باشم. ولی الان [که یه کشتی دارم] دلم می‌خواد چند تا کشتی داشته باشم. عجیبه! مگه نه؟!»
و سانسا ازش می‌پرسه: «چی عجیبه؟»
و بعد لیتل فینگر ادامه می‌ده: «مهم نیست که چی می‌خوایم. مهم اینه که وقتی به دست‌اش می‌آریم یه چیز دیگه می‌خوایم.»
https://bit.ly/3BP3a5L
https://t.me/bibalan_com
https://bibalan.com/?p=4712
روان‌شناسی پول
کتاب روان‌شناسی پول: درس‌های ابدی درباره‌ی ثروت، طمع و خوشحالی (The Psychology of Money: Timeless lessons on wealth, greed, and happiness) را به همراه چند تن از دوستان عزیزم خواندم.
مورگان هاوسل در این کتاب، شیوه‌ی تفکر، مدیریت و برخورد افراد با پول را بررسی می‌کند. به جای تاکید بر جنبه‌های فنی و تکنیکال، نویسنده به بررسی جنبه‌های رفتاری و احساسی انسان‌ها می‌پردازد و با کمک گرفتن از مباحث روان‌شناسی، واقعیات تاریخی و تجربیات شخصی تلاش می‌کند نشان دهد که موفقیت مالی بیشتر از آن که به هوش یا دانش فنی انسان‌ها وابسته باشد، به رفتار، رویکردها و ارزش‌های فردی انسان‌ها بر می‌گردد.
در این کتاب شما هیچ نشانه‌ای از راهکارهای حاضر و آماده یا توصیه‌های مالی یا تکنیکی پیدا نمی‌کنید. تجربه‌ی من از خواندن این کتاب، «یادگیری صورت مساله‌های مهم»، «فراگیری ابعاد مساله به ویژه از جنبه‌های روان‌شناختی» و «به چالش کشیده شدن باورها و آموخته‌ها» بود.
اجازه دهید بدون لو دادن مطالب کتاب، چند نمونه را با هم بررسی کنیم.
– در این کتاب توضیح می‌دهد که پول‌داری (rich) با ثروتمندی (wealthy) تفاوت دارد و آن چه باید به دنبال آن بود ثروتمندی است!
– جای دیگر کتاب درباره‌ی مفهومی به نام «کافی بودن» (enough) توضیح می‌دهد و تاکید می‌کند که «مقدار کافی بودن» موضوعی است شخصی و بعد توضیح می‌دهد که چگونه می‌توان از این مفهوم برای «آزادی مالی» استفاده کرد.
– در بخش دیگری از کتاب نیز بیان می‌دهد که حواس‌تان به آفت «تو – من» باشد. مشاوران سرمایه‌گذاری اعم از حرفه‌ای یا آماتور وقتی توصیه می‌کنند معمولن شرایط خودشان یا شرایط خاصی را برای سرمایه‌گذار در نظر می‌گیرند. باید مراقب باشید شرایط شما ممکن است با افراد مد نظر مشاوران متفاوت باشد.
کتاب روان‌شناسی پول از آن دسته کتاب‌هایی است که هر چند وقت یک بار باید دوباره آن را خواند. مهم‌تر این که می‌توان برای هر فصل کتاب جلسه‌های بحث و هم‌اندیشی گذاشت که بی‌شک به چالش ختم خواهد شد ;).
سپاسگزار دوستان عزیزم هستم که بانی و بهانه‌ای شدند برای خواندن این کتاب ارزشمند.
گزیده:
انسان‌ها کارهای احمقانه‌ای با پول می‌کنند ولی هیچ انسانی احمق نیست!
مورگان هاوسل – روان‌شناسی پول
https://bit.ly/4h3fpdL
https://t.me/bibalan_com
https://bibalan.com/?p=4719
کتاب روان‌شناسی پول: درس‌های ابدی درباره‌ی ثروت، طمع و خوشحالی (The Psychology of Money: Timeless lessons on wealth, greed, and happiness) را به همراه چند تن از دوستان عزیزم خواندم.
مورگان هاوسل در این کتاب، شیوه‌ی تفکر، مدیریت و برخورد افراد با پول را بررسی می‌کند. به جای تاکید بر جنبه‌های فنی و تکنیکال، نویسنده به بررسی جنبه‌های رفتاری و احساسی انسان‌ها می‌پردازد و با کمک گرفتن از مباحث روان‌شناسی، واقعیات تاریخی و تجربیات شخصی تلاش می‌کند نشان دهد که موفقیت مالی بیشتر از آن که به هوش یا دانش فنی انسان‌ها وابسته باشد، به رفتار، رویکردها و ارزش‌های فردی انسان‌ها بر می‌گردد.
در این کتاب شما هیچ نشانه‌ای از راهکارهای حاضر و آماده یا توصیه‌های مالی یا تکنیکی پیدا نمی‌کنید. تجربه‌ی من از خواندن این کتاب، «یادگیری صورت مساله‌های مهم»، «فراگیری ابعاد مساله به ویژه از جنبه‌های روان‌شناختی» و «به چالش کشیده شدن باورها و آموخته‌ها» بود.
اجازه دهید بدون لو دادن مطالب کتاب، چند نمونه را با هم بررسی کنیم.
– در این کتاب توضیح می‌دهد که پول‌داری (rich) با ثروتمندی (wealthy) تفاوت دارد و آن چه باید به دنبال آن بود ثروتمندی است!
– جای دیگر کتاب درباره‌ی مفهومی به نام «کافی بودن» (enough) توضیح می‌دهد و تاکید می‌کند که «مقدار کافی بودن» موضوعی است شخصی و بعد توضیح می‌دهد که چگونه می‌توان از این مفهوم برای «آزادی مالی» استفاده کرد.
– در بخش دیگری از کتاب نیز بیان می‌دهد که حواس‌تان به آفت «تو – من» باشد. مشاوران سرمایه‌گذاری اعم از حرفه‌ای یا آماتور وقتی توصیه می‌کنند معمولن شرایط خودشان یا شرایط خاصی را برای سرمایه‌گذار در نظر می‌گیرند. باید مراقب باشید شرایط شما ممکن است با افراد مد نظر مشاوران متفاوت باشد.
کتاب روان‌شناسی پول از آن دسته کتاب‌هایی است که هر چند وقت یک بار باید دوباره آن را خواند. مهم‌تر این که می‌توان برای هر فصل کتاب جلسه‌های بحث و هم‌اندیشی گذاشت که بی‌شک به چالش ختم خواهد شد ;).
سپاسگزار دوستان عزیزم هستم که بانی و بهانه‌ای شدند برای خواندن این کتاب ارزشمند.
گزیده:
انسان‌ها کارهای احمقانه‌ای با پول می‌کنند ولی هیچ انسانی احمق نیست!
مورگان هاوسل – روان‌شناسی پول
https://bit.ly/4h3fpdL
https://t.me/bibalan_com
https://bibalan.com/?p=4719
برنامه‌نویسی دلی! – بخش یک
پیش‌گفتار یک: نگاه ریاضی‌گونه و نگاه مهندسی‌گونه به برنامه‌نویسی
به گذشته که نگاه می‌کنم می‌بینم که آموزش برنامه‌نویسی همراه بوده با نوعی نگاه که بی‌شباهت به حل مساله‌های ریاضی یا فیزیک نیست. نوعی نگاه حذف جزییات در ابتدا و اضافه کردن جزییات در ادامه.
برای نمونه در نگاه ریاضی‌گونه به برنامه‌نویسی شما ابتدا باید ساختار داده‌ها (data structure) را تعیین کنید و بعد با نگاه رویه‌گونه و الگوریتمی به کمک تابع یا رویه (procedure or function) راه‌حل‌تان را به گام‌هایی بشکنید و همین گام‌ها را تکرار کنید. روی کاغذ، در کامپیوتر یا در ذهن‌تان، ابتدا باید این اجزا فکر کنید و بعد کدنویسی رو شروع کنید. البته می‌توانید کمی فکر کنید و بعد کد بنویسید و بعد باز هم فکر کنید و کد بنویسید و …
در نگاه مهندسی هم برای نمونه در مدل آبشاری (waterfall) تلاش بر این است که قبل از ورود به جزییات و کدنویسی، طرحی از راه حل آماده شده باشد و به اندازه کافی پخته شده باشد تا هزینه پیاده‌سازی و ورود به جزییات کاهش پیدا کند. بماند که در این رویکرد تاکید بر این است که تا جای ممکن قبل از شروع پیاده‌سازی به همه چیز فکر کنید.
از این منظر، نگرش روش‌های تکراری-تدریجی (iterative-incremental) نیز همین گونه است فقط «به همه چیز فکر کن بعد کد بنویس» به «یک کم فکر کن یک کم کد بنویس بعد دوباره فکر کن …». تلاش بر این است که اندازه و مدت آماده کردن طراحی و سپس پیاده‌سازی آن کاهش پیدا کند.
رویکرد توسعه‌ی آزمون محور (Test Driven Development) به شکلی خلاقانه به جای شروع از «فکر کردن»، با نگاه صرفن کدنویسی، تلاش می‌کند تا ابتدا طرح کلان را از لا به لای آزمون‌هایی که به صورت کد نوشته می‌شود بیرون بیاورد. یادآوری این نکته مهم است که یکی از نتایج دوست‌داشتنی توسعه‌ی آزمون محور این است که شما برای نوشتن آزمون‌ها باید به طراحی کدی که می‌خواهید بنویسید فکر کنید. ولی در هر صورت باید «قبل از پیاده‌سازی فکر کنید»
برداشت من این است که اگر از این منظر به روش‌های توسعه‌ی نرم‌افزار نگاه کنیم همه‌ی آنها بر این بنیان استوارند که «اول فکر کن بعد کد بنویس»!
در یکی دو نوشته‌ی بعدی در نظر دارم کمی در این باره بنویسم و ایده‌ای را با شما مطرح کنم.
گزیده:
برنامه‌نویس کیه؟
برنامه‌نویس، ماشینی یه که قهوه [ یا چایی] رو به کد تبدیل می‌کنه!
https://bit.ly/4g1BmsJ
https://t.me/bibalan_com
https://bibalan.com/?p=4706
پیش‌گفتار یک: نگاه ریاضی‌گونه و نگاه مهندسی‌گونه به برنامه‌نویسی
به گذشته که نگاه می‌کنم می‌بینم که آموزش برنامه‌نویسی همراه بوده با نوعی نگاه که بی‌شباهت به حل مساله‌های ریاضی یا فیزیک نیست. نوعی نگاه حذف جزییات در ابتدا و اضافه کردن جزییات در ادامه.
برای نمونه در نگاه ریاضی‌گونه به برنامه‌نویسی شما ابتدا باید ساختار داده‌ها (data structure) را تعیین کنید و بعد با نگاه رویه‌گونه و الگوریتمی به کمک تابع یا رویه (procedure or function) راه‌حل‌تان را به گام‌هایی بشکنید و همین گام‌ها را تکرار کنید. روی کاغذ، در کامپیوتر یا در ذهن‌تان، ابتدا باید این اجزا فکر کنید و بعد کدنویسی رو شروع کنید. البته می‌توانید کمی فکر کنید و بعد کد بنویسید و بعد باز هم فکر کنید و کد بنویسید و …
در نگاه مهندسی هم برای نمونه در مدل آبشاری (waterfall) تلاش بر این است که قبل از ورود به جزییات و کدنویسی، طرحی از راه حل آماده شده باشد و به اندازه کافی پخته شده باشد تا هزینه پیاده‌سازی و ورود به جزییات کاهش پیدا کند. بماند که در این رویکرد تاکید بر این است که تا جای ممکن قبل از شروع پیاده‌سازی به همه چیز فکر کنید.
از این منظر، نگرش روش‌های تکراری-تدریجی (iterative-incremental) نیز همین گونه است فقط «به همه چیز فکر کن بعد کد بنویس» به «یک کم فکر کن یک کم کد بنویس بعد دوباره فکر کن …». تلاش بر این است که اندازه و مدت آماده کردن طراحی و سپس پیاده‌سازی آن کاهش پیدا کند.
رویکرد توسعه‌ی آزمون محور (Test Driven Development) به شکلی خلاقانه به جای شروع از «فکر کردن»، با نگاه صرفن کدنویسی، تلاش می‌کند تا ابتدا طرح کلان را از لا به لای آزمون‌هایی که به صورت کد نوشته می‌شود بیرون بیاورد. یادآوری این نکته مهم است که یکی از نتایج دوست‌داشتنی توسعه‌ی آزمون محور این است که شما برای نوشتن آزمون‌ها باید به طراحی کدی که می‌خواهید بنویسید فکر کنید. ولی در هر صورت باید «قبل از پیاده‌سازی فکر کنید»
برداشت من این است که اگر از این منظر به روش‌های توسعه‌ی نرم‌افزار نگاه کنیم همه‌ی آنها بر این بنیان استوارند که «اول فکر کن بعد کد بنویس»!
در یکی دو نوشته‌ی بعدی در نظر دارم کمی در این باره بنویسم و ایده‌ای را با شما مطرح کنم.
گزیده:
برنامه‌نویس کیه؟
برنامه‌نویس، ماشینی یه که قهوه [ یا چایی] رو به کد تبدیل می‌کنه!
https://bit.ly/4g1BmsJ
https://t.me/bibalan_com
https://bibalan.com/?p=4706
برنامه‌نویسی دلی! – بخش دو
فیلم «پیدا کردن فارستر» (Finding Forrester) به داستان آشنایی یک رمان‌نویس معروف، برنده‌ی جایزه پولیتزر و البته منزوی به نام ویلیام فارستر (با بازی شان کانری) و یک نوجوان دبیرستانی به نام جمال می‌پردازد. فارستر پس از آن که پی می‌برد جمال برای پذیرفته شدن در کالج نیاز دارد متنی ادبی بنویسد، تصمیم می‌گیرد به او کمک کند. متن زیر گفتگوی فارستر و جمال است در اولین تلاش فارستر برای کمک به جمال. در این صحنه، فارستر پشت یک ماشین تحریر می‌نشیند و جمال هم رو به روی او و جلوی یک ماشین تحریر دیگر ایستاده است.
فارستر: پس بیا به اون [یکی از استادهای دانشگاه و عضو کمیته ارزشیابی] نشون بدیم که تو چه کاری می‌تونی انجام بدی.
جمال: چرا چیزهایی که برای خودمون می‌نویسیم … همیشه خیلی بهتر از چیزهایی‌اند که برای دیگران می‌نویسیم؟
فارستر: زود باش.
– بشین.
– شروع کن.
جمال: چی رو شروع کنم؟
فارستر: نوشتن رو
در این لحظه، فارستر شروع به تایپ می‌کنه.
جمال: داری چه کار می‌کنی؟
فارستر: دارم می‌نویسم، همون کاری که تو قراره بکنی… وقتی که شروع کنی به فشردن اون کلیدها [ی ماشین تحریر].
در اینجا، جمال که پشت ماشین تحریر نشسته، بدون اینکه چیزی تایپ کنه مشغول فکر کردن می‌شه.
فارستر: چیزی شده؟
جمال: نه. فقط دارم فکر می‌کنم.
فارستر: نه. فکر کردن ممنوعه. فکر کردن برای بعدنه.
– پیش‌نویس اولت رو با قلبت می‌نویسی…
– و بعد با عقلت بازنویسی می‌کنی
– اولین اصل نوشتن … نوشتنه، نه فکر کردن
جمال: خدایا.
گزیده:
ما از رویاهایمان دست می‌کشیم چون می‌ترسیم در رسیدن به آنها شکست بخوریم و بدتر این که آنها را رها می‌کنیم چون می‌ترسیم به آنها برسیم.
ویلیام فارستر در فیلم پیدا کردن فارستر
https://bit.ly/4g1BmsJ
https://t.me/bibalan_com
https://bibalan.com/?p=4738
فیلم «پیدا کردن فارستر» (Finding Forrester) به داستان آشنایی یک رمان‌نویس معروف، برنده‌ی جایزه پولیتزر و البته منزوی به نام ویلیام فارستر (با بازی شان کانری) و یک نوجوان دبیرستانی به نام جمال می‌پردازد. فارستر پس از آن که پی می‌برد جمال برای پذیرفته شدن در کالج نیاز دارد متنی ادبی بنویسد، تصمیم می‌گیرد به او کمک کند. متن زیر گفتگوی فارستر و جمال است در اولین تلاش فارستر برای کمک به جمال. در این صحنه، فارستر پشت یک ماشین تحریر می‌نشیند و جمال هم رو به روی او و جلوی یک ماشین تحریر دیگر ایستاده است.
فارستر: پس بیا به اون [یکی از استادهای دانشگاه و عضو کمیته ارزشیابی] نشون بدیم که تو چه کاری می‌تونی انجام بدی.
جمال: چرا چیزهایی که برای خودمون می‌نویسیم … همیشه خیلی بهتر از چیزهایی‌اند که برای دیگران می‌نویسیم؟
فارستر: زود باش.
– بشین.
– شروع کن.
جمال: چی رو شروع کنم؟
فارستر: نوشتن رو
در این لحظه، فارستر شروع به تایپ می‌کنه.
جمال: داری چه کار می‌کنی؟
فارستر: دارم می‌نویسم، همون کاری که تو قراره بکنی… وقتی که شروع کنی به فشردن اون کلیدها [ی ماشین تحریر].
در اینجا، جمال که پشت ماشین تحریر نشسته، بدون اینکه چیزی تایپ کنه مشغول فکر کردن می‌شه.
فارستر: چیزی شده؟
جمال: نه. فقط دارم فکر می‌کنم.
فارستر: نه. فکر کردن ممنوعه. فکر کردن برای بعدنه.
– پیش‌نویس اولت رو با قلبت می‌نویسی…
– و بعد با عقلت بازنویسی می‌کنی
– اولین اصل نوشتن … نوشتنه، نه فکر کردن
جمال: خدایا.
گزیده:
ما از رویاهایمان دست می‌کشیم چون می‌ترسیم در رسیدن به آنها شکست بخوریم و بدتر این که آنها را رها می‌کنیم چون می‌ترسیم به آنها برسیم.
ویلیام فارستر در فیلم پیدا کردن فارستر
https://bit.ly/4g1BmsJ
https://t.me/bibalan_com
https://bibalan.com/?p=4738