As Swagger documentation files tend to get real large und hard too read, splitting the config across multiple files might be a good idea.
With $ref you could do this quite easily.

For example you could reference a single config file per path like so:

swagger: "2.0"
basePath: "my-api/v1/"
info:
  version: "0.0.1"
  title: "my API"
tags:
  - name: "section1"
    description: "Some Section"
  - name: "section2"
    description: "Some other Section"

paths:

  ##section 1

  /section1/some/path:
    $ref: 'paths/section1_some_path.yml'

  /section1/some-other-path:
    $ref: 'paths/section1_some_other_path.yml'

Then have all actions for this path defined in a dedicated file like this:

paths/section1_some_path.yml:

post:
  tags:
  - "section1"
  parameters:
    ...

This really helped me managing larger documentation files, which otherwise tend to get quite hard to read.

As I moved the code to github this week, I wanted to give a quick overview of the project and its technical underlyings, just in case someone might be interested :)

As the title of this post might already suggest, its about selecting and layering loops from audiofiles hosted on soundcloud.com and thereby creating new music.

Those collections of layered loops are called a session. Sessions can be created anonymously by everyone and are auto-saved on every action. By distributing the URL of a session other users can join and every action is synced between all users in realtime.
(complete mayhem, indeed :)

The application is built with HTML5 and JS w/ jQuery using the soundcloud API on the client side and runs on node.js & mongoDB with express, socket.io and mongoose on the server side.

I basically started the project to find out if you could play multiple loops asynchronous and synced with low latency using the Web Audio API while collaboratively working together with multiple users in realtime. 

As that turned out to be not only possible but performed real nicely, the experiment then developed in somewhat of an application and finally got a name and a face.

There’s a whole lot of things i’d like to implement / refactor and do when i get some time on my hands, as

– adding a “record” feature to record, save and export created sessions as audiofiles

– rewriting the client side with backbone.js (as things got a bit messy …)

– adding some audio effects to the tracks

– write some tests

I’d appreciate any form of contribution as much as any questions or feedback on the project :)

Feel free to check out the live version at  http://mashcloud.net/ or the sources at https://github.com/gherkins/mashcloud

Heute möchte ich einen alternativen, vielleicht pragmatischeren Ansatz als der andererer populärer Implementierungenn herbeispinnen, um Dependency Injection (DI) in PHP 5.3 zu realisieren.

Für diverse Programmiersprachen gibt es – auf den jeweiligen Anwendungsbereich mehr oder weniger spezialisierte – sogenannte Dependency-Injection (DI)-Container. Der DI-Container als solcher dient im Grunde als Manager oder Konfigurator, der das Zusammenspiel unserer Abhängigkeiten definiert – meist auf Grundlage einer Konfigurationsdatei, die bspw. in XML vorliegt:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">

  <bean id="..." class="...">
    <!-- collaborators and configuration for this bean go here -->
  </bean>

  <bean id="..." class="...">
    <!-- collaborators and configuration for this bean go here -->
  </bean>

  <!-- more bean definitions go here... -->

</beans>

(Quelle: Springsource)

