DevTwitter | توییت برنامه نویسی

خبر تکنولوژی همه‌جا هست؛ چیزی که کمتر پیدا می‌شه، توضیح ساده‌ایه که بگه این خبر یا خطر دقیقاً چه تأثیری روی ما داره. توی «نوشدارو» درباره کلاهبرداری‌های جدید، امنیت، حریم خصوصی و اتفاقات مهم دنیای فناوری مطالب کاربردی منتشر می‌شه. @NooshDaroo_web @NooshDaroo_web

اگر روی یک محصول SaaS کار کرده باشید، می‌دانید محاسبه دقیق مصرف کاربر (مثل تعداد فراخوانی API، مصرف ترافیک یا منابع) بدون افت پرفورمنس و جلوگیری از Race Condition کار ساده‌ای نیست. پروژه SaaS-Metering با ترکیب جنگو، ردیس و سلری، یک سولوشن تر و تمیز برای رهگیری Asynchronous و بدون تاخیر مصرف، ثبت دقیق متریک‌ها و آماده‌سازی داده‌ها برای مدل‌های بیزینسی Pay-as-you-go پیاده‌سازی کرده. ​اگر قصد پیاده‌سازی سرویس Metering یا بررسی نحوه هندل کردن همزمانی و صف‌های تسک در پایتون رو دارید، می‌تونید سورس و نحوه معماریش رو توی گیت‌هاب ببینید: https://github.com/hossein-rahmati/SaaS-Metering @DevTwitter | <Hossein/>

چرا برای هر ۱ میلیون توکن، چند دلار هزینه می‌کنی؟👀 وقتی با Sinox API هر ۱ میلیون توکن برای تمام مدل ها فقط ۱۹ سنت هزینه داره! دسترسی به مدل‌های برتر دنیا، همه با یک API و یک قیمت ثابت؛ ۹۹٪ ارزون‌تر! از استفاده روزمره تا کدنویسی و پردازش‌های سنگین؛ دیگه هزینه و حجم مصرف API محدودت نمی‌کنه بدون دردسر بلاک شدن اکانت و در دسترس حتی با IP ایران! 💙@Sinoxapi 🌐 Sinoxapi.com

یه ابزار جالب هوش مصنوعی دیدم برای جستجوی شغل که این کارا رو انجام میده برات: - شغل‌ها رو جستجو می‌کنه - رزومه‌ات رو برای شغل مد نظر شخصی‌سازی می‌کنه - کاورلتر می‌نویسه - برای مصاحبه آماده‌ت می‌کنه https://github.com/MadsLorentzen/ai-job-search ۴۳هزار استار و ۱۵هزار فورک داره. یاد یه چیزی افتادم. بارها پیش اومده که رزومه‌ها رو بررسی کنم. رزومه‌هایی که رنگ و بوی هوش مصنوعی میداد راستش واسم جالب نبود. نه اینکه بدم بیاد، بلکه فکر می‌کردم با این رزومه نمیشه سطح طرف رو متوجه شد و ارزش‌گذاری کرد. و بنابراین از راه‌های دیگه تلاش می‌کردم واقعاً ببینم طرف چکارست. به نظرم این روش‌ها و ابزارها فقط شاید توی کوتاه مدت جواب باشه. تصور کنید استفاده از این ابزارها بیشتر فراگیر بشه و همهٔ رزومه‌ها و کاورلترها به دست هوش مصنوعی نوشته بشه. همه رزومه‌ها خوشگل و شیک و پر از کلمه‌ها و جمله‌های سنگین و رنگین. دیگه کم‌کم بررسی رزومه و کاورلتر با انسان و ATS کار بی‌ارزشی میشه، و ملاک‌ها و معیارهایی جز یه نوشتهٔ دو صفحه‌ای (=رزومه) برای بررسی سطح کاندیداها مهم‌تر میشن. مثل فعالیت‌های شبکه‌های اجتماعی، نظر کارفرماهای قبلی درباره مهار

