گردآوری: یاسر کازرونی
پیش‌گفتار:

متن زیر خلاصه‌ی بخش‌هایی از گفتگوی اعضای گروه تلگرامی «متدهای چابک» (Agile Methods) است.

گفتگو:

در گروه پیشنهاد شد که دوستان با همفکری هم یک فهرست از کتابهای ضروری برای مطالعه‌ی تیم‌های چابک تهیه کنند. موضوعاتی که تیم‌ها برای رسیدن به سرآمدی فنی (Technical Excellence) بایستی به صورت جدی و عمیق مطالعه کنند.

———————–

فرید:

او کتاب Adaptive Code: Agile coding with design patterns and SOLID principles, 2nd Edition نوشته‌ی گری مک‌لین هال را معرفی می‌کند. این کتاب با توضیح مختصری در مورد اسکرام و سازکارهای آن آغاز می‌شود. در ادامه برای سازکارهای تشریح شده نمونه کدهایی را ارائه می‌کند. در این نمونه‌ها از اصول SOLID و فن‌آوری‌های مایکروسافت استفاده می‌کند. کتاب روی موضوع کدنویسی تطبیقی (Adaptive) تمرکز دارد؛ به‌طوری که در طول فرایند تولید نرم‌افزار با اسکرام نیازها و تغییرات جدید را تطبیق داد.

برای آشنایی و یادگیری تست‌نویسی ایشان کتاب The Art of Unit Testing, Second Editionنوشته‌ی رُی اُشیرِو را معرفی کرده است. در این کتاب اصول تست‌نویسی تشریح شده است. همچنین در بخش‌هایی از کتاب نیز از تکنولو‌ژی‌های پرطرفدار دات نت برای پیاده‌سازی اصول استفاده کرده و آنها را مقایسه و تشریح کرده است. مثلاً در بخشی از کتاب مفهومIsolation Framework را مفصل توضیح داده است و ضمن تشریح اصول حاکم بر آن، نمونه‌هایی هم که در دانت از آن‌ها وجود دارد را در کتاب آورده است.

در کتاب Poepleware :productive projects and teams, 3rd Edition نوشته‌ی تام دِمارکو نکات خیلی مهمی از محیط فیزیکی کار، استخدام و نکات مربوط به آن‌ها، نحوه رفتار در تیم و مباحث نسبتا فنی را مطرح می‌کند. این کتاب فوق العاده است و شما با خواندن آن حس می‌کنید نویسنده‌های این کتاب در کنار شما نشسته‌اند و چیزهایی که در محیط کار با آن‌ها مواجه هستید را دیده و تحلیل‌ کرده است.

چاپ دوم کتاب Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries نوشته‌ی براد آبرامز با این که قدیمی به نظر می‌رسد ولی معمولا به توسعه‌دهندگان کم تجربه اکیداً توصیه می‌شود که حتما این کتاب را مطالعه کنند. این کتاب دید خیلی خوبی در مورد نوشتن کدها می‌دهد که مصرف کنندگانش خودشان برنامه‌نویس‌ها هستند. لازم نیست که یک کتابخانه برنامه نویسی مفصل بنویسید تا این کتاب بدرد شما بخورد. برای نوشتن کد در پروژه‌های نستباً کوچکی که چند نفر در آن کار می‌کنند هم بسیار مفید است. نویسنده کتاب مدیر تولید یک یا دو نسخه دات‌نت بوده است و از تجربیاتش در طراحی چارچوب دات‌نت و بعضاً اشتباهاتشان در طراحی صحبت کرده است! این کتاب به نحوی یاد می‌دهد در دات‌نت چطور با الگوهای آن خوب کد بنویسیم.

کتاب 97Things Every Software Architect Should Know: Collective Wisdom from the Experts نوشته‌ی ریچارد مانسون مجموعه‌ای از مقالات کوتاه در مورد موضوعات خاص طراحی، معماری و تیم است که توسط افراد شناخته شده‌ای نوشته شده و تحت عنوان این کتاب مجموعاً به چاپ رسیده است. این کتاب به نظر ایشان در رده کتاب Peopleware قرار می‌گیرد. این کتاب ابزار انتقال تجربه‌ی نویسندگان به خوانندگان است. زمانی که خواننده این کتاب را می‌خواند با نویسندگان کتاب هم صحبت می‌شود و از دانش و تجربه ایشان بهره‌مند می‌شوند.

———————–

ابراهیم:

