DevTwitter | توییت برنامه نویسی
Відкрити в Telegram
توییت های برنامه نویسی و طراحی وب :) Admin: @dvtwi Hashtags: devtwitter.t.me/5 DevBooks Channel: https://t.me/+AYbOl75CLNYxY2U0 Github: https://github.com/DevTwitter X: https://x.com/devtwittir
Показати більше📈 Аналітичний огляд Telegram-каналу DevTwitter | توییت برنامه نویسی
Канал DevTwitter | توییت برنامه نویسی (@devtwitter) у мовному сегменті Фарсі є активним учасником. На даний момент спільнота об'єднує 31 530 підписників, посідаючи 4 118 місце в категорії Технології та додатки та 10 878 місце у регіоні Іран.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 31 530 підписників.
За останніми даними від 29 серпня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на 1 099, а за останні 24 години на 27, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 19.04%. Протягом перших 24 годин після публікації контент зазвичай збирає 14.19% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 6 003 переглядів. Протягом першої доби публікація в середньому набирає 4 475 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 44.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як پرو, #کوته_نیوز, ارتباط, ابزار, چیز.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“توییت های برنامه نویسی و طراحی وب :)
Admin:
@dvtwi
Hashtags:
devtwitter.t.me/5
DevBooks Channel:
https://t.me/+AYbOl75CLNYxY2U0
Github:
https://github.com/DevTwitter
X:
https://x.com/devtwittir”
Завдяки високій частоті оновлень (останні дані отримано 30 серпня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
31 530
Підписники
+2724 години
+1607 днів
+1 09930 день
Архів дописів
اگه با ایجنتهای هوش مصنوعی کار میکنید، ایده جدید DeepSeek برای ساخت و شخصیسازی Agentها ارزش دیدن داره.
ابزار DeepSeek Harness یک محیط ماژولاره که تقریباً همهچیز در اون میتونه بهصورت پلاگین تعریف بشه؛ از مدل و Skill گرفته تا Session، ابزارها، Loopها و حتی رابط کاربری.
ایده اصلی سادهست: اجزایی که برای ایجنتتون لازم دارید رو کنار هم میذارید و هر زمان هم لازم باشه میتونید بدون بازطراحی کل سیستم، بخشی از اون رو تغییر بدید.
کاربردهای مهم:
- ساخت ایجنت با ترکیب مدلها و ابزارهای مختلف
- اضافه یا تعویض کردن قابلیتها بهصورت پلاگین
- استفاده از Skillهای آماده جامعه کاربری
- شخصیسازی ساختار ایجنت برای پروژههای مختلف
در واقع بهجای اینکه هر بار یک Agent رو از صفر بسازید، Harness تلاش میکنه اجزای مختلف رو مثل قطعات لگو کنار هم قرار بده.
لینک گیتهاب:
https://github.com/topics/dsh-plugin
@DevTwitter | <Bahram Ghorbani/>
Repost from انجمن علمی مهندسی کامپیوتر دانشگاه اراک
تابستون امسال برنامهنویسی رو اصولی شروع کن! 🚀
بوتکمپ پروژهمحور برای یادگیری Python از صفر تا ساختن یک پایهی حرفهای برای ورود به دنیای تکنولوژی.
📚 سرفصلهای کلی
• Algorithms & Flowcharts • Variables & Data Types • Conditional Statements • Loops & Iterations • Functions & Modular Programming • Error Handling (Try / Except) • Data Structures • File Handling • Regular Expressions (Regex) • Object-Oriented Programming (OOP) • Git & GitHub • Python Projects & Practical Exercises • LinkedIn & Resume Building🎓 گواهینامهها علاوه بر گواهی AIM، مسیر Certificate از Harvard University – CS50P نیز برای شما فراهم خواهد بود. 🚀 بعد از بوتکمپ یک مسیر مشخص برای ادامهی یادگیری و ورود به حوزههای مختلف از جمله:
🤖 Artificial Intelligence 📊 Data Science 💻 Software/Web Development 🌐 Networking 🔐 Cybersecurity 🎮 Game Developmentدر اختیارتان قرار میگیرد تا بدانید بعد از Python دقیقاً چه مسیری را ادامه دهید و ما در ادامه این مسیر نیز همراه شما خواهیم بود. 📩 برای ثبتنام، به ما پیام دهید. 🆔@aim_techworld
یه ابزار جالب پیدا کردم به اسم CoderPad
اساسا یه IDE آنلاینه که تو مصاحبههای فنی استفاده میشه؛ یعنی هم شما کد میزنید هم مصاحبهکننده همزمان میبینه چی مینویسید.
جالبترین بخشش اینه که قابلیت AI هم بهش اضافه کردن و میبینن شخص چجوری از AI کمک میگیره
https://coderpad.io/
@DevTwitter | <Abolfazl Soltani/>
اگر فکر میکنی امنیت فقط برای Backend هست، اشتباه میکنی!
وقتی صحبت از امنیت یک Web App میشه، معمولاً ذهنمون میره سمت Backend، Database، Authentication و API.
اما واقعیت اینه که Frontend هم میتونه یکی از مهمترین نقاط ورود حمله باشه.
چند موردی که بهعنوان Frontend Developer باید جدی بگیریم:
- XSS
هر دادهای که از کاربر دریافت میکنیم قابل اعتماد نیست. نحوهی نمایش و پردازش این دادهها میتونه جلوی اجرای کدهای مخرب در Browser رو بگیره یا برعکس، راه رو براش باز کنه.
- Cookie و Session
نحوهی مدیریت Token و Cookie اهمیت زیادی داره. گزینههایی مثل "HttpOnly"، "Secure" و "SameSite" بخشی از همین ماجرا هستن.
- CSRF
وقتی Authentication بر پایه Cookie باشه، باید حواسمون به درخواستهای جعلی و نحوهی محافظت از Endpointها هم باشه.
- Content Security Policy
CSP میتونه محدود کنه که Browser اجازهی اجرای Scriptها و دریافت منابع رو از چه Sourceهایی داشته باشه.
- Dependencyها
هر Package جدیدی که وارد پروژه میکنیم، یک Dependency جدید هم به پروژه اضافه کردهایم. پس بررسی و بهروزرسانی Dependencyها فقط برای مرتب بودن "package.json" نیست؛ بخشی از Security هم هست.
- Validation
اعتبارسنجی Validation در Frontend برای UX عالیه، اما نباید اون رو یک لایه امنیتی در نظر بگیریم.
کاربر میتونه درخواست رو بدون استفاده از UI ما مستقیماً به API ارسال کنه.
پس Validation و Authorization واقعی باید در Backend هم وجود داشته باشن.
- Error Handling
نمایش Stack Trace، اطلاعات Database یا جزئیات داخلی Server به کاربر، میتونه اطلاعات ارزشمندی در اختیار مهاجم قرار بده.
---
در نهایت، Security چیزی نیست که بعد از تمام شدن پروژه بهش فکر کنیم.
از اولین Form، اولین API Call، اولین Cookie و حتی اولین "npm install" داریم درباره امنیت تصمیم میگیریم..
@DevTwitter | <Abolfazl Soltani/>
همیشه ai دیزاین های افتضاحی میده بدون راهنمایی درست حسابی و کلی زور زدن
برای همین اسکیل ReadyDesign رو ساختم. نصب با یک کلیک برای هر ایجنتی، کامپوننت های آماده استفاده میکنه و از خودش چرتو پرت تولید نمیکنه، تم رنگی هم میتونید بهش بدید دنبال کنه.
https://github.com/ZethRise/ReadyDesign-Skill
@DevTwitter | <Zeth/>
وقتی جدول دیتابیس میلیاردها سطر داره، چطور فقط همون تکهای رو بخونیم که به کارمون میاد؟
دیتابیس که بزرگ میشه، فقط ایندکس کافی نیست. گاهی باید خودِ جدول رو تکهتکه کنیم تا موتور بتونه بخشهای نامربوط رو کلاً نادیده بگیره. به این میگن پارتیشنبندی.
توی این صفحه، چهار روش اصلی پارتیشنبندی RANGE، LIST، HASH و KEY رو بررسی کردم و تفاوت Partitioning با Sharding رو توضیح دادم.
همچنین با یک مثال، الگوی Sliding Window رو بررسی کردم که چطور میشه بدون انجام DELETE های سنگین، دادههای قدیمی رو آرشیو کرد. در نهایت هم تفاوت پیادهسازی این مفاهیم در SQL Server و MySQL رو بررسی کردم.
اگه براتون مفید بود، خوشحال میشم یه ستاره بهش بدین.
https://alireza-haeri.github.io/BackendDeepDives/DataPartitioning.html
@DevTwitter | <AliReza Haeri/>
یه بار سر پروژهای که ساختار دیتابیسش پیچیده شده بود، مجبور شدم برم تو دیبی کلاینت و دستی جدولها و فارینکیها رو دنبال کنم تا بفهمم کدوم جدول به کدوم وصله. کار خستهکنندهای بود، مخصوصاً وقتی چند نفر روی پروژه کار میکنن و شِمای دیتابیس هی تغییر میکنه.
ابزار Laravel Truss دقیقا همین مشکل رو حل میکنه. یه پکیج لاراولیه که شِمای دیتابیس شما رو اسکن میکنه و بهصورت یه دیاگرام ER قابل اسکرول و زوم، مستقیم داخل اپلیکیشن نمایش میده؛ دیگه لازم نیست بری سراغ ابزار جداگونه.
نکتهی مهمش امنیته: فقط ساختار (جدولها، ستونها، کلیدها، ایندکسها) رو میخونه و هیچوقت به دادههای واقعی جدولها دسترسی نداره یا نمایششون نمیده.
قابلیتهای جالبش:
- حالت Focus mode برای دیدن یه جدول و همسایههای فارینکیاش
- فیلتر بر اساس اسم جدول و سوییچ بین تایپ نیتیو و لیبلهای لاراولی
- کار آفلاین و بدون نیاز به CDN
برای هر Laravel developer که با دیتابیسهای نسبتاً پیچیده کار میکنه یا تازه وارد یه پروژهی قدیمی شده و میخواد سریع ساختارش رو بفهمه، مفیده.
https://github.com/albertoarena/laravel-truss
@DevTwitter | <Ladoya/>
Repost from N/a
محبوبترین تکنولوژی، همیشه بهترین انتخاب نیست!
انتخاب اشتباه تکنولوژی یا معماری میتونه هزینه توسعه رو بالا ببره و مسیر پروژه رو پیچیدهتر کنه.
در وبینار «از مسئله تا انتخاب تکنولوژی در توسعه نرمافزار»، سامان هاشمی و هژار آزیز از تیم فنی همکاران سیستم، با تجربه واقعی توسعه «راهکاران آیند» نشون میدن چطور از یک نیاز کسبوکار به تصمیم فنی، انتخاب تکنولوژی و معماری مناسب میرسن.
📅 ۲۹ مرداد و ۵ شهریور، ساعت ۱۱
🎟 شرکت در رویداد رایگانه
💼 امکان ارسال رزومه برای فرصتهای شغلی همکاران سیستم
اطلاعات بیشتر و ثبتنام:
🔗 quera.org/r/eah3n
سلام
بعد از سال ها کار کردن روی پروژه های فلاتر یک معماری برای ساختن اپلیکیشن های مایکرو سرویسی فلاتر ایجاد کردم . این معماری حاصل تلاش چند ساله منه امیدوارم خوشتون بیاد و اینکه اگه سوالی داشتین یا مشکلی دیدن تو گیت هاب برای من issue بزنید
https://github.com/Mahfa/CrusaderArch/tree/master
@DevTwitter | <Mohsen Fallahi/>
مخزن عمومی دادههای گنجور:
https://github.com/ganjoor/ganjoor-data
توضیحات بیشتر:
https://blog.ganjoor.net/1405/05/25/ganjoor-public-data/
* گنجور بزرگترین سایت شعر ایرانه که دیتاش به صورت پابلیک در دسترسه
@DevTwitter
#Dart
یه سؤال ساده شروعش کرد: چرا هر درگاه پرداخت ایرانی باید یه SDK کاملاً جدا داشته باشه؟
زرینپال یه شکل جواب میده، زیبال یه شکل دیگه، پیپینگ اسم فیلدهاش فرق داره، وندار احراز هویتش با بقیه یکی نیست... نتیجه؟ هر بار که بخوای درگاه عوض کنی یا دومی رو اضافه کنی، عملاً داری از صفر مینویسی.
برای همین pardakht رو ساختم — یه پکیج Dart که ۷ درگاه پرداخت ایرانی رو پشت یه interface واحد میبره:
زرینپال، زیبال، آیدیپی، پیپینگ، پی.آیآر، وندار، ایراندرگاه
چیزی که برام مهم بود، نه فقط «کار کنه» بلکه «قابل اعتماد باشه»:
نوع داده Money که واحد پول (ریال/تومان) رو صریح نگه میداره — دقیقاً همون جایی که خطای «ده برابر شدن قیمت» از اونجا شروع میشه.
وریفای تکراری = موفقیت، نه شکست. خیلی از مرچنتها پرداخت واقعی رو استرداد میزنن چون verify دوم رو اشتباه fail میخونن. اینجا این حالت یه state جدا و صریحه.
بدون وابستگی به Flutter — یعنی همون کد روی بکاند هم اجرا میشه، جایی که verify واقعاً باید انجام بشه (نه سمت کلاینت، که هرکسی میتونه callback رو جعل کنه).
هر درگاه یه سند مشخصات جداگانه داره: هر claim با URL منبع و تاریخ تأیید. هیچ فیلدی حدسی نیست.
۷۹۸ تست، ۱۰۰٪ پوشش خط، صفر warning.
کد، مستندات و همهچیز باز و در دسترس:
https://pub.dev/packages/pardakht
https://github.com/naeimlotfali/pardakht
@DevTwitter | <Naeim Lotfali/>
Repost from N/a
وقت نداری برای هر موضوع امنیتی ۲۰ صفحه گزارش بخونی؟ حق داری!
«نوشدارو» اصل ماجرا رو میگه: چه اتفاقی افتاده، چرا مهمه و چه چیزی باید ازش یاد بگیریم؛ بدون پیچیده کردن چیزی که میشه ساده گفت.
برای دولوپرهایی که میخوان توی «حریم شخصی»، «امنیت» و «آشنایی با آخرین خطرات» یک قدم جلوتر باشن.
همین الان دنبال کنید:
@NooshDaroo_web
@NooshDaroo_web
امروز Filament File Explorer v0.5.1 رو روی Packagist منتشر کردم.
یک مدیر فایل برای پنلهای Filament — پوشه، آپلود، چند وضعیت برای نمایش، و Form Picker — ساختهشده روی Spatie Media Library، Livewire و Tailwindcss.
میخواستم همون حس کار با finder و file explorer دسکتاپ رو داخل ادمین Filament داشته باشم.
چی توی v0.5.1 هست؟
- رابط Finer — درخت سایدبار، breadcrumbs، عقب / جلو، تولبار ریسپانسیو
- نماها — Grid، List، Table، Details + پنجره Get Info
- عملیات — آپلود Drag-and-drop، Cut / Copy / Paste، انتخاب چندتایی، دانلود Zip
- امکانات Filament — traitی HasFileExplorer، صفحه جدول فایلها، Form Picker، generator stub
- چندزبانه — ۱۵ زبان
- سازگار با Filament v4 و v5 · Laravel 11 / 12 / 13 · PHP 8.2+
نصب
composer require ardavan/filament-file-explorer:"^0.5" -W
Docs
https://ardavanshamroshan.github.io/filament-file-explorer/
Packagist
https://packagist.org/packages/ardavan/filament-file-explorer
GitHub
https://github.com/ardavanshamroshan/filament-file-explorer
پروژه هنوز اول راهشه — و مطمئنم با کمک جامعهی Filament و Laravel میتونه خیلی بهتر بشه.
@DevTwitter | <Ardavan ShamRoshan/>
یه ابزار ساختم که خیلی وقت بود اذیتم میکرد نبودنش :))
ابزار Schemat میذاریش رو ریپوت، دیاگرام ERت رو زنده نشونت میده.
دیتای Prisma، SQL، Drizzle، TypeORM و چندتای دیگه رو میخونه.
همهچی لوکال، بدون اکانت، بدون کلاود.
اوپنسورسه:
https://github.com/alirezahamid/schemat
@DevTwitter | <Alireza.js/>
یک دورهی کامل Git از صفر تا حرفهای، شامل ۳۰ بخش:
از مفاهیم پایه (staging area، commit، branch) شروع میشه، به merge/rebase/conflict میرسه، ابزارهائی مثل stash، cherry-pick، reflog، bisect، submodules و hooks رو پوشش میده، بعد وارد بخش حرفهای میشه و..
https://github.com/AsaEdgerunner/git-course-fa
@DevTwitter | <Asa/>
تولدت مبارک پیرمرد قابل اعتماد دنیای لینوکس!
از مرداد ۱۳۷۲ تا امروز Stable مثل همیشه
@DevTwitter | <MehrdadLinux/>
ایکس اومده الگوریتم بخش for you رو متنباز کرده، یه Agent انداختم تو کل سورس که فایلبهفایل بگرده و بفهمه که چطوری کار میکنه.
نتیجهاش خیلی جالب بود؛ مخصوصاً وزن Reply، Share، Follow، Report و اینکه اصلاً یک پست چطور وارد For You میشه.
چیزهایی که پیدا کردم رو توی ویرگول نوشتم
https://virgool.io/@mrbug_ir/x-algorithm-open-source-lrmu9j4z7fz2
@DevTwitter | <Alireza Rezaie/>
تجربه ۲ روز کدنویسی فشرده با مدل Qwen 3.8-27B روی RTX 3090 (24GB)
کانفیگ و ستاپ تست:
پنجره کانتکست: 128K
سطح استدلال (Reasoning Effort): xHigh
ایجنت / پلتفرم: Kilo Code
دقت مدل در اجرای درست تسکها با همان پرامپت اول فوقالعاده بالا رفته است. چرخههای فرسایشی دیباگ و اصلاحیههای پیاپی به حداقل رسیده و بیشتر کدها از همان ابتدا تمیز و آماده اجرا تحویل داده میشوند.
زنجیره تفکر و خروجیهای مدل بسیار متمرکزتر شده و تولید توکنهای زائد به حداقل رسیده است. این ساختار تمیز باعث میشود پنجره کانتکست ۱۲۸ هزارتایی دیرتر اشباع شود و نشستهای طولانی پایداری بیشتری داشته باشند.
میانگین سرعت خروجی (Decode Throughput) روی تسکهای سنگین کدنویسی حدود 45 t/s ثبت شد. افت سرعت نسبت به نسلهای قبل کاملاً محسوس است (که حاصل سربار تفکر عمیقتر و پارامترهای فعال است)، اما کیفیت بالای خروجی این افت سرعت را جبران میکند.
یکپارچگی مدل با ابزارهای خارجی عالی است؛ اتصال بدون نقص به Playwright برای بررسی خروجی دام، گرفتن اسکرینشات از UI، ارزیابی رندرینگ لایو و دیباگ خودکار بر اساس خطاهای رانتایم.
در سطح استدلال xHigh، مدل گاهی دچار Over-thinking میشود و زمان زیادی را صرف زنجیره تفکر (CoT) میکند، اما نکته مثبت این است که وارد لوپ بینهایت نمیشود و همیشه به یک خروجی نهایی و قابلاتکا میرسد.
معماری کامپوننتها، مدیریت استیت و خروجی UI بهطرز چشمگیری ارتقا پیدا کرده و در ساختارهای پیچیده فرانت، سطحی از پختگی مشابه مدلهای سری Claude Sonnet را نشان میدهد.
در پروژههای ماژولار بزرگ، پایداری مدل حتی در سشنهای پیوسته با حجم تجمعی چند میلیون توکن حفظ شد. زمان پاسخدهی از ۱ تا ۲ دقیقه برای باگفیکسهای سریع تا حدود ۴۰ دقیقه برای پیادهسازی کامل یک فیچر فولاستک (UI + منطق بکاند) متغیر بود.
کاری که پیش از این با مدلهای لوکال قدیمیتر نزدیک به ۲ هفته زمان میبرد، به لطف دقت One-Shot این مدل در ۲ روز جمع شد. برای یک ستاپ لوکال روی تککارت ۲۴ گیگابایتی، جهش عملکردی کمنظیری است.
@DevTwitter | <کدنویس اسطورهای/>
در PHP؛ وقتی انعطافپذیری زبان میتونه دردسرساز بشه!
یکی از ویژگیهای جالب PHP، Type Juggling هست؛ یعنی PHP در بعضی شرایط خودش سعی میکنه type دادهها رو تبدیل کنه تا عملیات موردنظر انجام بشه.
در نگاه اول این رفتار خیلی راحت و کاربردیه، اما وقتی وارد پروژههای بزرگتر مثل Laravel میشیم، همین انعطافپذیری میتونه گاهی باعث رفتارهای غیرمنتظره بشه.
اینجاست که چیزهایی مثل استفادهی درست از type declaration، validation و مقایسهی strict (===) اهمیت پیدا میکنن.
البته strict_types قرار نیست تمام مشکلات Type Juggling رو در PHP حل کنه؛ اما باعث میشه در بخشهایی از کد، رفتار typeها قابلپیشبینیتر باشه.
به نظرم یکی از نکات مهم در کار با PHP اینه که:
هرچقدر پروژه بزرگتر میشه، شناختن رفتارهای خود زبان اهمیت بیشتری پیدا میکنه؛ چون خیلی از باگهای سخت، نه از منطق پیچیدهی business، بلکه از یک assumption اشتباه دربارهی typeها
به وجود میان.
زبان PHP ساده به نظر میرسه، ولی هرچقدر عمیقتر بشناسیمش، متوجه جزئیات بیشتری میشیم که روی کیفیت کدمون تأثیر میذاره.
@DevTwitter | <Amir Mohammad M./>
یکی از مفاهیم جالب Kubernetes که معمولا درکش هم برای بار اول خیلی یجوریه و اذیت کنندس و باید چنتا سایت و داکیومنت رو خوند تا قشنگ فهمید موضوع Headless Service هستش و این که Service همیشه قرار نیست ترافیک رو بین Podها پخش کنه.
مثلا اگه سه تا Pod داشته باشیم که پشت یک Service قرار گرفته باشن، وقتی Application به اون Service وصل میشه، معمولا Service درخواست رو به یکی از Podها میرسونه.
ولی حالا ممکنه شرایطی پیش بیاد که Application بخواد IP تک تک Podها رو بدونه و مستقیم با هرکدوم یه ارتباطی برقرار کنه، مثلا توی بعضی سیستم ها مثل کافکا یا clickhouse لازمه خب که اعضای خودشون رو بشناسن و با هر Node بهصورت جداگانه ارتباط داشته باشن و ... که اینجا Service معمولی خیلی مناسب نیست.
یکی از راهاش اینه که بریم سراغ Kubernetes API و از اونجا لیست Podها و IPهاشون رو بگیریم بعد دونه دونه هرکار میخوایم بکنیم، ولی خب این یعنی Application ما باید Kubernetes رو بشناسه و مستقیم با API Server کار کنه.
راه تمیزترش میشه همون Headless Service .
توی حالت نرمال، DNS مربوط به یک Service، آدرس ClusterIP رو برمیگردونه، ولی وقتی Service رو Headless میکنیم، با نوشتن:
clusterIP: None
دیگه Kubernetes برای اون Service یک ClusterIP نمیذاره، بجاش وقتی Application از طریق DNS اون Service رو Lookup میکنه، DNS میتونه IP خود Podهای پشت Service رو برگردونه، حالا Application خودش تصمیم میگیره با کدوم Pod ارتباط برقرار کنه با یکی، چندتا یا همشون.
پس تفاوت مهمی که اینجا هست اینه که:
کوبر برای Service معمولی یه آیپی ثابت میده، خودشم یکی از Podها رو انتخاب میکنه و ...
ولی برای Headless Service دیگه Load Balancing انجام نمیده، آیپی Podهای پشت این Service رو بهمون میده، دیگه بقیش با خودمونه که چکار کنیم باهاش.
@DevTwitter | <S.M.Sadegh Raeeskarami/>