توییتی که ۱۷۰ میلیون ویو خورده توی ایکس یه استعفای جنجالی از Anthropic! یکی از محقق‌های سابق OpenAI و Anthropic امروز استعفا داده و گفته: «هیچ‌کدوم از این دو شرکت مسئولانه عمل نمی‌کنن.» ادعاش اینه که هر دو شرکت با سرعت دارن به سمت ابرهوش خودبهبوددهنده (Self-Improving Superintelligence) می‌رن؛ چیزی که به گفته‌ی اون، عملاً دارن با زندگی همه‌ی ما قمار می‌کنن. این آدم ۳ سال روی Pretraining در OpenAI و Anthropic کار کرده. وقتی یه نفر از داخل این دو شرکت چنین هشداری می‌ده… شاید بد نباشه جدی‌تر به این سؤال فکر کنیم: آیا رقابت برای ساخت AGI داره از کنترل خارج می‌شه؟ @DevTwitter | <امیرحسین ثقه الاسلامی/>

سال‌هاست توی پروژه‌های فرانت‌اند، تقریباً همه‌مون با این ترکیب کار کرده‌ایم: یک ابزار برای پیدا کردن مشکل‌های کد (ESLint) یک ابزار برای فرمت کردن کد (Prettier) ترکیب خوبیه؛ ولی هرچی پروژه بزرگ‌تر و وابستگی‌ها بیشتر میشن، هزینه‌ی اجرای این ابزارها هم بیشتر خودش رو نشون میده. دقیقاً همین‌جاست که Biome وارد بازی میشه. این ابزار با زبان Rust نوشته شده و از همون اول با هدف سرعت بالا و یکپارچه‌سازی ابزارهای Code Quality ساخته شده. یعنی به‌جای اینکه چند ابزار مختلف رو برای Lint، Format و مدیریت تنظیمات کنار هم بچینیم، میتونیم بخش قابل‌توجهی از این کارها رو با یک ابزار انجام بدیم. اما چرا Biome این‌قدر مورد توجه قرار گرفته؟ -️ از نظر Performance: به‌دلیل معماری و پیاده‌سازی Rust، در پروژه‌های بزرگ میتونه زمان اجرای Lint و Format رو به شکل محسوسی کاهش بده؛ مخصوصاً وقتی این فرآیندها مرتباً در Editor یا CI اجرا میشن. - از نظر Configuration: دیگه لازم نیست برای هماهنگ کردن چند ابزار و تعداد زیادی Plugin و Config، چندین لایه تنظیمات داشته باشیم. - از نظر یکپارچگی: Linting و Formatting در یک اکوسیستم انجام میشن و همین موضوع میتونه تعداد ابزارها و وابستگی‌های پروژه رو کمتر کنه. - از نکات فنی جالبش اینه که در نسخه‌های جدیدتر (سری ۲.x)، قابلیت Type-aware Linting رو بدون نیاز به اجرای کامل TypeScript Compiler ارائه میده؛ چیزی که قبلاً بین ابزارهای Lint جاوااسکریپتی کم‌سابقه بود. -️ برای پروژه‌های React، TypeScript، Next.js و حتی Monorepoها هم، Biome میتونه یک گزینه‌ی جدی برای جایگزینی بخشی از Toolchain قدیمی باشه. البته این به معنی این نیست که ESLint و Prettier دیگه به درد نمیخورن. اکوسیستم ESLint هنوز بسیار بزرگه و Pluginهای زیادی داره؛ مثلاً بعضی قوانین خاص eslint-plugin-import هنوز معادل کاملی توی Biome ندارن و ممکنه در پروژه‌های خاص بهشون نیاز داشته باشید. همین‌طور فرمت‌دهی Biome حدود ۹۷٪ با Prettier سازگاره، نه صددرصد؛ یعنی موقع مهاجرت ممکنه یه سری Diff جزئی رو ببینید، هرچند در عمل تأثیر چندانی روی کدبیس نداره. شاید وقتش رسیده Toolchain فرانت‌اند رو کمی ساده‌تر کنیم. @DevTwitter | <Pouya Bakhshi/>

