Allgemein

Eigene Skills für Amazon Echo und Alexa entwickeln

2. März 2017 Allgemein, Amazon Echo, AWS, Blog, Javascript No comments , , , , , , , , , , ,

Bild von Amazon Echo Dot 2

Was ist eigentlich Amazon Echo und Alexa

Das Thema Smarthome und künstliche Intelligenz zieht zunehmend auch in unsere Haushalte ein. Besonders für Programmierer ist das ein Grund sich mit den neuen Systemen auseinander zu setzen.
Als ein Assistenzsystem für Smarthome und künstliche Intelligenz findet sich seit geraumer Zeit Amazons Echo mit der Sprachassistentin Alexa.

Amazons Echo ist ein kleiner W-Lan Lautsprecher in welchem außerdem noch ein Mikro mit Fernfeldaufnahmemöglichkeit etwas Licht und einige Buttons verbaut sind. Damit ist es dem Gerät möglich über Spracheingaben verschiedene Anfragen zu stellen. Die Kommunikation mit dem Gerät wird wahlweise über die Wörter „Alexa“,“Echo“ oder „Computer“ gestartet und kann durch „Stop“ an jedem beliebigen Punkt beendet werden. Die Fähigkeit von Amazons Echo Geräten auf die Anfragen zu reagieren bezeichnet Amazon als „Skills“ die über einen speziellen Store hinzugefügt werden können um euer Gerät um neue Funktionen zu erweitern.

Wir haben euch oben den Amazon Echo Dot verlinkt. Dieser ist die kleine Version vom Amazon Echo und besitzt lediglich einen kleineren Lautsprecher ist damit aber wesentlich günstiger und ihr könnt ihn trotz allem mittels Auxkabel oder Bluetooth mit euren bestehenden Lautsprechern verbinden.

Die Entwicklung eures Skills

Wenn ihr diesen Artikel offen habt wisst ihr aber sicher schon einiges über Amazons Echo und besitzt wahrscheinlich sogar schon ein Gerät. Um das Thema eigene Skills zu programmieren geht es heute.

Vorausetzungen

Welche Kenntnisse ihr hierfür mitbringen solltet:

  • Kenntnisse mit JavaScript
  • Kenntnisse mit NodeJS
  • grundlegendes Verständniss von Serverkommunikation und JSON
  • grundlegende Englischkenntnisse

Als Vorraussetzung benötigt ihr zunächst einen Account bei developers.amazon.com und bei aws.amazon.com. Für den zweiteren wird zur Anmeldung eine Kreditkarte benötigt aber der Account ist das erste Jahr kostenfrei und kann danach auch gekündigt werden.

Wichtig ist das der Account bei developers.amazon.com der gleiche sein sollte mit welchem euer Echo verknüpft ist, denn so könnt ihr die Skills mit eurem Gerät testen und müsst diese nicht in den Store stellen. Zum testen eures Skill benötigt ihr übrigens kein Echo denn Amazon bietet eine Testumgebung um das Verhalten eures Skills zu simulieren.

Der Code für euren ersten Hallo Welt Skill

Der gesamte Code für dieses kleine Projekt kann auch über GitHub abgerufen werden:
Watch

Die Skills für den Amazon Echo werden im Amazon Lambda Service hinterlegt und mit NodeJS programmiert.
Dabei besteht die JavaScript Datei für Lambda aus verschiedenen Abschnitten.
Sie beginnt zunächst mit einem try-catch welches den Request überprüft und gegebenenfalls in bestimmte Funktionen springt um diesen zu verarbeiten.
Falls ein ungültiger Request eingeht wird die Lambda Funktion dann abgebrochen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
'use strict';
 