Eine weitere Möglichkeit Abhängigkeiten zu definieren, bietet das Convention Over Configuration-Paradigma: Heißt bspw. eine Member-Variable “Mailservice”, so kann der zugrundeliegende DI-Container entsprechend konfiguriert werden, sodass bei Instanziierung automatisch eine Klasse gleichen Namens (Mailservice) instanziiert und an das Objekt gebunden wird (so macht’s bspw. Grails in seinen MVC-Controller-Instanzen, wobei hier natürlich wieder das Spring IoC (Das hat nichts mit dem internationalen olympischen Komitee zu tun, sondern ist die Abkürzung für “Inversion of Control” und steht gleichbedeutend für “Dependency Injection”). Diese Implementierung erfordert natürlich ausgereifte Introspektionsmechanismen der zugrundeliegenden Programmiersprache (Stichwort “Reflection“), außerdem muss man dem DI bzw. IOC-Container vorher beigebracht haben, welche Klassen oder Verzeichnisstrukturen überhaupt durchsucht und unter “DI-Kontrolle” gestellt werden müssen – ein zusätzlicher Programmieraufwand ist also immer noch gegeben. Unvorhersehbarkeiten im Code und eine erhöhte WTF’s/min-Rate kommen dabei frei Haus.

PHP bieted zu dem ganzen Thema ab Werk erstmal – nix. Die Reflection-API ist aber schonmal ein ausgereiftes Werkzeug, um definierte Abhängigkeiten auszuwerten. Das allerdings ausschließlich mittels lesendem Zugriff auf Metadaten von bspw. Klassen, Methoden oder auch System- bzw. benutzerdefinierten Funktionen. Schreibende Operationen sind im Sprachkern erst einmal nicht vorgesehen. Es ist also prinzipiell möglich, zur Laufzeit Abhängigkeiten durch Konvention zu definieren, die Auflösung selbiger ist aber “mit Boardmitteln” nicht zu realisieren.

Ein eigenes Sprachkonstrukt wie Mixins ist auch (noch) nicht implementiert, und anonyme (“Lambda“)-Funktionen lassen sich nicht wie in Javascript oder auch Groovy direkt an den Objekt-Prototypen hängen oder auch an einzelne Instanzen, sondern müssen mühsam “by reference” gezogen und dann erst ausgewertet werden.

Javascript:

  var foo = function() { }
  foo.prototype.bar = function() { return "bar"; }
  foo.baz = foo.prototype.bar;

  var foobar = new foo;
  foo.bar(); // -> "bar"
  foo.baz(); // -> "bar"

PHP:

  $foo = new stdClass();
  $foo->bar = function() 
  {
    return "bar";
  }
  $foo->bar(); // method not found
   
  $bar = $foo->bar;
  $bar(); // -> "bar"

Zugegeben: Gäbe es bereits Mixins oder Prototypen im PHP-Kontext, wäre die Implementierung eines DI-Containers wohl eher unspannend, mindestens aber überflüssig. Dennoch fehlt eine zuverlässige Möglichkeit, PHP-Instanzen zur Laufzeit mit neuen Methoden anreichern zu können. Daher gehen die meisten PHP-DI-Frameworks immer den Weg über einen recht aufgeblähten DI-Container. Dieser macht aber im Grunde nichts anderes, als Referenzen zu verwalten. Der Container selbst wird dann an die anzureichernde Instanz gebunden, im Idealfall eventuell aber noch via magischer Methode __call() verborgen. Dann aber muss die zu aufnehmende Instanz wiederum mindestens ein Interface “Injectable” o.Ä. implementieren. Letzlich aber passiert am Ende immer folgendes:

class myController extends Controller
{
  public function indexAction(HttpRequest $request)
  {
    $db = $this->getService('Database');
  }
}

Der Service-Container übernimmt also die klassische Aufgabe des “ApplicationContext”: Er managed Referenzen, rückt diese aber erst “on demand” heraus. Meiner Meinung hat man dabei nicht allzu viel gewonnen, vor allem, wenn das obige Codeschnippsel noch eine Menge Konfiguration, Code zum Bootstrappen des DI-Containers und/oder Caching voraussetzt.

Ich persönlich würde mir dann doch eher “ganz oldschool” ein paar getter/setter zusätzlich schreiben und mich einfach darauf verlassen, dass der gute, alte ApplicationContext sowieso (fast) alles enthält, was ich brauch’, mit der Konsequenz, dass dieser eben nicht gerade leichtgewichtig ist.

Wozu also das ganze?

Ein alternativer DI-Container mit Doctrine 2 Annotations und Runkit

Die Annotations-Implementierung von Doctrine 2 ist einfach und mächtig genug, um eine beliebigen Klasse mit Metainformationen auszustatten, die die zu injizierenden Abhängigkeiten definieren. Runkit ermöglicht es, auf Basis dieser Metadaten Abhänigkeiten an das ensprechende Objekt zu binden – zur Laufzeit und ohne zusätzliche Implementierung von Schnittstellen o.Ä. Vom Prinzip her sollte es also möglich sein, eine Klasse zu schreiben, diese zu annotieren und dann bei Instanziierung automatisch alle gewünschten Abhängigkeiten zur Verfügung stehen zu haben. Ein Codebeispiel:

index.php:

  require __DIR__ . '/lib/vendor/doctrine-common/lib/Doctrine/Common/ClassLoader.php';

  use DoctrineCommonClassLoader;
  
  $classLoader = new ClassLoader('DoctrineCommon', __DIR__ . '/lib/vendor/doctrine-common/lib');
  $classLoader->register();

  $classLoader = new ClassLoader('deifschleife', __DIR__ . '/lib');
  $classLoader->register();

  // INITIALISIERUNG DES DI-CONTAINERS
  $di_container = new deifschleifediContainer;
  
  $di_container->setClassnames(array(
    'deifschleifeDITest'
  ));
  
  // "AUFNEHMENDE" KLASSE
  $test = new deifschleifeDITest();

  // GEHÖRT deifschleifeADependency
  echo $test->foo();
  
  // GEHÖRT deifschleifeAnotherDependency
  echo $test->bar();

  // GEHÖRT deifschleifeYetAnotherDependency
  echo $test->baz();
  
  // GIBT's NICHT, ÜBER __call() ABGEFANGEN
  echo $test->methodThatDoesNotExist();

Kurz erklärt:

$di_container = new deifschleifediContainer;
$di_container->setClassnames(array(
    'deifschleifeDITest'
  ));

Instanziiert den DI-Container und stellt eine Klasse (deifschleifeDITest) unter seine “Kontrolle”.

$test = new deifschleifeDITest();

  // GEHÖRT deifschleifeADependency
  echo $test->foo();
  
  // GEHÖRT deifschleifeAnotherDependency
  echo $test->bar();

  // GEHÖRT deifschleifeYetAnotherDependency
  echo $test->baz();
  
  // GIBT's NICHT, ÜBER __call() ABGEFANGEN
  echo $test->methodThatDoesNotExist();

Instanziiert die überwachte Klasse deifschleifeDITest und ruft einige Methoden auf, die sämtlich aus anderen Klassen nach DITest injiziert wurden. Die letze Methode ist nirgends existent. deifschleifeDITest implementiert ausschließlich __call(), ansonsten ist die Klasse (fast) leer:

<?php
namespace deifschleife;

/**
 * @Services({
 *   @Service(
 *    class="deifschleifeADependency",
 *    constructorArgs={
 *      "pong"
 *    }
 *  ),
 *  @Service(
 *    class="deifschleifeAnotherDependency",
 *    constructor={"deifschleifeAnotherDependency", "getAnotherDependency"}
 *  ),
 *  @Service(
 *    class="deifschleifeYetAnotherDependency",
 *    constructor="makeYetAnotherDependency"
 *  )
 * })
 */
class DITest
{
  public function __call($method, $args)
  {
    return sprintf("Called __call, Method: %s, Args: %s", $method . '()', implode(', ', $args));
  }

  public function makeYetAnotherDependency()
  {
    return new YetAnotherDependency();
  }
}

Interessant sind die Klassen-Annotationen ganz oben: @Services teilt dem Doctrine 2 Annotation Parser mit, dass hier eine Reihe von PHP-Klassen, die zu injizierende Methoden enthalten, zusammenzusuchen sind. Jeder einzelne @Service in der Liste kann noch grob konfiguriert werden, so kann bspw. eine eigene Factory-Methode für jede Dependency angegeben werden.

Die einzelnen Dependencies sind “ganz normale” PHP-Klassen. Intern passiert folgendes: Die Runkit-Erweiterung dient dazu, über runkit_method_add() “on the fly” eine magische Methode __call() an die mit zusätzlcihen Methoden anzureichernde Klasse deifschleifeDITest zu binden. Existiert bereits eine entsprechende Methode __call(), wird diese intern via runkit_method_rename() umbenannt und am Ende von __call() (neu) aufgerufen. Das bedingt natürlich eine gewisse Rücksichtname bei zusätzlicher Verwendung von __call().

Die Idee unterscheidet sch also nur unwesentlich von bereits vorhandenen Konzepten, spart aber einige Schritte ein:

1.) Man benötigt keine Abstrakte Klasse und/oder Interface, die dass die getService()-Logik bereitstellt.
2.) Man benötigt kaum zusätzliche Konfigurationsaufwand – eine einfache Annotation im PHPDOc-Comment-Format reicht aus (es spricht allerdings nichts dagegen, je nach Gschmäckle einen Config-Adapter dazwischen zu schieben, der das Mapping via XML oder bspw. Yaml erlaubt)
3.) Man kann auf Proxy-Instanzen verzichten, die __call() transparent bereitstellen.