چینی‌ها انگار تصمیم گرفتن صنعت ویدئوی AI رو هم به دردسر بندازن! فقط یه عکس + یه فایل صوتی می‌دی… و LongCat-Avatar برات یه ویدئوی چنددقیقه‌ای از همون آدم می‌سازه که لب و صدا کاملاً با هم Sync هستن بدترش برای سرویس‌های پولی؟ - اوپن سورس - رایگان - قابل اجرا توسط خودت چیزی که قبلاً دوربین، استودیو، بازیگر و کلی ادیت می‌خواست، حالا با چند فایل و یه ریپو قابل انجامه! AI Video داره خیلی سریع‌تر از چیزی که فکر می‌کردیم جلو میره ریپو : https://github.com/meituan-longcat/LongCat-Video مدل : https://huggingface.co/meituan-longcat/LongCat-Video-Avatar-1.5 @DevTwitter | <امیرحسین ثقه الاسلامی/>

مهندسان اوبر در یک بلاگ‌پست فنی جزییات جالبی از نصف کردن تاخیر جستجوی Uber Eats منتشر کرده‌اند. فارغ از بهینه‌سازی‌های مرسوم معماری، استفاده عملی‌شان از ایجنت‌های هوش مصنوعی برای تیونینگ کد توجه من را جلب کرد. خلاصه تغییرات کلیدی: ۱. تغییر متریک اصلی به ATF (مدت‌زمان رندر اولین بخش تصویر در گوشی کاربر) و تبدیل رندر HTML به یک پایپلاین کاملا Async. ۲. جداسازی Hydration به دو فاز مجزا؛ واکشی سریع سیگنال‌های رتبه‌بندی برای اجرای زودهنگام مدل‌ها، و لود موازی جزییات نمایشی (قیمت، تصویر و...). ۳. بهینه‌سازی امبدینگ‌ها با کاهش دقت اعشار و فشرده‌سازی تا ۴۶٪، در کنار تبدیل پوینترها به Value types در کد Go که مصرف ۴۰ درصدی پردازنده توسط Garbage Collector را به شدت کم کرد. ۴. استفاده از لوپ خودکار ایجنتی؛ ایجنت با تحلیل پروفایل‌های زنده پروداکشن، باتل‌نک‌های ریز را پیدا می‌کرد، کد بهینه‌سازی می‌نوشت، پول‌ریکوئست می‌زد و با بنچمارک نتیجه را می‌سنجید. ۵. برنامه‌های آینده بر پایه مایکروبچینگ، فیلترینگ در لایه ایندکس (Zero-Pass Ranking) و استریم فرگمنت‌های نتایج به سمت کلاینت. لینک مقاله: بخوانیدش، خیلی جالبه! uber.com/us/en/blog/uber-eats-search-pipeline/ @DevTwitter | <Mehdi Allahyari/>

⚠️ کاربران همیشه خطاهای اپلیکیشن را گزارش نمی‌کنند؛ گاهی فقط صفحه را می‌بندند و می‌روند. 🔮 اینجاست که داشتن تصویر دقیق‌تری از خطاها، عملکرد اپلیکیشن و تجربه واقعی کاربر می‌تواند به تیم فنی کمک کند سریع‌تر به ریشه مشکل برسد. 🔘 با سنتری هم‌روش می‌توانید: • جزئیات و شرایط وقوع خطاها را بررسی کنید. • خطاها را بر اساس رخدادها و کاربران تحت‌تأثیر اولویت‌بندی کنید. • با Traceها و Spanها، عملیات کند را پیدا کنید. • با Session Replay، مسیر کاربر پیش از بروز مشکل را بازبینی کنید. 💎 در این ویدیو، نگاهی کوتاه به قابلیت‌های اصلی سرویس سنتری هم‌روش انداخته‌ایم. 🔗 شروع تست رایگان: 🔗 https://hmrv.sh/Shh46Z ☁️@hamravesh #سنتری #توسعه_نرم‌افزار #مانیتورینگ #عیب‌یابی

