نوشته‌های ترمینالی

یه مطلب خوب در مورد کلمه‌های سخت میکروسرویس ها https://newsletter.systemdesign.one/p/microservices-design-patterns?publication_id=1511845&post_id=203522819 فقط متاسفانه همه‌ش رو نمی‌تونید رایگان بخونید، ولی تا همون جا که قابل خوندن هست توصیه میشه. میتونید به LLM هم بگید باقیشو براتون بنویسه.

من این مطلب رو خیلی دوست داشتم. یه واقعیتیو میگه که وایب کدرها ازش غافلن‌. ایده. اصلا اینه که ما قسمت برنامه نویسی رو سریع کردیم ولی قسمت مسئولیت پذیری هنوز وجود داره. نویسنده میاد چند تا مثال میزنه از تیم هایی که بعد از AI، یک سری نیروی جونیور دارد که فقط با سرعت بالا کد/متن بی‌کیفیت تولید می‌کنند و با ارزش‌ترین نیروها مجبورن کار اونا رو چک کنن. به نظرم مهم ترین قسمت مطلب هم همینه: AI didn't make the work cheaper. It moved the bill from the people who make things to the people who have to own them. Owning something means reading it. Understanding it well enough to defend it. Putting your name on it. Answering the phone when it turns out it was wrong. There's no model for that, and there isn't one coming soon. You can generate the artifact. You can't generate the liability. https://www.charafeddine.co/letters/94-your-best-people-are-now-proofreaders

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

شاید یه چیزی که کمک کنه به این که حس ناکافی بودن از زیاد بودن ابزارهای AI نگیریم اینه که ببینیم بقیه دارن چیکار می‌کنن. اینجا یه community شکل گرفته که آدم ها ستاپ هاشون رو به هم نشون میدن و به هم امتیاز میدن‌. دوست داشتید یه سری بزنید. https://app.therundown.ai/community

💡 شکاف بهره‌وری هوش مصنوعی: چرا برنامه‌نویسان هنوز ۱۰ برابر سریع‌تر نشده‌اند؟ بیورن روچ (Bjorn Roche) بیش از دو دهه تجربه در صنعت فناوری و برنامه‌نویسی دارد و در وبلاگ شخصی خود درباره مهندسی و مدیریت می‌نویسد. خلاصه‌ای از مطلب جدید او را در نوشدارو می‌خوانید؛ با این هدف که نگاه تازه‌ای در اختیار مدیران و برنامه‌نویسان حوزه‌ی فناوری قرار دهد. هوش مصنوعی بدون تردید سرعت کدنویسی را افزایش داده است؛ اما برخلاف تصور برخی مدیران، ساخت یک قابلیت آماده و قابل‌اعتماد برای یک «محصول واقعی» هنوز به‌اندازه تولید یک نمونه اولیه سریع نیست. دلیل این تفاوت ساده است: بخش بزرگی از زمان مهندسان نرم‌افزار اصلاً صرف نوشتن کد نمی‌شود. ⛓مطالعه مطلب در نوشدارو #خبر_و_تحلیل نوشدارو را در تلگرام دنبال کنید: 💡 @NooshDaroo_web

کتاب معروف Designing Data-Intensive applications بعد از حدود ده سال ویراست دومش رو داده. اگر تا حالا نخوندینش الان بهترین وقت برای خوندنشه. اینجا در موردش بخونید: https://medium.com/javarevisited/i-read-designing-data-intensive-applications-2nd-edition-and-its-awesome-417103df5aab من خودم یه فصل‌هایی ازشو خوندم و خیلی دوستش داشتم.

هر کدوم از اصطلاحات در htop به چه معنی هستند؟ هدفش لزوما htop نیست، کلی چیز در مورد کرنل یاد می‌گیرید. https://peteris.rocks/blog/htop/

اگه دوست دارید مختصر و مفید در مورد reflog در git بدونید این صفحه رو ببینید. به طور خلاصه reflog مال وقتیه که روز بدی داریم. :))) دنبال کامیت هایی هستیم که در هیچ برنچی نیستن و اصطلاحا گم شدن و منتظرن GC بیاد و پاکشون کنه. https://wizardzines.com/comics/the-reflog/

هرچیزی که به عنوان برنامه نویس باید از حافظه‌ی سیستم بدونید: https://people.freebsd.org/~lstewart/articles/cpumemory.pdf

به عنوان یک Engineering Manager چطور وقت و انرژی خودمون رو بودجه بندی کنیم؟ این مطلب رو من خیلی دوستش داشتم چون می اومد با مثال و توضیح می‌گفت که اگر اینجا اینقدر وقت بگذاریم نتیجه چی میشه و خیلی کمک می‌کرد به درک اتفاقاتی که در لایه مدیریت میفته و تاثیرش روی تیم. https://www.manager.dev/newsletter/the-engineering-manager-s-attention-budget

یه موقعیت شغلی توی بلاگ byte byte go دیدم که خیلی جالب بود. شاید یه دید خوبی به شما هم بده که دنیای برنامه نویسی داره به کدوم سمت می‌ره. موقعیت شغلیش آموزش 𝐖𝐫𝐢𝐭𝐞 𝐏𝐫𝐨𝐝𝐮𝐜𝐭𝐢𝐨𝐧 𝐆𝐫𝐚𝐝𝐞 𝐂𝐨𝐝𝐞 𝐰𝐢𝐭𝐡 𝐀𝐈 بود. و توانایی که لازمه داشته باشی. با ایجنت ها بلد باشی کار کنی، نحوه کارشون رو بشناسی. برای کدی که نوشته میشه هم بلد باشی با سرعت بالا ریویو کنی و باگ و مشکلات امنیتیشون رو بشناسی تا ai slop مرج نکنی. https://blog.bytebytego.com/p/hiring-part-time-instructor-write

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

