اگه از دیدن TUIهایی مثل Lazydocker لذت بردید، ولی فکر می‌کردید ساختن همچین اپ‌هایی فقط با گولنگ یا راست ممکنه، وقتشه نظرتون عوض بشه.


یه فریم‌ورک پایتونی به نام Textual هست که بهتون اجازه می‌ده اپلیکیشن‌های ترمینالی کاملا تعاملی، با انیمیشن روان، پشتیبانی از موس و حتی ۱۶.۷ میلیون رنگ بسازید؛ اون هم با پایتون.

• استایل‌دهی مثل وب؛ Textual یه سیستم CSS داره که می‌تونید باهاش Layout، رنگ، Border و حتی حالت‌های مختلف Widgetها رو کنترل کنید؛ بدون اینکه استایل رو با لاجیک پایتون قاطی کنید.

• ویژگی‌های Reactive؛ کافیه یه متغیر رو reactive تعریف کنید تا با تغییر مقدارش، Textual به‌صورت خودکار UI رو رفرش کنه؛ الگویی که برای توسعه‌دهنده‌های فرانت‌اند خیلی آشناست.

• ترمینال یا مرورگر؛ جالب‌ترین بخشش اینه که می‌تونید همون اپلیکیشن رو داخل ترمینال اجرا کنید یا با textual serve توی مرورگر در دسترس قرار بدید.

اگه دوست دارید چیزی فراتر از print و لاگ‌های ساده توی ترمینال بسازید، Textual می‌تونه یکی از جذاب‌ترین گزینه‌های اکوسیستم پایتون برای ساخت TUI باشه.

🐱 github.com/Textualize/textual


🔨• #DevEdu@Melfex

یکی از خطرناک‌ترین حس‌ها توی مسیر یادگیری برنامه‌نویسی، حسیه که شاید کمتر درباره‌ش حرف زده می‌شه: توهمِ فهمیدن.

یه مفهوم جدید یاد می‌گیرید؛ یه مقاله می‌خونید، یه ویدیو می‌بینید یا کد یه نفر دیگه رو بررسی می‌کنید. همه‌چیز منطقی به نظر می‌رسه. هر خط رو متوجه می‌شید و در آخر با خودتون می‌گید: «آها، فهمیدم.»

اما مشکل اینجاست که مغز ما بین «آشنا بودن» و «بلد بودن» تفاوت زیادی قائل نمی‌شه. وقتی چیزی رو دوباره می‌بینه، سریع حس آشنایی ایجاد می‌کنه و همین حس گاهی با یادگیری واقعی اشتباه گرفته می‌شه.

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

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

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

پس دفعه‌ی بعد که حس کردید یک مفهوم رو کامل یاد گرفتید، اول از همه بسنجید این حس رو.


👤• #FromFarshad@Melfex

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

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

امروز اما همه‌چیز بهتره؛ سیستم بهتره، ابزارها بهتر شدن، دانش و تجربه‌م بیشتره، AI و هزاران کتابخونه و سرویس وجود دارن که اون موقع حتی تصورشون رو هم نمی‌کردم. ولی خودم؟! بیشتر از یه ربع نمی‌تونم واقعا توی کار فرو برم.

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

امروز حتی شروع کردن یه کار ساده هم داستان خودش رو داره. اینترنت امروز کار می‌کنه؟! این سرویس باز می‌شه؟ VPN جواب می‌ده؟ این پکیج دانلود می‌شه؟! اون API در دسترسه؟! و مسئله فقط زمانی نیست که از دست می‌ره. هر بار که اتصال می‌پره یا برای ساده‌ترین چیز مجبور می‌شی دنبال راه جایگزین بگردی، رشته‌ی فکرت هم پاره می‌شه. برنامه‌نویسی فقط به سیستم و اینترنت نیاز نداره؛ به یه محیط نسبتا پایدار برای فکر کردن هم نیاز داره.

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

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

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

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

من هنوز همون آدمی‌ام که می‌تونه ساعت‌ها کد بزنه. می‌دونم، چون قبلاً انجامش دادم؛ با سخت‌افزار بدتر، امکانات کمتر و دانش خیلی کمتر. پس شاید لازم نیست بیشتر خودم رو سرزنش کنم. شاید اول باید بفهمم چرا این‌قدر خسته‌ام.

