چجوری کامیت های تمیز و مفهومی بنویسم؟!
کامیت به عنوان اجزای سازنده, کار یک برنامه نویس عمل می کنند. آنها اگر که به درستی نوشته شوند، ارزش قابل توجهی دارند. یک پیام commit به خوبی نوشته شده ضروری است زیرا آنها زمینه را فراهم می کنند، در غیر این صورت یک پیام commit در وهله اول مورد نیاز نخواهد بود.

آقای پیتر هاترر میگه:
یک کامیت خوب نشان می دهد که آیا یک توسعه دهنده یک همکار خوب است .

خب، کامیت های شما باید تمیز و قابل درک باشه:
به عنوان مثال اگر میخواید در UI تغییراتی اعمال کنید، کامیت رو به صورت زیر بنویسید:

git commit -m "Enhance UI: Header and sidebar Improvements"

یا
git commit -m " fix: prevent racing of requests"

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


@DevTwitter | <Mohammad Abdorrahmani/>

اگر دنبال ابزاری هستید که بتونید باهاش از پلتفرم‌های مختلف(یوتیوب، تیک‌تاک، اینستاگرام و ...) ویدیو و یا حتی فایل صوتی دانلود کنید، سایت زیر که از قضا اپن‌سورس، رایگان، بدون تبلیغ و هرنوع trackerی هست این کار رو براتون انجام می‌ده. اخیراً هم به نسخه جدیدی آپدیت شده و الان ویدیوهای یوتیوب رو تا کیفیت 8k می‌تونید دانلود کنید ازش. محدودیت خاصی هم نداره.
cobalt.tools
hadi @geekalerts

📕 کتاب REST API Design Rulebook

📌 فصل دوم: Identifier Design with URIs

📍پارت: پنجم

#کتاب

‏💎 URI Query Design 💎
این بخش درباره قوانین طراحی کوئری‌های URI صحبت می‌کنه. طبق استاندارد RFC 3986، کوئری URI (که اختیاری هست) بعد از مسیر (path) و قبل از تکه‌ی اختیاری (fragment) قرار می‌گیره:

URI = schema "://" authority "/" path [ "?" query ] [ "#" fragment ]

کوئری تو URI به شناسایی منحصربه‌فرد بودن یه منبع کمک می‌کنه. به این مثال توجه کن:

https://api.college.restapi.org/students/morgan/send-sms

https://api.college.restapi.org/students/morgan/send-sms?text=hello

اولی URI یه منبعی هست که پیامک می‌فرسته. دومی همون منبع رو نشون می‌ده ولی با این تفاوت که توش پیام "hello" فرستاده می‌شه.

قسمت کوئری URI شامل یه سری پارامتره که به عنوان یه نوع تغییر یا نسخه‌ای از منبع اصلی (که تو بخش مسیر URI تعریف شده) تفسیر می‌شه. پس این دو منبع دقیقاً یکی نیستن، ولی به هم خیلی نزدیکن.

قسمت کوئری تو URI می‌تونه به کلاینت‌ها امکانات بیشتری مثل جستجو یا فیلتر کردن بده. به همین دلیل، این بخش از URI ممکنه برای کلاینت‌های یه REST API شفاف باشه (یعنی زیاد براشون مهم نباشه).

در ضمن، کل URI یه منبع باید برای واسطه‌های شبکه مثل کش‌های HTTP غیرشفاف (opaque) باشه. کش‌ها نباید رفتار خودشون رو فقط بر اساس وجود یا عدم وجود کوئری توی URI تغییر بدن. یعنی پیام‌های پاسخ نباید فقط به خاطر وجود کوئری از کش شدن حذف بشن. همونطور که تو فصل ۴ توضیح داده شده، برای کنترل رفتار واسطه‌های کش باید از هدرهای HTTP استفاده بشه، نه کوئری‌ها.

⭕️ قسمت کوئری URI می‌تونه برای فیلتر کردن کالکشن ها یا Store ها استفاده بشه.
یعنی می‌تونی ازش برای مشخص کردن معیار جستجو توی یه مجموعه یا ذخیره استفاده کنی. یه مثال بزنیم:

GET /users
GET /users?role=admin

تو درخواست اول، کلاینت از سرور لیست همه کاربران رو درخواست می‌کنه.
تو درخواست دوم، کلاینت از سرور لیست کاربرانی که نقش (role) "admin" دارن رو می‌خواد.

در واقع، قسمت کوئری (?role=admin) داره لیست کاربرا رو فیلتر می‌کنه تا فقط اونایی که نقش "admin" دارن تو پاسخ نمایش داده بشن.


⭕️ قسمت کوئری (Query) توی URI باید برای صفحه‌بندی (pagination) نتایج مجموعه یا ذخیره‌ها استفاده بشه.
کلاینت یه REST API باید از پارامترهای pageSize و pageStartIndex توی کوئری استفاده کنه. پارامتر pageSize تعداد عناصر حداکثری رو که باید توی پاسخ برگردونده بشه مشخص می‌کنه، و pageStartIndex مشخص می‌کنه که اولین عنصر از کجا شروع بشه (با ایندکس صفر).

مثال:

GET /users?pageSize=25&pageStartIndex=50

این درخواست لیستی از ۲۵ کاربر رو برمی‌گردونه که از کاربر شماره ۵۰ شروع می‌شه.

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

POST /users/search

اینجا، به جای استفاده از کوئری توی URI، کلاینت می‌تونه درخواست‌های پیچیده‌تری مثل محدوده‌های خاص یا ترتیب‌های خاص رو توی بدنه (body) پیام ارسال کنه. فقط باید مطمئن باشی که نتایج کش‌شده کنترلر به درستی مدیریت بشن.


📝 قوانین طراحی URI در REST API 📝

این خلاصه، اصطلاحات مهمی رو که تو طراحی URIs برای REST API ها به کار میره توضیح میده:
‏
🔑 Authority: بخشی از URI که مسئول فضای نام هست.
📂 Collection: نوعی منبع که مثل یه دایرکتوری از منابع سرور مدیریت می‌شه.
🛠 Controller: منبعی که عملکردهای اجرایی رو مدل‌سازی می‌کنه (مثل یه تابع).
💾 CRUD: مخفف چهار عمل اصلی: ایجاد، خواندن، بروزرسانی و حذف.
🌐 Developer portal: یه رابط کاربری وب برای جذب کلاینت‌های جدید به API.
‏🏠 Docroot: نقطه شروع مدل REST API که والد همه منابع دیگه است.
📄 Document: منبعی که یه مفهوم منفرد رو مدل‌سازی می‌کنه.
🔗 Forward slash separator (/): علامتی که برای جدا کردن منابع مرتبط در URI به کار می‌ره.
👁 Opacity of URIs: یه اصل که می‌گه ساختار URI برای کاربر نباید مهم باشه.
📍 Parent resource: منبعی که یه مفهوم زیرمجموعه رو مدیریت می‌کنه.
🔍 Query: بخشی از URI که برای جستجو و فیلتر استفاده می‌شه.
🔧 Resource archetypes: چهار نوع اصلی منابع (مستند، مجموعه، ذخیره، کنترلر).
🗄 Store: یه منبع که به‌عنوان یه مخزن مدیریت‌شده توسط کلاینت مدل‌سازی می‌شه.
📌 URI path segment: بخشی از URI که نمایانگر یه گره (node) تو مدل سلسله مراتبی منبعه.
📑 URI template: فرمت URI که شامل متغیرهایی هست که قبل از استفاده باید جایگزین بشن.

@ninja_leanr_ir

به‌روز رسانی جدید کبالت، ویژگی‌های جدید و قابل توجّهی رو از جمله امکان خودمیزبانی، به این سکّوی کارآمد، اضافه کرد.

#news #FLOSS
@amiria703_channel

تجربه و نظرتون رو در مورد repository pattern در قسمت نظرات بنویسید.

