https://youtube.com/@doughtoli?si=4LxjqYpfGGxWpW2O
یه چند وقتی هست که برای گذران وقت، میشینم و youtube shorts نگاه می‌کنم. تو همین حال به کانال این بنده خدا رسیدم. اگر اشتباه نکنم یکی از معروف‌ترین افرادیه که خیلی تخصصی توی حوزه پیتزا داره کار می‌کنه و خیلی کارش خفنه و حتی فکر کنم چندتا رکورد هم داره ( تاکید می‌کنم فکر کنم 😅 ).
ولی اون چیزی که بیشتر از اینا، توجه من رو جلب می‌کنه، علاقه‌ای هست که به کارش داره. توی تک تک ویدئوهاش، خیلی فان و آروم داره کار می‌کنه و خیلی از کارش لذت می‌بره. عملا نمونه‌ی مجسم اون حس توی بچگیه که می‌گیم دلمون می‌خواد دکتر یا مهندس یا ... بشیم. خیلی حس خوبیه و خیلی خوب این حس دوست داشتن کارش رو انتقال می‌ده.
خیلی خوب می‌شه اگر بتونیم توی زندگی‌مون، تلاش‌مون رو بکنیم تا ما هم به یه چنین حسی برسیم. خود من به نسبت کارم واقعا چنین حسی دارم و همیشه سعی می‌کنم این رو انتقال بدم که یکی از راه‌های افزایش بهره‌وری، ایجاد یه حس فان و خوب به نسبت کاریه که دارین انجام می‌دین.
و این که حتی این دوستمون هم توی یکی از ویدئوهاش راجع به burn out شدن توضیح می‌ده. و خودش میگه که حتی به عنوان یه کسی که عاشق کارش هست، بازم براش پیش میاد و یه چیز کاملا طبیعیه. این که به نسبت burn out شدن دیدگاه درستی داشته باشیم هم خیلی توی زندگی کاری مهمه و باعث می‌شه بتونیم در مواقع سخت، تصمیمات درست‌تری بگیریم.
ترکیب این نکته رو کاملا و به وضوح میشه توی چهره‌ی این فرد موقع کار کردن دید! امیدوارم همه به سمت همین حال خوب توی کار کردن حرکت کنیم.

با ۴ روز تاخیر، روز برنامه‌نویس رو خدمت همه‌ی برنامه‌نویس‌ها و مهندسین نرم‌افزار، در هر سطح و موقعیتی که هستن ، تبریک می‌گم ✌️🔥🎉😄
کدهاتون بی‌باگ و دل‌هاتون، بی‌غم 😁
اما یه نکته جانبی هم بگم. روز برنامه‌نویس ۲۵۶امین روز سال هست و چون عدد ۲۵۶ میشه یک بایت، این روز رو به این نام زدن. در دنیای گذشته که فورترن بوده و COBOL، این نام‌گذاری خیلی منطقی بوده چون نکته‌ی اصلی اون زمان توی ساختن نرم‌افزار، استفاده بهینه از سخت‌افزار بوده و این دو، ارتباط تنگاتنگی با هم داشتن.
ولی توی دنیای حاضر، اگر شما توی دانشگاه به واسطه‌ی دروس تئوری با اعداد باینری آشنا نشین، یه شانس خوبی وجود داره که کلا این اعداد رو نشناسین و هیچ‌وقت هم چشمتون بهشون نخوره. چون در حال حاضر، سطح برنامه‌نویسی خیلی بالاتر ار سطح سخت‌افزار هست (در اکثر زبان‌ها)، و اکثرا برنامه‌نویس‌ها توی مهارت‌های نرم لنگ میزنن تا مهارت‌های فنی.
توی یه مدت زمان خیلی کوتاهی، سطح پیچیدگی روابط انسانی و مهارت‌های نرم به سطح پیچیدگی سیستم‌ها رسیده! خوبه این Trend رو ببینیم و در نظرش بگیریم توی مسیر پیشرفت شغلی‌مون!

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

