اگه چند وقت هست با گولنگ کار می‌کنید شاید بد نباشه که یه مروری روی ریزه کاری‌هاش داشته باشید.
من این کتاب ۱۰۰ اشتباه در گولنگ رو خیلی وقت پیش دیده بودم و امروز یه نگاهی انداختم بهش و به نظر برای این منظور کاربردی میاد.
https://100go.co/

برای این که بیش‌تر تشویقتون کنم یک نمونه هم می‌گذارم:

فرض کنید ۱ ملیون ایتم به مپ اضافه میکنیم در این مرحله برنامه ۱۰۰ مگابایت مموری مصرف می‌کنه. حالا هر ۱ ملیون تا رو حذف می‌کنیم و گاربیج کالکتور رو هم صدا می‌کنیم. در این مرحله برنامه چقدر مموری مصرف میکنه؟ نزدیک به صفر؟ پاسخ اینه که نه. چون تعداد bucket های مپ فقط زیاد میشن و کم نمیشن در نتیجه خود مپ همچنان مموری نسبتا زیادی مصرف می‌کنه.
https://100go.co/28-maps-memory-leaks/

آسیب پذیری جدید روی react باعث دسترسی remote code execution میشه! اسمش react2shellئه و میتونید اینجا ازش بخونید.

https://www.rapid7.com/blog/post/etr-react2shell-cve-2025-55182-critical-unauthenticated-rce-affecting-react-server-components/

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

در مورد estimate دادن روی تسک و ارتباط تک و پروداکت ویدیوی بامزه‌ای بود.
https://www.youtube.com/watch?v=yNtJP6EHBik

در مورد حافظه محدود LLM ها و contest window و چرایی نیاز به RAG این مطلب خیلی خوبی بود.

به طور خلاصه، LLM هیچ چیزی از ما یادش نگه نمی‌داره که به نحوه پیاده‌سازیش برمی‌گرده. حالا برای این که یه توهمی از حافظه و ادامه پیدا کردن چت به ما بده، به ازای هر پیامی که بهش می‌دیم، همه‌ی تاریخچه رو دوباره میخونه. برای همین چت که طولانی میشه هم دیرتر جواب میده هم دقتش کم میشه.
برای حلش تا یه جایی می‌شه context رو بزرگ تر کرد ولی یادمون نره که از order N^2 زمان و توان پردازشی مصرف می‌کنه. راه دیگه آوردن چیزهای مرتبط به کانتکسته که همون RAG می‌شه.


https://blog.bytebytego.com/p/the-memory-problem-why-llms-sometimes

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

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

لطفا هرچنلی که معرفی میکنید در یک پیام باشه ولی هر تعداد پیام خواستید بدید. ✌️

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

بین اونایی که شرکت‌های بزرگ ارائه کردن، من با Gemini و Claude Code کار کردم. Gemini اصلا خوب نیست و با این که اشتراک Ai Proش رو گرفتم نه جواب‌های خوبی می‌ده نه سرعت خوبی داره نه دقت خوبی داره. البته من با Gemini-2.5-pro تست کردم ولی جدا از دقت مدل، تجربه کاربری خیلی بدی هم داشت.
اما Claude Code بهترین تجربه‌ای بود که داشتم و هم سرعت نسبتا خوب هم دقت خیلی خوبی داشت و هم خودش todo درست می‌کرد از کارهایی که باید انجام می‌داد و تجربه کاربری خیلی خوبی هم داشت.

بین اونایی که provider قابل تنظیم داشتن، من چون اکانت openrouter داشتم محدودیتم این بود که حتما با api key اون کار کنه. با aider و opencode و vibe و goose کار کردم.

از همه بهتر opencode بود. رابط کاربری تمیزی داره، تجربه کاربری خوبی هم داره هرچند عالی نیست. مثلا این که full-screen بود یه مقدار منو اذیت می‌کرد ولی خب سلیقه‌ایه. نکته‌ی جالبش اینه که خودشون هم مدل ارائه می‌دن که هم کیفیت خوبی داره (مثلا grok 4.1 fast) و هم فعلا بدون لاگین و رایگان در دسترسه. البته قاعدتا نمی‌شه بلند‌مدت به این ویژگی اعتماد کرد ولی برای تست خوبه.
اینجا خوبه به crush هم اشاره کنم. نسخه‌ایه که تیم charm خریده/گرفته و توسعه رو ادامه می‌ده. من یکسری فیچر بیش‌تر دیدم ولی تفاوت خاصی قابل ملاحظه نبود هنوز.