چرا این چیزی که به عنوان repository pattern که معروف شده انقدر نچسب و بدقلق هست؟!
(شایدم به ما غلط آموزش دادند... 😯)

👇👇👇

چرا باید پروژتون رو منتشر کنید حتی اگه بد باشه؟

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

خودتو از نتیجه کار جدا کن.

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

بس کن یادگرفتن رو!

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

ویدئو تو یوتیوب و حتی کتاب رو ببند،
حتما این پست رو هم تموم کن!
به جای این کارها چی کار کنی؟ کد ادیتورت رو باز کن و شروع کن به کد نویسی.

میگم "اول باید <مفهوم-خاص> رو بهتر یاد بگیرم تا بتونم چیزی بسازم."
یا "باید در مورد <موضوع-خاص> بیشتر بدونم."
یا "چطور میشه اگه <ویژگی-خاص> من طبق بهترین شیوه های فعلی نباشه؟"

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


کپی‌کاری اشکال نداره!

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

یه فیچر یه فیچر کارو جلو ببر

برنامه‌ریزی خوبه، اما اگه بخوای باهاش کارو ول کنی اصلا خوب نیست! برنامه‌ریزی یه جور خودتو گول زدنیه که میگی: «آهان، خب من که برنامه‌ریزی کردم، پس کارم تمومه!»
یه چیز دیگه هم هست، ممکنه وسط کار یه چیزی یادت بیاد که اصلا تو برنامه‌ت نبوده. پس زیاد خودتو درگیر برنامه‌ریزی نکن. یه فیچر رو درست کن، بعد بعدی رو. مثلا اگه پروژه ی جدید ساختی شروع کن به تعریف کردن ماژول هاش مثل:

-> auth
-> client
-> admin
-> landing-page
-> payment

اینجوری نه خسته می‌شی، نه گیج. هر فیچری که تموم می‌شه، حسابی کیف می‌کنی که یه قدم جلو رفتی. حتی اگه خیلی کوچیک باشه و از todo list هم غافل نشید.

ولش کن بابا، زود منشترش کن!

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


تمومش کن، حتی اگه گند باشه!

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

کلام آخر

حالا که دارم این پست رو تموم می‌کنم، می‌خوام یه نقل قول از Kurt Vonnegut بهتون بگم. اگه کدنویسی رو یه نوع هنر حساب کنیم، حرفای اون خیلی به کارمون میاد:

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

خب دوستان، حالا برید و حسابی کد بزنید :)

🆔 @MdDaily

نحوه استفاده از اندپوینت‌های سفارشی برای بهبود فرایند اتصال در برنامه‌های #oblivion و #oblivionDesktop ...

🎥 youtu.be/zF8cpEetuRY?t=108
💡 ircfspace.github.io/endpoint

🔍 ircf.space
@ircfspace

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

احتمالا از پکیج منیجر استفاده میکنید مثل uv یا poetry یا pdm یا ... . اگه استفاده نمیکنید, حتما بکنید 😅

برای استفاده از hatchling کافیه تو pyprojectتون اینو بذارین

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

بعد مثلا سورس کدتون داخل یک دایرکتوری به اسم src هست. که همه ایمپورت هاتون این شکله:
from src.models import User

اونوقت کافیه اینم اضافه کنید به پای پروجکت

[tool.hatch.build.targets.wheel]
packages = ["src"]

@PyBackendHub

جایگزین Llama3.1 فقط می‌تونه یک نسخه بهتر براساس همین معماری باشه :

arcee-ai/Llama-3.1-SuperNova-Lite

مدل ۸ میلیارد پارامتری هست، مدل ۷۰ میلیاردی فقط از طریق api در دسترس هست.
طبق ادعا از 405b, gpt4o, ... بهتر عمل می‌کنه؛ البته برای تسک‌های مربوط به
instruction-following

شخصاً هم همین رو احساس کردم توی تست‌ها.

issues.chromium.org/issues/41294170

