Freecodecamp: FCC Weather API تعيد طقس اليابان بشكل عشوائي

أعتقد أنني حددت المشكلة! إنها ببساطة تقرأ من ذاكرة التخزين المؤقت التي تحتوي على البيانات اليابانية.

يتم استخدام ذاكرة التخزين المؤقت فقط إذا كان هناك أكثر من ستين طلبًا في قائمة الانتظار الخاصة بها (السطر 50) وهذا يعني أنه _ في بعض الأحيان_ ستعيد النتائج الصحيحة ؛ ولكن _ في بعض الأحيان_ ستعيد هذه النتائج غير المتوقعة.

كيف يمكن إصلاح هذا؟ لدينا ثلاثة خيارات ...

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

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

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

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

لا أعتقد أنه يمكنني تقديم طلب سحب إلى glitch.me API (ما لم يكن هناك ، بالطبع ، مستودع على GitHub فاتني) ؛ لذلك سيحتاج شخص ما لديه إذن الكتابة إلى دمج تغييراتي بعد اختبارها باستخدام مفتاح API عامل.

حسنًا ، أنا أفك في هذا الوقت ؛ لكنني أدركت أن الحد من المعدل مطلوب. سأصلح الكود الخاص بي قريبًا حتى يتم رفض الطلبات إذا تم إجراء عدد كبير جدًا من استدعاءات API.

حسنًا ، أعتقد الآن أنني أوجدت حلاً على المدى القصير. لست متأكدًا مما نريد القيام به بشأن جمع البيانات المخيفة - فالإحداثيات تميل إلى أن تكون دقيقة تمامًا (هل يجب تقريبها من أجل أغراض التخزين المؤقت؟). يجب علينا بالتأكيد تحديد الأشياء إذا كانت من ذاكرة التخزين المؤقت ، لتوضيح أنها ليست دقيقة بنسبة 100٪.

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

 function getBestCachedData(lon, lat){
+ /*
   var fs = require('fs');
   var obj = JSON.parse(fs.readFileSync('./data/cache.json', 'utf8'));
+ */
-  return obj;
+  return {
+     "error": "This API is overloaded with requests at the moment. Please try again in a few seconds and see if you get a response"
+  }
  }

مرحبًا @ joker314 أوافق على حل الرفض الذي

QuincyLarson هل يمكنك توجيه من يمكنه الوصول إلى هذا https://fcc-weather-api.glitch.me/ ؟ يمكنني تفويض إذا كنت المالك.

raisedadead أحب ذلك ، لكنني نظرت حولي ولست متأكدًا مما إذا كان glitch.me يدعم بالفعل طلبات السحب - إلا إذا كان لديك أيضًا نسخة على GitHub أو أنني أفتقد شيئًا ما؟

تحرير: بالطبع ، يمكن العثور على الكود المصحح في ريمكس الخاص بي.

@ joker314 ، أنت محق ، سنقوم بتحديث المشروع من ريميكس الخاص بك. الرجاء تجاهل تعليقي السابق.

أنا أنتظر على Quincy لتأكيد الوصول إلى هذا المشروع. شكرا جزيلا لمساعدتك في هذا.

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

إذن ما هي المدة التي سيستمر فيها هذا الإصلاح المؤقت؟

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

كان هذا غلافًا تم إنشاؤه أعلى OpenWeatherMaps API ، والذي لم يكن يدعم https على ما أعتقد ، وبالتالي يتعارض مع codepen.

إذا كان الأمر كذلك ، فسيزداد الأمر سوءًا مع قيام المزيد من المعسكر بإنشاء مشاريع الطقس. هل يمكن زيادة حد السعر؟

نعم ، يمكنك اختيار نسخة مدفوعة من خلال دمج واجهة برمجة التطبيقات مباشرة بدلاً من غلاف الأخطاء في التحدي.

انظر https://openweathermap.org/price

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

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

ما رأيك في هذا ،raisedadead؟

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

حسنًا من الناحية النظرية ، يمكننا إرسال بيانات عشوائية. لكننا لا نريد الحصول على شكاوى بشأن عدم صحة البيانات .. وأنا متأكد من أنها ستكون قضية.

على أي حال إذا كان يساعد في الحصول على البيانات العشوائية.

QuincyLarson هل يمكنك توجيه مع الطلب أعلاه ؟

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

أفكار؟

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

من فضلك ، هل تفكر في تثبيت مناقشات المنتدى الأخيرة على صفحة المشروع حتى يعرف المبرمجون أن هناك مشكلات في المشروع ولا يقضون وقتًا غير ضروري في محاولة إصلاح شيء لا يتحكمون فيه؟

راجع للشغل ، أعتقد أن عنوان url الخاص بالصورة icon لم يتم إرجاعه كما هو موضح في https://fcc-weather-api.glitch.me/.
قال Images links are included in the JSON under weather[0].icon ، وهو ليس كذلك.
لقد لاحظت أن الحل التجريبي كتب css لرسم الأيقونة.