من دلم برای اون لپ‌تاپ ذغالی تنگ نشده؛ دلم برای ذهنی تنگ شده که پشت اون لپ‌تاپ می‌نشست. ذهنی که فقط یه پروژه داشت، یه مسئله داشت، یه هدف داشت و واسه‌ی چند ساعت لازم نبود به صدها چیز دیگه فکر کنه.

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


👤 • #FromFarshad@Melfex

اگه یه اپلیکیشن Python روی سرور کند بشه، اولین کاری که معمولا می‌کنیم اینه که می‌ریم سراغ کد و شروع می‌کنیم به حدس زدن اینکه مشکل کجاست. اما اگه اپلیکیشن همین الان روی پروداکشن در حال اجرا باشه چی؟! نمی‌خوایم کد رو تغییر بدیم یا برای Profiling دوباره دیپلوش کنیم.


اینجاست که py-spy جالب می‌شه. یه Profiler واسه‌‌ی پایتونه که می‌تونه به یه پراسس در حال اجرا وصل بشه و نشونتون بده اپلیکیشن بیشتر وقتش رو کجا داره می‌گذرونه؛ بدون اینکه لازم باشه کد اپلیکیشن رو تغییر بدید یا دوباره رانش کنید.

• پروفایلینگ لایو؛ با py-spy top می‌تونید مثل دستور/کامند top ببینید کدوم فانکشن‌ها بیشترین زمان رو مصرف می‌کنن.

• گراف Flame؛ با py-spy record می‌تونید از ران اپلیکشین یه گزاف بگیرید و راحت‌تر هاتسپات‌های اپلیکشین رو پیدا کنید.

• بررسی استاک پراسس‌ها؛ با py-spy dump می‌تونید استاک فعلی تردهای پایتون رو ببینید و بفهمید اپلیکیشن دقیقا کجا متوقف شده.

نکته‌ی جالبش اینه که خود py-spy با Rust نوشته شده و خارج از پراسس اصلی اپلیکیشن اجرا می‌شه؛ واسه‌ی همین با هدف Profiling اپ‌های واقعی و حتی پروداکشن طراحی شده.

🐱 github.com/benfred/py-spy


🔨• #DevEdu@Melfex

یه مسیر جدید رو شروع کردم؛ AI Engineering.

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

فعلا دارم چیزهایی مثل "NLP"، "LLM"، "LMM" و تفاوت بین این مفاهیم پایه رو یاد می‌گیرم. شاید واسه کسی که مدت‌ها توی این حوزه کار کرده، این‌ها خیلی ابتدایی به نظر برسن؛ ولی واسه‌ی من قرار نیست چیزی رو فقط به خاطر اینکه «بلدم» رد کنم. و هدفم اینه که تا سال آینده حداقل به یه سطح مطلوبی از جونیوری برسم.

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

بریم ببینیم سال بعد کجای این مسیر ایستادم :)


🧠 • #AIEngineering@Melfex

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

ان‌ال‌پی (Natural Language Processing) یه حوزه از هوش مصنوعیه که روی تعامل کامپیوتر با زبان انسان تمرکز داره؛ یعنی مسئله‌هایی مثل ترجمه، تحلیل احساسات، استخراج اطلاعات، خلاصه‌سازی و پاسخ به سؤال، همگی می‌تونن توی حوزه‌ی NLP قرار بگیرن.

اما Language Model یه مدل آماری/محاسباتیه که با زبان کار می‌کنه؛ به‌طور ساده، یاد می‌گیره با توجه به یه توالی از توکن‌ها، درباره‌ی ادامه‌ی احتمالی اون توالی پیش‌بینی انجام بده.

ال‌ال‌ام (Large Language Model) هم در واقع یه Language Model توی مقیاس بزرگه؛ مدلی که معمولا با تعداد بسیار زیادی پارامتر و حجم عظیمی از داده (عمدتا هم از اینترنت‌) آموزش داده شده و می‌تونه طیف گسترده‌ای از وظایف زبانی رو انجام بده.

این تفاوت مهمه؛ چون وقتی از ChatGPT، Claude یا Gemini صحبت می‌کنیم، صرفا درباره‌ی «NLP» حرف نمی‌زنیم. داریم درباره‌ی سیستم‌هایی صحبت می‌کنیم که از مدل‌های زبانی بزرگ، در کنار اجزای مختلف دیگه، واسه‌ی انجام وظایف پیچیده استفاده می‌کنن.

از طرف دیگه، LLM رو هم داریم؛ مدل‌هایی که فقط به متن محدود نیستن و می‌تونن با چند نوع داده، مثل متن، تصویر یا صدا، کار کنن.



