مهندس نرم‌افزار هستید یا فقط یک تایپیستِ کد؟

ماه‌ها درگیر ترجمه و بررسی فصل‌به‌فصل کتاب The Clean Coder اثر رابرت سی. مارتین بودم. این کتاب نه درباره‌ی سینتکس است و نه فریم‌ورک؛ بلکه درباره‌ی شخصیت و صفت ما به عنوان یک متخصص است.
امروز، خلاصه این مانیفست بزرگ را در ۱۰ اصل جمع‌بندی می‌کنم. این چک‌لیستی است که مرز میان یک برنامه‌نویس آماتور و یک Software Craftsman را مشخص می‌کند:

مانیفست ۱۰ گانه‌ی عمو باب برای حرفه‌ای‌ها:

1- مسئولیت تام خرابکاری‌ها: اگر غیرحرفه‌ای اشتباه کند، کارفرما تاوان می‌دهد. اما وقتی حرفه‌ای اشتباه کند، خودش خسارت را جمع می‌کند و مسئولیت باگ‌هایش را می‌پذیرد.
2- قانون اول (آسیب نزن): فرستادن کدی که از تستش مطمئن نیستی به واحد QA، نهایت بی‌انضباطی است. QA برای اطمینان نهایی است، نه برای شکار اشتباهات بدیهی ما!
3- دفاع از کیفیت کد: سریع و کثیف یک دروغ بزرگ است. کثیف‌کاری همیشه سرعت تیم را در آینده نزدیک صفر می‌کند. شکستن اصول مهندسی زیر فشار ددلاین، خیانت به بیزینس است.
4- شجاعت در نه گفتن: حرفه‌ای‌ها حقیقت را به قدرت مدیران می‌گویند. وقتی کاری غیرممکن است، بگو غیرممکن است. چیزی به نام سعی می‌کنموجود ندارد؛ سعی می‌کنم یعنی آماده شدن برای شکست!
5- زبانِ تعهد: کلمات مبهم مثل امیدوارم، باید انجام بشه یا کاش را حذف کن. یک حرفه‌ای قطعی صحبت می‌کند: من این تسک را تا روز سه‌شنبه ساعت ۱۲ تحویل می‌دهم.
6- قانون ۴۰/۲۰ در اخلاق کاری: کارفرما وظیفه ندارد برای تیز کردن اره‌ی تو و آپدیت رزومه‌ات پول بدهد. ۴۰ ساعت در هفته برای کارفرما کار کن، ۲۰ ساعت در هفته در زمان شخصی‌ات مطالعه و تمرین Kata کن.
7- فرار از تله‌ی ناحیه جریان (Flow Zone): خلسه و تمرکز تونلی موقع کد زدن، دید کلان معماری را از تو می‌گیرد. برای فرار از این تله و حذف سیلوهای دانش، Pair Programming کن.
8- هرم اتوماسیون تست: تست کردن، نوشتن چند تست واحد پراکنده نیست. پایداری سیستم نیازمند لایه‌های هماهنگ از تست‌های واحد بالای ۹۰٪، تست مؤلفه، یکپارچه‌سازی و تست سیستم است.
9- بیزینس را بفهم: بدترین کار این است که خودت را در مقبره‌ای از تکنولوژی دفن کنی، در حالی که بیزینسی که به تو پول می‌دهد در حال سقوط است. وظیفه تو شناور نگه داشتن کشتی کسب‌وکار است.
10- مسئولیت بزرگان برای جوانان: دانشگاه تئوری علوم کامپیوتر را می‌گوید، اما مهندسی واقعی را نه! وظیفه اخلاقی مهندسان ارشد این است که جونیورها را زیر بال و پر خود بگیرند و منتور کنند.
تغییر و پذیرش این اصول، بیشتر از آنکه یک تصمیم عقلانی باشد، یک بلوغ انسانی و شخصیتی است.


@DevTwitter | <Hamed Heydarian/>

دیتاست کامل کانال «دِوتوییتر» تا ابتدای سال 2026

