← كل المقالات

موجز FourA: من 21 أغسطس إلى 28 أغسطس 2026

أصبح احتساب الاستخدام يشمل كل ساعة تمر خلال دورة الفوترة، وباتت المؤسسات تخطر المعنيين بما حدث، وتوقف Browser عن تسريب مقابض الملفات (file handles).

أهم التحديثات

يحسب الاستخدام الآن كل ساعة تتقاطع مع فترة الفوترة الخاصة بك، وبالتالي يغطي إجمالي الرصيد في صفحة الاستخدام والحدود (Usage & Limits) الفترة منذ ثانيتها الأولى. حصلت المؤسسات على المتابعة التي كانت تنقصها الأسبوع الماضي: يتلقى الشخص الذي تضيفه إشعارًا بذلك، وكذلك المالك الذي يدفع خطته، وتوضح أداة اختيار الأدوار أخيرًا ما يمكن لكل دور فعله. وراجعنا لوحة التحكم وأعدنا كتابة الرسائل التي كانت مكتوبة لمنظورنا الداخلي بدلاً من أن تكون موجهة لك.

الجديد

احتساب كل ساعة في فترتك

تبدأ فترة الفوترة في اللحظة التي سجلت فيها. يُقاس الاستخدام في فترات زمنية محددة. نادرًا ما يتطابق هذان الأمران، لذا يجب أن تكون الحسابات التي تربط أحدهما بالآخر دقيقة تمامًا عند الحدود.

أصبحت دقيقة الآن. تُقسم الفترة إلى فترات زمنية كاملة بأعلى دقة متوفرة لكل جزء، دون تجزئة ودون احتساب أي شيء مرتين. تشترك المواضع الثلاثة التي تقرأ الاستخدام في تطبيق برمجي واحد، وهو الحل الفعلي هنا. وجود ثلاث نسخ من نفس الحسابات الرياضية هو السبب في وقوع إحداها في الخطأ.

ما ستلاحظه: تظهر كل الأرقام في صفحة Usage & Limits أعلى قليلاً مما كانت عليه الأسبوع الماضي. نفس حركة المرور، لكن بحساب أكثر شمولاً. لم يتجاوز أحد حد الخطة بسبب هذا التغيير. نفس الحسابات تتحكم في الحصة النسبية الخاصة بك، لذا كان الأمر مهمًا في كلا الاتجاهين.

لا أحد ينضم إلى مؤسسة دون إشعار

أُطلقت المؤسسات الأسبوع الماضي وأصبح بإمكانك إضافة زميل، وتعيين دور له، والسماح له باستخدام المفاتيح التي تدفع الشركة تكلفتها. ما لم يكن بإمكانك فعله هو إعلامه. كان التلميح الموجود أسفل النموذج يطلب منك فعل ذلك بنفسك.

يتم إرسال بريدين إلكترونيين الآن. يتلقى الشخص المضاف بريدًا يوضح اسم المؤسسة، ومن قام بإضافته، وصلاحيات دوره، وكيفية مغادرتها إذا لم يكن يتوقع ذلك. ويتلقى المالك بريدًا عند انضمام أي شخص، لأن مفاتيح المؤسسة تُحسب ضمن خطة المالك، ووجود شخص إضافي يستهلك أرصدته هو شأن يخصه مباشرة وليس مجرد مجاملة. لا يُرسل أي من البريدين إلى من ضغط على الزر، فأنت لست بحاجة إلى إشعار بإجراء قمت به بنفسك.

يتم إرسال إشعار المالك في الحالتين: عند إضافة شخص مباشرة، وعند قبول دعوة عند أول تسجيل دخول، حيث لا يوجد منفّذ للإجراء لأن الشخص انضم بنفسه.

توضح الأدوار نفسها أيضًا. يتغير سطر أسفل أداة الاختيار أثناء التحديد، ويتضمن عمود Role تلميح شاشة يغطي الأدوار الثلاثة بما في ذلك المالك. الاختيار بين "Member" و"Admin" دون معرفة ما يمكن لأي منهما فعله هو السبب وراء منح صلاحيات المشرف تلقائيًا دون داعٍ.

خطوة واحدة لإضافة زميل