بعد از اون vibe بود که به تازگی معرفی شده توسط mistral. برای من به عنوان ابزاری که تازه معرفی شده دوست داشتنی بود. نکته بارزش اینه که اگرچه امکان اتصال به openrouter (در واقع بک‌اند های openai) رو داره ولی تنظیم کردنش از عمد سخته. وقتی بازش می‌کنید ازتون api key خود mitral رو می‌خواد که با شماره ایران و بدون هزینه هم ساختش امکان‌پذیر نیست. بعد از چند تا ادیت کانفیگ بالاخره موفق شدم از این مرحله رد بشم. همچنان کانفیگش یه مقدار اذیت کننده‌ست و باید لیست مدل‌ها رو خودتون به همراه قیمت هر توکن وارد کنید و بعدا هم آپدیت کنید. بعد از انجام این کارها، من تجربه نسبتا خوبی باهاش داشتم.

در مرحله بعدی goose بود که ابزار پرامکاناتیه، رابط کاربری قشنگی هم داره ولی خیلی سخته. من موفق نشدم خیلی باهاش دوست بشم. امکانات automation هم به نظر داره ولی من تست نکردم. خوندم که اخیرا به linux foundation اهدا شده و به نظر آینده‌دار میاد.

بدترین چیزی که تست کردم هم aider بود. رابط کاربری خیلی زشتی داشت. تجربه کاربری خیلی بدی هم داشت. گه تا همینجا از بدی‌هاش به قدر کافی نگفتم، در اجرای اول همه کدهای اون پوشه رو برای llm می‌فرسته و کلی توکن هدر می‌ده!

سلام به شما دوستان قوی و عزیز 🙂
امیدوارم حالتون خوب باشه

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

خوشحال می‌شم که بخونیدش:
لینک پست

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

https://www.lennysnewsletter.com/p/everyone-should-be-using-claude-code

چطوری code review رو سرعت ببخشیم:

https://leaddev.com/culture/4-steps-speed-up-code-reviews

کد ریویو اجباری خوبه یا بد؟ خلاصه اینکه توسعه رو کند می‌کنه ولی باگ ها رو هم کم میکنه!

نکته ها:
+ یا کد ریویو نکنید یا اگه میکنید سریع و دقیق باشه. :))
+ میشه به جای اجبار همیشگی، هوشمندانه استفاده کرد، مثلا اگه کد حیاتی نوشته شده، یا ریویوی کد کسی که به کد مسلط نیست.

https://newsletter.manager.dev/p/the-price-of-mandatory-code-reviews

چطور از اجزایی که ممکنه دچار خطا بشن، یک سیستم قابل اتکا بسازیم؟
این مطلب به نظرم خیلی جالب و عمیق بود. مثال هایی از سیستم های سیاسی تا زیستی میزنه ولی به نظرم روح system design جذابی داشت و توصیه می‌کنم حتما بخونید.

https://medium.com/@alireza_norouzi/build-reliable-systems-from-unrealiable-parts-bd921be088c5

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

https://mikefisher.substack.com/p/imposter-syndrome


نظر خودم هم بخوام بگم، ما معمولا خودمون رو با چیزهایی مقایسه می‌کنیم که نباید.

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

۲- نتیجه کار خودمون در چند ساعت یا چند روز رو با نتیجه کار یه تیم بزرگ و با بودجه زیاد که ماه ها روش کار کردن مقایسه می‌کنیم. مثلا من چرا نمیتونم تو خونه تلگرام رو بنویسم. در بهترین حالت من مثل یه برنامه نویس تلگرامم که روز اوله داره می‌ره وارد تیم میشه. و یادمون نره هرچیزی روز اول MVP بوده تا این که کم کم بالغ شده یا اکثرا رها شده.

این پنل به میزبانی دانشگاه بهشتی برگزار میشه، حضوریه و جاش سمت ولنجک تهرانه. اگه جا و زمانش براتون مسأله‌ای نیست، توصیه می‌کنم حتما شرکت کنید.

هزینه ثبت‌نام ۲۰۰ هزار تومنه، ولی با کد تخفیف dorsa سی درصد هم کم می‌شه.
زمان برگزاری هم چهارشنبه ۱۰ دیه، ساعت ۱۳.

لینک ثبت‌نام:
https://evand.com/events/ai4se

آیا در یک تیم نرم‌افزاری، همه‌ی کار قابل مشاهده است؟ نه!
کارهایی مثل کد ریویو، تغییرات سریع روی پروداکشن و ... معمولا به شکل تسک و روی جیرا قرار نمی‌گیرن، در نتیجه قابل ارزیابی و پایش (مثلا برای ترفیع هم نیستن)

این مطلب علاوه بر توضیح مساله، یه سری راهکار هم بررسی کرده ولی مهم تر از راهکار به نظرم اینه که همه این حقیقت رو بپذیریم!

https://newsletter.manager.dev/p/the-shadow-work-in-engineering-teams

نشانه های یک کاربر با تجربه در لینوکس!
خلاصه: استفاده درست از ترمینال. :)))

https://itsfoss.com/linux-power-user-signs/