همایش ژاکت دی (ZHAKET DAY)

همایش ژاکت دی (ZhaketDay) با حضور متخصصان و علاقه‌مندان به زبان برنامه‌نویسی PHP و JavaScript، روز پنجشنبه 14 مرداد ماه در مرکز همایش‌های هتل قلب تهران برگزار شد. در این رویداد، لقمان آوند هم‌بنیانگذار سون لرن، پیمان گلدسته مهندس ارشد نرم‌افزار اسنپ، حسام موسوی بنیانگذار راکت و احسان ملکی موسس باشگاه اپلیکیشن به بیان تجربیات خود پرداختند.

در اولین گردهمایی جامعه برنامه‌نویسان PHP ژاکت دی مطرح شد:

سبک ‌زندگی متفاوت برنامه‌نویسان، یکی از مسائل مطرح شده در همایش ژاکت دی

علی حاج‌محمدی؛ بنیانگذار مارکت وردپرس ژاکت

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

فقط برنامه‌نویس نباشید

خیلی وقت‌ها فردی برنامه‌نویس خوبی است اما با خانواده یا دوستان رابطه خوبی ندارد، چرا؟ چون مطالعه نکردند، چون بلد نیستند، به مشکل برخوردند و حلش نکردند. یک مذاکره ساده تبدیل به کدورت می‌شود. حاج‌محمدی در ادامه صحبت‌هایش در همایش ژاکت دی افزود: یا حوزه معنویت که قسمت جدا‌نشدنی از ثروت است و هر‌کسی نیاز معنوی خود را تامین می‌کند. پس ما باید کاری کنیم که از زمانی که ۱۲‌ساعت پر است، برسیم به زمانی که روی ابعاد دیگر زندگی خودمان کار کنیم. چطور باید ۱۲‌ساعت را خالی کنیم در حالی‌که درآمدمان کمتر که نشود هیچ، بیشتر هم شود. سیستم ‌سازیم، حرفه‌ای‌تر شویم، فروش آنلاین داشته باشیم، درآمد غیر‌فعال بسازیم. راه‌های خیلی زیادی برای درآمد غیرفعال وجود دارد. اگر روی بقیه مهارت‌های خود کار کنیم، چندین راه وجود دارد؛ یعنی وارد دسته ساخت کسب‌و‌کار شویم.  ولی اگر بخواهید از برنامه‌نویسی پول در‌بیاورید اما غیرفعال باشید، 2 راهکار ساده وجود دارد که باید پیاده کنید.

اولین راهکار اینکه بتوانید تیم بسازید. وقتی به هر فریلنسری می‌گوییم ما این پروژه را داریم و پروژه بزرگ است می‌گوید وقت ندارم. مشکل زمان است. وقتی یک برنامه‌نویس برای یک پروژه ۴۰ ساعت زمان می‌خواهد، روی کاغذ یعنی 5 روز اما در واقعیت یعنی همان 40روز. چون برنامه‌نویس جاهایی از پروژه را شاید ندیده و به مشکلاتی بر بخورد که حل آنها ممکن است روزها زمان ببرد.

راهکار دوم اینکه باید محصول بسازید. یک محصول، یک اسکریپت، یک CMS، یک تم، یک پلاگین که وقتی حتی خواب هستید بتواند برای شما پول بسازد. این محصول یک سرمایه‌گذاری بلند‌مدت است، یک ماه یا بیشتر روی ساخت یک محصول زمان می‌گذارید از بعد از ساخت، درآمد آن خیلی شیرین است. درآمد غیرفعال است یعنی انرژی کمی برای درآمد می‌گذارید.