یکی از نویسندگان کتاب Object-Oriented Analysis and Design with Applications, 3rd Edition گریدی بوچ است که یکی از اعضای گروه موسوم به Three Amigos از پیشگامان مفاهیم شی‌گرایی می‌باشد. کتاب سه بخش کلی دارد. در بخش اول مفاهیم شی‌گرایی به شکل بسیار عمیق (خصوصا در فصل اول که بحث‌ها جنبه فلسفی پیدا می‌کند) مورد بحث قرار می گیرد. در بخش دوم کتاب یک روش تکراری-افزایشی برای تولید شی‌گرای نرم افزار معرفی می‌شود که خیلی شبیه به متدولوژی RUP است. البته نویسنده کتاب آن را به نحو دیگری معرفی می‌کند. در بخش سوم کتاب روش معرفی شده در بخش دوم با چند کاربرد عملی توضیح داده می‌شود. کتاب متن روانی دارد که با توجه به حوزه مورد بحث (شی‌گرایی) به نسبت کتاب قدیمی محسوب نمی‌شود.

گروه متدهای چابک:

برای عضویت در گروه متدهای چابک، از این آدرس استفاده نمایید.

گزیده:
ندارد

چند روز پیش، یکی از دوستانم در تلگرام از من پرسید: “می‌خواستم ازتون بپرسم اگه بخوام شروع کنم به مطالعه در زمینه‌ی Lean، شما مطالعه‌ی چه کتابی را توصیه می‌کنید؟”

در پاسخ برایش نوشتم: “برای چه می‌خواهید Lean یاد بگیرید؟”

ایشان پاسخ دادند: “

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

و خیلی علاقمندم بدونم تفکر ناب چیه. یادمه سر کلاس اجایل، شما هم به مفهوم Lean خیلی علاقه‌مند بودید و من اولین بار اون‌جا اسم تفکر ناب رو شنیدم.
بعدش چندباری از جاهای مختلف دیگه مدل‌های دیگه‌ای شو شنیدم به خصوص Lean Startup یا Lean Canvas
حالا می‌خوام بدونم Lean در صنعت آی‌تی و زندگی به چه درد من می‌خوره”

با دیدن این پیام به این نتیجه رسیدم که باید مطلبی برای ایشان بفرستم که علاوه بر تاریخچه، چارچوب نظری تفکر ناب را نیز در بر داشته باشد.

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

علاوه بر آن، آدرس مقاله‌ای را هم برای ایشان فرستادم که بتوانند خیلی زود، پاسخ‌ پرسش‌های خود را پیدا کنند. این مقاله به قلم “مری پاپندیک” (Mary Poppendieck)، نویسنده و متفکر معروف حوزه‌ی توسعه‌ی ناب (Lean Software Development) است.

مقاله‌ی Lean Software Development: The Backstory که در سال ۲۰۱۵ نوشته شده است، مروری دارد بر تاریخ‌چه، تفکر، شباهت و تفاوت آن با چابکی، اصول و وضعیت توسعه‌ی ناب نرم‌افزار در سال ۲۰۱۵.

به صورت خلاصه چند نکته‌ی مهم در مورد تفکر ناب را به نقل از سایت پاپندیک‌ها در اینجا ذکر می‌نمایم .

Lean software development came to focus on these areas:
* Build the right thing: Understand and deliver real value to real customers.
* Build it fast: Dramatically reduce the lead time from customer need to delivered solution.
* Build the thing right: Guarantee quality and speed with automated testing, integration and deployment.
* Learn through feedback: Evolve the product design based on early and frequent end-to-end feedback.

Principles:

Appreciate the Entire Value Stream
… from concept to cash.
Optimizing any part will sub-optimize the whole.

Think Long Term
Think backward from the future.
Think forward to the next generation.

۳) Energize Workers

Building the Thing Wrong
If it seems like there is not enough time to build it right, then there certainly is not enough time NOT to build it right.

A Batch and Queue Mentality
Work in progress hides defects, gets obsolete, causes task switching, and delays realization of value.

۵) Enhance Learning

Integrating Events
Knowledge-based development seeks out knowledge gaps, develops multiple options for solutions, and frequently synchronizes all teams developing the system.

The Last Responsible Moment
Don’t make expensive-to-change decisions before their time – and don’t make them after their time!

Focus on Flow Efficiency, not Resource Efficiency
Resource efficiency interferes with the smooth flow of value; it often delivers half the value for twice the effort.

Manage Workflow rather than Task-based Schedules
The best way to establish reliable, predictable deliveries is to establish reliable, repeatable workflows.

Integrate Early and Often
Every development process ever invented had as its primary purpose to find and fix defects as early in the development process as possible.

Don’t Tolerate Defects
If you expect to find defects during final verification, your development process is defective.

Pay Attention to the Small Stuff
Reliable performance comes when noise is not tolerated, when small failures are deeply investigated and corrected.

