Telekom Tropo – Logfile Zugriff für’s Debugging

Hi…

da bei Telekom Tropo Applikationen zwei Server miteinander kommunizieren, ist es teilweise etwas schwierig ein ordentliches Debugging hin zu bekommen. Gerade am Anfang, wenn beim eigenen Webserver auf wundersame Weise nichts ankommt… (weil man sich bei der Server-Adresse vertippt hat… mal so).

Wir haben ein neues Feature online seit heute: Ich kann in die Logfiles des Tropo-Servers schauen. Dazu einfach in den Developer Center einloggen und den Tropo Reiter auswählen. Folgende Ansicht kommt und der Button in gelb ist neu.

Wenn ich darauf klicke, bekomme ich eine Tabelle mit den LogFile Einträgen zu meinen Applikationen auf Tropo:

Wenn ich mich nur für bestimmte Events interessiere gibt es oben rechts ein Suchfeld. Eingegebener Text wird sofort im Fenster als Suche umgesetzt:

Ein weiteres cooles Feature von Telekom Tropo.

CU

0xff

Telekom Tropo RevShare – Proposal II

Hi…

This time in English because I need to address a larger audience. Please bear with me…

Revenue share model – second shot

After my first idea I got some feedback which I would like to include into the concept. The following is a product idea, it is nothing real – for now. My goal is to find the Minimal Valuable Product which I could set up and test. Therefore I need your help and let us refine the original idea.

Hypothesis:

I believe that developers have an interest to use the IVR system Telekom Tropo in their applications. But they do not want to do the accounting. And, potential interest would increase dramatically, if we would share the revenue with the developer that his app generates for us.

How would it look like?

The main concept stays the same. You, Mr Developer, build an app (which doesn’t need to be a mobile one and ) which uses Deutsche Telekom services – in my case the Telekom Tropo API. Your customer acquires the app (buying or getting it for free) and, through your app, sets up an account with us. She can use any payment mechanism.

Whenever your customer is now using your app and generates service revenue with us, we share this revenue with you. All customer communications will be done through your app. To do so, we provide a component, you can include into your app which supports themes so you can camouflage it as much as you want.

Requirements:

  • You, Mr Developer, need to register with us. You act as a kind of reseller and acquire an app id.
  • Your app provides this app id when using our services.
  • We provide a proper reporting on what happening.
  • Your customer sets up an account with us. We take all efforts regarding account management.
  • Your customer could use her account with us in different apps. Logically, you, Mr. Developer would only earn when your app is the caller (hey, be fair…).

We would take care on all accounting and calculate the revenue share. You would get it paid out regularly.

Would you follow us down this path??

CU

0xff

Developer Life-Cycle Model

Hi…

Wie Peter Drucker so schön sagte „Die Hauptaufgabe jeder Organisation ist es, Kunden zu gewinnen“. Es ist hinlänglich über den Zyklus diskutiert worden, wie man als Organisation Bedürfnisse erkennt, diese mit Produkten adressiert und zu guter Letzt, diese Produkte auf den Markt bringt. Für mich ist die Aufgabe von Marketing in allen drei Phasen eine aktive. Es ist Aufgabe von Marketing Bedürfnisse zu erkennen (Märkte zu identifizieren), passende Produkte entwickeln zu lassen (so dass sie auf diesen Markt passen) und dann ja auch zu verkaufen. Dabei ist das ein Zyklus, kein einfacher Prozess.

