نوشته‌های ترمینالی
2.83K subscribers
425 photos
12 videos
32 files
2.31K links
Download Telegram
داشتم فورواردهای پست های چنل رو می‌دیدم، دیدم که چقدر چنل‌های خوبی دارید ولی من چشمم نخورده تا حالا. به جهت حمایت گفتم یه کاری بکنیم.

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

لطفا هرچنلی که معرفی میکنید در یک پیام باشه ولی هر تعداد پیام خواستید بدید. ✌️
27🔥1👏1
اگه دوست دارید با 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 می‌فرسته و کلی توکن هدر می‌ده!
👍43
Forwarded from ماه نامه
سلام به شما دوستان قوی و عزیز 🙂
امیدوارم حالتون خوب باشه

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

خوشحال می‌شم که بخونیدش:
لینک پست
6👍2👎1
ایده هایی برای استفاده از Claude code
و با استفاده فقط منظورم برنامه نویسی نیست، بلکه سریع و خودکار کردن کارهای روزمره. توصیه میکنم یه نگاهی به مثال هاش بندازید‌.

https://www.lennysnewsletter.com/p/everyone-should-be-using-claude-code
👍4👎4
کد ریویو اجباری خوبه یا بد؟ خلاصه اینکه توسعه رو کند می‌کنه ولی باگ ها رو هم کم میکنه!

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

https://newsletter.manager.dev/p/the-price-of-mandatory-code-reviews
👍9
چطور از اجزایی که ممکنه دچار خطا بشن، یک سیستم قابل اتکا بسازیم؟
این مطلب به نظرم خیلی جالب و عمیق بود. مثال هایی از سیستم های سیاسی تا زیستی میزنه ولی به نظرم روح system design جذابی داشت و توصیه می‌کنم حتما بخونید.

https://medium.com/@alireza_norouzi/build-reliable-systems-from-unrealiable-parts-bd921be088c5
🍓31
در مورد سندروم imposter یا همون حس ناکافی بودن خودمون این مطلب جالب بود و مثال های خوبی داشت. یکم طولانیه ولی اگه باهاش درگیر هستین توصیه میکنم بخونید. در مورد مدیرها هم قضیه رو باز می‌کنه که به‌عنوان مدیر بازخورد گرفتن و فهمیدن این که من خوبم یا نه چندان ساده نیست و ممکنه آدم ها راحت در این سمت، دچار خودکم‌بینی بشن.

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


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

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

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

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

لینک ثبت‌نام:
https://evand.com/events/ai4se
👍54👎3
آیا در یک تیم نرم‌افزاری، همه‌ی کار قابل مشاهده است؟ نه!
کارهایی مثل کد ریویو، تغییرات سریع روی پروداکشن و ... معمولا به شکل تسک و روی جیرا قرار نمی‌گیرن، در نتیجه قابل ارزیابی و پایش (مثلا برای ترفیع هم نیستن)

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

https://newsletter.manager.dev/p/the-shadow-work-in-engineering-teams
5👍4💔3
Forwarded from Linux Experts (𝖕𝖝𝖊)
💠 آشنایی با مجموعه ابزارهای moreutils

در کنار coreutils که ابزارهای کلاسیک مثل cp،‏ ls،‏ mv و… رو فراهم می‌کنه، moreutils چند ابزار کوچیک ولی کاربردی اضافه می‌کنه که جای خالی بعضی قابلیت‌ها رو تو محیط‌های یونیکسی و لینوکسی پر می‌کنن و توی اسکریپت‌نویسی خیلی به‌درد می‌خورن.

لیست چند تا از اسکریپت‌های کاربردی moreutils رو می‌تونید در ادامه ببینید:
‏- combine: ترکیب خطوط دو فایل با منطق AND/OR
‏- errno: نمایش اسم و توضیح خطاهای استاندارد errno
‏- ifdata: گرفتن اطلاعات اینترفیس شبکه بدون پارس ifconfig
‏- ifne: اجرای برنامه فقط اگه stdin خالی نباشه
‏- isutf8: چک‌کردن معتبر بودن UTF‑8 ورودی یا فایل
‏- lckdo: اجرای فرمان با فایل قفل برای جلوگیری از اجرای همزمان
این فرمان بعد از اضافه شدن فرمان flock به util-linux منسوخ شده و تو نگارش‌های آینده حذف می‌شه

‏- mispipe: پایپ‌کردن دو فرمان، ولی برگرداندن کد خروجی فرمان اول
‏- parallel: اجرای هم‌زمان چند فرمان (چند job)
‏- pee: شبیه tee، ولی فرستادن stdin به چند پایپ
‏- sponge: گرفتن کل ورودی و آخر کار نوشتن روی فایل
‏- ts: اضافه‌کردن timestamp به ابتدای هر خط ورودی
‏- vidir: ویرایش اسم/جای فایل‌ها از داخل ادیتور
‏- vipe: بازکردن stdin در ادیتور و فرستادن خروجی ویرایش به stdout
‏- zrun: اجرای فرمان روی فایل‌های فشرده، با آنزیپ خودکار موقت