Use the Scientific Method
Establish a hypothesis, conduct many rapid experiments, create concise documentation, and implement the best alternative. Then choose another problem and do it again.

گردآوری: یاسر کازرونی

پیش‌گفتار:

متن زیر خلاصه‌ی بخش‌هایی از گفتگوی اعضای گروه تلگرامی «متدهای چابک» (Agile Methods) است.

گفتگو:

در گروه پیشنهاد شد که دوستان با هم‌فکری هم یک فهرست از کتاب‌های ضروری برای مطالعه‌ی تیم‌های چابک تهیه کنند. موضوعاتی که تیم‌ها برای رسیدن به سرآمدی فنی (Technical Excellence) بایستی به صورت جدی و عمیق مطالعه کنند.

———————–

محمد حسین:

کتاب The Art of Agile Development نوشته‌ی آقای جیمز شور را معرفی می‌کند. او دلیل این معرفی را متن روان کتاب می‌داند و این کتاب را به کسانی که بعد از خواندن چند متن کوتاه مثل بیانیه چابک و راهنمای اسکرام می‌خواهند با مفاهیم چابکی آشنایی عمیق‌تری پیدا کنند به عنوان اولین کتاب پیشنهاد می‌کند.

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

ایشان به شدت خواندن این کتاب را حتی برای باتجربه‌ها پیشنهاد می‌کنند.

———————–

روح‌الله:

او به تیم‌هایی که مشغول توسعه نرم‌افزارهای سازمانی هستند توصیه می‌کند که برای دستیابی به سرآمدی فنی (Technical Excellence) حداقل یک کتاب درباره Domain Driven Design مطالعه کنند.

او در ادامه سه کتاب شاخص را در این زمینه معرفی می‌کند:

کتاب Domain-Driven Design: Tackling Complexity in the Heart of Software از اریک اوانس اولین کتابی است که در این زمینه نوشته شده است. در این کتاب، الگوهای تکنیکی و الگوهای استراتژیک را به خوبی توضیح داده شده است و کتاب مرجع محسوب می‌شود.

کتاب بعدی Implementing Domain-Driven Design نوشته ورنون است. این کتاب مکمل کتاب اوانس است. فرق مهم این کتاب با کتاب قبلی این است که به مباحث معماری CQRS می‌پردازد و از این نظر یک انسجام فکری در خواننده ایجاد می‌کند.

کتاب سوم Patterns, Principles, and Practices of Domain-Driven Design نوشته اسکات میلت است که جدیدترین کتاب در این زمینه محسوب می‌شود. این کتاب توانسته است بازخوردهای توسعه‌دهندگان و پیشنهادات آنها را مطرح کند و از کتاب‌های قبلی کامل‌تر به نظر می‌رسد.

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

———————–

محمد حسین:

او کتاب ماندگار و کلاسیک Working Effectively with Legacy Code از مایکل فذرز را معرفی می‌کند. این کتاب درباره این است که چگونه در سیستم‌های قدیمی (Legacy System) تغییر ایجاد کنیم و آنها را به سمت بهتر شدن سوق دهیم.

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

مارتین فولر در کتاب Refactoring به مبحث بازسازی کد می‌پردازد و فذرز درباره‌ی آماده کردن سیستم برای بازسازی کدها صحبت می‌کند. این موضوع از آن جهت حائز اهمیت است که بازنویسی کد بدون آزمون واحد خطرناک است و احتمالاً منجر به تولید باگ می‌شود؛ زیرا تا وقتی که پوشش آزمون صددرصد روی کُد نداشته باشیم، اطمینان نداریم تغییرات‌مان باعث ایجاد باگ شده است یا نه؟ از این رو فاولر در کتابش بازنویسی کد را با پشتیبانی آزمون واحد (Unit Test) توام می‌داند اما از طرفی به این سؤال هم جوابی نمی‌دهد که چگونه در سیستمی که از قبل موجود است آزمون واحد اضافه کنیم! او فرض می‌کند که سیستم از ابتدا با TDD توسعه‌ یافته است.

این سؤالی است که مایکل فذرز به آن جواب می‌دهد. در کل می‌توان گفت که موضوع کتاب ایشان این است که چگونه به کمک آزمون‌های واحد، در یک سیستم موجود که آزمون واحد ندارد تغییر ایجاد کنیم! از این نظر فذرز آزمون‌های واحد را به چاقوی جراحی تشبیه می‌کند؛ او می‌گوید: «همان‌طور که جراحی کردن نیاز به ابزار حرفه‌ای یعنی چاقوی مخصوص جراحی دارد، تغییر دادن در سیستم موجود نیاز به ابزار حرفه‌ای دارد که آزمون واحد است». فذرز حتی می‌گوید: «تغییر دادن در یک سیستم موجود بدون آزمون واحد کاری غیرحرفه‌ای هست! چون ممکن است منجر به باگ شود.»

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

