Neues Experiment – Unicycling

Btw … Did you know? Einradfahren ist in Japan regulärer Schulsport! Einrad heißt auf japanisch 一輪車 [いちりんしゃ]

Ich wollte mir vor 2 Jahren oder so schonmal ein Einrad kaufen … Klein, leicht und praktisch zum Transportieren.

Das Bild oben zeigt ein QU-AX Luxus 24″ … Bei eB*y bekommt man es neu für 100EUR. Mal schauen, ob das nicht rausgeschmissenes Geld war

Die Motivation dahinter ist, etwas kleines und leichtes im Auto mitnehmen zu können und Waldstrecken damit zu bewältigen. Falls ich es jemals zum Mountin-Downhill-Unicycling schaffe, könnte man das Ding auch relativ leicht nach oben tragen

Laut G**gle benötigt man zwischen 15h bis 30h Übung. In Wochen ausgedrückt so 2-3 Wochen … Bin mal gespannt!

Interessanterweise hab ich erst nach YT-Videos geg**gelt, nachdem ich mir eins bestellt hatte.

Ich wusste nicht, dass man sowas damit machen kann:

oder weniger krass, dafür echt stylisch:

Na, was wurde denn da geliefert? DVB-C Stick

Bestellt einen Suntek MediaTV Digital Home … Eigentlich hätte ich erwartet, dass er identisch zu meinem anderen Stick aussieht. Immerhin hab ich ihn erst seit 2 Wochen …

Geliefert wurde ein USB-Stick in Form eines schwarzen länglichen, ekigen Kästchens, der zudem auch noch irgendeinen Anschluss an der Seite hat, mit einem Haufen Adapterkabeln …

In  /var/log/messages hat er sich mit Sundtek Media TV Pro2 gemeldet, während der graue Stick erwartungsgemäß Sundtek MediaTV Digital Home ausgibt …

Also tatsächlich was anderes und eigentlich nicht das, was ich bestellt hatte … War aber 10EUR teurer, vielleicht war das der Grund?!

Gleich mal getestet und herausgefunden, dass der MediaTV Pro2 anscheinend wieder 4 Multiplex pro Transponder schafft, während der MediaTV Digital Home nur 2 schaffte …

Gleich nochmal genauer getestet und gleich mal 4 Kanäle aufgezeichnet und tatsächlich, das funktioniert … Ich kann mich erinnern, dass ich das mit dem Digital Home auch probierte und ich da nicht mal mehr einen Sender-Lock bekam, weil er die 4-fach-Einstellung grundsätzlich verweigerte (auch schon beim Sendersuchlauf).

Das ist doch sehr erfreulich! Soll ich meinen zweiten Pro2 behalten und dafür den Digital Home wieder verkaufen?

 

 

Auf DVB-C umgestiegen …

Nachdem jetzt fast alle SD-Programme im Kabel frei zu empfangen sind, hab ich beschlossen, meine Multi-Tuner-Konfiguratin von 2* DVB-T + 1* DVB-C auf 3* DVB-C zu ändern.

Die Auswahl an DVB-C Tunern für USB ist schon sehr sehr mager … Eigentlich gibt es nur einen derzeit erwerblichen USB-Stick, der wunderbar unter Linux funktioniert.

Dass er unter linux funktioniert ist kein Zufall, denn Sundtek bietet explizit Support für Linux für ihre MediaTV-Pro USB-Sticks an. Der Grund dahinter ist, dass man so die Dreamboxen mit weiteren Tunern erweitern kann.

Das schlägt sich leider auch auf den Preis nieder.

Nicht nur das, sondern auch die Tatsache, dass jetzt fast alle SD-Programme im Kabel frei empfangbar sind … Man muss jetzt fast 10EUR mehr für einen Stick zahlen, d.h. ein Stick kostet fast 90EUR!

Schon unglaublich …

USB DVB-C “UV+ Sundtek MediaTV” Remote + Lirc

Hat etwas gedauert, aber jetzt hab ich eine perfekt funktionierende Config für Lirc …

Zu beachten ist, dass es sich bei der Remote-Control – auf der selbstverständlich überhaupt keine Produktbezeichnung stand – um die handelt, die man hier sehen kann:

Hier die Config dafüt:

begin remote

  name  sundtek.conf
  bits           14
  flags SPACE_ENC|CONST_LENGTH
  eps            30
  aeps          100

  header        606  1633
  one           611  1634
  zero          611   516
  ptrail        610
  repeat       8984  2195
  gap          49259
  toggle_bit_mask 0x0

      begin codes
          POWER                    0x0D12
          SHUTDOWN                 0x0619
          1                        0x001F
          2                        0x100F
          3                        0x0817
          4                        0x1807
          5                        0x041B
          6                        0x140B
          7                        0x0C13
          8                        0x1C03
          9                        0x021D
          0                        0x051A
          FULLSCREEN               0x0A15
          PHOTO                    0x011E
          RECALL                   0x0E11
          BACK                     0x1906
          UP                       0x009F
          OK                       0x1A05
          RIGHT                    0x1847
          LEFT                     0x0857
          DOWN                     0x108F
          CH+                      0x110E
          CH-                      0x1B04
          MUTE                     0x045B
          VOL+                     0x0916
          VOL-                     0x025D
          REC                      0x0B14
          PLAY                     0x104F
          STOP                     0x005F
          PAUSE                    0x130C
          FWD                      0x0718
          REW                      0x0F10
      end codes

end remote

 

Java7 und Diamond-Operator

Hach, da haben die sich ja was schönes einfallen lassen

Statt

ArrayList<MyClass> list = new ArrayList<MyClass>();