حاج‌محمدی درباره تجربیات خود در همایش ژاکت دی گفت: در ژاکت قسمت‌هایی داشتیم که حتی کد زده شد، فرانت هم زده شد اما لانچ نشد. به همین دلیل ما یک تصمیم اساسی گرفتیم که هم ایده‌ها نسوزند و هم اتفاق بهتری بیفتد. قسمتی که خیلی به لانچ نزدیک است market place خدمات است. در این قسمت دیگر محصولی ارائه نمی‌شود، خدمات ارائه می‌شود. مثلا یک برنامه‌نویس می‌گوید می‌توانم برای شما پلاگین اختصاصی بنویسم، دیگری می‌گوید در این رنج قیمت می‌توانم پلاگین فارسی کنم یا تم فارسی کنم. قسمت جالب‌تر این است که می‌خواهیم یک مرکز نوآوری راه‌اندازی کنیم. در این مرکز نوآوری هم ایده‌های خود ما هست و هم ایده‌های دیگران. هدف این مرکز، پشتیبانی از ایده‌ها در حوزه دیجیتال مارکتینگ است.

مزایا و معایب استفاده از زبان برنامه‌نویسی PHP در سایت

پیمان گلدسته؛ مدیر ارشد نرم‌افزار اسنپ

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

اولین مورد FILE HANDLING است. FILE HANDLING معمولا فایل‌هایی هستند که موقع آپلود با آنها سر و کله می‌زنیم. مشکل کجاست؟ فرض کنید یک قابلیتی در سرویس خود گذاشتید که کاربران شما بتوانند عکس خود را آپلود کنند. برای عکس یک unique ID در نظر می‌گیرید و همه را در یک فولدر به نام آواتار می‌ریزید. کار می‌کنیم و همه چیز خوب پیش می‌رود. 5 سال می‌گذرد و تعداد کاربران ما به 30 میلیون نفر می‌رسد. در آن موقع در فولدر آواتار بالای 30 میلیون عکس دارید و لود شدن هر کدام از عکس‌ها 30 ثانیه طول می‌کشد. برای حل این مشکل یک راهکار خیلی خوب استفاده از ساختار داده بی تیری یا همان درخت‌های بالانس شده است.

چرا php سریع نیست؟ من 5 مورد که جزو مهم‌ترین موارد است را با شما در میان می‌گذارم:

php مفسری است و همه می‌دانیم که زبان‌های کامپایلری سریع‌تر هستند. php اسکریپت تایپ نیست. پس هر ریکوئستی که مفسر قرار است از آن استفاده کند، نیاز دارد که تایپ آن را چک کند که این performance kill  زیادی است. این زبان برنامه‌نویسی High level API است. یعنی فانکشن‌هایی که در اختیار ما قرار می‌دهند، فقط کاری که برای آنها تعریف شده را انجام می‌دهند. کنترلی روی garbage collection ندارد. البته php بای دیفالت garbage collector دارد. ولی فقط برای فانکشن‌های core – php است. شما در کد نمی‌توانید منابعتان را آزاد کنید. نکته آخر و نکته جالب، کلا  یک عدد data structure native دارد که آرایه است، که در واقع آرایه هم نیست.

برای حل مشکل سرعت در php چه کار باید کنیم؟ کارهای زیادی می‌شود انجام داد، راهکارهای زیادی وجود دارد. دو تا از راه‌هایی که عمومی هستند و روی همه اپلیکیشن‌های php قابل پیاده‌سازی هستند و performance gain آنها به نسبت وقتی که می‌گذارید خیلی چشمگیر است، اینها هستند:

1. اولین راهکار  استفاده از OPcache است. کافی است آن را اجرا کنید و تا ۷۵درصد سرعت شما بهتر می‌شود. البته ما به ۵۰ درصد سرعت بهتر رسیدیم. OPcache دو گام را در هر request life cycle کم می‌کند. یکی پارس کردن و دومی کامپایل کردن به آپ کدها. قسمت سخت هر cache، cache busting است. اگر در container از OPcache استفاده کنید خیلی بهتر است.
2. راهکار دوم، tune کردن PHP FPM. سه کانفیگ اصلی دارد و هر کدام آنها کانفیگ‌های مخصوص به خود را دارند. برای اینکه بفهمیم کدام کانفیگ بهتر است نیاز داریم که تغییراتی که انجام می‌دهیم را مانیتور کنیم.