کل تاریخچه پیام‌های کانال دِوتوییتر به صورت JSON منتشر شد!
این دیتاست شامل تمام پیام‌ها از ابتدای شکل‌گیری کانال در سال 1399 تا دی 1404 هست (may 2020 -dec 2025).

مناسب برای:
- تمرین دیتاساینس و NLP روی محتوای فارسی برنامه‌نویسی
- تحلیل روند تکنولوژی‌ها در جامعه توسعه‌دهندگان ایرانی
- استخراج منابع آموزشی و لینک‌های مفید
- تحلیل واکنش‌ها و محبوبیت محتوا

لینک دسترسی:
github.com/devtwitter/devtwitter-data

یادتون نره ستاره بدین :))

@DevTwitter

اگر با Bagisto کار می‌کنید یا قصد دارید یک فروشگاه آنلاین مبتنی بر Laravel راه‌اندازی کنید، امیدوارم این پروژه بتونه در زمان شما صرفه‌جویی کنه.

در واقع Bagisto یک پلتفرم متن‌باز فروشگاه‌ساز مبتنی بر Laravel هست که برای ساخت فروشگاه‌های اینترنتی حرفه‌ای استفاده میشه.

امکانات پروژه:
PHP 8.3 FPM
Nginx
MySQL 8
Redis
Elasticsearch
Kibana
Mailpit
Supervisor
Cron Worker
Composer & Node.js
Xdebug برای توسعه و دیباگ

یکی از ویژگی‌های مهم پروژه، اسکریپت راه‌اندازی خودکار هست که تنها با اجرای:
./setup.sh
مراحل زیرو انجام میده:
- راه‌اندازی سرویس‌ها
- ایجاد دیتابیس‌های موردنیاز
- نصب وابستگی‌ها
- تنظیم فایل‌های Environment
- نصب Bagisto
- و Seed کردن داده‌های اولیه

علاوه بر این، برای فروشگاه‌های ایرانیم یه پکیج پرداخت توسعه دادم که امکان اتصال Bagisto به پرداخت‌یارهای ایرانی مثل زرین‌پال رو فراهم می‌کنه.

Docker Environment: github.com/hamedslyn/Bagisto-docker

Iranian Payment Package: github.com/hamedslyn/Bagisto-Iranian-Payment

@DevTwitter | <Hamed Soleymani/>

معماری YAGNI؛ اصلی که می‌تواند شما را به برنامه‌نویس بهتری تبدیل کند

یکی از مهم‌ترین اصول توسعه نرم‌افزار، اصل YAGNI است:

You Aren't Gonna Need It
(به آن نیاز نخواهی داشت)

بسیاری از برنامه‌نویسان زمان زیادی صرف ساخت قابلیت‌هایی می‌کنند که «شاید» در آینده لازم شوند؛ اما در عمل هرگز استفاده نمی‌شوند.

نتیجه چیست؟

- کدهای پیچیده‌تر
- زمان توسعه بیشتر
- باگ‌های بیشتر
- نگهداری سخت‌تر پروژه

برنامه‌نویسان حرفه‌ای به جای پیش‌بینی همه نیازهای آینده، فقط چیزی را پیاده‌سازی می‌کنند که امروز به آن نیاز دارند.

- کد کمتر
- خوانایی بیشتر
- توسعه سریع‌تر
- هزینه نگهداری کمتر

به یاد داشته باشید:

«هر خط کدی که نمی‌نویسید، باگی است که هرگز ایجاد نخواهد شد.»

مطالعه مقاله Martin Fowler درباره YAGNI:
https://martinfowler.com/bliki/Yagni.html

@DevTwitter | <Narjes Esmaeili/>

#کوته_نیوز

حمله سایبری به ۴ بانک تایید شد

شورای هماهنگی بانک‌ها:
اختلال ایجادشده در سامانه‌های بانک‌های ملی، تجارت، صادرات و توسعه صادرات ناشی از یک حمله سایبری محدود بوده است.

۴ بانک ملی، تجارت، صادرات و توسعه صادرات از صبح امروز از دسترس خارج شده‌اند

@DevTwitter | <ITIRAN/>

