بحث Graybox Fuzzing بسیار توی این سال‌های اخیر مورد توجه قرار گرفته و سعی میشه توی کابردهای مختلفی بیان و یک فازر Target-specific طراحی کنن. بزرگترین ضعف Fuzzer ها زمانیه که به دنیای Distributed Systems و Concurrency ورود می‌کنن. تمام این حرفایی که توی پست بالا در مورد AFLGo زدم صرفا منوط میشه به برنامه‌های Sequential. توی برنامه‌های ترتیبی چون صرفا یک Thread داریم، واسه همین چیزی به اسم Scheduler وجود نداره در مقابل Fuzzer. مثلا همین مثالی که من زدم یا کیس استادی داچمن، این ابزارها میان با تکنیک‌های Static Analysis بررسی میکنن که آیا اون نقطه Reachable هست و هر جا که لازم باشه برای رسیدن به اون نقطه ورودی تهییه کنن، فازر رو صدا میزنن. خیلی بخوان براتون مرام خرج کنن به جای Static Analysis میان از تکنیک‌های Runtime Analysis استفاده میکنن که البته توی اینم خیلی ضعیفن و اکثر ابزارهای قوی این حوزه تکیه شون به Static Analysis عه. یعنی میان از طریق آنالیز سینتکس کدتون پیش میرن. خود غیرقطعی بودن Fuzzer یک طرف، اینکه Static Analysis بخاطر اینکه خیلی از مسائل کلیدیش Undecidable عه کلی corner case به جا می‌ذاره یک طرف.(اینجا یکم توضیح دادم اینو). خب همه‌ی اینا باعث میشه که Fuzzer ها نسبت به یک سری از برنامه‌های ترتیبی هم حتی خوب عمل نکنن. مثلا فرض کن برای اون فرمول f ای که توی پست قبل آوردیم، بیاد و ۱ میلیارد assignment جنریت کنه ولی هیچکدوم نتونن فرمول رو ارضا کنن. سوال، آیا فرمول ارضا ناپذیره، یا اینکه واقعا assignment ای وجود داره که fuzzer نتونسته پیداش کنه؟ جواب، نمی‌دونیم. ایراد بعدی شون توی برنامه‌های Sequential، گیرم Fuzzer بیاد و یه assignment به ما برگردونه و بگه این کار رو خراب میکنه. آقای داچمن هم برن و کلی کد رو بخونن و بالا و پایین کنن و یک patch ای بدن که دیگه برنامه روی اون assignment به باگ نخوره. آیا به راستی حالا که اینطور شده، باگ برنامه برطرف شده؟ جواب، نمی‌دونیم.

حالا بریم سراغ برنامه‌های Distributed و Concurrent. توی این برنامه‌ها یک چیزی هست به اسم Scheduler که داره thread ها رو زمان‌بندی می‌کنه. فازرها وقتی به چنین سدی میخورن هیچ برنامه‌ای براش ندارن. همینطور رندوم scheduler جلو میره و هر وقت لازم باشه برای جلو رفتن یک input ای داده بشه فازر کال میشه. حتی به فرض تهش هم یک assignment ای برگردونده بشه و شما بفهمی که برنامه‌ات باگ داره. از کجا میخوای بفهمی که چه Scheduling ای ما رو به این باگ رسونده؟ عملا دیباگینگ برنامه غیرممکن میشه. حالا همین آقای Abhik سال پیش یک مقاله‌ای رو چاپ کردن با عنوان Greybox Fuzzing of Distributed Systems که نشون بدن خیز برداشتن برای Distributed System. به زودی همین امسال دیس این مقاله میاد بیرون :) برای پیش درآمدش این تاک رو ببینید ( از 5:17:29 تا 5:48:36)

با همه‌ی این توصیفات جا داره بگم که Fuzzing و Static Analysis به هیچ وجه نمی‌تونن جای خالی Verification رو پر کنن و ما این رو با توسعه JMC نشون خواهیم داد. شما وقتی برنامه‌ات رو با JMC وریفای می‌کنی، اگر باگ داشته باشه قطعا پیداش میکنه، برات یک Execution Trace از ابتدای اجرای برنامه برمیگردونه که نشون بده چی شد که به این باگ رسیدیم و علاوه بر اون دیتای کامل Scheduling ای که ما رو به این باگ رسونده رو هم بهتون میده، شما مقایسه کنید Debugging با این حجم دیتا آسون تره و یا صرفا با داشتن چهار تا Value ؟