این کتاب از سه بخش اصلی تشکیل می‌شود که هر کدام شامل چند فصل است:

در بخش اول مفاهیم کلی را مطرح می‌کند (که خلاصه‌ای از آن را آوردیم) و مفاهیمی مثل آزمون واحد را تعریف می‌کند.

در بخش دوم که بخش اصلی کتاب است برای حالت‌های مختلف راهنمایی‌هایی برای تغییر کُد ارائه می‌دهد. مثلاً «من نمی‌توانم این متد را در آزمون فراخوانی کنم» یا «من می‌خواهم یک تغییر بدهم ولی نمی‌دانم چه تست‌هایی باید بنویسم که مکمل هم باشند».

در بخش سوم هم یک کاتالوگ از تکنیک‌های وابستگی‌شکنی (Dependency Breaking) را مطرح می‌کند که شبیه تکنیک‌های بازنویسی‌های فاولر است با این تفاوت که کم‌ریسک است و هدفش صرفاً شکستن وابستگی‌های داخل کُد برای آسان شدن نوشتن آزمون واحد است؛ تازه بعد از آن می‌توان بازنویسی‌های کتاب فاولر را انجام داد.

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

گروه متدهای چابک:

برای عضویت در گروه متدهای چابک، از این آدرس استفاده نمایید.

گردآوری: یاسر کازرونی

پیش‌گفتار:

متن زیر خلاصه‌ی بخش‌هایی از گفتگوی اعضای گروه تلگرامی «متدهای چابک» (Agile Methods) است.

گفتگو:

در گروه پیشنهاد شد که دوستان از تجربه‌های به‌کارگیری مفاهیم سرآمدی فنی (Technical Excellence) در تیم‌های خود بگویند و کتاب‌ها و مطالب مفید در این خصوص را برای آشنایی سایر عزیزان معرفی نمایند. آن چه می‌خوانید خلاصه‌ای است از این گفتگوها.

———————–
محمد حسین:

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

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

ما در اولین فرصت، شروع به بازنویسی یکی از ماژول‌‌های بزرگ و مشکل‌دار سیستم کردیم. در این بازنویسی علاوه بر تجربه‌هایی همچون استفاده از توسعه تکراری-تدریجی، تعریف شرایط پذیرش، استفاده از آزمون‌گر در تیم، استفاده از CI، کار گروهی و آزمون پذیرش خودکار تصمیم گرفتیم از TDD هم استفاده کنیم و به اصول بازسازی کد و تمیز نوشتن کدها نیز اهمیت دهیم.

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

او دلیل موفقیت این تیم را عوامل زیر می‌داند:

1. تمرکز و همبستگی
2. انگیزه‌ی بالای تیم برای اثبات توانمندی خود به سازمان
3. داشتن دانش و تجربه‌ی قبلی در کسب‌و‌کار

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

———————–

روح‌الله:

معتقد است که بدون توجه به اصولی مانند SOLID‌ یا Design Patterns و به‌روش‌های TDD ادعای چابکی کردن ‌ادعای بی‌اساسی است. او به همه‌ی توسعه‌دهندگان و تیم‌های چابک پیشنهاد می‌دهد یک‌بار کتابClean Code را مطالعه کنند.

True flexibility (agility) can only happen when you are able to make changes to the product in a easy, fast, and flexible way. In that sense Organizational Agility is constrained by Technical Agility

او همچنین مثال قبلی (تیم محمد حسین) را یک نمونه خوب از تاثیر مثبت ارزش Courage و اثربخشی در موفقیت یک تیم چابک می‌داند.

———————–

سهیل:

به نقل جمله‌ای از ناپلئون می‌پردازد و تسلط نداشتن و استفاده نکردن از تجربه‌های خوب مهندسی را دلیل نرسیدن به چابکی می‌داند:
چابکی یعنی وقتی برای یک مساله چندین راه حل داشتی، اونی رو انتخاب کنی که تغییر در آینده رو بتونه مهار (ساده) کنه [نه حتی بهترین یا سریعترین راه رو!]

———————–

فرید:

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

———————–

مهرداد:

مشکلات فنی را در تیم فعلی خود مطرح می‌کند و استفاده از مفاهیم سرآمدی فنی را لازم می‌داند. برخی از این مشکلات عبارتند از:

1. پاسخ‌گویی نامناسب به نیاز‌های مشتری در پروژه‌های قدیمی
2. تمایل نداشتن توسعه‌دهندگان تیم برای بازنویسی کدهای این پروژه‌ها
3. نداشتن قابلیت نگهداری کدها و استفاده مجدد از آنها
4. عدم امکان استفاده از معماری و چارچوب‌های جدید
5. نداشتن مرجع کاملی از مستندات کدها
6. تکراری و طولانی بودن کدها

منابع پیشنهادی:

1. Working Effectively with Legacy Code, Michael-Feathers
2. Refactoring: Improving the Design of Existing Code, Martin Fowler
3. Clean Code: A Handbook of Agile Software Craftsmanship, Robert C.Martin

گروه متدهای چابک:

برای عضویت در گروه متدهای چابک، از این آدرس استفاده نمایید.

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

ابتدا با اسکار فیشینگر آشنا شویم:

اسکار فیشینگر (به آلمانی: Oskar Fischinger) (متولد ۲۲ ژوئن ۱۹۰۰ در آلمان – متوفی ۳۱ ژانویه ۱۹۶۷ در لس آنجلس) انیماتور، فیلمساز و نقاش آبستره آلمانی بود.
او بیش از پنجاه انیمیشن کوتاه و هشتصد تابلوی نقاشی در کارنامه خود دارد که بسیاری از آن‌ها در موزه‌ها، نمایشگاه‌ها و مجموعه‌های مختلف در سراسر دنیا نگهداری می‌شوند. یکی از انیمیشن‌های او با عنوان نقاشی متحرک شمارهٔ ۱ که در سال ۱۹۴۷ ساخته شد، در فهرست ملی فیلم در کتابخانه کنگره آمریکا ثبت شده‌است. فیشینگر هم‌چنین به عنوان یکی از پیشگامان ساخت نماهنگ شناخته می‌شود و از معدود فیلمسازانی است که ذوق سمعی و بصری چشمگیرش را با دید علمی و هندسی عمیق به اجسام -که بخاطر تجربهٔ فیشینگر در معماری در او بوجود آمده بود- در خلق شاهکارهای بصری تلفیق می‌کند. او در سال ۱۹۳۵ و پس از شدت گرفتن فشارهای ممیزی حزب نازی روی هنر آبستره، مجبور به ترک آلمان به مقصد هالیوود شد و پایه‌گذار سنتِ تلفیق حرکت و موسیقی در انیمیشنهای والت دیزنی گردید. (مرجع: ویکی پدیا)

بعد هم این آدرس را ببینید:

http://g.co/doodle/p23u5q

حالا سعی کنید به صورت تصویری، آهنگ بسازید و از شنیدن آهنگ‌تان لذت ببرید.

اگر هم فرصت داشتید فیلم An Optical Poem محصول 1938 را در اینجا ببینید .

سپاسگزارم گوگل!

گزیده:

Everything in the world has a spirit which is released by its sound. Oskar Fischinger

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

خواندن کتاب، دوستی با یک فرد، دیدن یک فیلم، ….، نمونه‌ای از این پدیده‌ها و رویدادها هستند.

چند وقتی است که ذهن‌ام به شدت درگیر موضوع anti-fragile است که آقای نسیم نیکولاس طالب نظریه‌پرداز آن است. فعلا جز برخورد کردن با در و دیوارهای ندانستن و نفهمیدن، کار دیگری از دست‌ام بر نمی‌آید.

گزیده:

ندارد.

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

او رو به دو دخترها می‌کند و می‌گوید: “دو سه تا از وسایل‌تون رو بذارید توی یه کارتون، ببریم بذاریم تو اون خونه‌هه. فعلا اون جا باید کارگر بیاد، خونه رو تمیز کنه. ولی هر کدوم‌ از شما، دو سه تا از وسایل‌تون که خیلی براتون مهمه رو جدا کنید، ببرید بذارید توی کمدهای خونه جدیده.”

پارمیس و آمیتیس رو به بابا می‌کنند و می‌پرسند:”مثلاً چه چیزهایی؟”

پدر در پاسخ می‌گوید: “من نمی‌دونم چه چیزهایی، می‌خوایم اسباب‌کشی کنیم، کارگر میاد. دو سه تا چیزی که خیلی براتون مهمه که توی اسباب‌کشی گم و گور نشه، خراب نشه، بردارید بذارید توی کارتون”.

و این هم دو کارتون دخترهای خوشگل که مهم‌ترین دارایی آنها در زندگی است:

گزیده:

«فرزندانِ شما، حضورتان را بیشتر از هدیه‌هایتان لازم دارند.» جسی جکسون