زندگی رقمی‌تون رو بر مبنای چیزی که اهمیّتی به ایرادهای حتّیٰ گزارش‌شده نمی‌ده؛ نسازید.
این ایراد، از سال ۲۰۱۷ پابرجاست.

#note
@amiria703_channel

🔵 عنوان مقاله
makefile-graph: Turn a Makefile into a Graph

🟢 خلاصه مقاله:
این مقاله به بررسی و توضیح ابزاری پرداخته است که هم به عنوان کتابخانه و هم به عنوان ابزار خط فرمان (CLI) قابل استفاده است. این ابزار، فایل‌های makefile را تجزیه کرده و نمودارهایی را تولید می‌کند که روابط بین هدف‌های (targets) مختلف را نشان می‌دهند. نمودارهای تولید شده توسط ابزار dot متعلق به Graphviz، رندر می‌شوند. این فرآیند به توسعه‌دهندگان کمک می‌کند تا درک بهتری از وابستگی‌ها و تعاملات بین اجزاء مختلف در پروژه‌های بزرگ نرم‌افزاری داشته باشند و مدیریت وابستگی‌های پروژه را بهبود ببخشند. این ابزار به طور خاص برای کاربرانی طراحی شده که به بهینه‌سازی و دقت در مدیریت تکالیف و پروژه‌های خود نیاز دارند.

🟣لینک مقاله:
https://github.com/dnaeon/makefile-graph

➖➖➖➖➖➖➖➖
👑 @gopher_academy

حدود ۱ ماهه از ویندوز به لینوکس مهاجرت کردم. دومین باره که ترکوندمش و به کمک ChatGPT همه‌چیز رو برگردوندم.
حالا اگه ویندوز بود، باید اشک می‌ریختم و OS عوض می‌کردم

پ.ن: هنوز کورس لینوکس نگذروندم و فقط در حد نیاز روزانه یه دیتاساینتیست جونیور ازش استفاده می‌کنم

@DevTwitter | <Fatemeh Eslami/>

⚖ بررسی MySQL: همه چیز درباره یکی از محبوب‌ترین دیتابیس‌های دنیا 💎

امروز می‌خوام یه دیتابیس معروف و پرطرفدار رو بررسی کنیم؛ MySQL شاید اسمشو زیاد شنیده باشی ولی دقیق ندونی چیه و چه کاربردایی داره.

حالا MySQL چیه؟

خب MySQL یه دیتابیس رابطه‌ای (Relational) و اوپن سورس هست که توی سال 1995 ساخته شده. دیتابیس‌های رابطه‌ای یعنی دیتایی که توش ذخیره میشه توی جدول‌هایی با ردیف‌ها و ستون‌ها قرار می‌گیره و این جداول با همدیگه ارتباط دارن. 🛠️

این دیتابیس از SQL (زبان ساختارمند جستجو) برای مدیریت و پرس‌وجوی اطلاعات استفاده می‌کنه. از اونجایی که MySQL اوپن سورسه، یعنی هرکسی می‌تونه ازش به صورت رایگان استفاده کنه و حتی به کدهاش دسترسی داشته باشه. 💻

چرا MySQL محبوبه؟

1⃣ سرعت و کارایی بالا 🚀: MySQL یکی از سریع‌ترین دیتابیس‌های رابطه‌ای هست. این یعنی درخواست‌ها و عملیات‌های دیتابیس رو خیلی سریع هندل می‌کنه.

2⃣ پشتیبانی از حجم بالا 💾: MySQL می‌تونه مقیاس‌پذیر باشه و دیتابیس‌هایی با حجم زیاد و تعداد کاربران بالا رو به‌خوبی مدیریت کنه.

3⃣ سازگاری با همه چیز 🔗: این دیتابیس تقریباً با همه زبان‌های برنامه‌نویسی و فریمورک‌های محبوب مثل Python, PHP, Node.js و Django به خوبی کار می‌کنه.

- امنیت 🔒: MySQL امنیت بالایی داره و می‌تونید به راحتی دسترسی کاربران به دیتابیس رو مدیریت کنید.