حالا برای اینکه خیلی هم سر دیباگینگ اذیت نشید یه کاری رو داریم با خانم Andreea Costa شروع میکنیم، ایشون یکی از محققین گروه Abhik هستند، که با استفاده از JMC برنامه رو وریفای کنیم و وقتی باگ رو پیدا کردیم به شکل Automated برنامه رو Repair کنیم تا دیگه باگی نداشته باشه. یعنی نه تنها باگ رو پیدا کنیم بلکه رفعش کنیم و ثابت کنیم که باگ واقعا رفع شده. تمام تکنیک‌های Automated Program Repair تا به امروز بر پایه‌ی Static Analysis و Fuzzing ساخته شدن و قطعا می‌تونید حدس بزنید که Patch هایی که می‌سازه ممکنه واقعا Bug-free نباشه.

خلاصه که فرمال پیشه کنید.

اگر هم میخواید Fuzzing رو اصولی یاد بگیرید و کار کنید، که بسیار توصیه میشه اینکار رو بکنید،‌ منابعی که اینجا گفتم عالین.

استفاده از LLMها چه بلایی سر یادگیری میاره؟

احتمالا در طی این یک سال شما هم متوجه تاثیر استفاده از "AI" توی پروسه‌ی یادگیریتون شدین. تاثیری که اگر نخوام سخت‌گیر باشم، کفه‌ی ضررش ترازه با منفعتش.

Working hard and struggling is actually an important way of learning. When you’re given an answer, you’re not struggling and you’re not learning. And when you get more of a complex problem, it’s tedious to go back to the beginning of a large language model and troubleshoot it and integrate it.

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

https://cacm.acm.org/news/the-impact-of-ai-on-computer-science-education/

علم چیست؟ شبه‌علم چیست؟

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

وقتی راجع‌به علم صبحت میکنیم و این که ادعا کنیم که آیا روشی که به‌کار می‌بریم (یا به ‌کار برده شده) علمی یا scientificه، دو ویژگی براش درنظر گرفته میشه:

۱- تکرار‌پذیری (Replicability) داشته باشه. به این معنی که بشه در شرایط یکسان و با به‌کار گیری روش یک‌سان دوباره به اون نتیجه رسید. البته دو واژه‌ی Reproducibility و Replicability گاها به‌جای هم استفاده میشن. گاهی این دو رو به یک معنا میدونن، گاهی هم تعریف‌های متفاوتی براشون در نظر میگیرن:

In a review paper on the use of the terms reproducibility and replicability, Barba (2018) outlined three categories of usage, which she characterized as A, B1, and B2:

A: The terms are used with no distinction between them.
B1: “Reproducibility” refers to instances in which the original researcher's data and computer codes are used to regenerate the results, while “replicability” refers to instances in which a researcher collects new data to arrive at the same scientific findings as a previous study.
B2: “Reproducibility” refers to independent researchers arriving at the same results using their own data and methods, while “replicability” refers to a different team arriving at the same results using the original author's artifacts.

۲- ابطال‌پذیر (Falsifiable) باشه. به این معنی که اصولا گزاره و نظریه‌ در معرض ابطال باشن. در واقع این امکان وجود داشته باشه که بشه آزمایشی رو طراحی کرد یا مشاهده‌ای رو مطرح کرد که تحت اون بشه اون نظریه یا فرضیه رو رد کرد:

“In so far as a scientific statement speaks about reality, it must be falsifiable: and in so far as it is not falsifiable, it does not speak about reality.”
― Karl R. Popper, The Logic of Scientific Discovery

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

این اپیزود از پادکست «فلسفه‌ی علم» به این میپردازه که چطور علم رو از شبه‌علم میشه تمیز داد. «ابطال‌پذیری» یا «falsifiability» که پوپر اون رو سنجه‌ای برای تشخیص علم از شبه‌علم عنوان کرد به چه معناست و چه رابطه‌ای بین فلسفه‌ی علم و تاریخ علم وجود داره.