exports.handler = function (event, context) {
    try {
        console.log("event.session.application.applicationId=" + event.session.application.applicationId);
 
        if (event.session.new) {
            onSessionStarted({requestId: event.request.requestId}, event.session);
        }
 
        if (event.request.type === "LaunchRequest") {
            onLaunch(event.request,
                event.session,
                function callback(sessionAttributes, speechletResponse) {
                    context.succeed(buildResponse(sessionAttributes, speechletResponse));
                });
        } else if (event.request.type === "IntentRequest") {
            onIntent(event.request,
                event.session,
                function callback(sessionAttributes, speechletResponse) {
                    context.succeed(buildResponse(sessionAttributes, speechletResponse));
                });
        } else if (event.request.type === "SessionEndedRequest") {
            onSessionEnded(event.request, event.session);
            context.succeed();
        }
    } catch (e) {
        context.fail("Exception: " + e);
    }
};

Nach der Überprüfung des eingehenden Requests folgen die Definitionen unserer Funtionen. Zu allererst definieren wir eine funktion in welcher wir die Session starten in der unser Nutzer mit Alexa kommuniziert. Die Nutzung der Session ermöglicht es uns werte über mehrere Fragen und Antworten weiter zu geben und ein regelrechtes „Gespräch“ mit dem Gerät aufzubauen. Diese Funktion wird beim ersten Aufruf unseres Skills ausgeführt (siehe oben – if (event.session.new) )

31
32
33
34
function onSessionStarted(sessionStartedRequest, session) {
    console.log("onSessionStarted requestId=" + sessionStartedRequest.requestId
        + ", sessionId=" + session.sessionId);
}

Nun folgt die eigentliche Start Funktion diese wird definiert um dem Nutzer ein Feedback zu geben falls er unseren Skill startet ohne Anweisungen zu geben.

35
36
37
38
39
40
41
42
43
function onLaunch(launchRequest, session, callback) {
    console.log("onLaunch requestId=" + launchRequest.requestId
        + ", sessionId=" + session.sessionId);
 
    var cardTitle = "Hallo Welt"
    var speechOutput = "Sage Hallo Welt um Hallo Welt als Antwort zu bekommen!"
    callback(session.attributes,
        buildSpeechletResponse(cardTitle, speechOutput, "", true));
}

Die für uns wichtigste Funktion ist die hier als onIntent() bezeichnete. Diese wird immer ausgeführt wenn der Nutzer ein Kommando für einen Intent gibt.
Beim ausführen wird dann abgefragt um welchen Intent es sich handelt und auf die passende Funktion referenziert was aufgrund des Intents zu tun ist.

44
45
46
47
48
49
50
51
52
53
54
55
56
57
function onIntent(intentRequest, session, callback) {
    console.log("onIntent requestId=" + intentRequest.requestId
        + ", sessionId=" + session.sessionId);
 
    var intent = intentRequest.intent,
        intentName = intentRequest.intent.name;
 
    if (intentName == 'HalloIntent') {
        handleHalloWeltRequest(intent, session, callback);
    }
    else {
        throw "Invalid intent";
    }
}

Die Funktion onSessionEnded haben wir für das beenden der Session definiert und geben hier lediglich der Konsole die Informationen zur beendeten Session aus.
Hier kann später auch noch Logik eingebaut werden um Beispielsweise ein letztes mal eine API anzusprechen.

58
59
60
61
function onSessionEnded(sessionEndedRequest, session) {
    console.log("onSessionEnded requestId=" + sessionEndedRequest.requestId
        + ", sessionId=" + session.sessionId);
}

In Zeile 51/52 Referenzieren wir im Falle des ‚HalloIntent‘ nun auf folgende Funktion in welcher mit unserer Hilfsfunktion ein Response an den Amazon Echo erstellt wird.

function handleHalloWeltRequest(intent, session, callback) {
    callback(session.attributes,
        buildSpeechletResponseWithoutCard("Hallo, Welt!", "", "true"));
}