شكرًا لك على إخبارنا بهذه المشكلة المحتملة ، ولكن نموذج طلب استجابة amd يتضمن الحقل المطلوب. ما هو الطلب المحدد الذي قدمته والذي لا يحتوي على هذا المجال؟

@ joker314 تشك للرد.

https://fcc-weather-api.glitch.me/api/current?lon=39.988&lat=116.3000

{"coord":{"lon":139,"lat":35},"weather":[{"id":803,"main":"Clouds","description":"broken clouds"}],"base":"stations","main":{"temp":28.23,"pressure":1011,"humidity":74,"temp_min":26,"temp_max":31},"visibility":10000,"wind":{"speed":3.6,"deg":230},"clouds":{"all":75},"dt":1499396400,"sys":{"type":1,"id":7616,"message":0.0043,"country":"JP","sunrise":1499369792,"sunset":1499421666},"id":1851632,"name":"Shuzenji","cod":200}

لم ألاحظ أن المثال كان يعمل بشكل جيد ، لذلك أعتقد أن هذا قد يكون بسبب الموقع أو الطقس الخاص؟

@ Em-Ant يبدو أن هذه مشكلة في التطبيق الذي يعمل على Glitch. هل يمكنك إلقاء نظرة على ذاكرة التخزين المؤقت ومعرفة ما إذا كان هذا شيء يمكننا مسحه؟

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

@ moT01 ما نوع الاختبارات التي قمت بها؟ المشكلة هي أن هناك حدًا للسعر لكل حساب FCC المجاني المستخدم لإجراء مكالمات إلى OpenWeather API. بمجرد الوصول إلى حدود الأسعار هذه ، يقوم وكيل Glitch بإعادة إحداثيات اليابان. السبب الوحيد لعدم النظر إليه على أنه مشكلة في الوقت الحالي ، هو أن هذا المشروع أصبح الآن اختياريًا في المناهج الدراسية ، لذلك لم يكن هناك العديد من النتائج التي كانت عليه في السابق. بمجرد أن تضغط على Glitch 60 مرة في الدقيقة ، يتم إرجاع JSON التالي:

{
  "coord": {
    "lon": 139,
    "lat": 35
  },
  "weather": [
    {
      "id": 803,
      "main": "Clouds",
      "description": "broken clouds"
    }
  ],
  "base": "stations",
  "main": {
    "temp": 28.23,
    "pressure": 1011,
    "humidity": 74,
    "temp_min": 26,
    "temp_max": 31
  },
  "visibility": 10000,
  "wind": {
    "speed": 3.6,
    "deg": 230
  },
  "clouds": {
    "all": 75
  },
  "dt": 1499396400,
  "sys": {
    "type": 1,
    "id": 7616,
    "message": 0.0043,
    "country": "JP",
    "sunrise": 1499369792,
    "sunset": 1499421666
  },
  "id": 1851632,
  "name": "Shuzenji",
  "cod": 200
}

هل يمكنك إعادة فتح هذه المشكلة ، لأنها لا تزال مدرجة في قائمة المهام الخاصة بي للمشاريع لإصلاحها؟

آه ، نعم - لقد أجريت للتو مكالمتين سريعتين إلى API وتمكنت من الحصول على الطقس الصحيح. أفترض أنه ربما ينبغي علي الاستفسار أكثر قليلاً قبل إغلاق القضايا.

بدأت العمل على إصلاح في بداية Hacktoberfest ثم انخرطت بشكل كبير في عملية ضمان الجودة. الباقي هو التاريخ. أحتاج إلى إعادة النظر في هذا مرة أخرى ، لأنني الآن لدي فهم أفضل بكثير لـ Node و Express لأتمكن من الحصول على حل عملي.

توجد ذاكرة تخزين مؤقت ثابتة بها إدخال واحد فقط (الموقع في اليابان).

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

على أي حال ، فإن مشروع api هذا على خلل مملوك لـ MiloATH ، ولا يمكننا تحريره بدون "تفرعه" ، أي إنشاء تطبيق جديد بعنوان url جديد.

لقد أرسلت طلب انضمام على https://glitch.com/edit/#!/fcc -weather-api باستخدام حساب camperbot إلى Milo.

هذه تبدو وكأنها أفكار جيدة! هناك خيار ثالث. لإصلاح ذاكرة التخزين المؤقت بحيث يتم تخزين البيانات بالفعل هناك - أو لإرسال بيانات عشوائية إذا تم الوصول إلى محدد المعدل.

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

@ joker314 كنت

لقد أرسلت دعوة إلى مشروع الخلل.