گاهی وقتها نیاز نیست دقیقا مثل بقیه عمل کنی
شاید قدرت در نگاه متفاوت بر خلاف بقیه هست
بیایید این دو خط رو با دو زبان برنامه نویسی مطرح این روزها برسی کنیم
گولنگ یا همون Go
راست یا Rust
قطعا در دنیای نرم افزار به اهمیت حافظه پی بردید
حافظه محدوده و برای نرم افزارها مثل نفس که اگر نباشه قطعا مرگ حتمی است
حالا یک اتاق رو در نظر بگیرید که چندین نفر توش تشک انداختن و خوابیدن صبح که بلند میشن و میرن اگر تشکها رو جمع نکنیم جا برای نشستن نیست
پس مجبوریم اگر خودشون جمع نکردن یک نفر این کار رو انجام بده در دنیای نرم افزار اگر اون اتاق رو حافظه در نظر بگیریم میگیم GC و کارش جمع کردن تشکها هست وقتی کسی توش نخوبیده تا جای نشستن باز بشه
خیلی از زبانها این روش رو دارن و استفاده میکنن
اما زبان برنامه نویسی Rust این مفهوم و قابلیت رو پیاده نکرد و از دو مفهوم دیگه استفاده میکنه به اسم Ownership و Borrowing
یعنی هر مقدار یک مالک دارد که بعد از استفاده اون رو پاک میکنه
به زبان ساده تر میگه بزرگواری که روی تشک خوابیدی اگر بلند شدی رفتی بیرون حتما باید جات رو جمع کنی وگرنه معرفت باید بیاد جمع کنه دیگه وظیفه یک شخص خاص نیست
برای همین مدیریت حافظه در راست در زمان کامپایل انجام میشه با دادن و پس گرفتن و این تضمین تمیز ماندن و نبود سرباره
علاوه بر اون گاهی اوقات GC کارش رو تموم نمیکنه و متوقف میشه در راست چینین چیزی وجود نداره
پس به جای رفتن در مسیری که همه رفتن
یک مسیر و تفکر جدید رو پیش گرفت
دنیای فنی مدیون همین متفاوت فکر کردنهاست


@DevTwitter | <Akbar Rezaeyan Ghane/>

یکی از سوال‌هایی که خیلی از افرادی که وارد دنیای دیتا می‌شن می‌پرسن اینه که تفاوت بین Data Scientist، Data Analyst، Product Analyst، BI Engineer، Data Engineer و ده‌ها عنوان شغلی مشابه چیه؟

واقعیت اینه که جواب مشخص و یکسانی برای این سوال وجود نداره.

شاید عجیب به نظر برسه، اما در صنعت داده، عنوان شغلی همیشه بیانگر کاری که واقعاً انجام می‌دی نیست. خیلی وقت‌ها دو نفر با یک عنوان شغلی مشابه، در دو شرکت مختلف، وظایف کاملاً متفاوتی دارن.

مثلاً در یک شرکت، Data Engineer بیشتر زمانش رو صرف ساخت زیرساخت‌های داده، طراحی Data Pipelineها و مدیریت انبارهای داده می‌کنه. اما در یک شرکت دیگه، ممکنه بخش قابل توجهی از کارش ساخت داشبوردها و گزارش‌های مدیریتی باشه.

یا یک Data Analyst در بعضی سازمان‌ها صرفاً روی تحلیل داده، تهیه گزارش و پاسخ به سوالات کسب‌وکار تمرکز داره؛ در حالی که در شرکت‌های دیگه ازش انتظار میره SQL پیشرفته بنویسه، Pipeline بسازه، آزمایش‌های A/B طراحی کنه و حتی در تصمیم‌گیری‌های محصول نقش کلیدی داشته باشه.