و در ادامه، اگر هم راجع‌به تاریخ علم کنجکاوید و میخوایید بیشتر راجع‌به اون بدونید و این که چرا تاریخ علم نقشی اساسی در فهم ایدئولوژی‌ها و اندیشه‌ها داره، میتونین به اپیزود ۲۹‌م همین پادکست تحت عنوان: «چرا تاریخ اینقدر بنیادین است؟» گوش بدین. مهمان برنامه هم دکتر امیرمحمد گمینی ـه که از اساتید پژوهشکده تاریخ علم دانشگاه تهرانن و در زمینه‌ی تاریخ علم و به طور خاص، تاریخ علم در ایران و اسلام کار میکنن.

شاخص بیگ مک

It’s just a burger, but the price of a Big Mac can help us understand the dizzying cost of living.

“If [the price of a Big Mac is] moving, it means there’s something really strong going on in the economy at large,”
-Leonora Risse, associate professor of economics at the University of Canberra.

راجع به شاخص قدرت خرید و سنجش برابری قدرت خرید (PPP) داخل کانال قبلا یکی دو تا پست گذاشتم که به‌نظرم اون‌ها رو ببینید. ارجاع دادم به ویدیو‌ی چراز که خیلی خوب این ماجرا رو توضیح داده. ولی جهت یادآوری، به طور خلاصه: برای این که بشه قدرت خرید مردم کشور‌های مختلف رو سنجید درحالی که ارزش پول یک‌سان ندارند، روش‌‌های مختلفی وجود داره. یکی از اون روش‌ها، روش غیر رسمی‌ه به‌نام شاخص بیگ مک یا Big Mac Index.

ماجرا از این قراره که با پاسخ دادن به این سوال که شما توی کشورتون، با ۵۰ دلار آمریکا (به طور معمول ارز مبدا رو دلار آمریکا در نظر میگیرن)، چند تا بیگ مک میتونید بگیرید به تخمینی از قدرت خرید مردم اون کشور برسید. این که چرا بیگ مک انتخاب شده و فرقش با PPP چیه، ماجرا از این قراره:

- prevalence of the fast food chain worldwide
- the sandwich remains largely the same across all countries.

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

این مقدمه رو گفتم که این مطلب رو بذارم. تو این مقاله اومدن تغییرات هزینه‌‌ی زندگی و بحران‌هایی که در یک بازه‌ی چند‌ساله (از ۲۰۱۷ تا ۲۰۲۴) رو با همین شاخص بررسی کردن. این که چه تغییرات قیمتی توی اجزای یک ساندویچ بیگ مک پیش اومده و یه سری آمار و ارقام دیگه و به طور خاص به دوره‌ی COVID هم پرداختن. این پست اینتراکتیوه و خیلی حرف رو ساده و سر راست میزنه که خوندنش رو جذاب کرده. اگر حوصله داشتید، به‌نظرم خوندنش براتون میتونه هم جالب باشه هم مفید.

https://www.abc.net.au/news/2024-08-05/cost-of-living-interest-rates-burgers/104156654

پی‌نوشت (یادآوری): من تو آگورا بجز مطالبی که مربوط به علوم کامپیوتره و به‌طور مشخص، موضوعاتی که در راستای شغل‌ و تخصص منه، در چیز دیگه‌ای نه متخصصم و نه اداعایی دارم. حتی در باره‌ی اون‌‌هایی که در حیطه کاری منه هم ادعایی ندارم ولی علی‌الاصول به سبب تجربه‌ و درس خوندن تو اون زمینه‌ها احتمال خطاش توی اون‌ها کمتره. به هر صورت، هیچ‌کدوم از مطالبی که این ‌جا مینویسیم که حاصل برداشت شخصی از کنجکاوی‌های شخصیه، مصون از خطا نیستند. اگر چیزی اینجا نوشتم که غلطه یا فکر میکنید که ساده‌سازیش به صحت مطلب خدشه‌ای وارد کرده خوش‌حال میشم بهم بگید. چه توی pv، چه توی کامنت‌ها.