يمكن أن تكون نقطة النهاية أفضل بكثير. أعتقد أنه يجب علينا بناء ريبو منفصل باستخدام CI ونشره في شيء أكثر نضجًا مثل Heroku (نسخة مجانية). سيتيح لنا ذلك العمل بسهولة أكبر في المشروع.

لم نعد ننتشر في heroku بعد الآن. سنستخدم Glitch في الوقت الحالي. بمعنى أنه إذا كان هناك مشروع بديل ، يسعدنا نشره ضمن حساب freeCodeCamp على Glitch واستبدال التحدي الحالي في المنهج الدراسي

تضمين التغريدة
مرحبا! أي تحديثات على هذا؟
سيكون من الرائع رؤية بعض المخططات مع البنية وتدفق البيانات (وفي النهاية أسماء الملفات المرتبطة)

@ Hash2C يمكنك إعادة

https://glitch.com/edit/#!/fcc -weather-api؟ path = server.js: 1: 0

شكرًا RandellDawson ، لقد كنت أعمل عليها ، وآمل أن أتمكن من إنهاء المسودة الأولى حتى يوم الخميس

@ Hash2C خذ وقتك

شكرًا RandellDawson ، سأبذل قصارى جهدي.
سأحتاج إلى معرفة المزيد عن القيود الحالية.
قرأت أعلاه أن لدينا حدًا يبلغ 60 زيارة في الدقيقة ، والذي يبدو أنه المستوى المجاني في تسعير OpenWeather. هل هناك طريقة لزيادة هذا الحد؟ مثل إنشاء اشتراكات أخرى في OW؟ هل هناك "مصادر حقيقة" أخرى يمكن أن نستخدمها مع OW؟

تحرير: أيضًا ، ما هو نوع التأخير المقبول للتسليم؟ 5 دقائق؟ 15 دقيقة؟ 1 ساعة؟ 3 ساعات؟

Edit2: يبدو أن OW "تحديث بيانات Weather API" "أقل من ساعتين" كما هو موضح في هذا الجدول
https://openweathermap.org/price
نفس الجدول يخبرنا أن التوافر 95٪ فقط

هل هناك طريقة لزيادة هذا الحد؟ مثل إنشاء اشتراكات أخرى في OW؟

قد يكون لديهم أيضًا قيود على عنوان IP (غير متأكد) ، لذا فإن إنشاء اشتراكات أخرى لن يساعد.

هل هناك "مصادر حقيقة" أخرى يمكن أن نستخدمها مع OW؟

لا أكيد.

Edit2: يبدو أن OW "تحديث بيانات Weather API" "أقل من ساعتين" كما هو موضح في هذا الجدول

أقوم حاليًا بتطوير مشروع الطقس الخاص بي باستخدام الإصدار المجاني من OpenWeather ، وقد فكرت فقط في التحقق مما إذا كان الطلب أقل من 10 دقائق من الطلب الأخير ، ثم عرض آخر بيانات تم إرجاعها لنفس خط العرض / الطول.

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

لقد أنشأت هذا الريبو حتى يسهل اختباره محليًا.
https://github.com/Hash2C/fccWeatherApiDraft

أعتقد أن حالات الاستخدام الرئيسية الثلاث (في الوقت الحالي) قد تمت تغطيتها بالفعل

• إذا كانت الإحداثيات غير صالحة / غير موجودة ، أرسل خطأ
  وإلا ، فقم بتحويل الكابلات إلى تنسيق مناسب ثم نحاول الضغط على ذاكرة التخزين المؤقت

• إذا تم تخزين الإحداثيات المطلوبة مؤقتًا
  
  
  
  • إذا كان الطابع الزمني ضمن دلتا المقبولة: أرسل البيانات المخزنة مؤقتًا (1)
  
  
  • else: قم بتعيين البيانات المحاكاة على أنها بيانات مخزنة مؤقتًا (في حالة فشل استدعاء OpenWeather api لاحقًا)
  
  

• else: عيّن البيانات الساخرة كشيء نقرره (في حالة فشل استدعاء OpenWeather api لاحقًا).

• نحاول استدعاء OpenWeather api.

• إذا حصلنا على البيانات الصحيحة ، أرسلها ، وقم بتخزينها في ذاكرة التخزين المؤقت (2)
• عدا ذلك ، أرسل البيانات الساخرة (3)

هذا التدفق مفتوح بشكل كبير للنقاش بالطبع!

لا يزال هناك الكثير من العمل الذي يتعين القيام به ، وعمليات التحقق ، والأشياء غير المتزامنة ، وحالات الحافة (الاختبارات) ، إلخ. لقد علقت على ملف server.js كثيرًا (لا تخيف) ، سأقوم بتصفية معظم هذه المعلومات تدريجيًا وأطلب منك المساعدة هنا حتى نتمكن من مناقشة كل مشكلة.