چند وقت پیش تولد ۲۰ سالگی اوبونتو بود! من خودم به عنوان سیستم‌عامل اصلی از Arch استفاده می‌کنم، ولی برای اوبونتو جایگاه و ارزش خاصی قائلم. شاید با نگاه کردن به اوبونتو بتونیم یه درس خیلی بزرگ برای آینده‌مون به عنوان توسعه‌دهنده‌ی نرم‌افزار بگیریم، اونم اینه که سادگی در استفاده چقدر می‌تونه محصول شما رو از لحاظ کیفی بالا ببره. به جرأت میشه گفت اگر اوبونتو نبود، خیلی از افرادی که الان دارن از لینوکس استفاده می‌کنن، هیچ موقع به این سمت نمی‌اومدن و این جامعه‌ی بزرگی که الان می‌بینیم به این شکل وجود نمی‌داشت. و خیلی‌ها اصلا لینوکس رو به اوبونتو میشناسن 😁
تا باشه از این دسته نرم‌افزارها و محصولات که باعث بشه تجربه‌ی کاربری خوبی برای همه ایجاد بشه و نفع جمعی درونش باشه. ✌️

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

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

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

توی این چند روز، یه نیازی در یکی از پروژه‌ها به وجود اومد. ما یه سری فایل استاتیک داشتیم که هم باید توسط nginx در دسترس قرار می‌گرفتن، و هم در حین جنریت شدن یه سری صفحه‌ی html، توسط یه برنامه‌ی جاوایی استفاده می‌شدن. این فایل‌ها توی پروژه‌ی جاوا بودن و بعد از بالا رفتن اون پروژه، پیدا کردن این فایل‌های استاتیک از توی فایل jar پروژه و گذاشتنشون توی جایی که در دسترس باشه، کار خیلی سخت و پیچیده‌ای بود.
راه‌حل ساده و سریع؟ git submodule!
گیت یه مفهومی داره به اسم submodule، که توسط اون می‌تونید توی یه پروژه‌ای که توسط گیت مدیریت میشه، یه پروژه‌ی دیگه رو clone کنید، از فایل‌هاش استفاده کنید و اونها رو تغییر بدید،‌ بدون این که توی پروژه‌ی اصلی‌تون تغییر اساسی‌ای ایجاد بشه! یکی از فلسفه‌های پشت این قابلیت، می‌تونه نبود یک package manager درست و حسابی توی زبان‌هایی مثل C و C++ باشه. اگر می‌خواید بیشتر راجع به نحوه‌ی کار با submoduleها آشنا بشین، این صفحه توضیحات کاملی داده. درسته یکم دردسر داره برای استفاده، ولی فوایدش خیلی زیادتره 😁.
گیت همیشه آدم رو با featureهاش سوپرایز می‌کنه. این نشون میده چقدر git بر حول کاربرانش یعنی توسعه‌دهندگان طراحی و توسعه داده شده.

ورژن جدید DeepSeek به شدت داره غوغا به پا می‌کنه! طبق تجربه‌ی من، خروجی‌ش واقعا به پای chatGPTمیرسه و مهم‌تر از همه، مدل R1ش کاملا انسانی فکر می‌کنه و دلیل و منطق میاره.
اگر امتحانش نکردید، حتما امتحانش کنید.

https://evanhahn.com/my-failed-attempt-to-shrink-all-npm-packages-by-5-percent/
اینو یکی از دوستانم فرستاده بود و به نظرم خیلی مقاله‌ی جالبی بود. و در آن نکاتی نهفته است برای آنان که می‌اندیشند.
به نظر من جدای از نشون دادن اهمیت درست ارائه دادن ایده‌ها، نکته‌ی دیگه‌ای که میشه از این پست یاد گرفت، اینه که انجام دادن هرکاری، باید در مقیاس بزرگ، بصرفه. وگرنه over engineering محسوب میشه و نتیجه‌اش یه چیزی مثل داستان این مقاله میشه.
خیلی از ابعاد توی خیلی از مسائل درنظر گرفته نمیشه، و خیلی از راه‌حل‌ها کامل و بی‌نقص نیستن، شاید دلیلش این باشه که واقعا ارزشش رو ندارن که بی‌نقص باشن!