گلدسته در ادامه صحبت‌هایش در همایش ژاکت دی افزود: یک bad practice دیگر علاقه دولوپر ایرانی به استفاده از repository pattern است. این علاقه منجر به دو اتفاق می‌شود. یکی اینکه repository خیلی چاق می‌شود و دیگر couple می‌شود. برای حل مشکل چاق‌شدن repository ‌می‌توانیم از actionها استفاده کنیم. یعنی به جای اینکه business logic را روی repository   بنویسیم، هر business logic را داخل یک action می‌نویسیم و actionها هم مثل DTOها ورودی DTO دارند و خود آنها یک متد ساده execute دارند و قابل کیو کردن هستند و همه جای سیستم قابل استفاده هستند.

گزینه آخر معمولا در پروژه‌هایی است که سال‌های زیادی است که دولوپ می‌شوند، این است که Legacy Codeهایی که ما با آنها سر و کله می‌زنیم به‌شدت اذیت می‌کند، استفاده‌نکردن از ابزار quality control است. یک راه خیلی ساده وجود دارد. یک ابزاری معرفی می‌کنم به اسم grumphp که خود به‌تنهایی کار خاصی نمی‌کند ولی برای شما بستری را فراهم می‌کند که می‌توانید از ابزار quality control که در php  هست استفاده کنید.

بحث‌های مطرح شده درباره قالب وردپرس در همایش ژاکت دی

احسان ملکی؛ موسس باشگاه اپلیکیشن

در همایش ژاکت دی آقای احسان ملکی، موسس باشگاه اپلیکیشن، به بیان این موضوع پرداخت که Headless CMS چیست و چه کاربردی برای ما دارد؟ او در این باره گفت: headless framework که بیشتر به headless CMS مشهور است به این دلیل که فعلا در حوزه  CMS کاربرد دارد، کارش این است که فقط API را ارائه می‌دهند. یعنی اگر شما یک بخش فرانت دارید مثلا اگر با لاراول کار می‌کنید، انجین ویوی لاراول، بلید است یا جدیدا livewire. اما کار headless framework یا Headless CMS این است که انجین غالب را ندارند، یعنی در بخش ویو برای شما کارایی ندارند به همین جهت خیلی شسته رفته و کوچک‌تر هستند و کاربردهای خیلی دم‌‌دستی خیلی خوبی می‌شود از آنها گرفت.

در دنیای headlessها چیزی به نام  وردپرس داریم. چطور می‌توانیم از وردپرس به عنوان headless استفاده کنیم؟ از ورژن ۴ وردپرس به بعد API به خود وردپرس اضافه شده است اما این API دیفالتی که روی وردپرس اضافه شده اصلا جالب نیست. چون وردپرس سعی کرده همه چیز را برای ما ببیند. یعنی وقتی شما ریکوئست می‌زنید تا پست‌های اخیر خود را ببینید.  هر چی که در دیتابیس دارد برای شما می‌فرستند و طبیعتا شاید نیازی نداشته باشید. اول از همه اینکه سرعت API دیفالت وردپرس آن افتضاح است.

چرا با این اوصاف ما باید از وردپرس استفاده کنیم؟ اگر برنامه‌نویس php هستید، چرا باید از وردپرس انتخاب کنیم در حالی‌که headlessهای دیگری هم وجود دارد. اول اینکه وردپرس توسعه‌پذیر است. یعنی علاوه بر اینکه تا الان با وجود پلاگین‌های مختلف همچنان در حال توسعه پیدا‌کردن است. به همین دلیل با اینکه سرعت مناسبی ندارد اما توسعه‌پذیری خوبی دارد و این یکی از دلایلی است که شما باید از وردپرس استفاده کنید.

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

دنیای زبان‌های برنامه‌نویسی بدون فریم‌ورک‌ها چگونه است؟

حسام موسوی؛ بنیانگذار راکت