به طور کلی می‌شه این نقش‌ها رو این‌طور توصیف کرد:
موقعیت Data Analyst بیشتر روی استخراج بینش از داده‌ها، تحلیل روندها، تهیه گزارش و پاسخ به سوالات کسب‌وکار تمرکز داره.
موقعیت Product Analyst روی رفتار کاربران، عملکرد محصول، رشد، نگهداشت کاربران و تصمیم‌گیری‌های مرتبط با محصول کار می‌کنه.
موقعیت Data Scientist معمولاً علاوه بر تحلیل داده، از مدل‌های آماری و یادگیری ماشین برای پیش‌بینی، دسته‌بندی و حل مسائل پیچیده استفاده می‌کنه.
موقعیت BI Engineer زیرساخت گزارش‌گیری، داشبوردها، لایه‌های تحلیلی و سیستم‌های Business Intelligence رو توسعه می‌ده.
موقعیت Data Engineer مسئول ساخت و نگهداری زیرساخت انتقال، ذخیره‌سازی و پردازش داده‌هاست تا داده‌های قابل اعتماد در اختیار تیم‌های مختلف قرار بگیره.

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

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

به همین خاطر هنگام بررسی فرصت‌های شغلی، مهم‌ترین نکته اینه که روی عنوان شغل تمرکز نکنید؛ بلکه شرح وظایف، انتظارات شرکت، ابزارهای مورد استفاده و مشکلاتی که قراره حل کنید رو با دقت بررسی کنید.
در سال‌های آینده احتمالاً این روند حتی پررنگ‌تر هم خواهد شد. با رشد هوش مصنوعی، اتوماسیون و ابزارهای مبتنی بر مدل‌های زبانی بزرگ (LLM)، بسیاری از وظایف سنتی بین نقش‌های مختلف ادغام می‌شن و اهمیت عنوان‌های شغلی کمتر از قبل خواهد بود.

شاید در ۲ تا ۳ سال آینده، به جای اینکه خودمون رو Data Analyst، Data Scientist یا Data Engineer معرفی کنیم، بیشتر به سمت نقش‌های عمومی‌تر و منعطف‌تری حرکت کنیم؛ عنوان‌هایی مثل «Member of Technical Staff» که روی توانایی حل مسئله، درک سیستم‌ها و ایجاد ارزش تمرکز دارن، نه روی مرزبندی‌های سنتی بین نقش‌های مختلف.

در نهایت چیزی که آینده شغلی افراد رو تعیین می‌کنه، عنوان شغلی روی پروفایل لینکدین نیست؛ بلکه توانایی یادگیری، سازگاری با فناوری‌های جدید و حل مسائل واقعی کسب‌وکار با استفاده از داده‌هاست.

@DevTwitter | <Reza Jafari/>

تلگرام با قابلیت جدید Rich Formatting یک سری ابزار کامل برای نوشتن متن در اختیارتون میذاره، لیست، جدول، تیتر، ریاضیات و ...

@DevTwitter

کاش نتبلاکس یه آماری هم از میزان اختلال بانک ملی بذاره، یکی دو ماه خدمات میده باقیش اختلاله

@DevTwitter

این container که اپل ریلیز کرده رو تازه پیدا کردم! سبک‌ترین راهی که بتونید یه ترمینال لینوکسی ایزوله‌شده روی مک بالا بیارید!

با swift نوشته شده و برای پردازنده‌های Apple Silicon بهینه‌سازی کردن!

https://github.com/apple/container

@DevTwitter | <Amir/>

یه پروژه‌ی جالب دیدم به اسم SurfSense، که بهش می‌گن جایگزین اوپن سورس NotebookLM

اگه از NotebookLM میاید، باید بگم که SurfSense همون کارو می‌کنه؛ صرفا با کنترل کامل دست خودتون. خلاصه بخوام بگم، یه agent تحقیقاتی اوپن‌سورس و با تمرکز روی حریم خصوصیه که شبیه به کار NotebookLM رو انجام میده.

مزایا نسبت به NotebookLM:
• اتصال به ۲۵+ منبع: گوگل درایو، Notion، Slack، YouTube، GitHub و افزونه‌ی مرورگر برای ذخیره‌ی هر صفحه‌ای (حتی پشت لاگین)
• آزادی انتخاب مدل: ۱۰۰+ مدل از طریق LiteLLM، یا اجرای کاملاً لوکال با Ollama و vLLM
• بدون محدودیت داده: هیچ سقفی روی تعداد منبع و نوت‌بوک نیست، و دیتا روی سرور(یا سیستم) خودت می‌مونه
• جستجوی بهتر: RAG دومرحله‌ای در برابر سرچ تک‌مرحله‌ای NotebookLM
• قابلیت‌های تیمی جالب: به شما رول‌های Owner/Admin/Editor/Viewer میده + چت و کامنت و...
• تولید پادکستا بدون محدودیته