🧠 • #AIEngineering@Melfex

وقتی کار با گیت جدی‌تر می‌شه، بعضی کارها توی CLI کمی دردسر پیدا می‌کنن؛ مثلا وقتی بخوای فقط چند خط از یه فایل رو Stage کنی، یه Interactive Rebase انجام بدی یا بخشی از تغییراتت رو Stash کنی. اینجاست که Lazygit واقعا کاربردی می‌شه.

لیزی‌گیت یه رابط کاربری ترمینالی (TUI) واسه‌‌ی گیت‌ هست که بیشتر کارهای روزمره و حتی بعضی عملیات پیشرفته‌ی گیت رو از داخل یه محیط تعاملی در اختیارتون می‌ذاره.

• استیج کردن خط‌به‌خط؛ وارد فایل می‌شید و فقط همون خطوطی که می‌خواید رو استیج می‌کنید.

• ریبیس تعاملی؛ واسه‌ی Squash کردن، حذف یا جابه‌جا کردن کامیت‌مسیج‌ها، به‌جای درگیر شدن مستقیم با git rebase -i، عملیات رو از داخل خود محیط انجام می‌دید.

• مدیریت Stash و کانفلیکت؛ تغییرات رو می‌تونید از داخل محیط مدیریت کنید و هنگام مرج کانفلیکت هم تغییرات و گزینه‌های مربوط به حل کانفلیکت رو یک‌جا ببینید.

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

🐱 github.com/jesseduffield/lazygit


🔨• #DevEdu@Melfex

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

- اولین چیزی که شاید یکم عجیب و البته جالب به نظر برسه، اینه که توی هسته‌ی بسیاری از LLMهای مولد، یه مسئله‌ی خیلی ساده داریم: پیش‌بینی توکن بعدی (Next Token Prediction). یعنی مدل وقتی قراره متنی تولید کنه، بر اساس چیزهایی که تا اون لحظه در اختیارشه، احتمال توکن‌های بعدی رو محاسبه می‌کنه و یکی رو انتخاب می‌کنه؛ بعد همین فرایند دوباره و دوباره تکرار می‌شه تا پاسخ ساخته بشه.

- اما اینجا یه مفهوم خیلی پایه داریم به اسم توکن. متن قبل از اینکه وارد مدل بشه، به واحدهایی به اسم توکن تبدیل می‌شه؛ این واحدها لزوما یه کلمه‌ی کامل نیستن و می‌تونن بخشی از یه کلمه، یه کلمه یا حتی یه علامت نگارشی باشن. درک این موضوع مهمه، چون هر مدل ظرفیت محدودی واسه‌ی تعداد توکن‌هایی که می‌تونه توی یه ریکوئست در اختیار داشته باشه داره؛ چیزی که بهش Context Window می‌گیم. از طرف دیگه، مصرف منابع و هزینه‌ی استفاده از بسیاری از سرویس‌های LLM هم بر اساس تعداد توکن‌های ورودی و خروجی محاسبه می‌شه (همچنین ممکنه واسه‌ی هر مدل فرق کنه).

- یه نکته‌ی جالب دیگه، توهمِ داشتن حافظه‌ست. خود مدل به‌صورت ذاتی چیزی از ریکوئست و جت‌های قبلی رو نگه نمی‌داره؛ یعنی اگه ما بخوایم یه سیستم مکالمه‌ای/چت داشته باشیم که «حرف‌های قبلی» رو در نظر بگیره، باید این اطلاعات و دیتا رو به شکلی دوباره در اختیار مدل قرار بدیم. اینجاست که ساختار پیام‌ها و رول‌ها وارد ماجرا می‌شن. توی یه ساختار رایج، پیام‌ها با نقش‌هایی مثل این مشخص می‌شن:

۱. سیستم (System) : دستورالعمل‌ها و قواعدی که برای رفتار مدل تعیین می‌کنیم، می‌شه گفت همون پرامپت اولیه‌س که به مدل می‌دیم.
۲. یوزر (User) : پیام یا ریکوئست از طرف یوزر.
۳. اسیستنت (Assistant): جواب‌هایی که مدل قبلا تولید کرده.

پس اگه بخوایم یه چت چندمرحله‌ای داشته باشیم، معمولا هیستوری مکالمه رو همراه با ریکوئست جدید داخل کانتکست می‌ذاریم تا مدل بتونه بر اساس اون پاسخ تولید کنه.