مجرد فكرة: هل يمكننا في النهاية الحصول على خدمة بيانات ، تحاول تقليل عدد "الطلبات المتاحة إلى OpenWeather API (أو غيرها) التي لا يتم إجراؤها"؟ ستغذي هذه الخدمة ، دعنا نقول ، قاعدة بيانات MongoDB - والتي ستكون ذاكرة التخزين المؤقت لدينا (يمكننا استخدام Memcached ولكن ربما يكون هذا كثيرًا جدًا ، ولا نحتاج إلى هذه السرعة الإضافية)

إيديا أخرى: هل هناك أي إحصائيات استخدام سابقة لهذه الخدمة؟ إذا لم يكن الأمر كذلك ، فربما يمكننا البدء في إنشاء واحد ، وربما يكون ذلك مفيدًا ، لمحاولة تحسين حل ممكن في النهاية ولكنه دون المستوى الأمثل للغاية

هناك شيء واحد سأحتاج بالتأكيد إلى بعض المساعدة لفهمه وهو أن github يحذرني من مشكلات الأمان

(لسبب ما فاتني رسالتك تمامًا!)

قد يكون لديهم أيضًا قيود على عنوان IP (غير متأكد) ، لذا فإن إنشاء اشتراكات أخرى لن يساعد.

نقطة جيدة. هل يستحق الاختبار؟

هل هناك "مصادر حقيقة" أخرى يمكن أن نستخدمها مع OW؟

لا أكيد.

إذا سُمح لنا بالقيام بذلك ، فقد يزيد ذلك بشكل كبير من احتمال تحقيق حل ناجح.

أقوم حاليًا بتطوير مشروع الطقس الخاص بي باستخدام الإصدار المجاني من OpenWeather ، وقد فكرت فقط في التحقق مما إذا كان الطلب أقل من 10 دقائق من الطلب الأخير ، ثم عرض آخر بيانات تم إرجاعها لنفس خط العرض / الطول.

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

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

أتفق تمامًا مع هذه الفكرة المتمثلة في إعطاء المعلومات ذات الصلة للمطورين والسماح لهم بالاختيار ، فهذا هو المسار الذي كنت أفكر فيه ليكون الأكثر ملاءمة أيضًا

هل توجد أدوات معيارية للاختبار وتقديم الطلبات في مشاريع لجنة الاتصالات الفيدرالية؟
للطلبات التي أستخدمها (لمجرد أنني قررت تجربتها ، بدلاً من Axios)
www.npmjs.com/package/request
بالنسبة للاختبار ، ليس لدي خبرة كبيرة ولكني كنت أفكر في Mocha.
ولكن يرجى إعلامي بالأدوات التي تتكامل بشكل أفضل مع FCC

هناك شيء واحد سأحتاج بالتأكيد إلى بعض المساعدة لفهمه وهو أن github يحذرني من مشكلات الأمان

أبسط حل هو تشغيل npm audit fix ثم تنفيذ package.json و package-lock.json . يجب ألا تحتوي الحزم الجديدة على أي تغييرات متقطعة عن الحزم السابقة الضعيفة. ومع ذلك ، يفترض ذلك أن مؤلفي الحزمة لم يقدموا عن طريق الخطأ تغييرًا مفاجئًا ، لذلك يجدر التحقق يدويًا من تطبيقك بعد تطبيق الإصلاحات.

لقد كنت ألعب بواجهة برمجة تطبيقات OpenWeather (في الواقع كان يجب أن أفعل هذا من البداية).
هل عرفنا هذا؟ https://openweathermap.org/faq#error401
الجزء ذي الصلة

لمطوري البرمجيات الحرة والمفتوحة المصدر: نرحب بالبرامج المجانية ومفتوحة المصدر ونرغب في مساعدتك. إذا كنت ترغب في استخدام بيانات OWM في تطبيق البرنامج المجاني الخاص بك ، فيرجى تسجيل مفتاح API وتقديم بطاقة تصف التطبيق ومفتاح API المسجل. سوف يقوم OWM بمراجعة طلبات رفع حدود الوصول لمفتاحك إذا تم استخدامه في تطبيق مفتوح المصدر.

مرحبًا يا شباب ، لقد كنت مقيدًا أكثر مما كان متوقعًا.
في وقت فراغي ، كنت أدرس OpenWeather api. للأسف لم يتم توثيقها بشكل جيد.
أعتقد أنني توصلت إلى استراتيجية مجدية ، باستخدام خيار bbox ، لكنني ما زلت أختبر.
خطرت لي فكرة إنشاء مستند بكل المعلومات التي صادفتها ، والاختبارات التي أقوم بها.

@ Hash2C خذ وقتك

تضمين التغريدة
كنت تعرف ما كنت تقوله: علامة التحقق الثقيلة:

@ Hash2C كيف يأتي الحل الخاص بك؟

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