یعنی این حسی که الان ما به وایب کدر ها داریم همون حسیه اسمبلی کاران وقتی زبان های سطح بالا اومد به افرادی که شروع به کار با اون زبان ها کردند، داشتند؟

متین چه ویدیو خوبی رو پخت و پز کرد!
https://www.youtube.com/watch?v=PCzD3VnRjds

با استفاده از
https://www.remotion.dev/
+
Claude Code
میشه موشن گرافیک های جذابی ساخت!

همینطوری که دارم رس کلاد رو میکشم و قابلیت هاش رو در میارم، متوجه شدم در بخش کلاد دیزاین انیمیشن هم میسازه و در قالب mp4 تحویل میده! ( کاربردی برای معرفی محصول، تولید آمار و ... )
یک ویدیو آماری از وضعیت رفاه و زندگی در ایران از سال 1390 تا الان ، باهاش ساختم.

ایران در آینه آمار.

ازدواج: کاهش 51 درصدی!
قیمت دلار: افزایش 99 برابری!
فرزندآوری: کاهش 35 درصدی!
مصرف گوشت قرمز: کاهش 54 درصدی!
مسکن تهران: افزایش 40 برابری!
طلاق: افزایش 41 درصدی!

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

توی مقاله نویسی واو! خیلی خوبیم.
اما در عملی کردن همون پژوهش ها؟ خیر.

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

🔶 مایکروسافت می خواهد با تراشه TPM به هر روشی شده جلوی کرک شدن ویندوز با ابزار KMS بگیرد.

اگر برای ویندوز نرم افزارهای خاص و گیم کار نمی کنید مهاجرت به لینوکس مینت برای تازه کارها بهترین گزینه به حساب میاد.

#خبر

@TheRaymondDev

گیت‌هاب بزرگ‌ترین مشکل وایب کدینگ رو حل کرده به‌تازگی Spec Kit رو راه‌اندازی کردن و فقط در چند روز، این پروژه بیش از 100 هزار تا ستاره گرفته.

ایده چیه؟
به‌جای اینکه پرامپت‌های مبهم بدید و دعا کنید که عامل هوش مصنوعی پروژه‌تون رو خراب نکنه... Spec Kit هوش مصنوعی رو مجبور می‌کنه قبل از دست زدن به کد، یک مشخصات (Specification) ساختاریافته ایجاد کنه.

هوش مصنوعی ابتدا می فهمه شما دقیقاً چه چیزی می‌خواید بسازید، چیزهای ناقص یا نامشخص رو می‌پرسه پروژه رو سازمان‌دهی می کنه و بعد شروع به برنامه‌نویسی می کنه.

دستورات :
/constitution → قوانین و استانداردها
/specify → چیزی که می‌خواید بسازید
/clarify → برطرف کردن ابهام‌ها قبل از شروع
/plan → معماری و تکنولوژی‌های مورد استفاده
/tasks → وظایف مرتب‌شده و مرحله‌بندی‌شده
/implement → اجرا

نصب :
github.github.com/spec-kit

@Linuxor

امروز به موضوعی بسیار تامل برانگیز برخوردم!

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

توضیحات سازنده رو خوندم.
ترجمه توضیحات سازنده برنامه، Laurent Cozic:

الان سخت میشه قضاوت کرد، چون همه‌چیز خیلی سریع داره عوض میشه. قبلاً این‌طور بود که وقتی کسی یه قابلیت رو پیاده‌سازی می‌کرد، برای پروژه سود خالص داشت. یعنی وقتی نوشتنش بیشتر از ریویو کردنش وقت می‌بُرد. بعضی وقت‌ها که یه مهندس کاربلد PR می‌زد، واقعاً برد بزرگی بود، چون یه ریویوی کوتاه تمام چیزی بود که لازم داشتیم. و امیدوارم برای طرف مقابل هم برد بوده باشه، چون بالاخره خودش هم به قابلیتی که می‌خواست می‌رسید.

با کدی که هوش مصنوعی تولید می‌کنه، این منطق کاملاً برعکس شده. الان ریویو کردنش برای ما خیلی بیشتر از نوشتنش برای اون طرف وقت می‌گیره. ضمن اینکه خیلی راحت شده که یکی یه PR سرسری بزنه و رد بشه، شاید برای رزومه‌اش یا برای GSoC. ظاهرش خوبه و تقریباً هیچ هزینه‌ای هم براش نداره. کافیه اسپک رو بده به Claude و هر چی بیرون اومد رو پست کنه. گاهی حتی build نمی‌شه ولی طرف چک هم نمی‌کنه.

نتیجه‌ی منطقی‌اش اینه که همون بهتر خودمون قابلیت رو پیاده‌سازی کنیم. چون کار کردن مستقیم روی یه فیچر با Claude خیلی راحت‌تر از اینه که یه واسطه وسط باشه که کامنت‌های ما رو می‌ریزه توی Claude و هر چی بیرون اومد رو کامیت می‌کنه، بدون اینکه نه کامنت ما رو فهمیده باشه نه کدی که تحویل داده. متأسفانه جوابمون رو هم اغلب با هوش مصنوعی می‌دن، با این بهانه که انگلیسی‌شون خوب نیست (که خب با این روش هیچ‌وقت هم خوب نمی‌شه، نه؟) و در سطح انسانی هم خوشایند نیست که وقت بذاری، چیزی رو ریویو کنی، کامنت‌ها رو با دست بنویسی و آخرش عملاً یه بات جوابت رو بده.

