
Teilen Sie:
Chris ist Developer Relations Tooling Manager und leitet das Team, das Ihre Lieblingstools entwickelt. Er programmiert seit mehr als 15 Jahren in verschiedenen Sprachen und für verschiedene Projekttypen, von der Kundenarbeit bis hin zu Big-Data-Großsystemen. Er lebt in Ohio, verbringt seine Zeit mit seiner Familie und spielt Video- und TTRPG-Spiele.
Sich Zeit für sich selbst nehmen, kodierfähig
Lesedauer: 5 Minuten
Bereits im März 2020 habe ich über die Überarbeitung unserer Server-Spezifikationen gesprochenund dass eines meiner Hauptziele darin bestand, sicherzustellen, dass wir den Entwicklern, die unsere SDKs verwenden, die bestmögliche Erfahrung bieten. Die Aktualisierung der Serverspezifikation ermöglichte es unserem Team, sich ein wenig zu öffnen und die SDKs auf eine Art und Weise zu entwickeln, die für die Sprache sinnvoll ist und jedem Entwickler die Erfahrung bietet, die er erwartet.
Wir haben uns für die erste Jahreshälfte Ziele gesetzt, um die Benutzerfreundlichkeit zu verbessern. Dies führte dazu, dass unsere Sprachentwickler alle SDKs durchgingen, sowohl im Nexmo als auch im OpenTok-Namensraum, und herausfanden, wo wir uns besser an die neue Spezifikation anpassen konnten. Wir begannen, eine Liste der Stellen zu erstellen, an denen wir nicht mit der Spezifikation konform waren. Das hört sich sehr formal an, aber was wir meinen, ist, ob die SDKs mit unseren neuen Zielen übereinstimmen. Wo sehen die SDKs nicht wie eine Bibliothek für Sprache X aus oder fühlen sich nicht so an?
Eine Chance, einen ersten Eindruck zu hinterlassen
Viele Entwickler machen ihre ersten Erfahrungen mit einer Vonage API über unsere Server- oder Client-SDKs. Eine der ersten Aufgaben in ihrem Projekt besteht darin, unsere SDK-Software zu installieren und sie zum ersten Mal zu starten. Von diesem Moment an ist es unsere Aufgabe, das Schreiben von Software für unsere Plattform so einfach wie möglich zu gestalten.
Jede Sprache ist anders, und wir verstehen das. Ein Java-Entwickler hat andere Erwartungen an das Schreiben einer Anwendung als ein Ruby-Entwickler. Unsere SDKs sollten unsere APIs auf eine Weise offenlegen, die für die von uns unterstützten Sprachen sinnvoll ist. Wir sollten so pythonisch, idiomatisch oder sauber sein, wie ein Entwickler es von einer richtigen Bibliothek erwartet.
Auch Sprachen entwickeln sich weiter. Ich bin PHP-Entwickler, und ein großer Teil des Hasses, den unsere Sprache erfährt, basiert auf Code mit Erwartungen und Einschränkungen aus vergangenen Jahren und Versionen, die nicht mehr unterstützt werden. Unsere SDKs sollten sich mit den Sprachen weiterentwickeln, und das tun sie auch. Die Entwickler haben Erwartungen, wie "moderner" Code aussieht, und wir sollten uns bemühen, diese zu erfüllen.
Ein wichtiges Ziel unseres Server-SDK-Teams ist es, Bibliotheken bereitzustellen, die nicht nur mit unseren Produkten, sondern auch mit den Erwartungen der Entwickler Schritt halten. Wir haben schon immer verschiedene Ideen wie testgetriebene Entwicklung, hochwertige Dokumentation und Liebe zum Detail hochgehalten. Wir haben vor, weiterhin am Puls der Entwickler- und Sprachgemeinschaften zu bleiben, um die bestmögliche Erfahrung für Entwickler zu bieten.
Wonach haben wir gesucht?
Der größte Teil der Audits drehte sich um die Verwendung unserer Produkte und darum, ob die SDKs diese Verwendung auf klare, offensichtliche Weise offenlegen. Die Klarheit des Codes war ein wichtiger Schwerpunkt in der neuen SDK-Spezifikation und wurde zu einem wichtigen Thema bei den Audits.
Das Audit gab jedem unserer Sprachbefürworter die Zeit und die Möglichkeit, zu markieren, was wir besser machen könnten. Keines unserer SDKs war im Rückstand, wenn es um die von uns erwartete Unterstützung ging, aber jedes SDK hatte Optimierungen und Namensänderungen an öffentlichen Schnittstellen, die die Absichten klarer machen würden.
Als Vorgeschmack auf einige kommende PHP SDK-Änderungen wurde ein Großteil der Voice API-Schicht neu geschrieben. Wenn Sie einen ausgehenden Anruf tätigen wollen, erstellen Sie ein OutboundCall Objekt. Wenn Sie einen NCCO erzeugen wollen, können Sie ein NCCO Objekt erstellen und Aktionen zu dem NCCO hinzufügen. Nach dem Motto "selbstdokumentierender Code" sollte ein Entwickler in der Lage sein, diesen Code zu lesen und zu verstehen, was vor sich geht, auch wenn er mit PHP selbst nicht vertraut ist.
$outboundCall = new OutboundCall(new Phone(TO_NUMBER), new Phone(NEXMO_NUMBER));
$ncco = new NCCO();
$ncco->addAction(new Talk('This is a text to speech call from Vonage'));
$outboundCall->setNCCO($ncco);
$response = $client->voice()->createOutboundCall($outboundCall);
Der Gedanke ist nicht, dass die alte Methode schwierig war; es war nur nicht so klar, was passierte. Die Umbenennung von Methoden und Klassen kann eine ziemliche Herausforderung sein, aber wir hoffen, dass viele dieser Änderungen es nicht nur einfacher machen, zu verstehen, was unsere Produkte tun, sondern auch, wie man sie am besten einsetzt.
Durch dieses Audit konnten wir auch feststellen, wo ein oder zwei SDKs etwas taten, das für alle SDKs global gemacht werden sollte. Eine dieser Optionen war die Möglichkeit, dass die Benutzer Basis-URLs für die APIs angeben können. Dies war zwar eine Kundenanforderung, aber es stellte sich heraus, dass einige SDKs dies bereits umgesetzt hatten. Das Audit gab uns die Möglichkeit, diese Ideen zu sammeln und sicherzustellen, dass sie in allen unseren SDKs hinzugefügt wurden.
Die Produkte besser machen
Viele unserer Sprachentwickler, die unsere SDKs pflegen, sind auch so genannte Produktspezialisten. Unsere Produktspezialisten helfen bei der Zusammenarbeit mit Produktmanagern und den verschiedenen Entwicklungsteams bei der Entwicklung unserer API-Produkte. Da die Produktspezialisten dabei helfen, das Produkt selbst zu entwerfen, erhalten sie einen ersten Eindruck davon, wie Entwickler mit den APIs über die SDKs interagieren.
Wenn wir feststellen, dass etwas für einen Entwickler schwierig zu handhaben ist, können wir entweder auf API- oder SDK-Ebene bessere Entscheidungen treffen, um den Entwicklern das Leben zu erleichtern. Unsere Aufgabe besteht nicht nur darin, zu Veranstaltungen zu reisen und T-Shirts zu verteilen - wir nehmen all das Feedback der Entwickler auf und teilen den Produktmanagern und Ingenieuren mit, wo wir eine bessere Erfahrung bieten können, und helfen dabei, Lösungen zu finden.
Die jüngste .NET v5.0.0 Veröffentlichung brachte viele Verbesserungen für das SDK mit sich. Es gab einige hilfreiche Code-Ergänzungen wie eine verbesserte Fehlerbehandlung und ein flexibleres Logging-System, aber auch die Unit-Tests und Code-Schnipsel wurden überarbeitet. Diese Änderungen verbessern nicht nur unser und damit auch Ihr Vertrauen in den Code und die Änderungen, sondern die Beispiele wurden auch viel klarer und prägnanter, wie unsere SDKs zu implementieren sind.
Wir sind hier, um Ihnen zu dienen
Letztendlich ist es unsere Aufgabe, uns für die Entwickler einzusetzen, die unsere Software nutzen. Wir setzen uns nicht unbedingt dafür ein, dass Sie unser Produkt nutzen, sondern wir sind der Anwalt für Sie, den Entwickler, als eine Stimme innerhalb von Vonage. Ein Teil unserer Arbeit besteht darin, das Feedback, das wir von den Entwicklern bekommen, die wir treffen, aufzunehmen und unsere Produkte zu verbessern. Wir könnten unsere SDKs automatisch generieren und dann Feierabend machen, aber das hilft Ihnen nicht, der Person, die versucht, ein Problem zu lösen.
Bis Ende 2020 werden wir viele spannende Updates für die SDKs haben, die speziell darauf ausgerichtet sind, die Entwicklung klarer zu gestalten. Für .NET, Python und PHP sind einige wunderbare Überarbeitungen geplant, die dazu beitragen, verschiedene Erfahrungen zu bereinigen. Ruby führt die statische Typüberprüfung die in Version 6.3.0 eingeführt wurde zusammen mit verschiedenen allgemeinen Verbesserungen (v7.0.0 führte eine bessere Fehlerbehandlung und klarere Klassennamen ein, also schauen Sie sich diese Version an).
Sie können uns gerne Ihr Feedback zu unseren Produkten oder der von uns entwickelten Software, Demos oder Tools mitteilen. Wir haben einen Slack-Kanal der Gemeinschaft in dem unsere Sprach- und Produktbetreuer täglich Fragen beantworten. Wir überwachen Stack Overflow und helfen dabei, Antworten und Anleitungen zu den verschiedenen Problemen der Entwickler zu geben. Wir antworten auf E-Mails, die bei community@vonage.com zu vielen verschiedenen Themen über unsere SDKs und APIs.
Wir möchten Ihnen die Werkzeuge und die Unterstützung geben, die Ihr Problem so schnell und effizient wie möglich lösen.
Teilen Sie:
Chris ist Developer Relations Tooling Manager und leitet das Team, das Ihre Lieblingstools entwickelt. Er programmiert seit mehr als 15 Jahren in verschiedenen Sprachen und für verschiedene Projekttypen, von der Kundenarbeit bis hin zu Big-Data-Großsystemen. Er lebt in Ohio, verbringt seine Zeit mit seiner Familie und spielt Video- und TTRPG-Spiele.