#linux #commandline #tools
🔘 @linux_exp ~> More
👍73
Forwarded from Agora (Alireza)
شمارش با بو کشیدن: HyperLogLog
__________________

نیاز بود تعداد کانتکت‌هایی که به یک اکانت مشخص پیام‌ میدن در یک بازه‌ی ۲۴ ساعته شمرده بشن.

اولین راه حل و بدیهی‌ترینش این بود که واقعا ارسال کننده‌ی پیام‌ها رو توی یک ست ذخیره کنیم. یعنی توی یک بازه‌ی ۲۴ ساعته هرچی پیام بعد از یک ایونت شروع کننده‌ی اون ۲۴ ساعت میومد رو دونه دونه برای هر اکانت بررسی کنیم. پیجیده نبود ولی خیلی جالب به نظر نمیومد به خصوص این که نیازی به شمارش دقیق نداشتیم و این یعنی کلی هدررفت حافظه.

برای این که توی فضای بهینه این مسئله رو حل می‌کردم خیلی زود به یک حدس اولیه رسیدیم: Bloom filter.

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

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

تو این فکرا بودم و داشتم واسه یه مصاحبه سوال آماده می‌کردم که یهو یادم افتاد که من قبلا توی داکیومنت ردیس چشمم خورد به یک ساختمان داده‌ای که همون موقع برام خیلی جالب بود: HyperLogLog. بعد بررسی مجدد به نظر میر‌سید که جوابمون همینه!

هایپرلاگ‌لاگ یا HLL یک ساختمان داده با پیچیدگی فضایی ثابت مبتنی بر احتمالاته که میتونه تعداد عناصر یکتا در یک مجموعه‌ رو (که بهش می‌گن Cardinality) بدون این که واقعا تعداد تکرار‌ها رو بشمره و یا داده‌ها رو ذخیره کنه با ضریب خطای زیر یک درصد (حدود ۰.۸٪) محاسبه کنه. (برای تعداد ۲ به توان ۱۴ رجیستر. به صورت کلی، نرخ خطا برای m رجیستر برابر است با ۱.۰۴ بر رادیکال m)

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

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

احتمال این که یک عدد باینری:
- با ۱ صفر شروع بشه:
P(0) = ۱/۲

- با ۲ صفر متوالی شروع بشه (00):
P(00) = ۱/۴

- با ۳ صفر متوالی شروع بشه (000):
P(000) = ۱/۸

- با k صفر متوالی شروع بشه:
P(00…0)= ۱/۲^k

یعنی به ازای هر صفر اضافه، احتمال نصف می‌شه.

در نتیجه دیدن عددی که مثلاً با ۱۰ صفر شروع بشه، احتمالی به برابر با ۱ به ۱۰۲۴ داره. اتفاقی که فقط وقتی حجم داده‌ها بزرگ باشه رخ می‌ده.

در نهایت برای محاسبه‌ی تعداد تکرار، فرایند محاسبه‌ی آماری رو رو نه روی کل داده‌ها، بلکه روی مجموعه‌ای از رجیسترها انجام می‌ده. به این صورت که برای هر رجیستر فقط بیشترین تعداد صفر متوالی‌ای که تا اون لحظه دیده شده ذخیره می‌شه و با ترکیب آماری مقادیر همه‌ی رجیسترها، یک تخمین از تعداد عناصر یکتا به دست میاد.

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

در همین راستا، و برای این که این روایت برای علاقه‌مندان ابتر نمونه، این بلاگ پست رو که آقای Salvatore Sanfilippo که از ایتالیایی‌های اهل دل و البته از توسعه‌دهندگان اصلی ردیس هستن رو به هیج‌وجه از دست ندین. بلاگ راجع‌به HLL و پیاده‌سازیش در ردیسه:

Redis new data structure: the HyperLogLog

In the Redis implementation it only uses 12kbytes per key to count with a standard error of 0.81%, and there is no limit to the number of items you can count, unless you approach 2^64 items (which seems quite unlikely).
4👌4❤‍🔥2
در مورد مصاحبه شغلی به عنوان برنامه‌نویس، این سایت رو دوست داشتم. نظراتش رو خودمونی و دوستانه نوشته و توصیه‌های خوبی ارائه می‌ده. اگر درگیر این فضا هستید توصیه می‌کنم بخونید.
چیزی که تو فصل های اول جالب بود این بود که کار سختیه آفر گرفتن و قرار نیست با تلاش های اول به دست بیاد ولی به این معنی نیست که من ناکافی‌ام.

https://interviewguide.dev/
8👍3