حسام موسوی، بنیانگذار راکت با موضوع دنیا بدون فریم‌ورک‌ها به سخنرانی در همایش ژاکت دی پرداخت: آقای آوند درباره طرح صیانت صحبت کردند. یک لحظه از ذهن همه ما گذشت که اگر اینترنت به شکل الان نباشد ما چه کار کنیم؟ نظر من این است که اگر در حال حاضر فریم‌ورک‌ها، لایبرری‌ها، برای زبان‌های برنامه‌نویسی مثل php، جاوا اسکریپت، پایتون و مابقی وجود نداشته باشند، احتمالا با سختی‌های زیادی مواجه می‌شویم. اگر تخصصی بخواهیم بگوییم پروژه‌هایی که با زبان‌های مختلف توسعه داده می‌شوند، داستانی که به وجود می‌آید این است که ما دو انتخاب داریم. اول اینکه با pure php یا Vanilla.js پروژه‌های مختلفی را پیاده‌سازی کنیم. اگر این کار را بکنیم از فریم‌ورک‌ها یا لایبرری‌های در آن زبان‌ها استفاده نکنیم، چه مشکلاتی به وجود می‌آید؟

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

اولین مشکل مقیاس‌پذیری پروژه‌هاست. شما می‌توانید خیلی راحت با pure php و Vanilla.js کدهای خود را توسعه دهید و هیچ مشکلی هم ندارد. ولی نکته مهمی که وجود دارد این است که اگر اول کار ندانید که پروژه شما چقدر بزرگ است و فقط با pure php و Vanilla.js کدها را پیاده‌سازی کنید، ولی فریم‌ورک نداشته باشید، هرچقدر که پروژه بزرگ‌تر می‌شود، مشکلی که به وجود می‌آید، این است که سخت‌تر می‌توانید آن را توسعه دهید. پس اگر پروژه‌ای را انجام داده باشید و قرار به بزرگ‌تر‌شدن پروژه باشد، اگر هدف شما استفاده از Vanilla.js یا pure php است، کم‌کم می‌فهمید که انتخاب اشتباهی کردید. چرا؟ چون اگر یک چارچوب مشخص داشته باشید، در قالب آن چارچوب پروژه‌های خود را توسعه دهید، خواهید دید که کار توسعه زمانی که پروژه بزرگ‌ و بزرگ‌تر می‌شود، راحت‌تر می‌شود.

مورد دوم کار تیمی است. در شرکت‌های مختلف می‌توانید ببینید. اگر از pure php یا Vanilla JS استفاده کنند و قصد داشته باشند که پروژه‌ای را توسعه دهند. داستانی که به وجود می‌آید افراد یک تیم اگر روی یک پروژه‌ای کار می‌کنند و چارچوب مشخصی برای توسعه آن پروژه وجود نداشته باشد، باید هر بار با همدیگر صحبت کنند که چه کدی پیاده شده است؟ ولی وقتی یک چارچوبی وجود داشته باشد مثل لاراول، مثل vue.js، مثل react.js، اتفاقی که می‌افتد این است که به طور دقیق متوجه می‌شوید طرف مقابل شما روی چه بخشی کار می‌کند. تا حد‌ زیادی این مشکل، نه به طور صد در صد برطرف می‌شود.

مورد بعدی سرعت توسعه است. اگر با فریم‌ورک‌ها کار کرده باشید و در کنار آنها با خود Vanilla JS یا pure php کدی را نوشته باشید، صد‌در‌صد متوجه می‌شوید که سرعت توسعه در پروژه‌هایی که فریم‌ورک دارند به‌شدت سریع است.

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

مورد بعدی امنیت است. این مورد به نظر من از تمام مواردی که تا الان گفتم خیلی مهم‌تر است چرا؟ زمانی که یک پروژه‌ای را با pure php توسعه می‌دهید، اتفاقی که می‌افتد این است که تمام کدها، تمام بخش‌ها و اکثر موارد را خود شما باید پیاده‌سازی کنید. ولی اگر از یک فریم‌ورک استفاده کنید، شما یک تیمی از دولوپرها را در کل دنیا دارید که بدون اینکه نیاز باشد شما روی توسعه یک فریم‌ورک و چارچوب کار کنید، به شکل اوپن سورس آن فریم‌ورک را توسعه می‌دهند.

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

همه موارد بالا که لیست کردم، باعث می‌شود بهره‌وری یک پروژه بالاتر برود. یعنی همه اینها به شما کمک می‌کنند پروژه‌ای که پیاده‌سازی می‌کنید با یک چارچوب آماده که توسط N تعداد دولوپر در حال توسعه است، خیلی راحت‌تر به شما نتیجه بدهد. اگر به ۱۰تا ۱۵ سال پیش برگردیم، جایی که فقط pure php یا Vanilla Js را برای توسعه پروژه‌هایمان داشتیم من مطمئنم دوباره همین مسیر طی می‌شد و ما دوباره همین فریم‌ورک‌ها را داشتیم.