یه بازی دیگه با three.js https://whack-game.pages.dev/ @DevTwitter

یه اپ مک تمیز پیدا کردم که با SwiftUI نوشته شده: Claude Usage Tracker. . مصرف Claude رو لحظه‌ای تو منوبار نشون می‌ده، مولتی‌پروفایل داره، آیکوناش کاستومایز می‌شن و statusline ترمینال هم داره. . ۳.۴k استار. اوپن‌سورس، credential ها تو Keychain. https://github.com/hamed-elfayome/Claude-Usage-Tracker @DevTwitter | <ʀ≡ᴢᴀ/>

وقتی یه قابلیت رو به یه AI Coding Agent میسپاریم، مسئله فقط تولید کد نیست؛ مسئله اینه که AI دقیقاً چه چیزی رو باید پیاده‌سازی کند؟ اینجاست که مفهوم Spec-Driven Development یا SDD مطرح می‌شود. خب SDD یک رویکرد توسعه نرم‌افزار است که در آن Specification یا همان Spec به مرجع اصلی برای پیاده‌سازی و ارزیابی قابلیت تبدیل می‌شود. به زبان ساده، یعنی بجای اینکه AI را مستقیماً از یک ایده یا Prompt به سمت کد بفرستیم، ابتدا مشخص می‌کنیم دقیقاً چه چیزی باید ساخته شود، چه رفتاری باید داشته باشد و چه محدودیت‌هایی دارد. برای مقایسه Vibe Coding: ۱. نوشتن Prompt ۲. تولید کد ۳. اصلاح Prompt ۴. اصلاح کد ۵. تکرار این چرخه Spec-Driven Development: ۱. تعریف دقیق نیازمندی ۲. تهیه و بررسی Spec ۳. طراحی و برنامه‌ریزی ۴. پیاده‌سازی توسط AI Agent ۵. بررسی و اعتبارسنجی خروجی برای اینکه موضوع ملموس‌تر شود، فرض کنیم می‌خواهیم یک سیستم ورود بدون رمز عبور با Magic Link بسازیم. به‌جای اینکه فقط به AI بگیم: «یک سیستم Magic Link برای ورود کاربران بساز.» ابتدا Spec را تعریف می‌کنیم: نیازمندی‌ها: کاربر ایمیل خود را وارد می‌کند. یک لینک ورود برای او ارسال می‌شود. لینک فقط ۱۵ دقیقه معتبر است. لینک فقط یک‌بار قابل استفاده است. درخواست‌های متعدد برای یک ایمیل محدود می‌شوند. بعد، معیار پذیرش را مشخص می‌کنیم: Acceptance Criteria: ایمیل باید حداکثر طی ۳۰ ثانیه ارسال شود. لینک منقضی‌شده باید خطای مشخصی نمایش دهد. لینک استفاده‌شده دیگر نباید قابل استفاده باشد. حداکثر ۵ درخواست برای هر ایمیل در یک ساعت مجاز باشد. حالا AI Agent بر اساس این Spec، طراحی، Taskها، کد و حتی تست‌ها را تولید می‌کند. در پایان هم به‌جای اینکه صرفاً بپرسیم «کد درست به نظر می‌رسد؟»، می‌توانیم بررسی کنیم: آیا تمام مواردی که در Spec تعریف کرده بودیم واقعاً پیاده‌سازی شده‌اند؟ نکته مهم این است که Spec لزوماً یک سند ثابت و کاملاً انسانی نیست. در Workflowهای جدید، AI می‌تواند در استخراج ابهامات، تکمیل Spec، طراحی و حتی تبدیل آن به Taskهای قابل اجرا کمک کند؛ اما انسان همچنان مرجع تصمیم‌گیری و تأیید نهایی است. به همین دلیل، با گسترش AI Coding Agentها، مفاهیمی مثل Spec-Driven Development و ابزارهایی مانند GitHub Spec Kit، OpenSpec و Kiro مورد توجه قرار گرفته‌اند. @DevTwitter | <Amir Salehi/>