یه بابایی اومده و کامپیوتر ۸‌بیتی که توی کتاب "But How Do It Know? " نوشته‌ی J Clark Scott توصیف شده رو با Go و Assembly شبیه‌سازی کرده بدون این که درگیر کار با ادوات الکترونیکی بشه. اینجا راجع‌به این تجربه‌ش نوشته:

A few months ago it dawned on me that I didn’t really understand how computers work under the hood. I still don’t understand how modern computers work. However, after making my way through But How Do It Know? by J. Clark Scott, a book which describes the bits of a simple 8-bit computer from the NAND gates, through to the registers, RAM, bits of the CPU, ALU and I/O, I got a hankering to implement it in code.

https://djharper.dev/post/2019/05/21/i-dont-know-how-cpus-work-so-i-simulated-one-in-code/


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

Building an 8-bit breadboard computer!

یه یارویی هست تو یوتیوب که میاد چیزای مختلفی رو با لگو می‌سازه. احتمالا ویدیو‌هاش به چشمتون خورده. این ویدیو رو که اخیرا گذاشته واقعا جذاب بود! میاد هربار یک برج لگویی درست میکنه و یک ماشین (باز هم با لگو) طراحی میکنی که بتونه این برج رو خراب کنه. بعد از هر بار که موفق میشه، میاد و سازه‌ش رو سنگین تر و محکم‌تر میکنه طوری که مجبور بشه ماشینش رو بازطراحی کنه که بتونه از پس تخریب سازه‌ی جدید بر بیاد. خودتون ببینید:


https://www.youtube.com/watch?v=HY6q9hwYcoc

یک مورد دیگه رو هم من اشاره کنم که خیلی به چشمم اومد.

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

شاید این مثل من به درد شما هم خورد: How to read a research paper

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

احتمالا خیلی از شمایی که اینجاید مشکل خواب دارید و خب خوبه که یه فکری به حالش بکنیم. این ویدیوییه که امروز منتشر کرده با موضوع خواب:

https://www.youtube.com/watch?v=XCdjr-xbDFw

این برنامه با همکاری «مرکز تحقیقات علوم و اعصاب» و «انجمن پزشکی خواب ایران» تهیه شده.

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

بخش مهم کیفیت یه نرم افزار به انرژی ای بستگی داره که اول پروژه میذاری، هر چقدر تو شروع کار روی ساختار کار کنی، و بتونی مواردی مثل linter و security check و test رو به پروسه ci پروژه اضافه کنی کارت راحت تره، خلاصه که کارهای شروع پروژه رو به عقب ننداز که بعدا بعیده درستش کنی..

@gocasts

Assembler, Compiler, Linker, Interpreter, Loader all in simple words

https://ce101ms.wordpress.com/wp-content/uploads/2014/02/compiler_assembler_linker_loader.pdf

اگر علاقه‌مند به سیستم‌های فشرده‌سازی (و به‌طور خاص، عکس‌ها) هستید، حتما یه نگاهی به وب‌سایت JPEG بندازید. ماجرا از اینجا شروع شد که داشتم خبر شایعه‌ی امکان اضافه‌شدن پشتیبانی و ذخیره‌ی عکس‌ها با فرمت JPEG-XL در آیفون ۱۶ رو میخوندم و به سببش با این فرمت آشنا شدم. با همون عادت همیشگی شروع کردم یکم بیشتر سرک کشیدن و خب خیلی سریع هم سر از وب‌سایت رسمی JPEG در آوردم. برام جالب بود که ما چندین و چندین نوع از JPEG داریم: XR, XS و ... که هرکدوم کاربرد و ماجرای خودشون رو دارن.

اینجا میتونید خیلی بیشتر و مفصل‌تر راجع‌به JPEG-XL بخونید و اگر خیلی نرد بودین هم، میتونید اینجا و اینجا بیشتر راجع‌به Entropy Coding که برای فشرده‌سازی Lossless استفاده میشه و در JPEG-XL هم استفاده شده بخونید.

این رشته توییت جالب از سرگذشت «یک میلیون چک‌باکس» رو از دست ندین:

https://x.com/Loc0m0/status/1832188628719825347

خود ماجرا رو هم میتونید از زبون خود سازنده، تو یوتیوب ببینید که بامزه‌س:

https://youtu.be/OI4DbECnp8A?si=T3Y0PLuPrZMFNCBh

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

واقعیت غیرقابل انکاری که وجود داره وجود یک gap میان software engineering و data scientist هاست. دیتاساینتیست‌ها معمولا به دانششون در حوزه هوش و تحلیل داده می‌نازند، در حالی که هر چه قدر هم این دانش عمیق باشه اما در موقعیت‌های عملی واقعی که نیاز به طراحی و توسعه یک محصول پایدار و منعطف با همراهی با بقیه توسعه‌دهنده‌ها می‌ره، نیاز به نوعی دانش و مهارت مهندسی نرم‌افزار وجود داره. حالا این کتاب Software Engineering for Data Scientist از انتشارات Oreilly سعی داره تا همین گپ رو برای دیتا ساینتیست‌ها پر کنه و به میزان کافی و نه بیشتر، به اونها نکات مهندسی‌طور قضیه رو هم انتقال بده. کتاب متن خوبی داره و واقعا قبل از این که یک کتاب مهندسی نرم افزار باشه یک کتابیه که انگار از زاویه دید یک دیتا ساینتیست به مسائل و راه‌حل‌هاشون نگاه کرده، برای همین خیلی‌ جاها مثال‌هاش رو حتی روی ژوپیتر نوتبوک هم زده. این کتاب ۱۵ فصل داره:
چه طوری بهتر کد بنویسم و کد خوب اصلا چیه
چه طوری و از چه زوایایی عملکرد کد رو آنالیز کنیم
چه‌طوری از داده‌ساختار‌ها بهتر استفاده کنیم و در هر موقعیت از کدامشان استفاده کنیم
برنامه نویسی OO و Functional، چطور از هر کدوم در موقعیت مخصوص به خودش استفاده کنیم.
هندل‌کردن ارورها و لاگ و دیباگ
مسائل Code Formatting و Linting
تست‌کردن کد
دیزاین و ریفکتور، چطوری پروژه‌مون رو ساختاردهی کنیم و از یک نوتبوک به یک اسکرپیت برسیم
داکیومنتیشن و این که چگونه کدمون رو برای بقیه قابل خوندن و فهمیدن کنیم
به اشتراک گذاری کد و چیزایی مثل Version Control و Dependency
درست کردن API
دپلوی‌کردن و آشنایی با ابزارهای اتومات نظیر CICD
امنیت و ریسک‌ها و خطراتی که می‌تونن تهدید کنند
مهارت‌های توسعه نرم‌افزار و یک سری مفاهیم پیشرفته‌تر از جمله این ۱۵ فصل کتاب هستند. من این کتاب رو چند وقت پیش خوندم و ضمن لذت‌بردن نوع نگاهم به بعضی مسائل رو هم تغییر داد. بعد از چند وقت اما حس کردم که برای بهتر ملکه ذهن شدنم نیاز دارم تا مطالبش رو توضیح بدم و جایی برای خودم دوباره بنویسم. از همین رو در ادامه انشالله هر از چندگاهی فصلی از این کتاب رو در موردش به صورت خلاصه و اجمالی پست رفته ‌‌میشه.

توصیه می‌کنم خوندن این پست رو که حسین علیرضایی عزیز تو بلاگ مهندسی ترب منتشر کرده از دست ندین.

موضوع، راجع‌به بروز رسانی نسخه‌ی PostgresSQL از ۱۱ به ۱۶‌ه. علاوه بر نقل تجربه‌شون از شیوه‌ و چالش‌های انجام این عملیات که به‌نظرم بسیار دونستنش با ارزشه، به تفصیل به معرفی ابزار و روش‌های انجام این کار و مزایا و معایب هر کدوم از جنبه‌های مختلف پرداخته.

https://techblog.torob.com/postgresql-upgrade-from-11-to-16-torob-experience-v62efb53gn6h