reicht jetzt ein

ArrayList<MyClass> list = new ArrayList<>();

Aaaaber … Da bin ich über eine Falle gestolpert bei der Verwendung mit generischen Funktionen …

private <T> List<T> toList(T t) {
    ArrayList<T> list = new ArrayList<>();
    list.add(t);
    return list;
}

funktioniert tatsächlich nicht mit dieser Fehlermeldung:

Type mismatch: cannot convert from ArrayList<?> to ArrayList<T>

Verzichtet man in diesem Fall auf den Diamond-Operator, dann klappt es wieder …

Merkwürdig irgendwie … !

 

 

Websockets sind (zu) neu …

Ich entwickel fast alles mit einer Kombination aus Apache + Tomcat + Datenbank (mysql oder postgresql).

Für eine neue Webapp wollte ich mal Websockets ausprobieren.

Websockets ist ein HTML5-Feature, das momentan nur von den neuesten Browsern unterstützt wird. Sie bieten den Vorteil, eine Verbindung zu öffnen (und diese offen zu halten), damit man keine Mechanismen wie HTTP-Long-Polling benötigt, um Server-Pushs zu ermöglichen. Stattdessen schickt der Server einfach über die offene Verbindung Daten an den Client. Sehr praktisch!

Ein weiterer großer Vorteil ist, dass die Websockets nicht der same-origin-policy unterliegen, wie es bei AJAX der Fall ist. D.h. AJAX-Anfragen kann man nur an den Server der gleichen Domain stellen, aber man kann keine Anfragen irgendwohin anders stellen. Das ist oft hinderlich.

Leider sind Websockets sehr neu, weshalb es da etliche Probleme gibt.

Zuallererst muss der Application-Server Websockets unterstützen. Tomcat7 kann das. Man muss nur aufpassen, dass ein Interface der Api von Version 7.0.28 auf 7.0.30 geändert wurde, sodass die Version wichtig ist. Leider handelt es sich um das MessageInbound-Interface, das essenziell für die Websockets ist.

Ich hab da einige Zeit gesucht, bis ich herausgefunden habe, warum mein Tomcat eine Abstract-Class-Exception liefert, obwohl ich sauber die abstrakten Methoden implementiert hatte.

Das Problem lag daran, dass auf meinem Server die Tomcat-Version 7.0.28 lief, während meine Maven-Tomcat-Plugin-Version 7.0.30 verwendet. Ja, das hat es ausgemacht …

Weiterhin muss man wissen, dass man normale HTTPServlets nicht verwenden kann, d.h. man muss an seiner Tomcat-App auf jeden Fall etwas ändern. Man benötigt eine Klasse des Typs WebsocketServlet. Der Rest ist fast gleich …

Weiteres Problem war Apache … Apache unterstützt immer noch keine Websockets, dafür gibt es irgendwelche Selbstkompilate, die man als Module in den Server hängen kann. Viel zu kompliziert … mod_proxy kann eine Websocket-Verbindung jedenfalls nicht weiterleiten, weil es die Header entfernt. Websocket setzt auf HTTP auf und hat ein paar Header mehr, die dem Apachen nicht gefallen. Er stript sie einfach raus und das wars. Schon funktioniert es nicht mehr.

Die Lösung war, den veralteten Apachen einzustampfen und durch ein modernen NGINX zu ersetzen. NGINX ist ein sehr moderner Webserver, der nicht nur light-weight ist, sondern auch nicht mehr auf forken sondern auf threading basiert. Forken ist natürlich einfacher, weil wenn der Prozess abstürzt, dann ist der Hauptprozess weiterhin am Leben. Das ist bei NGINX schwieriger, denn die Threads laufen alle innerhalb eines Prozesses. Aber dafür ist er Resourcenfreundlicher und schneller

Ich war überrascht, wie schnell NGINX konfiguriert war. Websockets haben damit quasi sofort funktioniert.

Tjo, das war meine Erfahrung damit und jetzt funktioniert es …

Ich wollte NGINX eh mal testen und jetzt hab ich die Gelegenheit dazu

Erstaunt war ich nur, dass ich von jeder Software die neueste Version brauchte, die teilweise noch nicht mal in Debian-Testing ist …

JSON RPC und Python

Einfach nur toll!

JSON-RPC ist ein einfaches Protokoll, um remote auf einem Server Funktionen aufzurufen.

Hierbei kann eine Kommunikation ganz einfach so aussehen:

--> { "method": "echo", "params": ["Hello JSON-RPC"], "id": 1}
<-- { "result": "Hello JSON-RPC", "error": null, "id": 1}

Serverseitig wird die Methode ‘echo’ aufgerufen. Als Parameter wird (in diesem Fall) ein Array mit einem einzelnen String übergeben.

Das alleine ist noch nicht das tollste … In Verbindung mit Python ist das richtig genial …

from jsonrpc import ServiceProxy
s = ServiceProxy("http://.../jsonrpc")
print s.echo("Hello JSON-RPC")

gibt auf der Konsole aus:

Hello JSON-RPC

Selbstverständlich muss der Server die Methode unterstützen.

Auf Client-Seite muss man mit Python die Methode ‘echo’ nicht definieren. Man ruft eine Methode mit einem beliebigem Namen auf und die Library erstellt daraus JSON-RPC-Requests, die an den Server geschickt werden. Der Methoden-Name wandert hierbei in das Feld “method”, die Parameter nach “params”. Die Library fängt auch Fehlerfälle ab, wie z.B. die Methode existiert nicht, oder es ist irgendein anderer Fehler aufgetreten.

So einfach ist das!

Demnächst mehr auf Server-Seite in Java …