✅ اگه برنامه نویس هستی این کانالو از دست نده! امید زاهدی یکی از بزرگ ترین برنامه نویس ها در ایرانه که پروژه هاش توسط خبرگزاری ها و کانالای معروفی منتشر شده, با عضویت داخل کانالشون میتونید مطالب جالبی درمورد برنامه نویسی یاد بگیرید و از فرصت های شغلی جدید بهرمند بشید. لینک کانالشون:👇 https://t.me/+PGc3d7D-yjA2NzBk https://t.me/Funny_Learn

✅ همچنین میتونید جهت مشاوره برای شروع یادگیری برنامه نویسی بهشون مراجعه کنید: @Anony_muos

وقتی با همکارت تو چت به نتیجه نمی‌رسی چی می‌گی؟ «بیا یه جلسه بذاریم.» یه ابزار کوچیک ساختم که با Claude Code هم جلسه می‌ری. MR رو بهش می‌دی، باگ رو بهش می‌دی، دیزاین‌داک رو بهش می‌دی، و صوتی راجع‌بهش حرف می‌زنین. https://github.com/mhrlife/nutshell @DevTwitter | <The Big Rad/>

میدلولها خیلی بدردتون میخوره چند روز بعد از اینکه درباره تجربه خوبم با Graphify نوشتم، از workflow اصلی همون پروژه حذفش کردم! نه چون Graphify بد بود. اتفاقاً چون استفاده ازش باعث شد دقیق‌تر بفهمم از این مدل ابزارها چی می‌خوام. مسئله‌ای که داشتم فقط Search داخل codebase نبود. مسئله اصلی Orientation بود. هر تسک جدید با چند سؤال تکراری شروع می‌شد: این component کجا استفاده شده؟ این composable رو چی مصرف می‌کنه؟ این feature بین چه فایل‌هایی پخش شده؟ اگه این قسمت رو تغییر بدم، چه چیزهای دیگه‌ای تحت تأثیر قرار می‌گیرن؟ و Graphify برای اولین بار این حس رو بهم داد که قبل از باز کردن فایل‌ها، می‌شه یه نقشه از پروژه داشت. بعد رفتم سراغ Codebase Memory MCP تا ببینم همین ایده وقتی مستقیم وارد workflow خود Coding Agent می‌شه چه فرقی می‌کنه. مهاجرت هم اصلاً بی‌دردسر نبود :))) بعد از نصب و Index کردن پروژه، MCP داخل Codex با خطای Transport closed شکست خورد. CLI کار می‌کرد، Index سالم بود، حتی MCP خام هم جواب می‌داد؛ ولی چیزی که واقعاً می‌خواستم یعنی workflow داخل Codex کار نمی‌کرد. بعد از بررسی و سه Clean Start مستقل، MCP بالاخره در هر سه Session پایدار کار کرد و migration رو نهایی کردم. اما بخش جالب‌تر برای من اولین تسک واقعی بعد از مهاجرت بود. می‌خواستم نسخه موبایل پورتفولیوم رو اصلاح کنم: Header، Language Selector، Bottom Navigation و Responsive behavior. قبل از اینکه شروع کنم فایل‌ها رو بگردم، از CBM خواستم محدوده کار رو پیدا کنه. یکی از چیزهایی که سریع مشخص کرد این بود که BottomNav.vue از قبل توی پروژه وجود داره، ولی اصلاً داخل Layout mount نشده. همین کشف ساده جلوی ساختن دوباره چیزی رو گرفت که از قبل داشتم. ولی در همون تسک محدودیتش هم مشخص شد. و CBM معماری اولیه رو خوب پیدا کرد، اما detect_changes نتونست impact واقعی یه تغییر UI رو کامل بفهمه. Responsive CSS، Safe Area، RTL، Overflow توی عرض 320px و چیزی که کاربر واقعاً توی Browser می‌بینه، لزوماً توی Call Graph مشخص نیست. و اینجا به نتیجه‌ای رسیدم که به نظرم از خود مهاجرت مهم‌تره: من دیگه Graphify و Codebase Memory رو دو رقیب مستقیم نمی‌بینم. برای پروژه‌های Code-heavy، جایی که بیشتر سؤال‌ها درباره implementation فعلی، dependencyها، refactor و impact تغییراته، CBM برای من انتخاب طبیعی‌تریه. ولی وقتی پروژه فقط Code نیست و PRD، ADR، Research، Architecture Docs، PDF، Diagram و Domain Knowledge بخش مهمی از پروژه‌ان، Graphify هنوز ارزش خیلی جدی‌ای داره. حتی برای یه محصول بزرگ احتمالاً از هر دو استفاده می‌کنم: کدبیس Memory برای اینکه بفهمم: «الان کد چطور کار می‌کنه؟» و Graphify برای اینکه بفهمم: «چرا اصلاً اینطوری طراحی شده؟» با یه شرط مهم: هیچ‌کدوم Source of Truth نهایی نیستن. و Graph کمک می‌کنه سریع‌تر برسم به جواب. ولی برای implementation هنوز سورس رو می‌خونم، برای requirement خود PRD رو چک می‌کنم و برای UI هنوز Browser حرف آخر رو می‌زنه. تجربه کامل migration، failure، تست MCP و اولین task واقعی بعد از مهاجرت رو اینجا نوشتم: http://aliarghyani.vercel.app/fa/blog/graphify-to-codebase-memory-mcp @DevTwitter | <Ali Arghyani/>