یه کتاب از یکی از نویسندگان Designing data intensive applications اسمش که خیلی خلاقانه هم هست The missing README ئه، و سعی میکنه نکات عملی در حوزه کار نرم‌افزار رو بگه که جای دیگه در دانشگاه و غیره بهش پرداخته نمیشه. فصل های متنوعی داره و چیزهای جالبی گفته، نقدش رو اینجا بخونید: https://nurkiewicz.com/2021/10/the-missing-readme-book-review.html

Linux file permissions are more than just rwx. Learn about the special permisions. https://linuxhandbook.com/suid-sgid-sticky-bit/

ما اینجا هم از خوبی AI گفتیم هم از بدیش، هم فهمیدیم چقدر خوبه هم دیدیم کجاها به درد نمی‌خوره، ولی همه اینا یه معنی داره: یادگیری استفاده درست از هوش مصنوعی برای پیشرفت در خیلی از حرفه‌ها، مخصوصاً شغل‌های مرتبط با کامپیوتر لازمه. از دید من می‌شه یادگیری AI رو به سه سطح تقسیم کرد: سطح اول: سطح خیلی زیرساختیه که نشون می‌ده چطور Deep Learning و LLMها آموزش می‌بینن، Fine-tune می‌شن، Inference انجام می‌دن، متن تولید می‌کنن، معماری Transformer چیه، معماری‌های مختلف چه تفاوتی با هم دارن و الی آخر. سطح دوم: این سطح به شکل کاربردی‌تر به مسئله نگاه می‌کنه. نمی‌خواد خودش LLM بسازه، ولی می‌خواد بدونه چه توانایی‌هایی داره، RAG چیه، MCP چیه و چه نقشی در اتصال مدل به ابزارها و منابع داده داره، چطور مدل می‌تونه با دنیای بیرون ارتباط برقرار کنه (مثلاً با Tool Calling)، و مفاهیمی مثل Thinking Effort رو هم می‌شناسه. سطح سوم: این سطح آسون‌ترین و به نظرم مهم‌ترین سطحه. این که بتونیم به ChatGPT یا یه مدل چتی دیگه پرامپت بدیم و جواب بگیریم، بتونیم دو تا agent تحت ترمینال ستاپ کنیم و ازشون استفاده کنیم. تو این سطح به نظرم این که چه چیزی رو به مدل بگیم (توی Context بذاریم)، به چه چیزهایی دسترسی داشته باشه، برای انجام چه کارهایی باید از کاربر اجازه بگیره، کدوم مدل با کدوم agent بهتر کار می‌کنه و برای چه کاری سریع‌تر و البته ارزون‌تره مهمه. اینجا قیمت API هم به نظرم اهمیت داره؛ اگر کارم با DeepSeek راه می‌افته، سراغ خانواده Claude نرم. اگر با Sonnet راه می‌افته سمت Fable نرم و هزینه‌م رو کمتر کنم و حتی در زمان هم صرفه‌جویی کنم. دید من اینه که سطح اول واجب نیست، ولی سطح دوم و سوم برای بیشتر برنامه‌نویس‌ها ضروریه. و حالا نوبت شماست! اگر محتوای آموزشی، متن، ویدیو، کورس یا هر چیز دیگه‌ای می‌شناسید که یک یا چند تا از این موضوع‌ها رو خوب توضیح داده، معرفی کنید. همچنین کنارش بگید بیشتر مربوط به کدوم سطحه.

یه مطلب آموزشی خیلی خوب برای CORS من این سبک توضیح دادن رو خیلی دوست دارم. به نظرم هم قابل فهم بود هم عمق خوبی داشت. https://sanyamserver.online/posts/cors/ @terminal_stuff

آیا خروجی AI خروجی ماست؟ یا ما نظارتی روش داریم؟ Cognitive offloading is delegating to the AI and still owning the answer. Cognitive surrender is when the AI’s output quietly becomes your output and there is nothing you feel is left to check. For software engineers the line between the two moves under your feet most days, and most of us are crossing it without noticing. https://addyosmani.com/blog/cognitive-surrender/ و https://newsletter.manager.dev/p/the-i-don-t-know-claude-wrote-this-pandemic

این مطلب خوب از بلاگ byte Byte go میاد و تفاوت های معماری LLMهای معروف (Gemini, ChatGPT و Claude) رو در حدی که توضیحات رسمیشون موجود هست توضیح میده. مثلا این که multi modal چیه، mixture of experts چیه و model routing چطوریه و چرا انجام می‌شه. https://blog.bytebytego.com/p/chatgpt-vs-gemini-vs-claude-how-they

در ادامه قوانینی که اسم دارن مثل قانون مورفی، یک سری قوانین نانوشته هم داریم که خوبه در نظر بگیریم و رعایت کنیم. مثلا این که تا وقتی بکاپی رو واقعا برنگردوندیم بودم و نبودنش هیچ فرقی نمی‌کنه. :)) https://zaidesanton.substack.com/p/the-unwritten-laws-of-software-engineering

امروز روز بزرگداشت خوارزمی و به همون مناسبت روز فناوری اطلاعاته. مبارکتون باشه. :))