Zum generieren eines Response an den Amazon Echo haben wir uns zwei Helfsfunktionen angelegt. Diese unterscheiden sich lediglich darin, wie der Response übergeben wird.
Amazon Echo kann zum einen einfach nur einen Text ausgeben der gesprochen wird.
Es gibt aber auch die Möglichkeit dem nutzer auf seinem Mobiltelefon innerhalb der Alexa App eine Karte mit weiteren Informationen anzuzeigen.

66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
function buildSpeechletResponse(title, output, repromptText, shouldEndSession) {
    return {
        outputSpeech: {
            type: "PlainText",
            text: output
        },
        card: {
            type: "Simple",
            title: title,
            content: output
        },
        reprompt: {
            outputSpeech: {
                type: "PlainText",
                text: repromptText
            }
        },
        shouldEndSession: shouldEndSession
    };
}
 
function buildSpeechletResponseWithoutCard(output, repromptText, shouldEndSession) {
    return {
        outputSpeech: {
            type: "PlainText",
            text: output
        },
        reprompt: {
            outputSpeech: {
                type: "PlainText",
                text: repromptText
            }
        },
        shouldEndSession: shouldEndSession
    };
}
function buildResponse(sessionAttributes, speechletResponse) {
    return {
        version: "1.0",
        sessionAttributes: sessionAttributes,
        response: speechletResponse
    };
}

Den JavaScript Code für den HalloWelt Skill in Lambda einbinden

Den im vorherigen Abschnitt erklärten Code müssen wir nun bei Amazon Web Services im Lambda Service als Funktion einrichten. Dazu melden wir uns unter
aws.amazon.com an gehen auf die Region Europa/Irland und dann auf den Service Lambda.

Startseite von Amazon Web Services

Wir wählen hier den Service Lambda über die Suche oder das Menü aus.

Übersichtseite von AWS nach der Anmeldung

Nun Kommen wir auf die Oberfläche der Lambdaverwaltung und wählen hier unter Functions -> Create a Lambda function aus um eine neue Schnittstelle für unseren Skill anzulegen.

Konfigurationsoberfläche für AWS Lambda

Im folgenden Dialog bietet sich dem Nutzer nun die Möglichkeit, zwischen verschiedenen Blaupausen zu wählen. Dies ist für uns nicht notwendig so das wir die Option „Blank Function“ wählen und fortfahren.

Blaupausenauswahl von AWS Lambda

Im nächsten Schritt konfigurieren wir den Auslöser für unsere Schnittstelle. Hierbei Klicken wir in das punktierte Quadrat und wählen „Alexa Skills Kit“ um unsere Lambda Funktion durch Alexa steuerbar zu machen.

Schalterkonfiguration von Lambdafunktionen

Nun werden wir nach der Konfiguration für unsere Funktion gefragt. Im obersten bereich vergeben wir einen einzigartigen Namen und wählen als Runtime „Node.js 4.3“ aus.
Darunter folgt außerdem der JavaScript Code welchen wir oben besprochen haben und welcher außerdem in der GitHub Repo in der Datei index.js zu finden ist.

Konfiguration der Lambdafunktion

Zur weiteren Konfiguration gehört dann auch noch die Auswahl der Rolle die Lambda ausführt. Solltet ihr noch keine Nutzerrolle angelegt haben So legt so wählt „Create new role“ ansonsten wählt eure „lambda_basic_execution“ Rolle aus. In den Erweiterten Einstellungen solltet ihr dann noch den Timeout auf 10 Sekunden anpassen.

Weitere Konfiguration der Lambdafunktion

Wenn ihr fertig seid und alles bestätig habt findet ihr eine Übersicht eurer Funktion. In der oberen rechten Ecke findet sich dann außerdem die ARN. Die Zeichenkette hinter ARN: benötigt ihr dann für euren Alexa Skill damit dieser ein Ziel hat welches er ansteuert. Notiert euch diese deshalb oder kopiert sie in die zwischenablage

Lambda Funktion in der Übersicht nach Erstellung

Den Alexa Skill bei Amazon Developers einrichten