البته همیشه هم این‌طور نیست. کسی که واقعاً براش مهمه پروژه بهتر بشه این کار رو نمی‌کنه، و مهندس‌های باتجربه هم وقتی از هوش مصنوعی استفاده می‌کنن باز کد خوب تحویل می‌دن. مشکل اینه که چطور این آدم‌ها رو تشخیص بدیم بدون اینکه دوباره سیل PRهای بی‌کیفیت راه بیفته. برای همین فعلاً PRها رو محدود کردیم به کسایی که از قبل می‌شناسیم.

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

بسیار تامل برانگیز!
به چندین تا نکته اساسی اشاره کرد که به نظرم هیچ کس تا به حال بهشون اشاره نکرده بود.

‏Laurent Cozic به چندین تا مسیله اساسی اشاره کرد. اما به طور کلی مشکل اساسی پروژه های متن باز، یا حتی پروژه های شرکتی، حول محور عده ای خاصه.

افرادی که با هوش مصنوعی توهم قدرت و سرعت گرفته اند. این افراد دو دسته اند :
-وایب کدر هایی که هیچی از برنامه نویسی نمی‌دونند.
-برنامه نویسانی که شدیدا وایب کدینگ می‌کنند.

نتیجه چی میشه؟
با هوش مصنوعی کلی فیچر میزنن،دوست دارن سریع پیشرفت کنن. کلی برنامه هم میاد بیرون که تایتلش میشه : این برنامه رو صفر تا صد در دو روز زدم! یا پروژه های متن بازی که باید دم به دقیقه پول ریکویست های بی کیفیت رو ریویو کنند.

قبلا نوشتن و کار کردن روی برنامه واقعا لذت خاصی داشت. لازم بود با هزار تا چیز درگیر بشی،مطالعه کنی و در نهایت یک چیزی خلق کنی!
خیلی ها این درگیری رو یک نقطه ضعف می‌بینن ولی اتفاقا این درگیری خود لذت بود!

(البته پاراگرف آخر ربطی به حرفی که Laurent Cozic زد نداشت و نظر شخصی خودم بود.)

‏Joplin از فارسی پشتیبانی میکنه. اما فقط 78 درصدش تکمیل بود.
از برنامه نویس اصلی یعنی Laurent Cozic پرسیدم برای تکمیل ترجمه PR قبول می‌کنن؟ قول میدم از AI هم استفاده نکنم تا ترجمه ماشینی نشه 😅
گفت که اوکیه. منم چندین ساعت زمان گذاشتم و به طور دستی و با ابزار poEdit ترجمه رو تکمیل کردم. از 78 درصد رسوندمش به 100 درصد، یک سری اشتباهات ترجمه ای قبلی رو هم فیکس کردم.
حالا دیگه فارسی از معدود زبان هایی است که در برنامه Joplin به طور 100 درصد تکمیل شده است 🥳

در حال بیلد تست برای تمامی سیستم عامل ها...

یک نفر اومده کل استک دستیار هوش مصنوعی رو از صفر با زبان Zig از نو ساخته و اسمشو گذاشته NullClaw.

حالا اعداد و ارقامش رو ببینید تا مغزتون سوت بکشه:

حجم فایل باینری کلاً ۶۷۸ کیلوبایته،
حدود ۱ مگابایت رم مصرف می‌کنه
و زیر ۲ میلی‌ثانیه بالا میاد!
بدون ران‌تایم، بدون ماشین مجازی، بدون هیچ فریم‌ورک و بدون Garbage Collector.
فقط و فقط زیگ خالص!

چرا این موضوع این‌قدر غول و مهمه؟
یه مقایسه بکنیم:
- پروژه OpenClaw واسه اجرا به یه مک‌مینی ۵۹۹ دلاری و بالای ۱ گیگابایت رم نیاز داره.
- پروژه NanoBot به بالای ۱۰۰ مگابایت رم و پایتون نیازمنده.
- پروژه PicoClaw هم ۱۰ مگابایت رم و Go می‌خواد.

اما NullClaw راحت روی یه برد ۵ دلاری با فقط ۱ مگابایت رم اجرا میشه! دقیقاً همون قابلیت‌ها، ولی فقط با ۰.۱٪ مصرف منابع!

باورتون میشه تو همین ۶۷۸ کیلوبایت چه چیزایی جا داده؟
- بیش از ۲۲ ارائه‌دهنده هوش مصنوعی (مثل OpenAI، Anthropic، Ollama، DeepSeek، Groq و...)
- ۱۳ تا کانال چت (تلگرام، دیسکورد، اسلک، واتس‌اپ، iMessage و حتی IRC!)
- بیش از ۱۸ ابزار توکار (Built-in)
- جستجوی حافظه ترکیبی (برداری + کلیدواژه‌ای)
- محیط ایزوله (سندباکس) چندلایه (Landlock، Firejail، Docker)
- پشتیبانی مستقیم از قطعات سخت‌افزاری مثل آردوینو، رزبری پای و STM32
- پشتیبانی از MCP، زیرعامل‌ها (Subagents)، استریمینگ، صوت و خلاصه کل پشته (Full Stack) معماری‌ش هم فوق‌العاده‌ست؛