- پشتیبانی از تراکنش‌ها 💡: تراکنش‌ها (Transactions) توی MySQL به شما این امکان رو میدن که چند عملیات دیتابیسی رو به صورت اتمیک انجام بدید، یعنی یا همه اون عملیات‌ها باهم انجام بشن یا هیچکدوم.

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

sudo apt-get install mysql-server

بعد از نصب، برای ورود به دیتابیس MySQL از این دستور استفاده کن:

mysql -u root -p

چطوری با MySQL کار کنیم؟

بعد از نصب، می‌تونی جداول و دیتاهای موردنظرت رو با SQL مدیریت کنی. مثلاً برای ساخت یه جدول جدید:

CREATE TABLE users (
  id INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(100),
  email VARCHAR(100)
);

حالا برای اضافه کردن اطلاعات:

INSERT INTO users (name, email) VALUES ('John Doe', '[email protected]');

برای گرفتن اطلاعات:

SELECT * FROM users;

کجا از MySQL استفاده کنیم؟

خب MySQL برای پروژه‌های کوچیک و بزرگ مناسبه، از سایت‌های شخصی گرفته تا اپلیکیشن‌های بزرگ و سیستم‌های پیچیده. اگه نیاز داری یه دیتابیس سبک و سریع داشته باشی که هم اوپن سورسه و هم جامعه بزرگی داره، MySQL گزینه خوبیه. خیلی از سرویس‌های بزرگ مثل Facebook, Twitter, YouTube از MySQL استفاده می‌کنن! 😯

جمع‌بندی 🎯

در کل، MySQL یه دیتابیس رابطه‌ای قدرتمند، سریع و امنه که برای مدیریت اطلاعات توی پروژه‌های مختلف عالیه. چه پروژه‌های کوچیک داشته باشی و چه پروژه‌های بزرگ، MySQL می‌تونه نیازت رو برطرف کنه. اگه دنبال یه دیتابیس اوپن سورس و همه‌کاره هستی، حتماً یه سر به MySQL بزن😎🔥

امید وارم براتون مفید بوده باشه :)

#دیتابیس #mysql #db

@ninja_learn_ir

مدلهای Phi-3 کمپانی مایکروسافت که جز مدلهای زبانی کوچک (SLMs) حساب میشن واقعا در پرفورمنس عالین و قابل رقابت با مدلهای LLM بزرگ از جمله chatGPT هستند با این تفاوت که میتونید دانلود کنید و رایگان استفاده کنید. اکثرا نیاز به fine tuning هم ندارن
حالا مایکروسافت اومده یک cookbook داده که یک گنج به حساب میاد. از اینکه چطور محیط را آماده کنید تا fine tuning و evaluation از سیر تا پیاز با کد نشون داده. بگم که این مدلها شامل مدلهای vision هم میشه.
یک پروژه که پیشنهاد میدم اینه که با یکی از همین مدلها یک اپلیکیشن RAG درست کنید روی کل این ریپو و به اشتراک بزارید برای سوال و جواب روی این محتوای عالی! محشر میشه.
اینم لینک:
https://github.com/microsoft/Phi-3CookBook

@DevTwitter | <Mehdi Allahyari/>

خب منتظرم اطلاعات رو از سرور ماتریکس بگیره تا منتقل کنم به حساب جدید، بعدش باید برم توی اتاق‌هایی که دسترسی ادمین داشتم خودم رو ادمین کنم و حساب قدیمیم رو غیرفعالش کنم :))



@SohrabContents

Sohrab Behdani changed their name to Sohrab Behdani (Old)

‏یه سری برنامه نویس ها هستند در خلوت خودشان فوق العاده حرفه ای برنامه نویسی میکنند و پروژه های بزرگی هم کار کردند ، اما در مباحث تخصصی همیشه تبادل نظر میکنند نه مخالفت و مجادله !

اینها برعکس نصاب های وردپرس ، اصلا دنبال به رخ کشیدن عملکردشون به بقیه نیستن !

فقط یاد بگیرید ...

@DevTwitter | <‏AliAhkami/>