Die eben angelegte Lambda Funktion kann nun in einen Amazon Alexa Skill eingebunden werden. Aus diesem Grund loggen wir uns auf developers.amazon.com ein oder legen hier einen Account an.
Wir gehen dann auf den Link Alexa und wählen den Punkt „Alexa Skills Kit“ aus.

Alexa Menü bei Amazon Developers

Um nun unseren Hallo Welt Skill anzulegen wählen wir „Add a New Skill“ und werden zur Oberfläche zum Anlegen eines Skills für Alexa geleitet.

Übersicht im Alexa Skills Kit

Für unseren Skill und die meisten allgemeinen Skills nutzen wir folgende Einstellungen:
Skill Type : Custom Interaction Model
Language : German
Name : HalloWelt
Invocation Name : Hallo Welt (Achtung der Invocation Name darf nicht aus einem Wort bestehen wenn ihr den Skill in den Store einreichen wollt)
Audio Player : no

Haben wir alle Einstellungen gesetzt gelangen wir über „Next“ zur nächsten Oberfläche

Oberfläche zum Anlegen eines Skills - Skill Informationen

Unter dem Menü zum Interaction Modal spielt sich die restliche Konfiguration für Alexas Logik unseres Skills ab.
Zum einen finden wir hier das Intent Schema : Dieses definiert welche Intents als welche Interaktionsräume es mit Alexa gibt und welche Slots spricht werte darin übertragen werden können. Außerdem können wir für den Slot auch eigene Datentypen anlegen was für diese Anleitung aber erstmal unrelevant ist.

Oberfläche zum Anlegen eines Skills -Intent und Interaktionseinstellungen

In das Feld Intent Schema folgen wir nun folgende Inhalte ein (GitHub: intent_schema.json):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{
   intents: [
              {
                 intent: "HalloIntent"
              },
              {
                 intent: "HalloNameIntent",
                     slots: [
                              {
                                name: "PersonName",
                                type: "AMAZON.DE_FIRST_NAME"
                              }
                            ]
              }
            ]
}

Das Intentschema unserer Anwendung sagt aus das es Zwei Interaktionsräume geben soll: den „HalloIntent“ und den „HalloNameIntent“. Außerdem enthält der „HalloNameIntent“ einen slot namens „PersonName“ vom Typ „AMAZON.DE_FIRST_NAME“.

Außerdem werden unter Sample Utterances die Aufrufe angegeben wie der Nutzer mit Alexa und unserem Skill interagiert.
Die Sample Utterances sind immer nach dem Schema aufgebaut – IntentName Nutzeranweisung {SlotWert}
In unserem Fall sieht das ganze wie in der GitHub Repo in sample_utterances.conf aus:

1
2
3
4
5
6
HalloIntent Hallo Welt
HalloIntent Hi Welt
HalloIntent Guten Morgen Welt
HalloIntent Wie geht es Welt
HalloNameIntent Hallo Welt ich bin {PersonName}
HalloNameIntent Hi Welt ich bin {PersonName}

Oberfläche zum Anlegen eines Skills - Ausgefüllte Interaktionsinformationen

Sind wir Fertig klicken wir auf Next und kommen zum Konfigurationsfeld. Hier wählen wir als Endpunkt AWS Lambda und als Region Europa aus. In das Feld ARN fügen wir außerdem die ARN Nummer aus der vorherigen Konfiguration in Amazon Lambda ein

Oberfläche zum Anlegen eines Skills - Endpunkt Konfiguration

Nun ist unser Skill bereit zum Testen. Über den folgenden Dialog aktivieren wir den Skill zum testen in unserem Account. Das ermöglicht, das wir den Skill durch unsere Mailadresse mit unserem Echo Gerät nutzen und testen können ohne das wir ihn veröffentlichen.
Im Abschnitt Service Simulator können wir unter „Enter Utterance“ simulieren was wir zum Echo sagen und bekommen im Feld Service Response angezeigt was unsere Lamda Schnittstelle zurückgibt.