معایب:
• نصبش هلو برو توی گلو نیست واقعا. رو اعصابه — باید با dependency، API key و فایل‌های Env کلنجار برید
• هنوز کاملاً production-ready نیست و در حال توسعه‌ی فعاله
• باید خودت میزبانی و نگهداری کنی؛ طبیعتا که راحتی NotebookLM رو نداره

جمع‌بندی:
صادقانه بگم، NotebookLM همچنان ساده‌تر و آماده‌تره ولی کاملاً بسته‌ست. SurfSense سخت‌تر راه میفته ولی دیتا و انتخاب مدل کاملاً دست خودته. اگه با self-hosting و سرور هم بخواید پیش برید، به درد بخورترینه.

ریپوی اصلی: http://github.com/MODSetter/SurfSense
آدرس خود وبسایتش برای دانلود مستقیم نرم‌افزار: https://surfsense.com

@DevTwitter | <Matin SenPai/>

بزرگ‌ترین اشتباهی که برنامه‌نویس‌های تازه‌کار می‌کنن، کم کد زدن نیست.
زیاد یاد گرفتنه.
هر روز یک دوره جدید.
هر روز یک تکنولوژی جدید.
هر روز یک ویدیو با عنوان:
“این مهارت رو یاد نگیری عقب می‌مونی!”
و نتیجه؟
۶ ماه می‌گذره.
۱۰ دوره دیدی.
۵۰۰ ساعت آموزش دیدی.
اما هنوز یک پروژه واقعی نداری.
حقیقتی که خیلی‌ها دوست ندارن بشنون:
بازار کار به تعداد دوره‌هایی که گذروندی پول نمی‌ده.
به مسئله‌هایی که می‌تونی حل کنی پول می‌ده.
من رزومه‌هایی دیدم که ۳۰ مدرک داشتن.
ولی حتی یک پروژه کامل داخلشون نبود.
از اون طرف افرادی رو دیدم که فقط ۲ یا ۳ تکنولوژی بلد بودن.
اما پروژه ساخته بودن.
و دقیقاً همون‌ها استخدام شدن.
اگر امروز دوباره از صفر شروع می‌کردم:
کمتر آموزش می‌دیدم.
بیشتر می‌ساختم.

@DevTwitter | <Arsham Hajeb/>

مدل‌های رایگان گران قیمت

مدل‌هایی مثل Llama 4، Gemma 4، DeepSeek V3 و Qwen 3 در ظاهر «رایگان» و متن‌باز هستن، اما این رایگان بودن فقط تا وقتی معنی داره که داخل یک نوت‌بوک یا محیط تستی ازشون استفاده کنی. به محض اینکه وارد فضای واقعی و پروداکشن بشی، هزینه‌ها شروع می‌شن و عملاً اون چیزی که رایگان به نظر می‌رسه تبدیل به یک زیرساخت گران و پیچیده می‌شه. دلیلش هم اینه که هزینه اصلی این مدل‌ها نه خود مدل، بلکه اجرای پایدار، سریع و مقیاس‌پذیر اون‌هاست.

مدل‌های کوچک‌تر که بین ۸ تا ۳۰ میلیارد پارامتر دارن، معمولاً روی سیستم‌های شخصی با ۲۴ تا ۴۸ گیگ VRAM اجرا می‌شن و بیشتر برای تست، یادگیری و ساخت نمونه اولیه مناسب هستن. اما وقتی وارد مدل‌های متوسط مثل ۷۰ میلیارد پارامتر می‌شی، فقط برای نگه‌داشتن وزن مدل به ۷۰ تا ۱۴۰ گیگ VRAM نیاز داری و دیگه یک کارت گرافیک معمولی جواب نمی‌ده؛ در نتیجه باید سراغ سرورهای ابری بری که هزینه‌شون ماهانه به چند هزار دلار می‌رسه.

