30 مارس 2026 | وقت القراءة: 13 دقائق و37 ثانية
رد الفعل ضد التطوير المعتمد على السحابة
لمدة عقد من الزمن، بدا مسار أدوات المطورين حتمياً: الهجرة إلى السحابة، وإضافة ميزات التعاون، وتحقيق الأرباح من المنصة. بنت Postman帝国 على هذا الأساس. بحلول عام 2023، أصبحت منصة اختبار API ضرورية لملايين المطورين، وتحركت الشركة بقوة لدفع المستخدمين نحو مساحات العمل المستندة إلى السحابة مع الحسابات الإلزامية والتخزين على جانب الخادم والميزات المدعومة بالذكاء الاصطناعي التي تعمل فقط في السحابة. بدا أنه تطور طبيعي - تعاون أفضل، ذكاء أغنى، عائدات أكثر لكل مستخدم.
لكن حدث شيء غير متوقع. بدأ المطورون يرحلون. ليس في حشد، لكن في موجة ذات مغزى أشارت إلى عدم رضا أعمق. لم يريدوا تخزين مجموعات API الخاصة بهم على خوادم شخص آخر. لم يريدوا أن يكونوا مضطرين للاتصال بالإنترنت للوصول إلى عملهم. لم يريدوا الاحتفاظ بالبائع مقنعاً كميزة. وبالتأكيد لم يريدوا المصادقة فقط لاستخدام أداة محلياً.
يمثل هذا التمرد ضد أدوات السحابة أولاً شيئاً أكبر من الإحباط تجاه منتج واحد. إنه يعكس تحولاً فلسفياً أساسياً في ما يطلبه المطورون من أدواتهم في عام 2026. لم تعد أفضل الأدوات معرفة بالميزات المركزية والبنية التحتية السحابية الملكية. بدلاً من ذلك، تنجح بمعاملة الملفات المحلية كمصدر الحقيقة، ومستودعات Git كطبقة التعاون، وآلة المطور كبيئة التنفيذ الأساسية. السحابة مخصصة للنشر، وليس للتطوير.
مشكلة Postman وإجابة Bruno
قصة أصل Postman مفيدة. في أوائل 2010، كانت عبارة عن ملحق Chrome بسيط جعل من السهل صياغة واختبار طلبات HTTP. لا يوجد حساب مطلوب، لا مزامنة سحابية، لا تعقيد - فقط واجهة نظيفة للمطورين الذين يبنون APIs. اعتمدها آلاف المطورين لأنها حلت مشكلة حقيقية بأناقة.
على مدار العقد التالي، تطورت Postman بطرق متوقعة. أضافت الشركة التعاون في مساحة العمل، وإدارة البيئة، والخوادم الوهمية، وتوثيق API، والمراقبة، والتكاملات مع العشرات من المنصات الأخرى. كان كل ميزة منطقية بمعزل عن غيرها. لكن معاً، كانوا يتطلبون البنية التحتية. لدعم التعاون في الوقت الفعلي، احتاجت Postman إلى تخزين المجموعات على خوادمهم. لتقديم بيئات مستمرة ومشاركة تعريفات API، كانت تحتاج إلى حسابات. لتحقيق الأرباح من المنصة، كانت تحتاج إلى طبقات: مجاني للاستخدام الأساسي، مدفوع للميزات المتقدمة.
بحلول عام 2023، أصبحت المنصة مختلفة بشكل ملحوظ عن الأداة الخفيفة التي تذكرها المطورون. كانت المجموعات تتزامن مع السحابة افتراضياً. تم قفل العديد من الميزات المتقدمة خلف جدران الدفع. تدهورت الأداء. أصبحت الطبقة المجانية محدودة بشكل متزايد. ووجد المستخدمون الذين أرادوا الاحتفاظ بمجموعاتهم الخاصة أنفسهم يكافحون ضد الإعدادات الافتراضية لـ Postman، التي فضلت التخزين والمشاركة السحابية.
دخل إلى هذه الفجوة Bruno. تم إطلاق Bruno كمشروع مفتوح المصدر، اتخذ Bruno نهجاً مختلفاً بشكل جذري. يتم تخزين مجموعات API كملفات .bru عادية على نظام الملفات المحلي الخاص بك. هذه الملفات قابلة للقراءة من قبل الإنسان، وقابلة للتحكم في الإصدار، ومصممة للعمل بشكل جميل مع Git. لا يوجد حساب سحابي مطلوب. لا مزامنة. لا احتفاظ بالبائع. تعيش مجموعاتك في مستودعك، بجانب الكود الخاص بك، محكوم بإصدار مثل كل شيء آخر مهم. إذا كنت تريد مشاركتها مع زملاء فريقك، فأنت تفتح طلب سحب. إذا كنت تريد معرفة كيفية تغيرت تعريفات API، فأنت تشغل git diff. إذا كنت تريد أن تفهم من عدل مجموعة وإلى ماذا، فأنت تتحقق من سجل الالتزام.
كان الرد فوراً وساحقاً. تراكمت Bruno 37,000 نجم على GitHub وحققت 2.5 مليون تحميل. تخدم الأداة الآن 150,000 مستخدم يومي. لم يحدث أي من هذا لأن Bruno توفر ميزات أكثر من Postman - فهي لا تفعل. حدث لأن Bruno تحترم استقلالية وتفضيلات المطور. Bruno تقول: "هذا هو عملك. إنه يعيش على آلتك. نحن هنا لتوفير محرر جيد، لا أكثر."
لم تكن هذه حنين للبساطة. كانت إدراكاً أن نموذج السحابة أولاً لأدوات التطوير قد وصل إلى حده الأقصى. أدرك المطورون أن تخزين مجموعات API في سحابة Postman قدم تبعيات غير ضرورية والاحتفاظ بالبائع. اختبار وتصميم APIs هو في الأساس نشاط محلي، شيء تفعله أثناء الترميز. لماذا يجب أن يتطلب هذا العمل اتصالاً بالإنترنت؟ لماذا يجب أن تتحكم شركة في تعريفات المجموعة الخاصة بك؟ لماذا يجب أن تصادق على خدمة ملكية للوصول إلى شيء أنشأته؟
أثبت نجاح Bruno أن هذا لم يكن رأياً متخصصاً. كانت شيئاً ينتظره جزء كبير من مجتمع المطورين. وفي اللحظة التي كسر فيها السد، بدأت أدوات مماثلة في الحصول على جاذبية. بدأت Insomnia، منصة اختبار API أخرى، أيضاً بالتركيز على التخزين المحلي أولاً وتكامل Git. كانت الرسالة واضحة: أراد المطورون أدواتهم مرة أخرى.
ما وراء اختبار API: الفلسفة المحلية والمحسومة
لكن نجاح Bruno كشف عن شيء أكبر من تحول التفضيلات حول اختبار API. كشفت عن نمط ناشئ في كيفية أن يريد المطورون من جميع الأدوات أن تعمل. الرؤية لم تكن أصلية - رواد البنية التحتية كأكواد كانوا يتبشرون بهذا الإنجيل سنوات - لكنها تطبق فجأة على مجالات بعيدة عن البنية التحتية.
المبدأ الأساسي هو هذا: يجب أن يوجد العمل المهم كملفات في مستودع Git. يجب أن يكون محكوماً بالإصدار. يجب أن يكون قابلاً للمراجعة من خلال طلبات السحب. يجب أن يكون قابلاً للدمج والفرز والمراجعة. يجب أن يعمل بدون اتصال. لا يجب أن يتطلب المصادقة السحابية للوصول. والأهم من ذلك، يجب أن يكون محمولاً وغير معتمد على منصات ملكية.
هذا هو السبب في أن Terraform و Pulumi أصبحت معايير الصناعة لتوفير البنية التحتية. استبدلا نموذج النقر على الأزرار في وحدات التحكم بالسحابة (خدمات الويب الأمازونية وجوجل كلاود وأزور) بنموذج كتابة الأكواد التي يمكن مراجعتها وإصدارها ونشرها من خلال أنابيب CI/CD. أصبحت البنية التحتية شفافة وقابلة للمراجعة والمحمولة بطرق أن النشر القائم على وحدة التحكم لم يتمكن من ذلك أبداً.
في عام 2026، تنتشر هذه الفلسفة في الملاحظة والإدارة والأمان والتوثيق والترجمة وعشرات المجالات الأخرى. الأدوات التي تتبنى هذه الفلسفة تنجح. الأدوات التي تقاومها تكافح. والنمط لا لبس فيه: المطورون على استعداد للتبديل عن بعض الراحة وبعض ميزات التعاون في الوقت الفعلي إذا كان هذا يعني أن عملهم يبقى تحت سيطرتهم، ويعيش في Git، ويعمل بدون اتصال.
يجسد Grafana Alloy هذا التحول في فضاء الملاحظة. مع جمع المؤسسات لمزيد من المقاييس والسجلات والآثار والملفات الشخصية من أنظمتها، احتاجوا إلى أدوات قوية لمعالجة هذه البيانات الهندسية. وجدت Grafana Agent لهذا الغرض، لكن أصبح واضحاً بشكل متزايد أن ملفات الإعدادات الثابتة لم تكن قادرة على التقاط تعقيد خطوط أنابيب الملاحظة الحديثة. احتاجت الفرق إلى شيء أكثر قابلية للبرمجة.
Grafana Alloy: تصبح الملاحظة أكواداً
يمثل Grafana Alloy التطور التالي في كيفية إدارة الفرق لبنية الملاحظة الخاصة بها. بدلاً من تكوين الوكلاء من خلال ملفات YAML (النموذج القديم)، يستخدم Alloy لغة التكوين المستندة إلى المكونات التي تشعر بمزيد من البرمجة. يمكنك تكوين خطوط أنابيب الملاحظة من 120+ مكون يتعامل مع جمع وتحويل وتجميع وتصدير المقاييس والسجلات والآثار والملفات الشخصية.
الابتكار الرئيسي هو أن هذه الخطوط الأنابيب هي أكواد، وليست تكوين. يمكنك استخدام المتغيرات والشروط والحلقات والمراجع لبناء خطوط أنابيب ديناميكية تستجيب لاحتياجات نظامك. هل تريد جمع مقاييس مختلفة من مضيفات مختلفة؟ اكتب مكوناً يحمل شروط تكوينات مختلفة. هل تريد تحويل وإثراء السجلات بناءً على متغيرات البيئة؟ اجمعها في خط الأنابيب الخاص بك. هل تريد توسيع نطاق بنية الملاحظة الخاصة بك بتفعيل مجمعات مكلفة فقط على أنظمة الإنتاج؟ قم بإشارة إلى متغير والتحكم فيه من خلال نظام النشر الخاص بك.
والأهم من ذلك، أن هذه خطوط الأنابيب تعيش في مستودع Git الخاص بك. يتم التحكم في إصدار بنية الملاحظة الخاصة بك. عندما يقترح شخص ما تغييراً على كيفية جمع البيانات الهندسية، فإنه يمر عبر طلب سحب. يراجع المهندسون التغيير، ويفهمون آثاره، ويوافقون عليه قبل أن يذهب إلى الإنتاج. إذا أفسد التغيير شيئاً ما، فلديك السجل الكامل لـ Git يظهر ما تغير، ومن غيره، ولماذا. يمكنك استرجاع تكوين ملاحظة سيء بنفس السهولة كما تسترجع أكواد الطلب.
يمثل هذا تحولاً أساسياً في كيفية تفكير الفرق في البنية التحتية. كان نموذج 2010 هو: تعيش البنية التحتية في وحدة التحكم بالسحابة، تنقر الأزرار، تحدث الأشياء، وتأمل أن تتذكر ما فعلت. نموذج 2020 هو: البنية التحتية أكواد، تعيش في مستودع، يتم مراجعتها وتصحيحها مثل كل شيء آخر مهم.
يمتد Alloy هذا إلى الملاحظة على وجه التحديد، لكن نفس النمط مرئي في كل مكان. يستمر OpenTofu، الفرع المفتوح المصدر من Terraform، نفس المسار. يطبق Pulumi نفس الفلسفة على البنية التحتية كأكواد لكنه يستخدم لغات برمجة للأغراض العامة بدلاً من لغات خاصة بالمجال. حتى في الذكاء الاصطناعي، تؤكد أدوات مثل Cursor على التطوير المحلي أولاً، وتشغيل النماذج على جهازك والاحتفاظ برمزك خاصاً افتراضياً.
الميزة المحلية أولاً
لماذا تنجح هذه الفلسفة فجأة؟ الفوائد حقيقية وجوهرية.
الأول هو الخصوصية. قد تحتوي مجموعة API على رموز المصادقة ومفاتيح API والأسرار الأخرى. يعني تخزين هذا في سحابة Postman الوثوق بـ Postman لتأمينها بشكل صحيح، لا تكشفها أبداً، والامتثال لمتطلبات حوكمة البيانات الخاصة بمنظمتك. للمؤسسات التي تتعامل مع البيانات المنظمة أو الأحمال الحساسة، هذا غير قابل للتحمل. التخزين المحلي يعني أنت تتحكم في حيث تعيش مجموعاتك. إذا كانت منظمتك تتطلب أن يحدث عمل التطوير على شبكات معزولة أو أجهزة بدون وصول إلى الإنترنت، فإن الأدوات المحلية أولاً هي الخيار الوحيد القابل للتطبيق.
الثاني هو الأداء. كل عملية في أدوات المعتمدة على السحابة تتطلب رحلة شبكية. فتح مجموعة، وتشغيل اختبار، والتبديل بين البيئات، والبحث عن طلب - كل هذه قد ينطوي على اتصال الخادم. تزيل الأدوات المحلية أولاً كل هذه الكمون. أنت تعمل مباشرة مع الملفات على القرص الخاص بك. فرق الأداء ليست دقيقة، خاصة على اتصالات الشبكة السيئة أو من المواقع بكمون عالي لخوادم السحابة.
الثالث هو القدرة على العمل بدون اتصال. قد يكون مطور على متن طائرة، أو في مؤتمر بدون WiFi موثوق، أو في منطقة بنية تحتية إنترنت سيئة يمكنه لا يزال العمل بإنتاجية مع أدوات محلية أولاً. هذا ليس حالة استخدام ثانوية - يعمل المطورون في بيئات كثيرة، والقدرة على الترميز والاختبار بدون الاعتماد على الاتصال الخارجي تعتبر قيمة حقيقية.
الرابع هو الملكية والمحمولية. عندما يوجد عملك كملفات في مستودع، فأنت تملكه. يمكنك نقله إلى أداة مختلفة، ومشاركتها بشكل مختلف، والنسخ الاحتياطي بأي طريقة تريدها، والهجرة بعيداً عن البائع بدون احتكاك. مع أدوات المعتمدة على السحابة، عملك مقفل في نظام البائع. إذا غيّر البائع الأسعار أو الميزات أو الشروط، تكون خياراتك محدودة. تزيل الأدوات المحلية أولاً هذا الخطر.
الخامس هو التعاون من خلال Git. قد يبدو هذا غير بديهي - ألا يشعر التعاون القائم على Git بدائي أكثر من المزامنة السحابية في الوقت الفعلي؟ في بعض النواحي، نعم. ميزات التعاون في الوقت الفعلي تشعر بالسحر مقارنة بسير عمل طلب السحب غير المتزامن. لكن التعاون القائم على Git يوفر شيئاً تكافح معه الأدوات السحابية بشكل أساسي: مراجعة الأكواد الحقيقية وتتبع التغييرات. عندما يعدل زميل مجموعة API، يمكنك رؤية بالضبط ما تغير، لماذا غيروه (من خلال رسائل الالتزام)، والموافقة على التغيير من خلال طلب سحب. هذا أكثر صرامة من التعاون في الوقت الفعلي، الذي غالباً ما يخفي من غيّر ماذا ومتى.
ما نخسره: تبادلات السحابة أولاً
هذا لا يعني أن أدوات السحابة لم تكن لها فوائد. كانت لديها، وكانت هذه الفوائد حقيقية.
تأتي المزامنة في الوقت الفعلي عندما يعمل عدة أشخاص على نفس الشيء في نفس الوقت. فريق تصميم API معاً يستفيد من رؤية التغييرات للجميع على الفور، بدون انتظار الالتزامات وطلبات السحب. الميزات التعاون المباشر، المؤشرات المشتركة، والتعليقات الفورية منتجة حقاً.
تزيل الحلول المستضافة الحاجة إلى تشغيل البنية التحتية بنفسك. أنت لا تضطر إلى صيانة الخوادم أو القلق بشأن التوسع أو إدارة النشرات. يتعامل البائع مع كل هذا، ويمكنك التركيز على عملك.
الميزات المستندة إلى السحابة مثل مساعدة الذكاء الاصطناعي والتحليلات والتكاملات تستفيد من النطاق. خدمة مركزية يمكنها توفير قدرات التعلم الآلي التي تحلل استخدام منظمتك الكاملة وتقدم رؤية. التكاملات مع الخدمات السحابية الأخرى غالباً ما تكون أقوى عندما يعيش كل شيء على منصة واحدة.
السؤال لعام 2026 هو: هل هذه الفوائد تستحق تبادلات احتفاظ البائع وقلق الخصوصية والقيود بدون اتصال؟ للعديد من المطورين، الإجابة تصبح لا بشكل متزايد. وبشكل مثير للاهتمام، يمكن تكرار العديد من هذه الفوائد السحابية مع أدوات محلية أولاً إذا كنت على استعداد لقبول تبادلات مختلفة.
التعاون في الوقت الفعلي ممكن مع أدوات محلية أولاً إذا كان الفريق مشترك المقر أو يستخدم مؤتمرات الفيديو. التعاون القائم على Git، بينما غير متزامن، يمكن أن يكون سريعاً بما يكفي لمعظم الأغراض إذا كانت منظمتك تتمتع بممارسات CI/CD جيدة. الحلول المستضافة ليست ضرورية إذا فضلت الفرق الاستضافة الذاتية أو إذا ظهرت الاستضافة السحابية للأدوات المحلية أولاً. والعديد من ميزات الذكاء الاصطناعي التي بدت تتطلب المركزية تعمل بشكل متزايد محلياً حيث تصبح النماذج أصغر وأكثر كفاءة.
منظر أدوات المطورين في عام 2026
المنتصرون في نظام أدوات المطورين في عام 2026 كلهم تقريباً محلي أولاً وأدوات Git الأصلية. Bruno تهيمن على اختبار API وليس لأنها توفر أكثر الميزات، بل لأنها تحترم استقلالية المطور. Grafana Alloy تفوز في الملاحظة لأنها تتعامل مع خطوط أنابيب القياس عن بعد كأكواد تنتمي إلى التحكم في الإصدار. OpenTofu، أداة البنية التحتية كأكواد المفتوحة المصدر، تزدهر لأنها توفر نفس قوة Terraform بدون مخاوف الترخيص. Cursor، محرر الأكواد الذي يعمل بالذكاء الاصطناعي، يكتسب الاعتماد لأنها توفر مساعدة الذكاء الاصطناعي المحلية أولاً التي تحترم الخصوصية وتعمل بدون اتصال.
يمتد النمط ما وراء الأدوات التي ناقشناها. في إدارة قاعدة البيانات، أدوات مثل Prisma و Drizzle ORM تتعامل مع الأسكيمات كأكواد تعيش في مستودعات. في حاويات الإنشاء، ملفات Docker Compose محكومة بالإصدار وتعامل كبنية تحتية. في الأمان، تخزين أدوات مثل HashiCorp Vault التكوين كأكواد. حتى التوثيق يتحول نحو أدوات Git الأصلية: منصات Documentation-as-Code تتعامل مع التوثيق مثل الأكواد، محكومة ومراجعة مثل كل شيء آخر.
يثبت المستودع المفتوح المصدر أنه قوة قوية في هذا المشهد. أدوات يقودها المجتمع التي تحترم تفضيلات المطورين تتفوق على البدائل الشركاتية التي تعطي الأولوية للربحية. هذا لا يعني أن الأدوات التجارية لا يمكنها الفوز - يمكنها، إذا تبنت الفلسفة المحلية أولاً. لكن SaaS المحض والاحتفاظ بالبائع أصبح من الصعب بشكل متزايد تبريره لدى المطورين المتطورين.
بشكل مثير للاهتمام، تذهب أدوات الذكاء الاصطناعي أيضاً محلية أولاً في عام 2026. مع تحسن نماذج اللغة القائمة على الجهاز وتصبح أصغر، تقدم أدوات مثل Cursor والآخرون مساعدة الذكاء الاصطناعي التي تعمل محلياً، محتفظة برمزك خاصاً افتراضياً. السخرية ليست فقدت على أحد: الذكاء الاصطناعي، الذي بدا يتطلب البنية التحتية السحابية الضخمة، يتحرك بشكل متزايد نحو أجهزة الحافة والآلات المحلية. الذكاء الاصطناعي المحافظ على الخصوصية والمحلي أولاً يصبح ميزة تنافسية.
التحول الأوسع في قيم المطورين
ما يحدث في أدوات المطورين يعكس تحول أوسع في كيفية تفكير المطورين حول علاقتهم بالتكنولوجيا. بدا عصر 2010 "انقل كل شيء إلى السحابة" حتمياً في الوقت نفسه. قدمت السحابة المرونة والقياس والراحة. للعديد من الحالات، لا تزال قيمة ممتازة. لكن المطورين تعلموا دروساً صعبة حول احتفاظ البائع وخصوصية البيانات والتكاليف الحقيقية للاعتماد على الخدمات الخارجية.
الأدوات التي تنجح في عام 2026 تعامل جهاز المطور والمستودع كمساحة عمل أساسية. يفهمون أن عمل المطور مقدس - إنه الشيء الذي يهم أكثر. يجب أن تسهل الأدوات هذا العمل، لا تملكه. يجب أن تعزز قدرات المطور، لا تقيدهم. يجب أن تمكن التعاون من خلال آليات مثبتة مثل Git وطلبات السحب، وليس من خلال ميزات السحابة الملكية التي تقفل العمل في منصة.
هذا يمثل نضجاً في نظام أدوات المطورين. إنه ليس حنين؛ إنه التعلم من التجربة. سماع السحابة أولاً بدا جيداً على الورق، لكن في الممارسة، أنشأ احتكاكاً والاحتفاظ بالبائع يفوق الفوائد لحالات استخدام كثيرة. البندول لا يتأرجح كل الطريقة مرة أخرى إلى أدوات محلية بحتة - تأثيرات الشبكة وفوائد التعاون للاستضافة السحابية حقيقية. لكن التأرجح بالتأكيد نحو توازن أفضل: تطوير محلي أولاً، التعاون القائم على Git، استضافة سحابية اختيارية، وتنسيقات محايدة للبائع.
الخلاصة: مستقبل أدوات المطورين
أفضل أدوات المطورين في عام 2026 تعمل وفقاً لمبدأ بسيط: ملفاتك هي مصدر الحقيقة. مستودعك هو مصدر التحكم الخاص بك. جهازك هو مساحة العمل الأساسية الخاصة بك. السحابة للنشر، وليس للتطوير.
هذا لا يعني أن الأدوات لا يمكنها تقديم ميزات سحابية. تقدم العديد من الأدوات اليوم استضافة سحابية اختيارية وتعاون ومنصات وخدمات سحابية مبنية فوق أساسات محلية أولاً. لكن الأساس دائماً محلي. إذا اختفت خدمة السحابة، يكون عملك لا يزال يمكن الوصول إليه. إذا اخترت الاستضافة الذاتية، تدعمها الأداة. إذا كنت تريد الهجرة إلى منصة مختلفة، بياناتك بتنسيقات مفتوحة غير مقفلة في نظام ملكي.
تشير نجوم Bruno البالغ 37,000 على GitHub و 2.5 مليون تحميل إلى رسالة واضحة حول ما يريده المطورون. يُظهر اعتماد Grafana Alloy أن هذه الفلسفة تنتشر إلى ما وراء الأدوات البسيطة إلى البنية التحتية المعقدة. وينبغي أن ينجاح البدائل المفتوحة المصدر للأدوات السحابية يقترح أن السوق تحول بشكل أساسي.
المطورون الذين يبنون أدوات في عام 2026 يفهمون هذا التحول هم الأوامر. يبنون أدوات التي تحترم المستخدمين، التي لا تقفل العمل في منصات ملكية، والتي تعمل بشكل جميل مع Git والتحكم في الإصدار. يثبتون أنك لا تحتاج احتفاظ السحابة لبناء أدوات التطوير القوية والتعاونية. أنت فقط تحتاج إلى الثقة في المطور.
ثورة Git الأصلية والمحلية أولاً ليست خطوة للخلف. إنها إدراك أن أفضل الأدوات هي التي تحترم استقلاليتك، وحماية خصوصيتك، وتتعامل مع عملك كشيء تملكه، وليس شيء تستأجره من منصة. في عام 2026، هذا ليس جميل - إنه يصبح التوقع الخط الأساسي للأدوات التي يثق بها المطورون مع عملهم الأكثر أهمية.