Oberfläche zum Anlegen eines Skills - Testumgebung

Fazit

Abschließend ist eigentlich nur zu sagen als Entwickler macht es richtig Spaß die Skills für Amazons Echo oder Echo Dot zu Entwickeln. Über die einzelnen Services kann mit mit vernünftigem Wissen in JavaScript schnell erste Skills entwickeln und diese immer mehr Erweitern. Auch das Gerät selber punktet mit zunehmend coolen Funktionen und erleichtert einem den Alltag durch Funktionen wie den Wetterbericht oder Nachrichten. Einfach nur cool!

Die nächsten Wochen folgt übrigens ein weiterer Artikel zum Thema „Skills mit HTTP/HTTPS Requests um Schnittstellen anzusteuern“ darin wird noch einmal gezeigt was ihr beachten müsst um einen Skill zu bauen der auch eine API oder sonstiges ansteuern kann.


Twig & localizeddate() – Darstellung bzw. Konvertierung eines Datums anhand des Symfony-Locales

19. Januar 2017 Allgemein, Blog, Log, Symfony No comments ,

Nutzung des „date()“-Filters in Twig

Anwendungsfall:
Beim Rendering eines Twig-Templates durch einen Controller in Symfony wird ein Objekt vom Typ „DateTime“ an das Template übergeben. Das Datum soll innerhalb des Templates dargestellt werden.

Lösung:
Auf das Objekt vom Typ „DateTime“ wird ein Twig-Filter angewandt:

1
{{ newspaper.dateOfIssue | date('m.F Y') }}

Dies ergibt beispielsweise die Darstellung von 01.December 2008. Die Ausgabe erfolgt standardmäßig mit „en_EN“ (Locale) unabhängig davon, ob in der config.yml von Symfony ein anderer Locale-Wert gesetzt wurde.

Anzeige des Datums mit gezielter Sprache unter Verwendung von localizeddate()

Möchte man nun die Ausgabe des Datums an den vorliegenden Locale-Wert von Symfony anpassen, so kann man folgende Anpassung vornehmen:

(alt)

1
{{ newspaper.dateOfIssue | date('m.F Y') }}

(neu)

1
{{ newspaper.dateOfIssue | localizeddate('long', 'none', app.request.locale, NULL, 'dd.MMMM Y') }}

Was hat sich geändert?
Der Filter date() wird durch localizeddate() ersetzt. Dieser kann mehrere Argumente zur Darstellung der Anzeige entgegennehmen. Wichtig für o.g. Beispiel ist der Bezug auf den Loacale-Wert der Symfony-Awendung mit „app.request.locale“ und die entsprechende Formatierung „dd.MMMM Y“. Die Formatierung des Datums mittels „localiceddate()“ unterscheidet sich vom Filter „date()“.

Bei der Anwendung von „date()“ kann bei der Formatierung diese Übersicht verwendet werden. Beim Einsatz von „localiceddate()“ ist diese Formatierungs-Übersicht zu verwenden. Welche Argumente beim „localizeddate“-Filter verwendet werden können, ist der Übersicht Argumente localizeddate zu entnehmen.

Voraussetzungen für den localizeddate mit Twig und Symfony

Für die Vermeidung von Fehlermeldungen wie:

Attempted to load class „Twig_Extensions_Extension_Intl“

oder