خلاصه هرچی بیشتر وارد این مفاهیم می‌شم، بیشتر برام جالبه که پشت چیزی که از بیرون شبیه «چت با یه موجود هوشمند» به نظر می‌رسه، چه حجم زیادی از مفاهیم ریاضی، آماری و مهندسی وجود داره.


🧠 • #AIEngineering@Melfex

این بار رفتم سراغ «عقاید یک دلقک» اثر هاینریش بُل؛ یکی از آثار شناخته‌شده‌ی ادبیات آلمان که سال ۱۹۶۳ منتشر شده.

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

فعلاً تازه شروعش کردم و نمی‌خوام زودتر از خوندنش درباره‌ش قضاوت کنم. طبق روال معمول، پاراگراف‌ها و بخش‌هایی که از نظرم ارزش بیشتری دارن رو با هشتگ #عقاید_یک_دلقک اینجا به اشتراک می‌ذارم.


📚• #FReading@Melfex | #عقاید_یک_دلقک

تا حالا شده یه API Key، توکن بات یا پسورد دیتابیس رو اشتباهی کامیت کنید؟! چیزی که الان زیاد دیده می‌شه همين اشتباهاست، خصوصا پروژه‌هایی که وایب کد می‌شن.

اینجاست که Gitleaks به کار میاد.

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

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

• جلوگیری از نشت دیتا؛ با استفاده از Pre-commit Hook می‌تونید قبل از ثبت تغییرات، فایل‌ها رو اسکن کنید.

• یکپارچگی با CI/CD؛ امکان اجرای خودکار اسکن‌ها داخل پیپ‌لاین وجود داره تا دیتای حساس قبل از انتشار شناسایی بشن.

🐱 github.com/gitleaks/gitleaks


🔨• #DevEdu@Melfex

احتمالا دقت کردید که وقتی از چت‌بات هایی مثل ChatGpt یا Claude سوالی می‌پرسید، پاسخ و ریسپانس به‌جای اینکه یک‌جا نمایش داده بشه، به‌صورت تدریجی روی صفحه ظاهر می‌شه. اما تا حالا فکر کردید این استریم کردن اون پشت چطوری اتفاق می‌افته؟!

یکی از راهکارهای رایج برای این کار، تکنولوژی Server-Sent Events یا همون SSE هست که اتفاقا ای‌پی‌آی‌های رسمی اوپن‌ای‌آی و انتروپیک هم ازش پشتیبانی می‌کنن.

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

• مبتنی بر HTTP؛ نیازی به برقراری اتصال وبسوکت ندارید و می‌تونید ریسپانس‌ها رو روی یه HTTP ریسپانس استریم کنید.

• پشتیبانی نیتیو مرورگر؛ با API استاندارد "EventSource" می‌تونید ایونت‌ها رو دریافت کنید و حتی از قابلیت Auto-reconnect استفاده کنید.

• پیاده‌سازی ساده؛ واسه‌ی سناریوهایی مثل داشبوردهای مانیتورینگ، نوتیفیکیشن‌های لایو یا استریم پاسخ مدل‌های زبانی، لزوما نیازی به پیاده‌سازی ارتباط دوطرفه ندارید.

البته SSE همیشه جایگزین وبسوکت نیست؛ ضمن اینکه واسه‌ی استریم ریکوئست‌های پست یا مدیریت کانکشن مجدد، ممکنه به پیاده‌سازی بیشتری نیاز داشته باشید.

یه نکته‌ی جالب هم اینکه استفاده از SSE پشت ریورس‌ پروکسی‌هایی مثل Nginx نیازمند توجه به تنظیماتی مثل ریسپانس Buffering هست؛ وگرنه ممکنه داده‌ها به‌جای نمایش تدریجی، با تاخیر به کلاینت برسن.


🔨• #DevEdu@Melfex

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

به‌نظرم یکی از بزرگ‌ترین اشتباهات ما اینه که گاهی محدودیت شناخت خودمون رو فراموش می‌کنیم و با همون اطلاعات ناقص، درباره‌ی زندگی و انتخاب‌های دیگران قضاوت می‌کنیم.

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

شاید مسئله این نباشه که نباید قضاوت کنیم؛ بلکه باید بپذیریم فهمیدنِ موقعیت یه آدم، با تصور کردن خودمون به‌جای اون آدم یکی نیست.


📚• #FReading@Melfex | #عقاید_یک_دلقک