https://youtu.be/Myd3aRMZabY?si=aBS0X7D_xUGmv4M-
داستان از این قراره که یه مهندس نرم‌افزار، تونسته یه جوری پلاکی برای ماشینش بگیره که NULL بوده. و متأسفانه یکی توی کدی که مربوط به جریمه‌های رانندگیه، کدش رو جوری می‌نویسه که مقدار Null به صورت رشته رو با خود null برابر در نظر می‌گرفته! ادامه‌ی داستان و مشکلات این مهندس نرم‌افزار رو توی فیلم ببینید.
ولی درس اخلاقی این داستان برای ما؟ کدتون رو به خوبی تست کنید. سعی کنید کدی که می‌نویسید با بقیه‌ی سازمان تطابق و انسجام داشته باشه. و از همه مهم‌تر، کاربر رو هر موجود غیرهوشمندی که به ذهن‌تون می‌رسه، فرض کنید!

https://youtu.be/IP-rGJKSZ3s?si=DFtCp1T8d6m7R6MX
این فیلم کوتاه، یه مسئله حیاتی در دنیای کامپیوترها رو خیلی ساده توضیح میده. و تا الان من به اهمیتش واقعا پی نبرده بودم.
توی دنیای کامپیوتر، چه در بعد نرم‌افزار، چه در بعد سخت‌افزار، چه شبکه باشه یا آفلاین، یه اصل ثابت وجود داره: عدم قطعیت. ما در نهایت نمی‌تونیم مطمئن باشیم که کدی که زدیم، همیشه بدون خطاست. نمیشه روی رسیدن پکت‌ها به مقصد، حساب باز کرد. این رو همیشه باید در نظر بگیریم و براش آماده باشیم. اگر کدمون قراره روی کامپیوتر اجرا بشه، باید حواسمون به این محدودیت‌ها هم باشه!

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

سال نو مبارک‌تون باشه، به امید سالی سرشار از موفقیت و شادی ✌️🎉🎉🔥

امروز، ۲۵۶امین روز سال، و روز برنامه‌نویس هست. اکثر افرادی که توی حوزه‌ی برنامه‌نویسی نیستن، ما رو به عنوان افرادی که با کامپیوتر کار می‌کنن، می‌شناسن. در صورتی که این، کم‌اهمیت‌ترین مهارت یه برنامه‌نویسه. برنامه‌نویسی یک کار پیچیده‌ی ذهنی مثل خلق اثر هنریه. و برای انجام دادن این کار، میزان خوبی از خلاقیت، نوآوری، مهارت حل مسئله، قدرت کار تیمی و ... لازمه. این مهارت‌ها و توانایی‌های برنامه‌نویس‌ها به ندرت توسط دیگران دیده میشه، ولی برای ما که با هم کد میزنیم و فیچر جدید توسعه می‌دیم، خیلی اهمیت داره!
و شاید یه نکته‌ی مهم‌تر این باشه که در این روز، باید بدونیم برنامه‌نویس‌ها برای بهتر کار کردن، انعطاف‌پذیری، ساعات کاری و حقوق مناسب، حق تصمیم، مدیریت منعطف و ... لازم داره. این‌ها واقعا nice to have نیست که مثل بک‌آپ سرور ازش بگذریم! بلکه جزئی حیاتی از زندگی کاری ماست که به ندرت دیده می‌شه.
به امید کدهای بهتر و باگ‌های کمتر! روزمون مبارک!✌️🥳

یکی از تجربه‌های خیلی خوب و نه چندان محبوب‌ام، استفاده از مدل‌های چینی در زندگی روزمره‌س. مثل KIMI, DeepSeek، GLM و QWEN. این مدل‌ها هم خیلی ارزونن، هم خروجی به نسبت قابل قبولی دارن. مهم‌تر از همه، اینه که اینا مدل‌هایی هستن که هر کسی استفاده نمیکنه و معمولا برای مقایسه با بقیه مدل‌ها و دیدن خروجی‌های خاص، خیلی خوبن.

@SSCACHEE

https://youtu.be/7vw445i8gOI?si=qDS89sw0i7SWr_PC

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

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

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

The best way to go faster is to slow down

یلداتون مبارک. 🥳🍉

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