Fazit: Es ist prinzipiell möglich, Dependency Injection – passender noch “Mixins” – mit PHP zu realisieren, ohne nennenswert viel Codeoverhead zu produzieren.

Allerdings muss man berücksichtigen, dass Runkit eine experimentelle Erweiterung ist, deren Zuverlässigkeit in komplexen Projekten nicht vorauszusehen ist. Außerdem wird es sehr wahrscheinlich in Bälde ein mächtiges, neues Sprachkonstrukt geben, das Mixins ermöglicht (siehe RFC zu Traits). Und natürlich kann ich mir auch totalen Murks zusammen gereimt haben, denn sicherlich sind die existierenden Implementierungen von fähigeren Architekten entworfen worden und haben bestimmt ihre Daseinsberechtigungen in einem Kontext, den ich vielleicht einfach noch nicht erfasst haben. Comments dazu wären wir sehr willkommen!

Ausblick

Die Lösung zentral über __call() ist die Schnelle, aber nicht optimale. Vorstellbar ist eine injizierung sämtlicher öffentlicher Methoden wie runkit_method_add, und ein globaler Accessor, der die Objektinstanz der Abhängigkeit liefert. Das ganze könnte man (optional) konfigurierbar gestalten (über Doctrine 2 Annotationen), um eventuellen Namenskonflikten auszuweichen.