اكتب عنوان بريد إلكتروني، واضغط على Add. إذا كان يستخدم FourA بالفعل، ينضم مباشرة. وإذا لم يكن كذلك، نرسل له دعوة عبر البريد الإلكتروني وينضم بمجرد تسجيل الدخول. نفس الزر، ونفس التأكيد، ونفس النتيجة في الحالتين، وتصف الصفحة النتيجتين في جملة واحدة بدلاً من تحديد أيهما ينطبق على العنوان الذي كتبته.

اختفى مربع الحوار الثاني هذا، واختفى معه الرد الذي كان يخبرك بما إذا كان هناك حساب مسجل بعنوان معين هنا. لم يعد التحقق مما إذا كان بريد إلكتروني عشوائي مسجلاً لدينا سؤالاً نجيب عنه.

توقفت لوحة التحكم عن الكتابة إلى السجل

عبارة "Failed to fetch organizations" هي سطر مخصص لنا، لكنها كانت تظهر أمامك.

تحول 35 من هذه الرسائل إلى جمل يمكن للمستخدم اتخاذ إجراء بناءً عليها، مثل "تعذر تحميل منظماتك. حاول مجدداً بعد قليل." صياغة طبيعية ومباشرة في كل موضع يقرأ فيه إنسان. أصبحت رسالة "Invalid member id" ومثيلاتها توضح ما حدث بدلاً من ذكر اسم متغير. أما أسطر وحدة التحكم (console) التي كانت تختلط بها سابقاً فلم نغيرها، لأنها بالفعل مخصصة لنا. وينطبق الأمر نفسه على التحقق من بنية API الذي تتلقاه عند الاستدعاء برمجياً، وعلى الرموز القابلة للقراءة آلياً والتي تعتمد عليها لوحة التحكم في التفريع البرمجي.

حصلت رسائل البريد الإلكتروني على التحديث نفسه. الدعوة التي تطلب من شخص الانضمام إلى "منظمة" دون توضيح هي رسالة مصيرها سلة المهملات، لذا أعدنا الأسماء التي اخترتها: الحساب، والمفتاح، والمنظمة، وهوية من قام بالدعوة. أما النصوص الحرة التي يكتبها العميل فما زالت مستبعدة بالكامل من أي بريد إلكتروني نرسله.

ما وراء الكواليس

كان Browser يسرب مقبض ملف (file handle) واحداً لكل جلسة معالجة، ولم تكن المشكلة في الكود الخاص بنا. تقوم مكتبة نعتمد عليها بإغلاق أحد مقبضي السجلات الخاصين بها، ثم تنهي التنفيذ مبكراً وتتجاوز الثاني، ولكن فقط عندما يوفر المستدعي دليل ملف شخصي (profile directory) خاصاً به. ونحن نوفر دليلاً مع كل عملية تشغيل، مما جعل التسريب حتمياً ومستمراً.

يغلف التعديل (patch) تلك الدالة المحددة بدلاً من عمل تفريع (fork) للمكتبة التابعة. يقوم بتشغيل الدالة الأصلية أولاً ولا يتدخل إلا إذا كان المقبض لا يزال مفتوحاً، بحيث إذا قامت المكتبة الأصلية بنقل ذلك السطر قبل أمر return مستقبلاً، يتحول تعديلنا تلقائياً إلى عملية بلا تأثير (no-op). تعيد الاختبارات إنتاج التسريب قبل تثبيت التعديل، لكي يوضح ملف الاختبار ما يدافع ضده بدلاً من مجرد تأكيد أن الأمور تعمل بشكل طبيعي.

النتيجة العملية: تحافظ حالات Browser التي تعمل لفترات طويلة على سعتها بدلاً من تراجع الأداء مع تراكم الجلسات. إذا كنت تريد التحكم في شكل تلك الجلسات عبر الشبكة، فقد تم إطلاق browser profiles بالتزامن مع هذا التحديث.

انطلق كلا الحلين أعلاه من النقطة نفسها. اجتاز شيء ما فحصاً لم يكن الفحص الفعلي المطلوب: مجموعة اختبارات تظهر باللون الأخضر بينما تضيع ساعة كاملة من كل فترة، وعملية تسجل جاهزيتها للعمل بينما نفد منها المورد الوحيد الذي تحتاجه. الحصول على اللون الأخضر في الاختبارات أمر سهل. السؤال الأصعب هو ما الذي يجب أن ترصده أدواتك قبل أن تتحول إلى اللون الأحمر، وهل بمقدورها رصده من الأساس.