هر زیرسیستم یه رابط قابل تعویضه. یعنی واسه تغییر ارائه‌دهنده‌ها، کانال‌ها، ابزارها یا حافظه، فقط کافیه فایل تنظیمات (Config) رو دستکاری کنید، بدون اینکه لازم باشه دست به کد بزنید!
از نظر امنیت هم کلیدهای API به‌صورت پیش‌فرض با الگوریتم ChaCha20-Poly1305 رمزنگاری میشن. ۲,۷۳۸ تا تست داره، حدود ۴۵,۰۰۰ خط کد تمیز Zig هستش و صفر وابستگی فراتر از libc داره!
صد در صد رایگان و متن‌باز (Open Source)

https://github.com/nullclaw/nullclaw

@DevTwitter | <بوکانت/>

⁉️ نیاز به جستجوی دقیق در تلگرام داری؟ این ابزارها خیلی کمک می‌کنن:

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

❗️موتورهای جستجوی تلگرام ↓

• xtea.io/ts_en.html‎
• telemetryapp.io‎
• lyzem.com‎
• tgstat.com/en/search‎
• tgdev.io/tme/‎

+ واسه پیدا کردن فایل ، کانال ، گروه ، پست یا حتی تحلیل کانال و... خیلی بدرد میخوره

چرا آپلود فایل روی Vercel شکست می‌خورد؟

داستان خطای 413 (Content Too Large)

در پروژه ام یک عکس یا ویدیو بالای 5MB آپلود می‌کردم و بدون هیچ مشکلی آپلود انجام میشد. اما وقتی همین پروژه رو روی ورسل دیپلوی میکردم، برای فایل های بالای 5MB به خطای : 413 (Content Too Large) بر می‌خوردم!

چیزی که کلافه ام می‌کرد این بود که من حتی این فایل ها رو روی خود ورسل آپلود نمی‌کردم. بر روی فایل استوریج آروان آپلود میکردم و فقط از Server Actions گذر می‌کرد!

خب اولین حدس های من این بودند :
شاید اگر bodySizeLimit رو افزایش بدم درست بشه؟
-خیر. نشد.
خب اگر پلن رو ارتقا بدیم درست میشه؟
-خیر، مشکل چیز دیگریست.
اگر Server Action را به Route Handler تبدیل کنی چه؟ یعنی در خود پروژه یک api بسازی و از اون استفاده کنی به جای Server Action .
-خیر، این هم راه حل نیست.

خب، پس الان مشکل دقیقا کجاست؟ تقصیر از Next.Js است یا ورسل؟
مشکل اینه که ورسل Serverless هه! و این چیزیه که من بارها در معرفی ورسل دیده بودم،هزاران جا شنیده بودم اما اصلا به ماهیت اینکه یعنی چی ، توجه نکرده بودم.

حالا Serverless یعنی چی؟
سرور های سنتی (همین سیستم های لوکال خودمون، VPS ها) یک پروسه Node اجرا می‌کنند و 24/7 ساعته بالاست، یک پورت باز نگه میداره و هر ریکویست به شکل stream به سوکتی میرسه که پورسه ما مالکشه.

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

و ورسل Serverless هستش. هر Route Handler، هر Server Action، هر API Route که می‌نویسید، پشت صحنه تبدیل به یک تابع مستقل روی AWS Lambda می‌شه.
(پیام بازرگانی:AWS Lambda سرویس «تابع به‌عنوان سرویس» آمازون است که عملاً این دسته را در سال ۲۰۱۴ ساخت. کد را آپلود می‌کنید، آمازون هر وقت لازم شد اجرایش می‌کند، و شما به‌ازای هر اجرا و هر گیگابایت-ثانیه پول می‌دهید. صفر ریکوئست یعنی صفر هزینه.)

اینجاست که تکه های پازل پاسخ رو نمایان می‌کنند.
تابع ما یک استریم دریافت نمیکنه. یک event object دریافت میکنه.
پروکسی پلتفرم ما، کل ریکویست رو یکجا میگیره.
حالا Lambda سقف این payload را ۶ مگابایت گذاشته. بدنه هنگام ورود base64 میشه که حدود ۳۳٪ حجمش را زیاد می‌کند: ۶ ÷ ۱.۳۳ ≈ ۴.۵ مگابایت
و این تصمیم تجاری نیست که با افزایش پلن درست بشه. ماهیت مدل Serverless هه. و در نتیجه نمیتونیم ریکویست های بالای 4.5 مگابایت بزنیم و رویای آپلود فایل با چنین سیستمی رو، فراموش کنید.

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

تازه از تنور دراومده. اگر مثل من دقیقا با ماهیت Serverless آشنا نبودید بخونید، بد نیست.

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