An exception has been thrown during the rendering of a template
(„The Symfony\Component\Locale\Stub\StubIntlDateFormatter::__construct() method’s argument $locale value ‚en_IN‘ behavior is not implemented. Only the ‚en‘ locale is supported.

sind Twig-Extensions und Symfony-Intl in das Projekt einzubeziehen. Diese können via Composer mit:

composer require twig/extensions
composer require symfony/intl

installiert werden. Weiterhin ist die services.yml um folgende Zeilen zu ergänzen:

1
2
3
4
    twig.extension.intl:
        class: Twig_Extensions_Extension_Intl
        tags:
            - { name: twig.extension }

Auf dem entsprechenden System (bei mir Ubuntu + php7) ist php7.0-intl zu installieren. Dies ist eine Erweiterung (Extension) für Internationalisierungen (siehe php.net). Die Installation erfolgt mit:

sudo apt-get install php7.0-intl

Damit kann „localizeddate()“ nun grundsätzlich wie in o.g. Beispiel angewandt werden. Der Cache von Symfony ist anschließend zu leeren und der Anwendungsserver neu zu starten.


Werbeanzeige:
extending_symfony2
Extending Symfony 2 Web Application Framework
[Author: Sebastien Armand]

2017! Was euch hier erwartet

3. Januar 2017 Allgemein, Blog No comments , ,

Zunächst einmal wünschen wir euch ein gesundes neues Jahr. Viel Glück und vor allem ganz wenige Bugs.
Doch nun zum eigentlichen Thema: Was erwartet euch auf programmers-log.net dieses Jahr.

Wir wollen uns dieses Jahr unter anderem einer neuen Kategorie auf unserer Website widmen und diese lautet: Arduino !
Vom Kauf des ersten Arduino über die verschiedenen Arduino Boards bis hin zu kleinen und großen Projekten mit dem fantastischen Mikrocontroller Board. Ihr bekommt von uns
gut erklärte Anleitungen inklusive den Links zu Shops wo ihr Arduinos und alle Teile erwerben könnt.
Außerdem könnt ihr gerne Projektwünsche über die Kommentarfunktion äußern und wir setzen ausgewählte Ideen zum Thema Arduino um.
Ist das nicht super ?!

Schaut einfach vorbei unter:
Kategorie: Arduino

Natürlich widmet sich aber auch dieses Jahr unser Log vor allem den Problemen und deren Lösungen auf die wir während unserer Arbeit immer wieder stoßen.
Also besucht uns fleißig.

Eure Coder Micha und Robert

Symfony – Fehlermeldung (Prod Environment) 500 Internal Server Error

21. September 2016 Allgemein, Blog, Log, PHP, Symfony No comments , ,

Symfony Internal Server Error 500 Titelbild

Man freut sich vielleicht gerade eine Anwendung fertig gestellt zu haben, will diese nun Online bringen und plötzlich meldet sich ein 500 Internal Server Error.
Häufig kommt es vor, das sich die Bildschirmausgabe des Webprojektes in der Entwicklungsumgebung ( Dev Environment ) von der Produktiv-Umgebung (Prod Environment) unterscheidet.

Beim Entwickeln überprüft man die Anwendung z.B. via Webbrowser
http://localhost:8000/unterseite/artikel

wenn o.g. URL nun wie folgt erweitert wird:

http://localhost:8000/app.php/unterseite/artikel (entscheidend ist hierbei app.php)
kann getestet werden, wie sich die Anwendung mit Prod-Environment (Produktiveinsatz) verhalten würde. Ist optisch und funktional alles wie beim 1. Link, so ist dies ein gutes Zeichen und die Anwendung ist bereit Online zu gehen.

Warum verhalten sich beide Aufrufe unterschiedlich?

Dies kann zum einen auf die Anwendungskonfoguration zurückzuführen sein, welche ggf. für das Dev-Environment ausgelegt ist oder man nutzt innerhalb der Entwicklung Module von Symfony, die lediglich für den Entwicklungsprozess gedacht sind und live bzw. im Prod-Environment nicht zur Verfügung stehen.

Triviales Beispiel für die Erzeugung eines 500 Internal Server Error – kein dump im Prod

Beim Entwicklungsprozess wird ggf. des Öfteren auf die dump-Funktion von Symfony zurückgegriffen um sich Inhalte während der Datenverarbeitung anzeigen zu lassen.
Der Dump von Inhalten funktioniert hierbei sowohl aus einem Twig-Template oder auch über einen der Controller.
Dies ist für die Entwicklung sehr nützlich, jedoch für die online geschaltete Webanwendung sehr gefährlich. Angenommen die Dumps werden nicht entfernt (Vergesslichkeit), dann würden die Ausgaben einem zukünftigen Betrachter der Webanwendung interne Strukturen offen legen, also ein gefundenes Fressen für potentielle Angreifer. Daher steht die dump-Funktion nur im dev-Environment und nicht im prod-Environment zur Verfügung.

Symfony Prod Error Log – Informationen zum Fehlverhalten der Website auslesen

Angenommen die Live geschaltete Anwendung wirft nun ein 500 Internal Server Error oder andere Fehlermeldungen, so quittiert Symfony diese innerhalb eines Logfiles ( dieses findet man unter app/logs/ ).

Eine Eintrag aus dem Logfile könnte wiefolgt aussehen:
[2016-07-20 14:28:16] request.CRITICAL: Uncaught PHP Exception Symfony\Component\Debug\Exception\UndefinedFunctionException: „Attempted to call function „dump“ from namespace „AppBundle\EventListener“.“ at /home/micha/git/Simplicando/src/AppBundle/EventListener/ContentUpdateListener.php line 27 {„exception“:“[object] (Symfony\\Component\\Debug\\Exception\\UndefinedFunctionException(code: 0): Attempted to call function \“dump\“ from namespace \“AppBundle\\EventListener\“. at /home/micha/git/Simplicando/src/AppBundle/EventListener/ContentUpdateListener.php:27)“} []

Beim betrachten der Log-Line stößt man nun auf UndefinedFunctionException(code: 0): Attempted to call function \“dump\“. Dies bedeutet das ein Ausnahmefehler (Exception) geworfen wird weil die dump-Funktion nicht exisitert.

Was kann man gegen den Error machen?

Das zuvor gennante Beispiel zeigt, das Dumps in im Prod-Environment nicht funktionieren. Die Anwendung muss daher auf den Einsatz dieser Ausgaben geprüft werden. Entfernen / auskommentieren und erneut testen, ob der Internal Server Error bestehen bleibt.

Handelt es sich nicht um o.g. Szenario, so ist die Ursache so pauschal nicht zu ermitteln und benötigt ggf. Untersuchungen des Quellcodes oder der Konfiguration.
Zunächst ist es jedoch Sinnvoll sich einen Überblick über die Fehlermeldungen (HTTP-Status Codes) zu verschaffen. Eine Liste mit allen Status-Codes ist hier zu finden.

So kann das Problem zumindest schon mal grob eingegrenzt werden (z.B. Inhalt nicht gefunden Error 404 oder einer 500er Meldung). Weiterhin sollten die Error-Logs unter /app/logs (Symfony Nutzer) oder Log-Files Ihres Webservers betrachtet werden. Es ist erstaunlich, wie schnell man dem Fehler durch die Log-Files auf die Schliche kommt.

Literaturempfehlung für den Umgang und Erweiterung von Symfony

Werbeanzeige:
extending_symfony2
Extending Symfony 2 Web Application Framework
[Author: Sebastien Armand]

Unser Besuch zum AWS Summit Berlin 2016

15. April 2016 Allgemein, Blog, Events No comments , , , , , , , ,

Veranstaltungspass AWS Summit Berlin 2016

Montag 11. April 2016, 14 Uhr

Wir fahren unsere Rechner runter. So früh ? Ja, denn wir machen uns auf den Weg nach Berlin zum AWS Summit 2016.
Ab ins Auto und schon geht es los. Unser Hostel liegt mitten in Kreuzberg in einem gemütlichen Hinterhof. Unser Zimmer erstrahlt in den Farben Blau, Weiß und rot. Es ist das UK Zimmer.
An der Wand lächelt uns die Queen an.

Da der AWS Summit ja erst am nächsten Tag machen wir uns auf dem Weg und erkunden die Gegend und das Veranstaltungsgelände.
Die Veranstaltung soll in der Station Berlin stattfinden, eine ehemalige Fabrikhalle und würdige Location für das Event.
Als wir Abends vor dem Gebäude ankommen ist schon einiges Los. Überall finden sich bereits Amazon Logos, Bühnen werden aufgebaut.

Wir sind gespannt auf den nächsten Tag!


Dienstag 12. April 2016, 6 Uhr

Es geht früh aus den Federn denn heute ist es soweit, AWS Summit Berlin 2016.
Wir machen uns frisch und treten unseren Weg zur Station Berlin an.

Es ist einfach beeindruckend! Alles ist bunt und hell beleuchtet. Im Eingangsbereich legt ein DJ auf.
Wir geben unsere Jacken an der Garderobe ab und es geht zum Check-In.
Hier erhalten wir einen Veranstaltungspass.

In der Exibition-Area präsentieren sich alle Sponsoren des Events mit einem Stand.
Am Buffet schnappen wir uns ein Croissant und eine Cola und beginnen die Erkundungstour.
Uns war beiden klar das dies ein großes Event ist, doch wir hätten nicht gedacht das es so groß ist.
Bei den Ständen sind uns bekannte Firmen wie „RedHat“ oder „Intel“ vertreten. Aber auch uns noch fremde Firmen wie zum Beispiel „ctera“.

Um 9 war es dann so weit die Keynote mit Werner Vogels CEO von Amazon. Es war einfach bombastisch.

Die Keynote Halle des AWS Summit Berlin 2016

Nach der Keynote geht es auf zu den Workshops und Events des Tages. Mehr als 40 Vorträge zu Themen rund um Cloudcomputing, vernetzte Technologien und alles was man mit AWS erreichen kann.

Neben Vorträgen und Workshops besteht außerdem die Möglichkeit mit einem Experten über unser System zu reden und uns Tipps geben zu lassen.
Hier haben wir die Möglichkeit Todd von Amazon Luxemburg nach Lösungsansätzen zu unserer Architektur zu fragen.
Nachdem wir nun zahlreiche Tipps erhalten haben besuchen wir noch einige Workshops und dann machen wir uns auf dem Weg zurück ins Hostel.

Doch das soll noch nicht das Ende gewesen sein.

Gegen 17.30 geht es zurück zum AWS Summit. Wir lauschen gespannt der Abschluss Keynote von Werner Vogels in welcher er allen Zuhörern einige Tipps mitgibt welche er in seiner langjährigen Erfahrung gesammelt hat:

  1. Build evolvable Systems. Something that never have to go down to do Upgrades.
  2. Expect the unexpected.
  3. Primitives not Frameworks
  4. Automation is the key. Protect against your own failures and use API’s
  5. API’s are forever, for you and your costumers.
  6. Know your resource usage.
  7. Build security in from the ground up.
  8. Encription is a first class citizen.
  9. Importance of the Network.
  10. Reduce your blast radius.
  11. Scale on DAY ONE
  12. Know the difference between accounts and identity.

Nach diesen ewertvollen Tipps machen sich alle auf zum Abschlussevent.

Es gibt Drinks und Livemusik.

Izzy Bizu beim AWS Summit Berlin 2016

Izzy Bizu performt zum Abschlussevent beim AWS Summit Berlin 2016 unter anderem ihren Song „White Tiger“

Auf der Bühne genießen wir die Soul, Pop und R&B geprägte Musik von Izzy Bizu.

Wir genießen den Abend und die Cocktails.

Nach Izzy Bizu gibt es noch etwas Musik vom DJ.

Gegen Mitternacht treten wir dann den Heimweg an. Wir sind immer noch begeistert von diesem wahnsinnigen Event.

 


Wir können es jedem nur empfehlen einmal an einem AWS Summit teilzunehmen.

Der nächste große AWS Summit findet am 30. Juni 2016 in Frankfurt statt.
Eine Liste aller AWS Summits findet ihr unter : https://aws.amazon.com/summits/