تو این روزایی که وضعیت اینترنت جالب نیست، اپلیکیشنهای Todo که دنبال سینک کردنن و به اینترنت و VPN نیاز دارن (مثل Notion) رو مخ میرن. واسه همین یه Todo Manager جمعوجور با Go نوشتم که همه چی رو لوکال توی یه فایل JSON ذخیره میکنه و دیگه کاری به نت نداره:
📥 GitHub: togo
کی میدونه؛ ممکنه باز بهکار بیاد.
🔘 @TerminalNotes <- #project
📥 GitHub: togo
کی میدونه؛ ممکنه باز بهکار بیاد.
پ.ن: نمونش توی وب بود ولی به کل بازنویسیش کردن به gui. چرا خب؟ کامند لاین به این خوشگلی :)
نسخه cliش رو بر اساس فیچرها و نیازهای خودم نوشتم.
🔘 @TerminalNotes <- #project
👍2🔥1
💢 فیش ورژن 4 و تغییر Keybind های دیفالت
توی fish shell از ورژن 4 به بعد، اومدن bind های پیشفرض رو عوض کردن و ماسل مموری کاربرای قدیمی رو به چالش کشیدن. مثال تفاوت
🔹Version 3
🔸Version 4
توی ورژن 3 کلمه پاک میشه ورژن 4 توکن.
🛠 راه حل
اگه مثل من به ورژن 3 عادت دارید، برای برگشتن به رفتار قدیمی فایل
و کد زیر رو داخلش paste کنید:
پ.ن: فیش یه مکانیزم autoload داره که هر فایلی توی
قرار بگیره به عنوان یه فانکشن مستقل لود میشه.
🔗 Issue 10926
🔘 @TerminalNotes <- #linux #fish
توی fish shell از ورژن 4 به بعد، اومدن bind های پیشفرض رو عوض کردن و ماسل مموری کاربرای قدیمی رو به چالش کشیدن. مثال تفاوت
alt+backspace بین ورژن 3 و 4:🔹Version 3
curl https://wttr.in/Tehran # before
curl https://wttr.in/ # after
🔸Version 4
curl https://wttr.in/Tehran # before
curl # after
توی ورژن 3 کلمه پاک میشه ورژن 4 توکن.
🛠 راه حل
اگه مثل من به ورژن 3 عادت دارید، برای برگشتن به رفتار قدیمی فایل
fish_user_key_bindings.fish رو توی مسیر زیر بسازید:~/.config/fish/functions/
و کد زیر رو داخلش paste کنید:
function fish_user_key_bindings
bind alt-left prevd-or-backward-word
bind alt-right nextd-or-forward-word
bind alt-backspace backward-kill-word
bind alt-delete kill-word
bind ctrl-left backward-token
bind ctrl-right forward-token
bind ctrl-backspace backward-kill-token
bind ctrl-delete kill-token
bind ctrl-alt-h backward-kill-word
end
اسم فایل و فانکشن نه تنها باید با هم یکی باشن، بلکه باید دقیقا همین اسم باشن — چون fish_user_key_bindings یه هوک هاردکدشده fish هست که بعد از لود شدن bind های پیشفرض صدا زده میشه.
پ.ن: فیش یه مکانیزم autoload داره که هر فایلی توی
~/.config/fish/functions/قرار بگیره به عنوان یه فانکشن مستقل لود میشه.
🔗 Issue 10926
🔘 @TerminalNotes <- #linux #fish
📌 #Tool: eBPF
اگه دواپس کار میکنید احتمالا اسم eBPF رو شنیدید. یه تکنولوژی که خیلیها از شرکتها مثل نتفلیکس و فیسبوک بهش وابستهان.
تا قبل از eBPF، اگر میخواستید بدونید "دقیقا" توی سیستمعامل چه خبره، یا میخواستید روی ترافیک شبکه کنترل داشته باشید (مثل فیلتر کردن پکتها یا load balancing سفارشی)، دو راه داشتید:
۱. تغییر سورس کرنل: که خب زمان بره.
۲. ماژولهای کرنل: که دسترسی کامل داشتن، ولی یه باگ کوچیک توشون کافی بود تا همه چیز بیاد پایین.
🧭 راه حل مدرن: eBPF
خیلی ساده، eBPF یه ماشین مجازی (Virtual Machine) کوچیک و امنه که داخل خودِ کرنل لینوکس زندگی میکنه.
شما میتونید برنامه بنویسید، اونها رو به کرنل تزریق کنید و کرنل اونها رو اجرا کنه. اما با این مزیت که:
🔹 امنیت تضمین شده: قبل از اجرا، یه بخشی به اسم Verifier کد شما رو چک میکنه تا مطمئن شه لوپ بینهایت نداره یا به حافظه غیرمجاز دسترسی پیدا نمیکنه.
🔹 بدون توقف: برای اجرای این برنامهها نیازی به ریستارت کردن سیستم یا کامپایل دوباره کرنل نیست.
🔹 سرعت بالا: کدها به صورت JIT (Just-In-Time) کامپایل میشن و با سرعت Native اجرا میشن.
این تکنولوژی نیروی محرکه نسل بعدی ابزارهای شبکه و نظارت (Observability) هست.
⚖️ کاربردش کجاست
تقریبا هر جایی که نیاز به سرعت و دید عمیق هست:
• مانیتورینگ و Observability: ابزارهایی که نشون میدن کدوم پروسس داره چه فایلهایی رو باز میکنه یا چه پکتهایی رو میفرسته (بدون سربار ابزارهای قدیمی).
• شبکه: فیلتر کردن و مدیریت ترافیک.
شرکت هایی که ازش استفاده میکنن و چطور رو میتونید اینجا از سایت رسمی ببینید.
💠 جمعبندی
امروزه کار با eBPF با وجود زبونایی مثل Go و پایتون و کتابخونههای جدید راحت شده و نوشتن ابزارهایی که مستقیم با کرنل حرف میزنن خیلی سادهتر شده.
یه پروژه قدیمی با Go پیدا کردم که ساده پراسس های سیستم رو لایو مانیتور میکنه. چون قدیمیه یکم ریفکتورش کردم و پست های بعدی میذارمش میتونید چک کنید و ابزار خودتون رو بنویسید.
🔘 @TerminalNotes <- #linux #ebpf
اگه دواپس کار میکنید احتمالا اسم eBPF رو شنیدید. یه تکنولوژی که خیلیها از شرکتها مثل نتفلیکس و فیسبوک بهش وابستهان.
تا قبل از eBPF، اگر میخواستید بدونید "دقیقا" توی سیستمعامل چه خبره، یا میخواستید روی ترافیک شبکه کنترل داشته باشید (مثل فیلتر کردن پکتها یا load balancing سفارشی)، دو راه داشتید:
۱. تغییر سورس کرنل: که خب زمان بره.
۲. ماژولهای کرنل: که دسترسی کامل داشتن، ولی یه باگ کوچیک توشون کافی بود تا همه چیز بیاد پایین.
🧭 راه حل مدرن: eBPF
خیلی ساده، eBPF یه ماشین مجازی (Virtual Machine) کوچیک و امنه که داخل خودِ کرنل لینوکس زندگی میکنه.
شما میتونید برنامه بنویسید، اونها رو به کرنل تزریق کنید و کرنل اونها رو اجرا کنه. اما با این مزیت که:
🔹 امنیت تضمین شده: قبل از اجرا، یه بخشی به اسم Verifier کد شما رو چک میکنه تا مطمئن شه لوپ بینهایت نداره یا به حافظه غیرمجاز دسترسی پیدا نمیکنه.
🔹 بدون توقف: برای اجرای این برنامهها نیازی به ریستارت کردن سیستم یا کامپایل دوباره کرنل نیست.
🔹 سرعت بالا: کدها به صورت JIT (Just-In-Time) کامپایل میشن و با سرعت Native اجرا میشن.
این تکنولوژی نیروی محرکه نسل بعدی ابزارهای شبکه و نظارت (Observability) هست.
⚖️ کاربردش کجاست
تقریبا هر جایی که نیاز به سرعت و دید عمیق هست:
• مانیتورینگ و Observability: ابزارهایی که نشون میدن کدوم پروسس داره چه فایلهایی رو باز میکنه یا چه پکتهایی رو میفرسته (بدون سربار ابزارهای قدیمی).
• شبکه: فیلتر کردن و مدیریت ترافیک.
🛑 البته قدرت همیشه درست به کار نمیره. این ابزار قابلیت DPI هم داره که سانسورچی توی ایران ازش برای بلاک کردن و کنترل ترافیک مردم استفاده میکنه.
شرکت هایی که ازش استفاده میکنن و چطور رو میتونید اینجا از سایت رسمی ببینید.
💠 جمعبندی
امروزه کار با eBPF با وجود زبونایی مثل Go و پایتون و کتابخونههای جدید راحت شده و نوشتن ابزارهایی که مستقیم با کرنل حرف میزنن خیلی سادهتر شده.
یه پروژه قدیمی با Go پیدا کردم که ساده پراسس های سیستم رو لایو مانیتور میکنه. چون قدیمیه یکم ریفکتورش کردم و پست های بعدی میذارمش میتونید چک کنید و ابزار خودتون رو بنویسید.
قبلش برای درک برنامه لازمه چندتا مفهوم لینوکسی مثل یوزر اسپیس و کرنل اسپیس توضیح داده بشه که پست بعد مینویسم.
🔘 @TerminalNotes <- #linux #ebpf
📌 #Concept: Kernel Space & Userspace
یه رستوران بزرگ رو تصور کنید:
• مشتری (برنامهها): شما که توی سالن رستوران نشستید و میخواید غذا سفارش بدید. مشتریها اجازه ندارن وارد آشپزخانه بشن یا دست به وسایل آشپزخونه بزنن.
• گارسون (System Calls): واسطه بین شما و آشپزخونه هست. منو رو جلوتون میذاره و سفارشتون رو به آشپزخونه میبره.
• آشپز و آشپزخونه (Kernel): قلب اصلی رستوران که دسترسی کامل به همه امکانات داره، غذا میپزه، و کارهای مهم رو انجام میده.
به همین ترتیب Kernel space و userspace از هم جدا میشن و از طریق یه راه ارتباطی ایمن که syscall باشه با هم دیگه ارتباط میگیرن.
💢 چرا این جداسازی؟
1. امنیت
2. پایداری
🔆 نحوه سفارش تا تحویل با System Calls
1. انتخاب غذا: شما از منو (API سیستم عامل) چیزی مثل "پیتزا" انتخاب میکنید. برای مثال برنامه میخواد یه فایل رو باز کنه.
2. گارسون سفارش رو میبره: فراخوانی سیستمی (syscall) مثل
3. آشپز سفارش رو آماده میکنه: کرنل با دسترسی کامل به منابع سیستم، درخواست رو پردازش میکنه، فایل رو باز میکنه، دیتا رو میخونه یا تو دیسک مینویسه.
4. غذا سرو میشه: نتیجه به برنامه برمیگرده و CPU دوباره به حالت User برمیگرده.
❇️ مزایای این معماری و جمع بندی
این طراحی باعث میشه:
• هر برنامه در فضای امن خودش کار کنه و نتونه کار دیگران رو خراب کنه.
• اگه یه برنامه مشکل پیدا کرد، کل سیستم از کار نیوفته.
• منابع حیاتی سیستم (مثل دیسک، CPU و غیره) تحت کنترل کامل کرنل باشن.
🔘 @TerminalNotes <- #linux
یه رستوران بزرگ رو تصور کنید:
• مشتری (برنامهها): شما که توی سالن رستوران نشستید و میخواید غذا سفارش بدید. مشتریها اجازه ندارن وارد آشپزخانه بشن یا دست به وسایل آشپزخونه بزنن.
• گارسون (System Calls): واسطه بین شما و آشپزخونه هست. منو رو جلوتون میذاره و سفارشتون رو به آشپزخونه میبره.
• آشپز و آشپزخونه (Kernel): قلب اصلی رستوران که دسترسی کامل به همه امکانات داره، غذا میپزه، و کارهای مهم رو انجام میده.
به همین ترتیب Kernel space و userspace از هم جدا میشن و از طریق یه راه ارتباطی ایمن که syscall باشه با هم دیگه ارتباط میگیرن.
💢 چرا این جداسازی؟
1. امنیت
اگه هر مشتری بتونه مستقیم به آشپزخونه بره، هرج و مرج به پا میشه. ممکنه کسی اشتباهی اجاق رو خاموش کنه یا مواد غذایی بقیه رو خراب کنه. توی لینوکس هم همینطوره برنامههای کاربری نباید بتونن مستقیما به حافظه یا سختافزار دسترسی داشته باشن.
2. پایداری
اگه یه مشتری تو سالن غذاش بریزه، مشکلی برای آشپزخونه پیش نمیاد. ولی اگه کسی توی آشپزخانه اشتباهی بکنه، کل سفارش ها تاخیر میخورن یا حتی ممکنه کنسل بشن. توی لینوکس هم اگر یه برنامه کرش کنه، سیستم عامل به کارش ادامه میده و مختل نمیشه.
🔆 نحوه سفارش تا تحویل با System Calls
1. انتخاب غذا: شما از منو (API سیستم عامل) چیزی مثل "پیتزا" انتخاب میکنید. برای مثال برنامه میخواد یه فایل رو باز کنه.
2. گارسون سفارش رو میبره: فراخوانی سیستمی (syscall) مثل
()open شروع به کار میکنه و یه وقفه نرمافزاری ایجاد میکنه که CPU رو از حالت User به حالت Kernel تغییر میده.3. آشپز سفارش رو آماده میکنه: کرنل با دسترسی کامل به منابع سیستم، درخواست رو پردازش میکنه، فایل رو باز میکنه، دیتا رو میخونه یا تو دیسک مینویسه.
4. غذا سرو میشه: نتیجه به برنامه برمیگرده و CPU دوباره به حالت User برمیگرده.
خلاصه که نمیتونید داد بزنید "آشپز! پیتزا بده!". باید از طریق گارسون (syscall) سفارش بدهید.
❇️ مزایای این معماری و جمع بندی
این طراحی باعث میشه:
• هر برنامه در فضای امن خودش کار کنه و نتونه کار دیگران رو خراب کنه.
• اگه یه برنامه مشکل پیدا کرد، کل سیستم از کار نیوفته.
• منابع حیاتی سیستم (مثل دیسک، CPU و غیره) تحت کنترل کامل کرنل باشن.
🔘 @TerminalNotes <- #linux
👍2💔1
Terminal Notes
📌 #Tool: eBPF اگه دواپس کار میکنید احتمالا اسم eBPF رو شنیدید. یه تکنولوژی که خیلیها از شرکتها مثل نتفلیکس و فیسبوک بهش وابستهان. تا قبل از eBPF، اگر میخواستید بدونید "دقیقا" توی سیستمعامل چه خبره، یا میخواستید روی ترافیک شبکه کنترل داشته باشید (مثل…
📥 GitHub: eBPF Monitor
کلی دست به سر و رویش کشیدم و اپدیتش کردم. این پروژه در اصل با Go ورژن 1.16 نوشته شده بود و یکسری کدها و متدهای منسوخشده (Obsolete) داشت که همگی بهروز شدن. علاوه بر این، ظاهر خروجی (CLI) مدرنتر شد و Error Handling بهتری اضافه شد تا برنامه پایدار کار کنه.
🔘 @TerminalNotes <- #project
کلی دست به سر و رویش کشیدم و اپدیتش کردم. این پروژه در اصل با Go ورژن 1.16 نوشته شده بود و یکسری کدها و متدهای منسوخشده (Obsolete) داشت که همگی بهروز شدن. علاوه بر این، ظاهر خروجی (CLI) مدرنتر شد و Error Handling بهتری اضافه شد تا برنامه پایدار کار کنه.
🔘 @TerminalNotes <- #project
💔1
Terminal Notes
📥 GitHub: eBPF Monitor کلی دست به سر و رویش کشیدم و اپدیتش کردم. این پروژه در اصل با Go ورژن 1.16 نوشته شده بود و یکسری کدها و متدهای منسوخشده (Obsolete) داشت که همگی بهروز شدن. علاوه بر این، ظاهر خروجی (CLI) مدرنتر شد و Error Handling بهتری اضافه شد…
♨️ طرز کار برنامه (اتصال Kernel Space به Userspace)
🔘 @TerminalNotes <- #project
این ابزار بر اساس تعامل بین Userspace و Kernel Space کار میکنه و مکانیزمش به این صورته:
۱. تزریق و هوک سیستمی
برنامهexecve.bpf.c(که با C نوشته شده) بعد از اینکه به بایتکد BPF کامپایل شد، توی کرنل لینوکس لود میشه. این برنامه روی سیسکالexecve(که دروازه اجرای تمام باینریهاست) یک Tracepoint ثبت میکنه.
۲. استخراج اطلاعات
به محض اینکه یه پروسه سیسکالexecveرو صدا بزنه، برنامه eBPF فعال میشه و بدون اینکه وقفهای ایجاد کنه، متادیتای ضروری (مثل PID و اسم دستور) رو مستقیم از دلِ کرنل میکشه بیرون.
۳. انتقال داده با Perf Buffer
برای انتقال دادههای استخراجشده از کرنل به Userspace، از Perf Event Array (مبتنی بر Perf Buffer) استفاده شده. برنامه eBPF دادههای populate شده رو درون این بافر قرار میدهه تا در دسترس برنامه Userspace قرار بگیره.
۴. خوندن توی Userspace
سمت دیگه ماجرا، برنامه Go نشسته و ایونتها رو از بافر میخونه، دیتای باینری (Raw Data) رو دیکد میکنه و بعد از یه فرمتدهی تمیز، توی خروجی ترمینال نشون میده.
🔘 @TerminalNotes <- #project
💔1
Terminal Notes
Classic | Reddit 🔘 @TerminalNotes <- #fun
بعد از تقریبا دو سه سال استفاده از Mint با Cinnamon، دوباره به آرچ و Window Manager برگشتم. قبلا WMهای مختلفی داشتم که همشون روی Xorg بودن، اما این دفعه به پیشنهاد دوستان (@pxe_archive)، niri رو امتحان کردم که روی Wayland هست و طی این دو ماه استفاده رضایت بخش بوده (گرافیک انویدیا استفاده نمیکنم).
~ dotfiles | wall | niri ~
🔘 @TerminalNotes <- #shot #wm
ستون خیلی وضعش بهتر شده.
~ dotfiles | wall | niri ~
🔘 @TerminalNotes <- #shot #wm
💔1
قدیم WMهای مبتنی بر X مثل Lego بودن و باید اجزای مختلف جداگونه انتخاب و سرهم میشد؛ مثال:
• Compositor
• Bar
• Notification daemon
• Wallpaper manager
• Application launcher
• Clipboard manager
• Session management (e.g. lock screen)
و غیره.
توی Wayland، بهخاطر طراحی پروتکل، کمپوزیتور باید مسئولیت window management رو هم به عهده بگیره. علاوه بر این، ابزارهای جدیدی به اسم Desktop Shell بیشتر مطرح شدن که مجموعهای از موارد بالا (نوار، اعلانها، لانچر و موارد مشابه) رو یکجا ارائه میدن و نیاز به سرهمکردن جز به جز رو کمتر میکنن. دوتا از خوباش در حال حاضر DMS و Noctalia هستن.
سرجمع، WM زدن این روزا خیلی راحت شده. مثل قدیم زمان بر نیست دیگه.
🔘 @TerminalNotes <- #linux #wm
• Compositor
• Bar
• Notification daemon
• Wallpaper manager
• Application launcher
• Clipboard manager
• Session management (e.g. lock screen)
و غیره.
توی Wayland، بهخاطر طراحی پروتکل، کمپوزیتور باید مسئولیت window management رو هم به عهده بگیره. علاوه بر این، ابزارهای جدیدی به اسم Desktop Shell بیشتر مطرح شدن که مجموعهای از موارد بالا (نوار، اعلانها، لانچر و موارد مشابه) رو یکجا ارائه میدن و نیاز به سرهمکردن جز به جز رو کمتر میکنن. دوتا از خوباش در حال حاضر DMS و Noctalia هستن.
سرجمع، WM زدن این روزا خیلی راحت شده. مثل قدیم زمان بر نیست دیگه.
🔘 @TerminalNotes <- #linux #wm
❤1💔1👾1
AI may be dubbed the great disruptor, but it’s really just an accelerator of whatever you already have. The 2025 DORA report places AI’s primary role in software development as that of an amplifier — a funhouse mirror that reflects back the good, bad, and ugly of your whole pipeline. AI is proven to be impactful on the individual developer’s work and on the speed of writing code. But, since writing code was never the bottleneck, if traditional software delivery best practices aren’t already in place, this velocity multiplier becomes a debt accelerator.
I don’t think LLMs change the value of rapidly building and releasing small slices of capability. The promise of LLMs is to increase the frequency of that cycle, and doing more in each release.
Even a legend of the industry like Grady Booch, who has been appropriately dismissive of AGI claims and is actively disdainful of AI slop posted recently that he was “gobsmacked” by Claude’s abilities. Booch’s advice to developers alarmed by AI on Oxide’s podcast last week? “Be calm” and “take a deep breath.” From his perspective, having watched and shaped the evolution of the technology first hand over a period of decades, AI is just another step in the industry’s long history of abstractions, and one that will open new doors for the industry.
…whether one wants those doors opened or not ultimately is irrelevant. AI isn’t going away any more than the automated loom, steam engines or nuclear reactors did. For better or for worse, the technology is here for good. What’s left to decide is how we best maximize its benefits while mitigating its costs.
✍️ Fragments: February 18
🔘 @TerminalNotes <- #ai
🤝1
اگر برنامهنویس Go هستید و الان به هر طریقی به دسترسی اینترنت دارید، میتونید داکیومنتهای stdlib رو لوکال در دسترس داشته باشید؛ با pkgsite میتونید مشابه pkg.go.dev مستندات رو روی سیستم خودتون بالا بیارید. نصب:
بعد از نصب، مطمئن بشید دایرکتوری باینریهای گولنگ توی PATH سیستمتون باشه، در غیر این صورت دستور pkgsite شناسایی نمیشه:
بعد وارد یک پروژه که فایل
حالا مستندات stdlib از آدرس زیر در دسترسه و میتونید سرچ کنید:
http://localhost:8080/std
💠 سبک تر کردن دانلود
اگر سورس Go رو روی سیستم دارید، مسیرش رو بدید تا نیازی به دانلود دوباره داک نباشه (که توی این وضعیت اذیت نکنه):
🔘 @TerminalNotes <- #programming #golang
go install golang.org/x/pkgsite/cmd/pkgsite@latest
بعد از نصب، مطمئن بشید دایرکتوری باینریهای گولنگ توی PATH سیستمتون باشه، در غیر این صورت دستور pkgsite شناسایی نمیشه:
export PATH="$PATH:$(go env GOPATH)/bin"
بعد وارد یک پروژه که فایل
go.mod داره بشین و دستور زیر رو اجرا کنید:pkgsite -open .
حالا مستندات stdlib از آدرس زیر در دسترسه و میتونید سرچ کنید:
http://localhost:8080/std
نکته: یا اسم پکیج مورد نظر رو توی سرچ بزنید (مثلfmtیاnet/http) یا مستقیم آخر آدرس رو
/std
بذارید تا لیست stdlib رو ببینید.
💠 سبک تر کردن دانلود
اگر سورس Go رو روی سیستم دارید، مسیرش رو بدید تا نیازی به دانلود دوباره داک نباشه (که توی این وضعیت اذیت نکنه):
pkgsite -open -gorepo $(go env GOROOT)
🔘 @TerminalNotes <- #programming #golang
❤1
اگر با Rust هم کار میکنید و از طریق toolchain اون یعنی rustup نصبش کردید همه مستندات stdlib بدون هیچ کار اضافهای آفلاین آمادس:
🔘 @TerminalNotes <- #programming #rust
rustup doc
🔘 @TerminalNotes <- #programming #rust
📌 داکیومنتهای آفلاین با Zeal
برنامه Zeal یه نرمافزار رایگان و اوپنسورس هست که برای ذخیره آفلاین داکیومنتها ساخته شده:
• همه ابزارها یکجا: برخلاف
• بدون نیاز به سرور لوکال: برنامه رو باز میکنید و تمام. نیازی نیست برای خوندن داکیومنتها هر دفعه توی ترمینال سرور لوکال ران کنید.
میتونید توی بخش Docsets، داکیومنتهایی که لازم دارید رو دانلود کنید. حجمشون هم زیاد نیست (Go حدود 17 مگابایت و Docker حدود 100 مگ). بعد از اون میتونید بدون نیاز به اینترنت داکیومنتها رو بخونید.
تا همین باریکه اینترنت هست و متصلید، داکیومنت ابزارهای مورد نیازتون رو دانلود کنید.
🔘 @TerminalNotes <- #tool
برنامه Zeal یه نرمافزار رایگان و اوپنسورس هست که برای ذخیره آفلاین داکیومنتها ساخته شده:
• همه ابزارها یکجا: برخلاف
pkgsite یا rustup که توی پستهای بالا راجع بهشون صحبت شد، اینجا دیگه محدود به یک زبان برنامهنویسی خاص نیستید. میتونید داکیومنتهای داکر، پایتون، ریاکت، پستگرس و کلی ابزار دیگه رو یکجا کنار هم داشته باشید.• بدون نیاز به سرور لوکال: برنامه رو باز میکنید و تمام. نیازی نیست برای خوندن داکیومنتها هر دفعه توی ترمینال سرور لوکال ران کنید.
میتونید توی بخش Docsets، داکیومنتهایی که لازم دارید رو دانلود کنید. حجمشون هم زیاد نیست (Go حدود 17 مگابایت و Docker حدود 100 مگ). بعد از اون میتونید بدون نیاز به اینترنت داکیومنتها رو بخونید.
تا همین باریکه اینترنت هست و متصلید، داکیومنت ابزارهای مورد نیازتون رو دانلود کنید.
🔘 @TerminalNotes <- #tool
❤3👍1🐳1
توی دنیای DevOps و SRE ارزش شما با «میزان عمق دانش از یک ابزار» سنجیده نمیشه، بلکه به این هست که چقدر خوب میتونید دانشتون از ابزارهای مختلف رو به هم متصل کنید تا یک مشکل واقعی کسبوکار رو حل کنین. اینجاست که بازدهی زمانِ یادگیری (ROI) از قانون 80/20 پیروی میکنه: یادگیریِ 20 درصد از قابلیتهای یک ابزار، 80 درصد از نیازهای روزمره شما رو برطرف میکنه. اگه خیلی زود درگیر یادگیری جزئیات و ریزهکاریهای یک ابزار بشید، وقت باارزشی رو هدر میدید که میتونستید صرف یادگیری کلیت سیستم و بقیه ابزارها کنید.
مثلا اکر جونیور هستین و ۴۰ ساعت وقت بذارید و داکیومنتهای NGINX رو از سیر تا پیاز بخونید، شاید یاد بگیرین که چطوری بافرهای سطح پایینِ ورکرها (Workers) رو با زبان C دستکاری کنید و کلی کار خفن دیگه. اما یه کارآموز یا جونیور واقعا چند وقت یکبار به همچین چیزهایی نیاز پیدا میکنه؟ تقریبا هیچوقت. توی این حالت بازدهی یادگیری شما پایینه، چون ۳۵ ساعت از اون ۴۰ ساعت رو صرف چیزهایی کردید که احتمالا تا سالها به کارتون نمیاد.
📈 چطوری بازدهی (ROI) را بالا ببریم؟
پیاده کردن قانون 80/20 خیلی سادس: وقتی با ابزار جدیدی روبهرو میشید، سراغ 20 درصدی برید که برای راهاندازی و انجام یه کار واقعی به اون نیاز هست.
اما یه سوال مهم اینجا مطرح میشه: کدوم 20% رو باید یاد گرفت؟
راه درستش اینه که همیشه از یه سنیور یا تیملید بپرسید؛ اگر در دسترس نیست از AI. بدون این راهنمایی، ریسک اینو دارید که اشتباهی چیزهای حیاتی رو «advanced» فرض کنید و skip کنید (یا برعکس).
💭 اما آیا این یعنی همیشه سطحی بمونیم؟
ممکنه بگید اگه تمام اعضای تیم فقط دانش سطحی و گسترده داشته باشن، سایت یا اپلیکیشن شما با قطعیهای طولانیمدت مواجه میشه (که درسته). به همین دلیله که شرکتها مهندس Senior استخدام میکنن؛ کسایی که در طول بیش از 7 سال کار، به تدریج دانش خودشون توی ابزارها رو عمیق کردن و تو شرایط بحرانی، جونیورها رو پشتیبانی میکنن.
این مدل توی صنعت به T-Shaped Engineer معروفه:
بخش افقیِ T: آگاهی گسترده از ابزارهای مختلف
بخش عمودیِ T: عمق واقعی در حداقل یک حوزه
هدف اینه که در مسیر رشدتون، به تدریج اون بخش عمودی رو بسازید، نه از روز اول.
🔘 @TerminalNotes <- #devops #sre
مثلا اکر جونیور هستین و ۴۰ ساعت وقت بذارید و داکیومنتهای NGINX رو از سیر تا پیاز بخونید، شاید یاد بگیرین که چطوری بافرهای سطح پایینِ ورکرها (Workers) رو با زبان C دستکاری کنید و کلی کار خفن دیگه. اما یه کارآموز یا جونیور واقعا چند وقت یکبار به همچین چیزهایی نیاز پیدا میکنه؟ تقریبا هیچوقت. توی این حالت بازدهی یادگیری شما پایینه، چون ۳۵ ساعت از اون ۴۰ ساعت رو صرف چیزهایی کردید که احتمالا تا سالها به کارتون نمیاد.
📈 چطوری بازدهی (ROI) را بالا ببریم؟
پیاده کردن قانون 80/20 خیلی سادس: وقتی با ابزار جدیدی روبهرو میشید، سراغ 20 درصدی برید که برای راهاندازی و انجام یه کار واقعی به اون نیاز هست.
اما یه سوال مهم اینجا مطرح میشه: کدوم 20% رو باید یاد گرفت؟
راه درستش اینه که همیشه از یه سنیور یا تیملید بپرسید؛ اگر در دسترس نیست از AI. بدون این راهنمایی، ریسک اینو دارید که اشتباهی چیزهای حیاتی رو «advanced» فرض کنید و skip کنید (یا برعکس).
💭 اما آیا این یعنی همیشه سطحی بمونیم؟
ممکنه بگید اگه تمام اعضای تیم فقط دانش سطحی و گسترده داشته باشن، سایت یا اپلیکیشن شما با قطعیهای طولانیمدت مواجه میشه (که درسته). به همین دلیله که شرکتها مهندس Senior استخدام میکنن؛ کسایی که در طول بیش از 7 سال کار، به تدریج دانش خودشون توی ابزارها رو عمیق کردن و تو شرایط بحرانی، جونیورها رو پشتیبانی میکنن.
این مدل توی صنعت به T-Shaped Engineer معروفه:
بخش افقیِ T: آگاهی گسترده از ابزارهای مختلف
بخش عمودیِ T: عمق واقعی در حداقل یک حوزه
هدف اینه که در مسیر رشدتون، به تدریج اون بخش عمودی رو بسازید، نه از روز اول.
🔘 @TerminalNotes <- #devops #sre
❤3👍2
Terminal Notes
توی دنیای DevOps و SRE ارزش شما با «میزان عمق دانش از یک ابزار» سنجیده نمیشه، بلکه به این هست که چقدر خوب میتونید دانشتون از ابزارهای مختلف رو به هم متصل کنید تا یک مشکل واقعی کسبوکار رو حل کنین. اینجاست که بازدهی زمانِ یادگیری (ROI) از قانون 80/20 پیروی…
الان که توی شرایط قطعی (Blackout) سراسری اینترنت هستیم و عملا کار زیادی از پیش نمیره، داشتن یه پیشرفت حداقلی و کوچیک خیلی واجبه. مسیر یادگیری مثل دوچرخهسواریه؛ اگه دست از رکاب زدن بردارین، زمین میخورین.
کتاب خوندن یکی از بهترین راهها برای حفظ این حرکته. شاید این حرف کلیشهای باشه و همهجا شنیده باشین (که البته درست هم هست)، اما صحبت الان من چیز دیگهایه: چطوری باید با کتابهای حوزه IT رفتار کنیم؟
1. خوندن کتابهای IT با رمان فرق میکنه
وقتی خوندن یه کتاب فنی رو شروع میکنین، لزوما قرار نیست اون رو از فصل اول تا آخر پشت سر هم بخونین. برای اینکه بدونین دقیقا چقدر از یه کتاب رو باید مطالعه کنین، به همون قانون ۲۰/۸۰ که توی پیام قبل گفتم مراجعه کنید.
با بقیه کتاب مثل یه مرجع (Desk Reference) رفتار کنین؛ یعنی هر وقت برای حل یه مسئله به بخش خاصی نیاز پیدا کردین، همون بخش رو بخونین. این روش مزایای خودش رو هم داره: وقتی یه مفهوم جدید رو یاد میگیرین و همون لحظه ازش استفاده میکنین، ماندگاریش توی ذهن به مراتب بیشتر میشه.
2. مراقب کتابهای تاریخگذشته (Outdated) باشین
توی دنیای IT، کتابهایی که موضوعشون مرتب در حال تغییر و تحوله (مثل Docker) و بیشتر از 2 سال از انتشارشون میگذره، توی این حوزه منسوخ حساب میشن. پس اگه منابع بهروزتر و بهتری در دسترس دارین، وقتتون رو صرف کتابهای قدیمی نکنین.
🔘 @TerminalNotes <- #book #it
کتاب خوندن یکی از بهترین راهها برای حفظ این حرکته. شاید این حرف کلیشهای باشه و همهجا شنیده باشین (که البته درست هم هست)، اما صحبت الان من چیز دیگهایه: چطوری باید با کتابهای حوزه IT رفتار کنیم؟
1. خوندن کتابهای IT با رمان فرق میکنه
وقتی خوندن یه کتاب فنی رو شروع میکنین، لزوما قرار نیست اون رو از فصل اول تا آخر پشت سر هم بخونین. برای اینکه بدونین دقیقا چقدر از یه کتاب رو باید مطالعه کنین، به همون قانون ۲۰/۸۰ که توی پیام قبل گفتم مراجعه کنید.
با بقیه کتاب مثل یه مرجع (Desk Reference) رفتار کنین؛ یعنی هر وقت برای حل یه مسئله به بخش خاصی نیاز پیدا کردین، همون بخش رو بخونین. این روش مزایای خودش رو هم داره: وقتی یه مفهوم جدید رو یاد میگیرین و همون لحظه ازش استفاده میکنین، ماندگاریش توی ذهن به مراتب بیشتر میشه.
2. مراقب کتابهای تاریخگذشته (Outdated) باشین
توی دنیای IT، کتابهایی که موضوعشون مرتب در حال تغییر و تحوله (مثل Docker) و بیشتر از 2 سال از انتشارشون میگذره، توی این حوزه منسوخ حساب میشن. پس اگه منابع بهروزتر و بهتری در دسترس دارین، وقتتون رو صرف کتابهای قدیمی نکنین.
🔘 @TerminalNotes <- #book #it
👍3🐳1