Wenn man Marketing machen will, so muss man sich Gedanken um seine Zielgruppe machen. Man muss sie verstehen und sich ein Model bauen. Naja, Letzteres machen vor allem Physiker, die jetzt einen Marketing-Job machen. Es gibt viele Modelle für den Consumenten (Beispielsweise hier http://de.wikipedia.org/wiki/Sinus-Milieu), aber erstaunlicherweise wenig bis gar nichts zu Software-Entwicklern. Erstaunlicherweise weil derzeit ja alle Welt hinter App-Entwicklern her rennt.

Ich habe einen interessanten Beitrag hier http://www.visionmobile.com/product/developer-economics-2012/ gefunden. Eine Segmentierung mal als Beispiel.

Vielleicht vorab noch so viel: Ein Modell ist ein Modell. Es zeigt nicht die für jeden Einzelfall gültige absolute, dauerhafte Wahrheit. Vielmehr reduziert ein Modell strategisch, d.h. es konzentriert sich auf einige wesentliche Aussagen und blendet eine Menge komplexe Realität aus. Und der letzte Satz war ein Anthropomorphismus.

Ich habe mir auch ein paar Gedanken gemacht und folgendes Modell entwickelt:

Entwickler leben in einem Zyklus von Projekten, mit unterschiedlicher Laufzeit. Manchmal heißt Projekt-Ende, dass man eine ganz neue Umgebung bekommt (bei Freelancern häufig), manchmal ist es nur ein Produkt-Release und alles geht so weiter wie gewohnt. Bei einem solchen Projekt-Start steigt mein Modell ein. Zu Beginn haben Entwickler meist sehr viel Zeit sich mit neuen Dingen zu beschäftigen (Explore). Warum?? Nun, man sucht neue Tools, Prozesse, Technologien etc, um das neue Projekt erfolgreich gestalten zu können. Für manche ist diese Phase extrem groß (z.B. Architekten, die stets auf der Suche sind), für manche sehr schmal (z.B. den Abteilungs-ABAP-Programmierer… armer Kerl). Aber irgendwie sind wir alle aus dem Holz gemacht. Wir alle haben unsere Explore-Phase und wir geben sie nur sehr ungern auf. Mein Modell zeigt, dass Explore auch immer ein wenig bleibt. Weil wir halt Spielkinder sind und immer auf dem neuesten Stand bleiben wollen. Für mich als Evangelist ist jetzt die Frage, wie muss der Content in dieser Phase aussehen?? Es muss ein gute Mischung aus Entertainment und Education sein, Edutainment. Sehr viel Architektur, Beispiele zum ausprobieren, Trials, Video, Artikel, Kongress-Vorträge…

Irgendwann müssen wir aber zum Schuß kommen und wir wählen Tools und Kram zum Arbeiten. Manchmal bleibt alles beim alten, manchmal wechseln wir die ganze Plattform. Aber langsam müssen wir mehr Zeit wieder der eigentlich Arbeit zu wenden. Also gehen wir in die Work-Phase. Hier geht es jetzt nicht mehr Architekturen und lustig Overview, sondern konkrete Themen. Man hängt an Fehlern fest oder sucht die eine Funktion, die den String HTML-encoded. Hier ist eine andere Art von Content gefragt. Der kluge Developer checkt das natürlich vorher. In der Explore-Phase wird schon mal gecheckt, wie gut ist der Service, wie stark ist die Community, gibt es ausreichend Artikel etc und lala. Irgendwann – und wir kennen das alle – sitzen wir dann 16 Stunden am Tag am Codieren, weil die Abgabe nahe rückt. Wir haben doch etwas weniger Zeit für Explore, vielleicht auch gar keine Zeit mehr. Natürlich passiert uns das nie, da wir perfekt planen. Aber ich habe gehört, dass der Schwager eines entfernten Bekannten häufiger solche Zeiten hatte.

Ganz oben auf schwimmt das Thema Maintainance. Wir alle leben nicht prinzipiell immer wieder auf einer grünen Wiese. Vielmehr gibt es bestehende Themen, die wir so nebenher weiter pflegen müssen. Es mag Ausnahmen geben (wenn wir für die NASA eine Sonde bauen, müssen wir wahrscheinlich nicht alten Code pflegen). Meist haben wir aber alten Code in Form von alten Produkten oder Produkt-Versionen zu pflegen. Ich habe diese Phase ausgewiesen, weil diese Zeiten einige spezielle Eigenschaften hat. Zumeist kommt der Kram unvorhergesehen und zu dem, was wir sowieso tun müssen oben drauf. Dazu sind es eigentlich Kleinigkeiten, keine wesentlichen Änderungen. Wir waten tief durch Code, der ewig alt ist und den wir am Ende nicht mal selber geschrieben haben. Wir arbeiten hier mit alten Versionen von Tools, Betriebssystemen, Datenbanken, Tralala. Welchen Content man hier sucht, ist auch klar. Sehr stark wie in der Work-Phase, aber halt alte Versionen. Als Hersteller ist das interessant, weil man entscheiden muss, nicht nur wie lange man Content für alte Version hält (das ist ja noch einfach) sondern in wie weit man diesen Content noch pflegt.

Für mich ist dieses Modell ein wichtiger Leitfaden, den richtigen Content-Mix zu finden. Vielleicht auch für Euch interessant.

CU

0xff

 

Telekom Tropo RevShare – A product proposal

Hi…

ich brauche Euch. Ihr müsst mir helfen zu entscheiden, ob dieses Produkt von Interesse wäre und wie eine minimale Ausprägung aussehen müsste, damit es Sinn macht.

Hypothese:

Ich glaube, dass Entwickler Interesse daran hätten, das IVR System Telekom Tropo in ihren Applikationen zu nutzen. Sie wollen aber nicht die Buchhaltung machen. Und, das Interesse würde expotentiell steigen, wenn wir sie am Umsatz beteiligen würden, dass ihre App bei uns erzeugt.

Mein Produkt:

Telekom Tropo Revenue Share

Wie würde es aussehen:

(1) Der Entwickler baut eine App, die Telekom Tropo Dienste nutzt und stellt sie dem Benutzer zur Verfügung. In meinem Beispiel ist das eine CRM Applikation, die mit Telekom Tropo Anruf-Verwaltung macht.

(2) Der Benutzer hat diese App und aktiviert die Telekom Tropo Funktion. Im ersten Schritt würde der Kunde ein Konto bei uns anlegen und das aufladen (Pre-Paid).

(3) Der Benutzer verwendet die CRM App und dadurch auch Telekom Tropo. Wir tracken welche App die Umsätze auslösen und bezahlen einen Anteil diesen Umsatzes an den Entwickler. Der Kunde würde marktübliche Preise bezahlen müssen und es nicht “spüren”, dass wir an den Entwickler Gewinne ausschütten.

Frage:

Macht das Sinn?? Würden Eure Kunden ein Konto bei uns anlegen und aufladen?? Was würdet Ihr brauchen, um das zu verwenden??

CU

0xff

 

Developer Garden: Project Gestalt – Wir schalten in den nächsten Gang…

Hi…

Abgeschlossene Systeme wie wir sie in der Physik gerne gebrauchen, sind abstrakte Modelle. In der Realität kann sich ein System nicht den Veränderungen entziehen, die in seiner Umgebung geschehen. Bei diesen steten Anpassungsprozessen neigen Systeme dazu, Komplexität und Overhead anzuhäufen. Man muss dann aktiv daran arbeiten, diese wieder abzubauen. Das alles ist ganz natürlich und wer das Gegenteil behauptet, bekommt von mir den Ehrentitel „Traumtänzer“. Dazu kommen aber auch neue Dinge, die man gerne haben würde, sie aber irgendwie nicht reinpassen oder man schlichtweg keine Zeit hat, weil man ja so mit dem bisherigen zu tun hat. Daher hat ein schlauer Mensch, dessen Namen mir gerade nicht einfällt, mal die Red Queen Hypothesis definiert (ja, kommt von Alice im Wunderland): Man muss seine gesamte Kraft aufwenden und nach vorne rennen wie bekloppt, dass man sich nicht zurückbewegt.

Dem Portal Developer Garden geht es keinen Deut anders. Das Portal ist nun seit Jahren am Laufen und hat viele neue Themen im Laufe der Jahre aufgegriffen. Dabei natürlich auch Komplexität aufgebaut. Wir wollen in den nächsten Wochen und Monaten uns die Aufgabe stellen, das Portal zu verändern, zu modernisieren, zu verschlanken, es noch attraktiver, knackiger zu machen… Kurz: So geil, dass man morgens mit Freude aufsteht, weil man wieder den Frühstückskaffee mit Developer Garden verbringen darf.

Jetzt habe ich mal gelernt, dass man solche Aufgaben am besten angeht, wenn man die Welt zu seinem Zeugen macht (gelernt von John F. Kennedy: „First, I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth.“). Das hat scheinbar mit der Tatsache zu tun, dass der Mensch als soziales Wesen stets darauf achtet, was die anderen über ihn sagen, und er daher nicht hinter seinem Wort zurückfallen will. Naja, vertiefen wir das mal nicht weiter. Trotzdem, wir von B2B2X bei der Deutschen Telekom AG, die Teams in Berlin und Darmstadt, machen Euch alle jetzt zu unseren Zeugen und werden regelmäßig zu unserem Projekt berichten. Wir nennen es…

Project Gestalt

Beginnen wir vorne. Ich darf Euch mit der Vision / Mission des Portals Developer Garden bekannt machen. Als internationales Unternehmen mit Sub-Teams in Berlin und Darmstadt, mussten wir das natürlich in Englisch machen:

Developer Garden is the portal by

Deutsche Telekom for developers which enables them to

efficiently build solutions.

Wie immer ist jedes Wort hierin mit Bedacht gewählt. So wie die Bibel mit der historisch-kritischen Methode interpretiert werden kann, gibt es auch hierzu eine Anleitung:

  • Receiving Audience: Developers of all color and from any origin
  • Portal is overarching for all bidirectional online channel “for Developers” and DTAG
    • E.g. Facebook, Twitter…
  • Additional REACH by including partners (e.g. MSDN, AppUp, developerWorks)
  •  Sending Entity: Deutsche Telekom as a whole
  • Telekom APIs might be highlighted/featured in an own area of the portal
  • Clients (German: Mandanten)  which want to be included in “the portal”
    • E.g. T-Labs, M2M, Connected Home…
  • Mission is to enable…
  • Components (or Assets) which will be basically available and/or distributed through a market place (CMP) to “efficiently build solutions”
    • E.g. APIs, Templates, Whitelabel Solutions, Libraries…
  • RELEVANT content is KING!!!

Das ist die Aufgabe, der wir uns mit aller Kraft stellen wollen. Kurz: Ziel ist es, das verdammt nochmal geilste Developer-Portal mit größter Reichweite und sexy-relevantesten Inhalten in dieser fantastischen Galaxis zu haben. Und von dieser Vorstellung können wir jetzt auch keinen Millimeter mehr abweichen, weil Ihr uns sonst auslacht, wo Ihr uns trefft…

Ich werde Euch über unsere Fortschritte auf dem Laufenden halten…

CU

0xff

PS: Jetzt habe ich auch ein wenig Angst, aber das ist wahrscheinlich genau richtig so 😉

An die Krieger des Lichts…

Hi…

so, Freunde, dieser Post geht mal explizit nicht an Luschen und Warmduscher. Wer im Winter den Pelzkragen an die Jacke macht, kann gleich mal weiterblättern. Das Internet hat genug Seiten für Weinerle. Gesucht werden Menschen, die das Zeug zum Veteran der Browser-Wars haben. Personen, die dieses Wochenende aus Langeweile aus ihrer Espresso-Maschine einen zweiten Mars-Rover bauen. Der dann aber auch Kaffee kocht, nicht so wie der Blechkasten der NASA. Und der einzige Grund, warum dieses Ding nicht direkt noch am Sonntag neben dem NASA Spielzeug landet ist, dass diese Menschen eben keine Langeweile haben. Menschen, die ein echtes Abenteuer noch zu genießen wissen. Die Spaß am Basteln, am Tun haben!!

Wir suchen Menschen, die bei Alan Turing auf die Facebook-Wall hätten schreiben dürfen. Mit denen Ada Lovelace sogar eine Anglaise getanzt hätte. Große Geister, die sogar Bjarne Stroustroup noch Tricks verraten, wie man Programiersprachen noch komplizierter machen kann. Menschen, denen Steve Jobs einen Pullover geschenkt hätte, den dann Steven Sinofsky ihnen zu liebe angezogen hätte. Die Grady Booch den Rat geben dürfen, sich endlich die Haare zu schneiden und er würde darüber nachdenken (wir wollen mal nicht übertreiben). Menschen, die einen Saal von Entwicklern dazu bringen, spontan einen Flash-Mob zu machen. Kurz: Menschen, die ein Händchen für die großen und kleinen VIPs in dieser Industrie haben. Menschen, die Spaß daran haben mit den Großen zu lernen und die Neuen zu lehren.

Menschen, die Programmieren und alles was damit zusammenhängt lieben, ja auch körperlich. Die ein Programmiersprache auf einer Zugfahrt zwischen Köln und Düsseldorf lernen. Die Technik aufsaugen wie Sintepragetori, eine noch nicht entdeckte Schwammart, die sich von schwarzen Löchern ernährt. Menschen, die wissen, dass LaTeX neben Fetischklamotten noch was ganz anderes ist. Die irgendwie Alles interessiert, was Strom verbraucht und auch die Firmware eines Mixers verbessern können. Menschen, deren DNA binär codiert wurde. Manche würden wohl Vollblut-Techniker sagen; wir meinen Helden einer neuen Ära.

Dabei noch echte Kumpel und Team-Player. Die perfekte Mischung von Bud Spencer und Terence Hill. Ein Ego so groß und kräftig, dass man damit Wände einrammen kann. Was sie aber gar nicht nötig haben, weil sie jede Tür geöffnet bekommen. Menschen, die Spaß an dem haben was sie tun und das ausstrahlen wie Sirius A. Die mit anderen lachen können. Die über sich selbst lachen können. Die überhaupt immer gut drauf sind. Die verrückt genug sind, sich mit ihren Kollegen Nerf Schlachten zu liefern. Die eine solche innere Ruhe besitzen, dass sie Prodigy zum Einschlafen hören. Menschen, die schon viele Elefanten gegessen haben, weil sie wissen, dass man jedes Großprojekt immer nur in kleine Scheibchen zerlegen muss.

Silbermond nannte sie mal die Krieger des Lichts. Wir suchen Menschen, die mit ihrem Manager morgens um 6:30 Uhr 10 km joggen gehen und sich danach frisch an die Arbeit machen. Menschen, die es angehen wollen, einen weltweiten Großkonzern von innen zu wandeln. Menschen, die soviel Drive und Energie haben, dass sie die Märklin-Eisenbahn des Vaters durch bloßes Handauflegen zum Durchdrehen bringen.

Ja, wir suchen Evangelisten…

https://jobwelt.telekom.com/jpapps/n/ext/jv/,00012153

http://stellenanzeige.monster.de/Developer-Evangelist-B2B2X-m-w-Manager-Level-Job-Darmstadt-Hessen-Deutschland-112996536.aspx?WT.mc_n=KSPON

CU

0xff

Telekom Tropo – Make the elefant dance…

Hi…

nachdem man sich für Telekom Tropo angemeldet hat (siehe diesen Post) und sich seine Nummer zuweisen hat lassen (siehe diesen Post), möchte man natürlich auch was machen. Vielleicht erwähne ich noch vorab: Soweit ist dies alles erstmal kostenfrei. Wir werden irgendwann mal die besonderen Kosten für deutsche Nummern (wir hatten das ja schon) umlegen müssen, aber vorerst gilt: It’s a free ride!!

Wie funktioniert Telekom Tropo

Im Prinzip hinterlege ich bei Telekom Tropo eine URL, die im Falle eines Anrufs aufgerufen wird. Weiterhin kann ich Aktionen auslösen, in dem ich dem Telekom Tropo Server einen Call schicke. Dabei handelt es sich immer um JSON, das ausgetauscht wird.

Das alles ist hervorragend erläutert in der Produkt-Dokumentation (Achtung: Englisch) https://www.developergarden.com/fileadmin/microsites/ApiProject/Dokumente/Dokumentation/Api_Doc_4_0/telekom-api-tropo-1.0/html/index.html

Das JSON Format ist trivial. Mal ein kleines Hello-World-Beispiel

Wie man sieht wird das say-Verb aufgerufen. Dem kann ich Text (der wird dann vorgelesen) oder auch Links auf Dateien zum vorspielen mitgeben. Alle zur Verfügung stehenden Verben gibt es hier.

Um das Leben einfacher zu machen (und dass man nicht JSON auswendig lernen muss), gibt es vorgefertigte SDKs.

Erste Schritte mit PHP

Für Tropo gibt es eine PHP SDK. Damit ist das eigentlich nicht weiter problematisch.

Erste Schritte mit Python

Auch für Python gibt es eine entsprechende SDK.

Viele weitere Beispiele finden sich oben genannter Doku. Also einfach mal ausprobieren…

CU

0xff

 

 

 

Telekom Tropo – Nummer zur App zuordnen

Hi…

[Update: Wir haben diesen Prozess erheblich vereinfacht. Werde in Kürze einen neuen Artikel dazu veröffentlichen!!!]

ich hatte ja bereits zum Thema Tropo kurz mal was geschrieben. Jetzt machen wir mal weiter und klären wie ich denn jetzt eine entsprechende Telefonnummer zugeteilt bekomme.

Das Alles läuft auf dem Developer Center der Telekom. Hier werden alle Dinge gemacht, die direkt APIs betreffen.

Vorbereitung:

Für eine deutsche Telefonnummer braucht man den Scan eines amtlichen Lichtbild-Ausweises.

Schritt 1: Nach dem Einloggen, oben auf den Reiter Telekom Tropo API klicken. Dann auf Neue Anwendung erstellen.

Schritt 2: Die Anwendung braucht einen Namen (hier DemoDemo) und eine URL. ACHTUNG: Das http:// vorne nicht vergessen! Unter dieser URL wird dann der JSON Code abgefragt, wenn jemand Eure Nummer wählt. Die Umgebung kann Entwicklung oder Produktion sein. Bei Produktion gibt es keine Einschränkungen, es werden aber Kosten abgerechnet. Bei Entwicklung gelten 10 Minuten Grenzen. Dann auf Speichern.

Schritt 3: Ihr landet auf diesem Formular. Hier könnt Ihr bereits einige wichtige Dinge sehen: Die SIP Adresse, Tokens für ausgehende Verbindungen. In der Mitte ist ein Hyperlink zum Beantragen einer neuen Telefonnummer. Da klicken wir jetzt mal drauf…

Schritt 5: Im oberen Drop-Down-Feld kann man sich aussuchen, in welchem Land Eure Nummer beheimatet sein soll. Jedes Land auf der Welt ist eigentlich danach ganz easy, nur Deutschland nicht 😉

Also wählen wir mal Deutschland (GERMANY) aus. Daraufhin könnt Ihr eine Stadt auswählen. ACHTUNG: Diese Stadt muss mit Eurem Wohnsitz übereinstimmen!! Dies ist keine Schikane sondern deutsches Gesetz. Wohnt Ihr auf dem platten Land oder wollt Eure Vorwahl da nicht drin haben, dann bitte +49 3222 auswählen. Dies ist eine Vorwahl, die nicht mit einem konkreten Ort verbunden ist. Dann klicken wir mal weiter…

Schritt 6: Mit jeder Telefonnummer in Deutschland MUSS eine Person und Adresse verbunden sein. Daher muss auch ein Bild des Personalausweises (bei juristischen Personen ein entsprechender Nachweis) angehängt werden. Gesetz ist Gesetz und ich verstehe immer besser, was Rene Obermann meint, wenn er sagt, der Telekommunikationssektor sei überreguliert.

Also im folgenden Feld den Scan der entsprechenden Papiere hochladen.

Schritt 7: Call me maybe…

Sobald Euch die Nummer zugewiesen wurde, findet Ihr diese auf der Applikationsübersicht. Dazu einfach im Developer Center – Telekom Tropo API – Eure Applikation anklicken.

Happy calling…

CU

0xff

 

 

 

We are hiring…

Hi…

Junior Product Manager

Entrepreneur in einem Startup im Bereich Software Developer und Mobile Devices in einem globalen Unternehmen… fehlt noch ein Buzzword?? Dagegen ist jedes Trainee-Programm Kindergarten. Wer das Ding im Lebenslauf hat, sticht theoretische MBA-Schönlinge mit 5 Jahren Erfahrung im Beratungsunternehmen. Wer diesen Job macht, hat Spaß, Abenteuer, den Tanz der Kulturen, lernt Menschen kennen, lebt an der Bleeding-Edge-of-Technology, versteht was B2B2X wirklich heißt, braucht keine Drogen, lernt Miss Bridgestone persönlich (!!) kennen, baut Projekte, wird berühmt, hat ein Team-Interview überlebt, ist sportlich, kann Sonnenaufgänge wieder genießen, spielt mit Chuck Norris Fernschach, kann erklären was B2B2X wirklich heißt, trägt abgewaschene T-Shirts mit Werbung für Technologie, die es noch gar nicht zu kaufen gibt…

All das ist nur einen Klick weit weg…

https://jobwelt.telekom.com/jpapps/n/ext/jv/,00011896

So, jetzt Du…

CU

0xff