در سطح بالاتر، مدل‌های بزرگ MoE مثل Llama 4 Maverick با ۴۰۰ میلیارد پارامتر، Qwen 3 با ۲۳۵ میلیارد یا DeepSeek V3 با ۶۷۱ میلیارد پارامتر قرار دارن که برای اجرا به صدها گیگ حافظه تجمیعی نیاز دارن. حتی با کوانتیزه‌سازی هم هنوز به زیرساخت چند GPU قدرتمند مثل H100 یا H200 احتیاج داری و اگر بخوای کانتکست طولانی هم پشتیبانی کنی، مصرف حافظه (KV cache) عملاً هزینه و نیاز سخت‌افزاری رو تا نزدیک دو برابر بالا می‌بره.

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

به همین دلیل در عمل، خیلی از تیم‌ها بعد از بررسی هزینه‌ها به این نتیجه می‌رسن که استفاده از APIهای آماده مثل OpenAI یا Anthropic به‌صرفه‌تر از راه‌اندازی و نگه‌داری زیرساخت GPU اختصاصی است، چون اون‌ها همه این پیچیدگی‌ها و هزینه‌های پنهان رو در قالب یک قیمت ساده به ازای هر توکن مدیریت می‌کنن.

@DevTwitter | <Reza Jafari/>

یکی از بهترین پادکست‌هایی هست که میتونین در مورد پیشرفت شغلی در شرکتی که کار میکنید گوش بدید.

https://www.youtube.com/watch?v=8JQUjpBf3Ig

@DevTwitter | <سهیل/>

با ظهور Agent های هوش مصنوعی مثل Claude Code و Codex، بنظرم یک سؤال جدی‌تر از همیشه مطرح میشه:

آیا هنوز به فریمورک‌هایی مثل Laravel نیاز داریم؟

یکی از دلایل اصلی شکل‌گیری فریمورک‌ها، ساده‌تر کردن توسعه و حذف پیچیدگی‌های تکراریه.
اما اگر یک AI Agent بتونه همین کار را با PHP خام انجام بده و هم‌زمان مواردی مثل امنیت، design pattern ها و best practice ها را هم رعایت کند و تازه، احتمالا خودش قرار تنها کسی باشه که قرار روی پروژه توسعه بده، آیا هنوز استفاده از فریمورک‌ها منطقیه؟

اگر این مسیر را در نظر بگیریم، شاید برخی مزیت‌ها این‌طور باشند:
- کاهش وابستگی به abstraction های اضافی
- سبک‌تر شدن پروژه‌ها
- احتمالاً بهبود performance

اما در مقابل:
- امنیت و جلوگیری از خطاهای انسانی
- استانداردسازی در تیم‌های بزرگ
- نگهداری بلندمدت سیستم
- همکاری تیمی و onboarding ساده‌تر

شاید سؤال اصلی این نباشد که «فریمورک‌ها حذف میشن یا نه»، بلکه این باشه که:
در آینده، فریمورک‌ها چه نقشی در کنار AI ایفا خواهند کرد؟

@DevTwitter | <Amirreza Sharifi/>

دیتای متروی تهران (Tehran Metro Data) چیه؟

دسترسی به یک دیتابیس دقیق، ساختاریافته و آماده از خطوط و ایستگاه‌های متروی تهران، همیشه یکی از دغدغه‌های برنامه‌نویس‌ها و توسعه‌دهنده‌ها بوده. برای همین ما ریپازیتوری «Tehran Metro Data» رو منتشر کردیم.
این پروژه یک دیتاست استاندارد از شبکه متروی تهران هست؛ یعنی شما رو از جستجوی پراکنده، جمع‌آوری دستی یا اسکرپ کردن اطلاعات برای پروژه‌هاتون کاملاً بی‌نیاز می‌کنه.
این دیتا بدون نیاز به هیچ پیش‌پردازشی، مستقیماً برای ساخت اپلیکیشن‌های مسیریابی، بات‌ها یا تحلیل داده قابل استفاده است. مهم‌تر از همه اینکه اطلاعات به شکلی مرتب شده که به‌راحتی و بدون دردسر Data Cleaning، توی کد ایمپورت بشه.