Test-Sourcen

Die PHP-Quelltexte zu den obigen Beispielen kann man hier herunterladen:
http://ifschleife.de/dependency_injection.tar.gz

Ich habe die DoctrineCommon-Package bereits beigelegt, das Beispiel sollte also unter PHP5.3 funktionieren (bitte di.php aufrufen, der Rest ist noch durchsetzt mit Doctrine 2 Testklamotten).

Eine Anleitung, wie man Runkit unter php5.3 zum laufen kriegt, gibt es hier (Japanisch, aber der Quelltext ist auf PHP ;))

Die Test-Sourcen liegen, wie in den obigen Codebeispielen beschrieben, unter lib/de/ifschleife. Ich möchte betonen, dass das nur eine Art Fallstudie ist, ich wäre aber über jeden Kommentar erfreut, der mir widerlegt oder bestätigt, ob man den programmatischen Ansatz vielleicht weiterverfolgen sollte.

Vielen Dank für die Aufmerksamkeit! :)

Des Rätsels Lösung ist ja eigentlich meistens Flash – so auch bei Soundmanager 2.
Nur bleibt Flash hier komplett im Hintergrund und wird nur als “Ausgabegerät” missbraucht.

Sounds lassen sich dann mittles einer wirklich mal sehr coolen JS API einbinden, triggern und noch einiges mehr.
Dazu ist das ganze auch noch hervorragend dokumentiert.

Im einfachsten Fall sieht sowas dann so aus:

var mySoundObject = soundManager.createSound({
 id: 'mySound',
 url: '/audio/mysoundfile.mp3'
});

mySoundObject.play();

soweit so praktisch schonmal.
Die Performance ist übrigens ebensfalls hervorragend.

Richtig gut wird es dann, wenn man Flash 9 vorrausetzt:

waveformData array: 
256 waveform data values available while playing sound