الان خیلی اتفاقی دیدم که ۷ سال از آخرین فصل شرلوک گذشته! ۷ سال از دیدن بدترین فصل شرلوک گذشت و فراموش کردن گذر زمان الان صاف خورد تو صورتم! بابا من ۲۰۱۷ تازه رفتم دانشگاه! :)) الان هم دیگه رسیدم آخرای مستر و این بین من اندازه‌ی یه دانشنامه‌ی بریتانیکا خاطره و داستان دارم.... پسر ۷ سال واقعا یک عمره!

پی‌نوشت: تو خاطرم هست که اولای دبیرستان، توی صف داشتم به علی و ممد (یکیشون داره الان پزشکی میخونه اون یکی آلمان رفته مستر بگیره توی مواد و متالوژی) که آقا این فصل ۳ رو همین امروز توی kickass تورنت دیدم که سید کردن گذاشتم دانلود (لیچ) بشه. فلش بیارید براتون بریزم :)) همون‌موقع هم یادمه که کلی منتظر بودم که فصل سه بیاد که ببینیم تکلیف چی میشه.

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

«انتظار داشتن، تاب‌آوری رو کم میکنه» و تاب‌آوری از اساسی‌ترین ملزومات ادامه دادن مسیره.



چرا من این حرف رو خریدارم و فکر میکنم ارزشش رو داره؟ این که مدیر انویدیا گفته؟! نه. هرکی که میکروفون دستش میگیره فکر میکنه باید چیزی بگه که مخاطب تحت‌ تاثیر قرار بگیره. اما من این رو میخرم چون این رابطه رو من توی زندگی آدم‌هایی که اطرافم هستند و اون‌ها رو آدم حسابی میدونم میبینم. آدم‌‌هایی آن‌چنان آروم که انگار مشکلات هیچ‌وقت سراغ اون‌ها نمیاد. آدم‌هایی که با ساده‌ترین و بی‌تجربه‌ترین چشم‌ها هم میشه میشه کوهی از استعداد و توانایی رو در اون ها دید. در عین‌حال شما هیچ‌وقت نمی‌بینید این‌ها در تکاپویی رقت‌بار و پر از حسرت باشند برای رسیدن به خواسته‌‌هاشون: «اپلای کنیم بریم فلان دانشگاه؟» «چرا بهمان شرکت‌ها هرچی رزومه می‌فرستم منو نمیگیرن؟!!! من که خیلی باسوادم! من واقعا حیفم!!» و هزار تا مثال ازغرغرها و حسرت‌هایی که ما از دهن آدم‌های معمولا نزدیک اطرافمون (و البته خودمون) می‌شنویم.



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


https://www.youtube.com/watch?v=RX6y0Nrwa1I

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

Experimental web browser optimized for rabbit-holing

گویا به این روش خوندن مطالب (که ظاهرا خیلی هم فراگیره) میگن rabbit-holing* و واسم جالب بود :)
کاری که این مرورگر میکنه اینه که به جای این که مطالب رو برای شما توی یک تب دیگه باز کنه، این ها رو به شکل یک زنجیر ردیف میکنه و شما میتونید به صورت افقی بین این صفحه‌ها اسکرول کنید. اینجا میتونید بیشتر راجع‌بهش بخونید و اگر خواستید نصبش هم بکنید.

*اینجا که گفته rabbit-holing یاد قسمت اول متهم گریخت افتادم که هاشم از معلم زبان بچه‌ش میپرسه اگزوز به انگلیسی چی میشه، بعد معلم زبان میگه اصلا فارسی نیست. بعد میپرسه خب معنیش به انگلیسی چی میشه؟ یارو یه چرتی از خودش در میاره میگه: یعنییی جایی که دود ازِش میزنه بیرون :)))) بعد هاشم هم میگه: این انگلیسیا واقعا چه مخی دارن. به جای این که بگن یه جایی که ازش دود میزنه بیرون، یه کلمه میگن اگزوز خیالشونو راحت میکنن.
اینم شده حکایت این کلمه‌ی rabbit-holing. یه جای این که این همه کارکتر حروم کنه مثل من و توضیح بده این مرورگر واسه چیه، یه کلمه گفته rabbit-holing خیالشو راحت کرده.