https://github.com/mostafa-kheibary/tehran-metro-data


@DevTwitter | <تهلاگ/>

🚨 میانگین ۶۷۰ هزار دلار خسارت؛ تاوان استفاده کنترل‌نشده از هوش مصنوعی

هوش مصنوعی می‌تواند سرعت تیم‌ها را تا ۵۰٪ افزایش دهد؛ اما وقتی بدون «حاکمیت و نظارت» وارد سازمان شود، معمولاً از دو مسیر آسیب می‌زند:
📉 ۱. هدررفت بودجه
اوبر بودجه یک‌ساله هوش مصنوعی خود را در کمتر از ۴ ماه مصرف کرد؛ چون سقف مصرف مشخصی وجود نداشت.
🕵 ۲. هوش مصنوعی در سایه
اطلاعات استراتژیک سامسونگ به راحتی افشا شد، چون یک کارمند برای خلاصه کردن فایل صوتی جلسه، آن را به نسخه عمومی ChatGPT سپرد.

کارمندان قصد خرابکاری ندارند؛ آن‌ها فقط ابزاری برای تسریع امور می‌خواهند.
مسئله این است که سازمان باید این استفاده را مدیریت و کنترل کند.
💡 چت‌وان برای همین ساخته شده است:
✔ تعریف سقف مصرف برای افراد و دپارتمان‌ها
✔ جلوگیری از استفاده ابزارهای ناامن و پراکنده
✔ مدیریت دسترسی بر اساس نقش و نیاز هر کاربر

🔗 همین حالا فضای کاری امن تیم خود را بسازید


ارتباط با چت‌وان:
۰۹۰۱۸۳۷۴۴۲۰ - ۰۲۱۵۸۹۸۳۳۰۰

به جای اینکه امشب هم توی چرخ‌دنده‌های یوتیوب گم بشی و زمانت هدر بره...
این ۱۱ تا دوره رایگان رو دریاب تا کلود (Claude) رو کاملاً استاد بشی.

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

سطح اول: مفاهیم پایه (زمان مورد نیاز: ۲۰ دقیقه)

دریافت مدرک کلود:
claude101.com

آموزش کلود برای مبتدی‌ها:
https://ruben.substack.com/p/claude-for-dummies

هوش مصنوعی به زبان (خیلی) ساده:
https://ruben.substack.com/p/s?r=5m7l8v

نقشه راه یادگیری کلود:
https://ruben.substack.com/p/claude-roadmap

سطح دوم: فرآیندهای کاری واقعی (زمان مورد نیاز: ۵۵ دقیقه)

کار تیمی با همکار کلود (Claude Cowork):
claude-co.work

مدیریت کلود برای تیم‌ها:
how-claude.team

ساخت اسلاید و پرزنت با کلود:
how-to-gamma.ai

شخصی‌سازی فرآیندها با مهارت‌های کلود (Claude Skills):
claude-skills.free

سطح سوم: ترفندهای حرفه‌ای (زمان مورد نیاز: ۴۵ دقیقه)

اتصال کلود به بقیه ابزارها (Connectors):
https://ruben.substack.com/p/claude-connectors

چطور به محدودیت‌های پیام کلود برنخوریم؟
https://ruben.substack.com/p/how-to-stop-hitting-claude-usage

انتقال کامل بافت و اطلاعات شخصی به کلود:
https://ruben.substack.com/p/youre-just-a-text-file

اشتباهات رایج در استفاده از کلود در محل کار:
https://ruben.substack.com/p/how-to-use-your-personal-ai-at-work


@DevTwitter | <Hamed Heydarian/>

یه ریپو دیدم حدس هایی در مورد معماری مدل mythos. حدس و گمان ها در مورد recurrent depth هاست و اینکه دیگه اون ریزنینگ در سطح توکن رخ نمی‌ده. با توجه به ریزالت‌های trm، hrm و آخرین آپدیت ریزالتایی hrm-text1b که sota هم هست بعید نیست

https://github.com/kyegomez/OpenMythos

@DevTwitter | <KHAN/>