یه اصل ساده تو مدیریت زمان هست، از کتاب معروف Getting Things Done (دیوید آلن): «اگه کاری کمتر از ۲ دقیقه طول می‌کشه، همون لحظه انجامش بده» دلیلش هم مشخصه: نوشتنش تو لیست، بعداً دیدنش، به یادش آوردن، دوباره سراغش رفتن... کل این پروسه خودش بیشتر از خودِ کار طول می‌کشه. پس ارزون‌ترین راه همون لحظه تموم کردنشه. حالا حکایت ما با ai-agentها عملا اینطوری میشه که اگه این اصل رو جدی بگیریمش تقریباً همه‌چی می‌فته زیر این آستانه! https://gettingthingsdone.com/2020/05/the-two-minute-rule-2/ @DevTwitter | <Hossein Nazari/>

برای تمرین سرویس های کلاود مثل AWS یا گوگل کلاود و یا Azure به صورت لوکال و بدون نیاز به داشتن اکانت، قبلا از لوکال استک استفاده میکردیم. جدیدا آلترناتیوی کاملا رایگان و اوپن سورس اومده، به نام floci . راحت رو سیستم خودتون با داکر ران کنید و تمام. https://floci.io/ @DevTwitter | <Mani/>

ایران‌سرور داره توی تلگرامش چنتا اکانت جی‌پی‌تی و جمنای مجانی میده. الان ادمینشون گفت قراره تا سه شنبه چنتا کد تخفیف ۱۰۰ درصدی جدید بزارن. تو این گرونی حتی یه اکانت جی‌پی‌تی میشه 7 تومن. دوس دارم سابسکرایبرای من این هدیه رو ببرن💙 @iranservercom

گوگل تونست مشکل کمبود رم و gpu رو حل کنه، برای اینکار ویروسی رو با کریسپر طراحی کرده که می‌تونه به مگس سرکه حمله کنه و مدل‌های هوش مصنوعی رو مغز اونها اجرا کنه، برای اینترفیس هم از نور و سنسورهای خازنی استفاده میکنه اینطوری که توکن ورودی به صورت نور به کلاستر مگس‌های سرکه تابونده میشه مگس‌ها برای تولید و حدس توکن خروجی به روی سنسورهای خازنی میشینن و دیتا رو جنریت می‌کنن، از اونجا که عمر این مگس‌ها کمه کل سیستم شبیه سطل زباله میوه س و توش زباله میوه میریزین و مگس‌های جدید متولد میشن و ویروس رو از مگس‌های قبلی میگیرن و چرخه ادامه پیدا میکنه. @DevTwitter | <سج‌آد/>