eqData array: 
256 EQ spectrum data values available while playing sound

peakData object: 
Left and right channel peak/volume data available while playing sound

damit lassen sich dann mal eben eigene Meter Darstellungen skripten. In JS.

someSoundObject.whileplaying = function() {
// Move 256 absolutely-positioned 1×1-pixel DIVs, for example (ugly, but works)
var gPixels = document.getElementById(‘graphPixels’).getElementsByTagName(‘div’);
var gScale = 32; // draw -32 to +32px from “zero” (i.e., center Y-axis point)
for (var i=0; i<256; i++) { graphPixels[i].style.top = (gScale+Math.ceil(this.waveformData[i]*-gScale))+'px'; } } [/sourcecode] HTML Canvas beispiel : http://www.schillmania.com/projects/soundmanager2/demo/360-player/canvas-visualization.html

benutzt wird das ganze übrigens unter anderem von:
http://muxtape.com/
http://thecloudplayer.com/
http://8tracks.com/
und natürlich http://openchords.org ;)

tinyurl.com hat auch eine API.
Die ist zwar unglaublich simpel, aber das ist doch auch mal schön.

$tinyURL =  file_get_contents( 'http://tinyurl.com/api-create.php?url='.$tooLongURL );

und vice versa (hackish):

function reverse_tinyurl($url){
            // Resolves a TinyURL.com encoded url to it's source.
            $url = explode('.com/', $url);
            $url = 'http://preview.tinyurl.com/'.$url[1];
            $preview = file_get_contents($url);
            preg_match('/redirecturl" href="(.*)">/', $preview, $matches);
            return $matches[1];
        }

und noch die CURL variante von ersterem (via davidwalsh)

//gets the data from a URL  
function get_tiny_url($url)  
{  
	$ch = curl_init();  
	$timeout = 5;  
	curl_setopt($ch,CURLOPT_URL,'http://tinyurl.com/api-create.php?url='.$url);  
	curl_setopt($ch,CURLOPT_RETURNTRANSFER,1);  
	curl_setopt($ch,CURLOPT_CONNECTTIMEOUT,$timeout);  
	$data = curl_exec($ch);  
	curl_close($ch);  
	return $data;  
}

http://feednapi.net

Was macht es?
Es durchsucht verschiedene (viele) MedienSites nach bestimmten Keywords und stellt die neuesten Ergebnisse (schön) dar.

Wie gehts?
Es benutzt ganz brav die APIs der Sites.

Was soll das?
Das Web ist vielfältig und die Resourcen zu gewissen Interessengebiete sind verteilt. Das zu bündeln und eine Übersicht zu behalten war die Motivation.
ZB sind viele Flickr Nutzer nach Änderungen in den AGBs bzw nach restriktiverer Zensur zu Zooomr gewechselt.
Sucht man nun bei Flickr nach irgendeinem Motiv, würde man Medien dieser Nutzer nicht mehr finden. Das wäre schade. Bei Feednapi findet man beide.

Wann soll ich es benutzen?
Immer! Naja, Sinn macht es besonders dann, wenn man nach einem Event die neuesten Uploads im Blick haben will. Oder man Fan einer Band ist und man die nach den neuesten Videos sucht aber vergessen hat das diese Band vornehmlich auf Vimeo statt auf Youtube postet.
Und zu guter letzt: wenn man Langeweile hat!

Probleme?
Ja viele. Zum Beispiel taggen manche User ihre Inhalte etwas eigenartig, was bei den Suchergebnisse manchmal komische Dinge anzeigen läßt, die nun gar nichts mit dem Gesuchten zu tun hat.
Und Feednapi ist abhängig von den Möglichkeiten die die APIs einem lassen. So hat Vimeo zB bis heute kein Sorting nach Datum implementiert und Youtube ist da auch nicht sonderlich zuverlässig.

Wie gehts weiter?
Mehr Sites integrieren, Mehr Kategorien einbauen , Mehr Sorting ermöglichen. undundund
Immer wenn ich mal was Zeit hab! ;)

Schauts euch mal an!