چون قطعا برای توسعه پروژه نیاز به چارچوب داریم. بدون چارچوب درست توسعه‌دادن پروژه‌ها مشکلاتی که شرح دادم برای شما پیش می‌آید. اگر شما تجربه یک پروژه صفر تا صدی را فقط با pure php به دست بیاورید کاملا متوجه این داستان می‌شوید. یک آماری از pure php فریم‌ورک‌ها در سال‌۲۰۱۴ تا الان به شما بدهم. چند واژه کلیدی را در گوگل ترندز وارد کردیم، لاراول، سیمفونی، کد ایگنایتر، کیک php در این آمار هستند.

فرق لاراول با وردپرس چیست؟

هیچ وقت یک فریم‌ورک را با CMS مقایسه نکنید. لاراول یک چارچوب است که شما هر چیزی را که به ذهن شما برسد می‌توانید با آن به وجود بیاورید، حتی وردپرس را، ولی وردپرس یک سیستم مدیریت محتواست.

سال ۲۰۱۶ البته قبل‌تر، اگر شما جاوااسکریپت کار می‌کردید همه از شما می‌پرسیدند Jquery بلد هستید یا نه. ولی سال ۲۰۱۶ react در جایگاه اول در دنیاست. حدودا ۵۳درصد از دولوپرهای جاوا اسکریپت از react استفاده می‌کردند. بعد انگیولار، امبر و vue.js. سال ۲۰۱۷ هم تقریبا همین بود فقط vue.js جایگاهش را عوض کرد. مثلا Alpine.js تازه یکی دو سال است که آمده و به واسطه لاراول در حال پروموت‌شدن است و ممکن است خیلی سریع جایگاه بالاتر را هم بگیرد. چرا؟ چون نیاز نیست در فایل‌های جاوا اسکریپتی و فایل‌های js کد Alpine.js بنویسید، در HTML این کار را می‌کنید. ممکن است در سال ۲۰۲۵ تعداد فریم‌ورک‌ها بیشتر شود.

ضرورت یادگیری فریمورک‌ها

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

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

کلیدهای کسب درآمد از php، از دیگر نکات مطرح شده در همایش ژاکت دی

لقمان آوند؛ هم‌بنیانگذار سون‌لرن

لقمان آوند، هم‌بنیانگذار سون لرن، درباره کلیدهای کسب درآمد از php در همایش ژاکت دی گفت: حدود ۱۵۰ تا ۲۰۰سال پیش زمانی که هندوستان مستعمره انگلستان بود، تعداد مارها در شهر دهلی‌نو خیلی زیاد شد. طوری که دولت نمی‌توانست همه آنها را از بین ببرد. تعدادی از افراد تصمیم‌گیرنده تصمیم گرفتند که از مردم کمک بگیرند. قرار شد هر کسی که مارهای کبری را بگیرد و بکشد، در ازای آن پول دریافت ‌کند. مدتی اجرا شد و اوایل خوب بود اما چند ماه گذشت که تعداد مارها دو برابر و سه برابر شد. چرا؟ مردم مزارع پرورش مار کبری زدند. این اثر به اسم اثر مار کبری در سیاست و اقتصاد مطرح است.

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

منظور من از تخصص اصلا تخصص فنی نیست. آدم‌های تک‌بعدی آنطوری که باید رشد نمی‌کنند. مثلا اگر متخصص php لاراول شوید جایی 30 یا 40 میلیون تومان حقوق می‌گیرید ولی در همان جا می‌مانید. اگر می‌خواهید جایی CTO شوید و پوزیشن بالاتر بگیرید، باید کمی درباره رهبری بدانید. باید کمی در ارتباطات و مذاکرات قوی شوید، چون از کودکی تاکنون فقط آموزش‌های فنی دیدیم احساس می‌کنیم چیزی که نیاز به یادگیری دارد همان برنامه‌نویسی و مسائل فنی است.

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