SCACHE

خیلی وقت پیش، من روی یه پروژه‌ی کاملا vibe code کار کردم، که بیشتر برای رفع نیاز خودم طراحی شده بود. کار با openvpn روی لینوکس! خلاصه بگم، openvpn روی لینوکس کلاینت GUI-based خیلی درست و حسابی‌ای که من بتونم باهاش کار کنم، نداره. و همچنین کار کردن باهاش از طریق ترمینال هم به شدت برام چالش برانگیز و خسته کننده بود، این که همیشه یه ترمینال رو باز نگه‌دارم برای vpn، هر روز صبح یه کامند طولانی بزنم صرفا برای وصل شدن به سرویس‌های داخلی سازمان، یا اینترنت، و ... . در نهایت نتیجه گرفتم vpnctl رو با استفاده از GPT4.5 بنویسم. در اون زمان، صرفا با chat harness، یک ورژن خیلی اولیه نوشتم که کارم رو راه می‌انداخت و تا یه حدی باهاش تونستم زندگی کنم. ولی چیزی که توجه‌م رو جلب کرد، نبودن یک نمونه مشابه برای این کار بود. همیشه این توی ذهنم بود که یه زمانی، این اسکریپت رو بهترش کنم، و پابلیکش کنم تا هم روی سیستمم منظم‌تر بشه، و هم بتونم به عنوان یه پروژه‌ی open-source منتشرش کنم. امروز بالاخره تونستم این کار رو انجام بدم :) این شما و این هم ovpm: openvpn manager. هدف از نوشتن این اسکریپت، ساده‌سازی کار روزمره با openvpn بوده و تلاش کردم تا جای ممکن، به صورت سیستماتیک، openvpn رو مدیریت کنم. اینم لینک repoی پروژه: https://github.com/ehsanghorbani190/ovpm اگر استفاده کردین و نکته‌ای به ذهنتون رسید، یا پیشنهادی برای بهبود پروژه داشتین، حتما بهم پیام بدین و باهام به اشتراک بگذارین، به شدت استقبال می‌کنم! : )

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

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

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

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

امشب شب یلداست، بلندترین شب سال. جدای از مراسم یلدا که خانواده‌ها میگیرن و دور هم جمع میشن و دیدارها دوباره زنده میشه، مهم‌ترین چیزی که در این شب زنده میشه، اهمیت زندگیه. این که یک دقیقه بیشتر در حال حاضر زندگی کنیم، یک دقیقه کمتر به دغدغه‌ها و غصه‌هامون فکر کنیم، و بتونیم این تعادل بین لذت بردن از زندگی و رنج کشیدنش رو ایجاد کنیم. خیلی جالبه که این فرهنگ، اینقدر حیاتی و موثره که این روزا، یکی از جملات معروف دنیا اینه: The best way to go faster is to slow down یلداتون مبارک. 🥳🍉

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

https://youtu.be/7vw445i8gOI?si=qDS89sw0i7SWr_PC یه چند وقتیه که React داره باگ‌های امنیتی وحشتناکی میخوره. و این باعث میشه سخت‌گیری‌ها روی توسعه فرانت بیشتر بشه و سرعت انجام کارها کندتر. ولی جالبی این باگ‌ها، تلاش‌هاییه که برای درست کردنش صورت می‌گیره. خود React روی پچ جدیدش، یه پچ دیگه برای رفع باگ جدید میزنه و از طرف دیگه، cloudflare میاد قهرمان‌بازی دربیاره ولی متأسفانه باعث میشه خودش downtime بخوره!! خلاصه تو اون دورانی هستیم که قراره بعدا از روش کلی میم بسازن.

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

رفقا سلام✌️ آخرین اپیزود فصل اول پادکست کیبوردکست منتشر شد🎉🎉 🗣توی این اپیزود با دوست عزیزم احسان قربانی فول استک دولوپر شرکت نشان قراره درباره دنیای فرانت اند صحبت کنیم و ببینیم یک فرانت اند دولوپر دقیقا داره چه کارهایی رو انجام میده و چقدر نقشش در تولید و توسعه نرم افزارها و اپلیکیشن های تحت وب پررنگ و کلیدیه و درنهایت بفهمیم آیا فرانت اند کارها واقعا برنامه نویسن یا نه 👀 🗣اگه تو هم علاقه مند به حوزه فرانت اند هستی و میخوای بیشتر با این حوزه آشنا بشی این اپیزود خوراک خودته🔥🔥🔥 ⏺پادکست رو از طریق پلتفرم های زیر میتونید گوش کنید🔥: 🎙Castbox 📱Spotify 📱YouTube 🎙Pocket Casts 📻RadioPublick 👌@shahriaarrr12 👌@Deweloopers

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

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

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

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

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

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

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

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

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

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