Ich habe etwas mit State-Management in Java herum experimentiert und mir etwas geschrieben, um den State von Web-Apps (Vue.js, React, AngularJS,..) auf einen Server auszulagern. So dass sich die States und Actions der verschiedenen Clients gegenseitig beeinflussen können (Datenaustausch), aber private Daten wie Tokens trotzdem für die einzelnen Clients isoliert bleiben. Neben den Reducern gibt es noch Facets für die Anpassung der Ausgabe (so etwas wie Getter in Vuex).
Ich wollte dann einmal das Grundsystem (State-Manager, Interfaces, Server + Controller) in einem Mave-Repository ablegen und die konkrete Implementierung der Reducer, Facets und Filter dann sauber getrennt in einem eigenen Projekt haben.
Das Repository sollte einfach bei Github liegen und nicht in eines der öffentlichen und großen mit rein genommen werden, da es ja erstmal ein Proof-Of-Concept für meine Idee zu verteilten Daten ist. Ich habe mich dabei an diesem DZone-Artikel orientiert.
<dependencies>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.4</version>
<scope>provided</scope>
</dependency>
<!-- .... und noch mehr ..... -->
</dependencies>
</project>
Den Inhalt aus target/mvn-repo/hp-globalstate/hp-globalstate-core/ habe ich dann in ein Github-Projekt gepackt und hochgeladen. Das 2. Projekt kommt dann dieses dann hinzu:
public class Server {
public static void main(String[] args){
GlobalStateServer server = new GlobalStateServer();
List<Reducer> reducers = new ArrayList<>();
reducers.add(new de.hannespries.test.Reducer());
List<FacetFilter> facets = new ArrayList<>();
facets.add(new DefaultFacetFilterByToken(true));
Bei Heise gibt es von Techstage einige Artikel über Sets von Überwachungskameras mit Netzwerk-Recordern und Teilweise mit Monitoren. Einmal fällt auf, dass die Begrifflichkeiten aus einer Zeit zu stammen scheinen in dem noch auf Videobändern aufgezeichnet wurde und andererseits fällt auch auf, dass die Preise mit min. 220 Euro doch schon sehr teuer sind. Gerade das Bild des offenen IP-Recorders von Abus zeigt ganz klar, dass hier sehr wenig "Magic" im Spiel ist, sondern diese Sets meistens nur aus einer Ansammlung von Standard-Komponenten bestehen die mit Standard-Protokollen unter einander kommunizieren.
Gerade das fällt in den Artikeln auf, dass nicht einmal der Begriff ONVIF fällt, der diese ganzen Sets relativ schnell entzaubert, wenn es sich nicht gerade um extrem proberietäre Cloud-Lösungen geht (bei China-Produkten bedeutet der Begriff Cloud meistens einfach nur FTP-Upload). Wenn man nun keine 220 Euro ausgeben kann oder möchte und trotzdem eine gute Lösung haben möchte, kann auf andere Komponenten zurück greifen, die genau so sich über ONVIF verbinden lassen und dabei noch sehr viel günstiger und teilweise hochwertiger sind. Die Einrichtung ist dann auch nicht komplizierter als bei den normalen China-Lösungen.
Wir werden ein Set aus einem "IP-Recorder" und 2 Kameras für weniger als 200 Euro zusammen stellen und dabei 1920x1080 als primäre Auflösung nutzen. Leider gibt es meine präferierte IP-Kamera nicht mehr zu kaufen, aber da WLAN sowie nett zu haben ist, nehmen wir die WLAN-Varianten. WLAN ist sowie so eine eher zu vernachlässigende Sache, wenn man eine Outdoor-Lösung anstrebt. Man muss immer beachten, dass man die Kameras mit Strom versorgen muss.
Die Netzteile sind zumeist nicht wetterfest und man müsste Verlängerungskabel verwenden. Damit man wetterfest bleibt ist die beste Lösung outdoor-CAT6 Kabel für PoE (Power over Ethernet). Wenn man also schon Ethernet-Kabel mit einem PoE-Switch für die Stromversorgung nutzt, ist es kaum Mehraufwand, das ganze mit dem vorhanden Netzwerk zu verbinden und hat damit zu meist auch eine bessere Verbindung als wenn jede Kamera einzeln sich mit dem WLAN verbinden würde. Bei Outdoor ist WLAN als eher optional, falls man irgendwie eine Kameras direkt neben einer Steckdose anbringen kann.
PoE Hub aus China
Indoor sieht es natürlich ganz anders aus. Hier ist WLAN schon sehr praktisch, weil hier auch keine wetterfeste Stromversorgung von Nöten ist.
Aber egal ob indoor oder outdoor angestrebt ist, der zentrale Punkt bleibt der "IP-Recoder". Aber was ist so ein Recorder überhaupt? Auf der einen Seite ist es ein einfacher Netzwerkspeicher, aber auf der anderen Seite bietet er auch Motion-Detection und übernimmt die Aufzeichnung der Bilder und Videos. Meistens können die Kameras dieses aber schon selber und man braucht nur einen Netzwerkspeicher wie ein NAS oder eine Fritzbox. Eine Fritzbox mit einer externen Festplatte könnte also schon reichen solange die Kameras die Daten per FTP hochladen können. Aber man müsste für die Live-Ansicht jede Kamera direkt ansteuern (P2P-Modus mal ignoriert). Gerade diese Zentralität und Einheitlichkeit in der Konfigurierung, wenn man verschiedene Kameras verwenden sollte, machen so einen Recorder sehr praktisch. Zum Glück muss so ein Recoder nicht teuer sein.
Variante Mini-PC: Ein Mini-/Tiny-PC von HP oder Lenovo ist nicht teuer und bietet sehr viel Leistung, im vergleich zu den Varianten aus den Sets bei Techstage. Ein i3 mit 4-8GB RAM ist sehr viel leistungsfähiger als ein ARM Singleboard-Computer. Auch kann man hier einfacher eine große HDD oder SSD einbauen und mit externen Festplatten erweitern und spart sich damit ein zusätzliches NAS. Auch haben diese PCs mehrere USB-Anschlüsse für USB-Kameras (was indoor eine gute Alternative zu IP-Kameras sein kein). Wenn eine Windows-Version dabei ist, kann man diese nutzen oder sich ein Linux installieren.
Mit Windows kann man iSpy verwenden, das sehr viele Einstellmöglichkeiten hat und dabei sogar einen viel Arbeit abnimmt, in dem z.B. ONVIF-Kameras fast automatisch gefunden und eingerichtet werden. Die Motion-Detection funktioniert sehr zuverlässig und auch ein zusätzlicher FTP-Upload ist möglich. Der Nachteil ist, dass es eben eine Windows-Programm ist und man somit nicht einfach die Oberfläche auf ein Smartphone holen kann.
Mit Linux hat man die Möglichkeit motionEye zu verwenden, dass man als Package installieren kann. Diese Lösung bietet eine Web-UI an, die sowohl auf Desktops als auch Smartphone gut funktioniert. Man muss aber teilweise RTSP-Urls per Hand eingeben und bekommt alle Einstellmöglichkeiten direkt und ungefiltert präsentiert. Dennoch ist die übersichtliche Ansicht egal ob auf dem Desktop oder dem Smartphone immer sehr gut und leicht und schnell zu bedienen. Wenn man also auch mal von Unterwegs einen Blick auf die Kamera-Stream werfen will, halte ich motionEye für die bessere Lösung.
Ein Fujitsu Thinclient mit x86-64 Prozessor
Variante ARM-SBC: Wer einen Raspberry PI oder Orange Pi hat (als Set zwischen 20 und 40 Euro) kann mit einer 32GB SD-Karte und motionEye OS sich eine gleichwertige Lösung in sehr günstiger, kompakter und stromsparender Version zusammen stellen. motionEye OS auf der SD-Karte am PC installieren, dann in den ARM-PC stecken und einschalten. Nach 1-2 Minuten kann man die Web-UI aufrufen und mit der Einrichtung der ersten Kamera beginnen. Die Downloads findet man hier : https://github.com/ccrisan/motioneyeos/releases
Orange Pi One Kompletset
Egal welche Variante man nimmt sollte der Computer nahe dem Router stehen und benötigt so kein WLAN sondern nur ein kurzes LAN-Kabel. Bei der PC-Variante braucht man noch einen Monitor, eine Tastatur und eine Maus. Bei der ARM-Variante reicht eine SD-Karte, weil die Einrichtung rein über die Web-UI erfolgen kann (SSH ist natürlich auch möglich, aber nicht zwingend nötig).
Da wir nun einen "Recoder" haben, mit dem wir USB- und ONVIF-Kameras bedienen können brauchen wir nur noch die Kameras und etwas Zubehör.
Wenn man dazu ein Orange PI One Set von AliExpress rechnet ist man sehr genau bei 200 EUR Gesamtpreis. Wenn man PoE-Hub und Adapter auch in China bestellt, kann man dort auch nochmal etwas Geldsparen. Die Kameras können auch direkt per FTP auf das NAS einer Fritzbox schreiben.
Indoor:
2x ieGeek FullHD WLAN (schwarz ist unauffäliger als weiß) = 110 EUR
Indoor muss eine Steckdose in der Nähe sein und man kann sich den ganzen PoE-Part ersparen bzw. einsparen. Aber es ist zu überlegen im Haus kleinere Kameras zu verwenden, die weniger direkt ins Auge stechen, wenn man nicht gerade dadurch einen abschreckenden Effekt erzielen will (in Ladengeschäften sollten Kameras immer gut sichtbar sein).
Wenn man die Kameras mit dem WLAN verbinden möchte ist die einfachste Einrichtungsart, die Kamera per LAN-Kabel einmal an den Router zu hängen und dann per Web-Browser auf die Kamera zu zugreifen und dort das WLAN einzustellen. Alle anderen Lösungen waren bis jetzt immer umständlicher oder funktionierten garnicht. Ich halte wenig davon die Kameras per Smartphone-App einzurichten, weil man gerade bei der Eingabe von Text und WLAN-Schlüssel mit einer echten Tastatur sehr viel schneller ist.
Wem 960p als Auflösung der Kameras reicht (selbst 720p ist im Indoor-Bereich oft ausreichend) kann bei den Kameras noch so um die 15 EUR pro Stück sparen.
Das wichtigste Werkzeug hier ist die Übersicht der Netzwerk-Geräte und IP-Adressen des Routers oder auch das Programm ONVIF Device Manager.
Während die Installation von motionEye auf einem ARM-SBC und iSpy auf Windows sehr einfach ist, ist die Installation von motionEye auf einem Mini/Tiny PC unter einem Ubuntu-System leicht aufwendiger. Dafür hat man die Vorteile, dass man ein komplettes Linux-System hat und den PC auf für andere Serveraufgaben verwenden kann oder den PC auf direkt mit einem großen Monitor verbinden kann und Live-Streams der Kameras anzeigen kann (localhost im Webbrowser öffnen und man hat seine UI). ARM-SBC können das an sich auch, aber hier sind oft Grafik und Leistung nicht dafür ausgelegt viele Aufgaben auf einmal zu erledigen.
Hier habe ich ein mal zusammen getragen wie man motionEye auf einem Fujitsu Futro S900 installieren kann. Dieser PC kostet um die 30 Euro bei Ebay und mit einer mSATA SSD und einem WLAN-Stick bekommt man extrem flexibelen kleinen und günstigen PC für viele Anwendungszwecke.
Danach kann man über den Port 8765 die motionEye Web-UI aufrufen.
Man kann ohne Probleme viele USB- und IP-Kameras anschließen und hat keine Probleme mit Updates und kompatiblen Kameras, was bei Komplettsets schnell passieren kann, weil hier alle ONVIF kompatiblen Kameras funktionieren. Während mein Setup mit dem Futro S900 Thin-Client eine eher eingeschränkte Leistung hat, kann man mit z. B. Lenovo Tiny-PCs und i-Serie CPUs auf kleine Geschäfte oder mittelgroße Gebäude und Gelände überwachen (mit ~10 Kameras).
Um bei ONVIF-Kameras die URL für den Video-Stream heraus zu bekommen hilft der ONVIF Device Manager.
RTSP-URL einer ONVIF-Kamera in motionEye
Hier sieht man wie eine ONVIF-Kamera per RTSP angebunden wird.
Wer iSpy verwendet, hat den Vorteil, dass auch eingebaute Microphone von Kameras ausgewertet werden können und bei bestimmten Geräuschen ein Alarm ausgelöst werden kann. Plugins für die Erkennung von KFZ-Kennzeichen oder QR-Codes gibt es auch.
Wenn man sich also für eine "Selbstbaulösung" entschiedet, kann man viel Geld sparen und bekommt zusätzlich noch einen sehr viel leistungsfähigere Recorder für einen Bruchteil des Geldes. Bei dem Preis für die Abus-Lösung (siehe den Techstage-Test), bekommt man einen refurbished PC mit i3 oder sogar i5 CPU und mehr Festplattenspeicher und kann sicher trotzdem die selben Kameras verwenden.
Mal meine Ansichten zu Tim Bernes-Lees Solid. Kurz: Ich halte von der Idee garnichts. Grund: Die Benutzer. Ich mag ja dezentrale Lösungen und selbst Dateien hosten ist oft günstiger als OneDrive oder DropBox. Nur die Idee, dass durch diese Pods die großen Konzerne weniger Datensammeln und nutzen würden halte ich für eine falsche Annahme.
Denn es ist ja nicht so dass Google, Facebook und andere durch das Web ziehen und einfach Daten und Bilder klauen. Diese Daten werden ihen ja von den Nutzern bereit gestellt. Aber die Benutzer bekommen ja auch was dafür. Sie bekommen kostenlosen Zugang zu den Diensten. Es ist ja ein Tausch, den die Menschen eingehen und ich glaube kaum, dass sich da was ändern würde.
- Es beginnt schon beim Anbieter für den Pod-Speicher. Keiner wird dafür zahlen wollen. Deswegen wird am Ende wieder in Daten bezahlt werden.
- Soziale Netzwerke wie Facebook haben ihre AGB, um dabei da mitmachen zu dürfen, muss man diese annehmen. Am Ende ist es denen egal, ob man die Text da schreibt und die Bilder dort hoch lädt oder man denen eine URI übermittelt, wo sie die Inhalte finden
- Suchen und Werbung, wo die meisten Daten gesammelt und ausgewertet werden.. das ist da von gar nicht betroffen
Außerdem werden die Daten per Caching immer bei den Diensten zwischengespeichert, weil kein normaler Benutzer eine entsprechende Internetanbindung hat, um wirklich selbst zu hosten und kaum einer wird einen V-Host administrieren können oder wollen.
Das Argument, dass dezentrale Netzwerke aber sehr gut funktionieren (wie Mastodon), zählt nicht, weil es eben oben schon so funktioniert und man eher untersuchen sollte warum es funktioniert, bevor man etwas entwickelt, was sofort so viele Probleme offenbart, wenn man nur länger als 10min drüber nachdenkt (ind in den News-Foren fallen die Probleme fast allen sofort auf).
Man muss Dinge wie Mastodon cool machen.. dann lösen sich die Probleme von ganz allein.
Wer kennt das Problem nicht? Der Java-Appserver ist schon beim hochfahren, während der DB-Server noch Daten importiert und Hibernate fängt an wild Exceptions zu werfen.
Die Lösung ist das Script wait-for-it, das einfach wartet, bis ein Server auf einem bestimmten Port erreichbar ist.
FROM openjdk:12-alpine
RUN apk add --no-cache bash
ADD utils/wait-for-it.sh /wait-for-it.sh
RUN chmod +x /wait-for-it.sh
Ich bin über diese Artikel bei T3N gestolpert, der ein Thema aufgreift, dass mir auch in letzter Zeit öfters auffiel. Es geht um das Bezahlen mit Bargeld. Das letzte mal wurde mir der Konflikt in diesem Bereich zu Weihnachten wieder deutlich, wo man viel Bargeld geschenkt bekommt. Bei der Erzählung, dass man nun ja mal wieder zur Bank müsse, um das ganze Bargeld einzuzahlen, erntete man von verschiedenen Seiten doch sehr ungläubige Blicke.
Wieso sollte man das Geld zur Bank bringen? Man müsse dann doch kurze Zeit später wieder hin und es wieder abheben!
Wenn dann gesagt wurde, man würde ja an sich nur per Karte zahlen, gingen die Gespräche in zwei verschiedene Richtungen:
1) Was ist aber bei den Sachen, wo du Bargeld brauchst? Bei bestimmten Käufen bräuchte man das Bargeld ja einfach, weil man dort nicht mit Karte zahlen könne. Das stand so im Raum und alle Leute nickten zustimmend. Auf die Frage, wo das dann wäre, fingen alle an nachzudenken und kamen zum Schluss, dass man das nicht wisse. Es klang für alle vollkommen einleuchtend und erst beim genauen betrachten fiel allen auch auf, dass wir nicht mehr 1990 haben, wo es bei einigen Geschäftsbereichen noch "on vogue" war, Kartenzahlungen aufgrund von Preisen oder persönlichen Befinden per se abzulehnen. Aber heute kosten Zahlvorgänge über die klassische Maestro-Karte kaum noch was und die Miete der Geräte ist auch kein Kostenfaktor mehr. Selbst auf Weihnachtsbasaren kann bei den Ständen oft schon mit Karte bezahlen.
2) Dann kannst du aber mal mit Bargeld bezahlen! Von dieser Gruppe von Menschen wird ein riesiger Unterschied zwischen dem "klassischen" Bezahlen mit Bargeld und dem bargeldlosen Bezahlen gemacht. Zahlen mit Karte wird in Notfällen benutzt, aber auch gerade bei hohen Beträgen, wo viele Angst hätten mit so viel
Bargeld rum zu laufen, wird Bargeld besonders vorgezogen. In deren Darstellung ist einfach der Bezahlvorgang mit Bargeld hochwertiger als bargeldloses bezahlen. Es geht nicht darum, das es Vorteile hätte oder ähnliches, sondern es besteht wirklich die Annahme, dass es einen Unterschied in Qualität des Vorganges gibt, auch wenn die Ergebnisse gleich sind. Das sind auch oft die Leute die Auszüge bei der Bank holen und wichtige Schreiben per Hand aufsetzen (und nicht am PC schreiben und Ausdrucken). Wenn man es genau nimmt sind es diese Leute die somit bewusst auch viel Sicherheit verzichten (Diebstahl von Bargeld.. keine PIN.. alles per Handschreiben.. verschicken und keine Kopie mehr haben, weil es nur ein Original gibt). Da kann man mit Argumenten nichts ausrichten, weil die höhere Qualität inhärent ist und damit keinem Beweis benötigt.
Die Vorstellung wird dann auch oft vorgeschoben, um sich auf keinen Fall mit modernen oder neueren Technologien und Entwicklungen beschäftigen zu müssen, weil diese per se mit einer schlechteren Qualität des Vorgangs gleich gesetzt werden. Lebensmittel online bestellen und damit mehr Freizeit haben? Unsinn... im Laden einzukaufen ist besser und Hochwertiger, auch wenn man am Ende die selben Waren zu hause stehen hat.
Das beschreibt auch oft die Probleme Digitalisierung und Automatisierung, die gerade die Jobs gefährden, die oft solche Ansichten vertreten. Aber da wird keine Problem gesehen, weil direkt damit argumentiert wird, dass die Arbeit des Menschen eine höhere Qualität habe.
Nicht das Ergebnis! Aber der Vorgang der zu dem Ergebnis mit der selben Qualität führt. Daher wären Faktoren wie Kosten und Zeit auch relevant.
Wer jetzt glaubt ich schreibe hier von Menschen ab 50 aufwärts.. nein.. ich habe das genug bei Leuten erlebt die noch nicht 30 sind. Ich bin gespannt, wie lange solche Meinungen noch überdauern können. Wenn man Leute über 60 sieht, die nie ein Smartphone haben wollten, weil es viel zu kompliziert sei. Internet und Homebanking sein ja sowie so unsicher und zu kompliziert. 5 Jahre später wird alles dies von diesen Menschen wie selbst verständlich verwendet und ein Verzicht darauf stünde auch gar nicht mehr zur Diskussion. Die Welt entwickelt sich weiter und das betrifft nicht nur einzelne Generationen sondern immer alle Menschen auf einmal. Alle müssen sich anpassen und keiner kann es in dem Sinne aussitzen (durch wegaltern).
Wer erinnert sich noch an den FAST- AV-Master? Eine PCI Videograbber-Karte für Win9x, die in voller PAL-Auflösung aufnehmen konnte. Mit Ulead Media Studio Pro konnte man echt gute Videos schneiden. Hardware MJPEG-Encoder.
Nur wenn man damit 30min Video aufgenommen hatte, sollte man aufpassen den hinteren Teil der Karte zu berühren... der war dann extrem heiß. Aber kein Kühlkörper drauf... hätte echt geholfen.
Den DV-Master habe ich dann doch leider nie benutzt. Eine einfache Firewire-Karte (Miro/Pinnacle DV200) hat gereicht.
Wenn man sich generische Componenten in React oder Vue bastelt, wie Lists oder Grids/Tables kommt man schnell zu dem Punkt, wo man Werte aus einem Object extrahieren muss. Z. B. wenn man sich in einer Table eine Column definiert. Man könnte eine function rein reichen, die auf die konkrete Implementierung des Item zugeschnitten ist, aber oft will man nur die vorhandenen Werte im Object zur Anzeige bringen und nicht zu viel schreiben.
Wenn man einen Key hat und auf der ersten/obersten Ebene agiert wie bei item.id ist alles einfach. Bei item.sub.moreSub.verySub.id ist es schon schwieriger.. naja eigentlich nicht und jeder hat so etwas schon mal gebastelt. Hier meine Lösung die vielleicht jemanden 5 Minuten Arbeit ersparen kann :-)
function getObjectValue(obj, path){
let curObj = obj;
const parts = path.split(".");
for(let i = 0; i < parts.length; i++){
if(curOjb[parts] !== undefinded){
curObj = curObj[parts];
}
else {
return undefined;
}
}
return curObj;
}
Manchmal hat man bei React trotz besserem Wissens sich Strukturen gebaut, die es schwierig machen, den Datenfluss sauber abzubilden. So passierte es plötzlich, dass in einer Child-Component etwas geändert wurde und diese Änderung es verlangte, dass in einer Geschwister Child-Component eine Liste neu geladen werden sollte. Diese Component lud die Liste von einer REST-API selber und bekam die Liste nicht von der Parent-Component. Doof. Per Callback wurde die Parent-Component von der Änderung unterrichtet, aber diese konnte das Neuladen ja nicht so einfach anstoßen, weil es an sich keine State-Änderung gab.
Man braucht ein Flag, dass sich ändert, wenn ein Refresh der Child-Component nötig wurde. Da reicht ein bool-Flag, das bei jeder Änderung seinen Zustand ändert.
Damit child2 nun was laden kann muss man nicht mehr groß selbst prev-props mit next-props vergleichen sondern kann useEffect() verwenden:
useEffect(() => {reloadList()}, props.refresh);
Schön einfach und kompakt. Das man mit useEffect() direkt auf einzelne props/Änderungen reagieren kann, macht mir React schon sehr viel sympathischer. Erinnert mich an Watcher und Proxies aus Vue, nur sehr viel einfacher zu verwenden.
Ich hatte in den letzten Tagen etwas mehr mit verschiedenen Formular-Generatoren in verschiedenen JS-Frameworks zu tun. Vorraussetzung bei allen was, dass die JSON-Schema als Schema-Sprache unterstützten. Bis jetzt war keiner dabei der wirklich fehlerlos funktionierte. Ich kann jetzt nicht sagen, ob es nicht doch irgendwie an mir lag, aber falls jemand bestätigen kann, das ein Problem kein generelles Problem dabei ist, wäre ich doch sehr glücklich und würde mich noch mal genauer damit beschäftigen.
Vue: FormSchema Native: lief erstmal ganz gut, aber wenn sich das Schema oder das Model im State geändert hat, würde die Form nicht neu gerendert. Wenn man eine Form-Component schreibt in die verschiedene Schemas rein gericht werden können zur Laufzeit ist das echt doof. Ansonsten machte es nämlich einen guten Eindruck.
React: react-jsonschema-form: bis jetzt das Beste nur gibt es leichte Probleme wenn man $schema mit etwas anderen als dem default-Schema rein reicht. Aber ansonsten funktioniert bis jetzt am Besten. Auch mit 3 Forms auf der Seite.
AngularJS Angular Schema Form: Wenn man nur eine Form auf der Seite braucht funktioniert es perfekt. Wenn ich aber zwei Forms mit zwei unterschiedlichen Schemas verwende, wollte die zweite Form nicht mehr rendern. Aber eine Form allein funktionierte echt super. Leider ist AngularJS aber ja nicht mehr wirklich supported und ich hätte lieber etwas für Vue gehabt, was genau so gut funktioniert.. eben dann auch mit 2-3 Form pro Seite. Edit: Problem hat sich in Luft aufgeloest...
Meine Suche geht weiter, weil ich Vue doch lieber mag als React. Oder am Ende doch selber schreiben oder ein andere auf JSON-Schema anpassen?
Ich habe bei meinem alten Thinkpad T500s die 160GB HDDs durch günstige Kingston 120GB SSDs ausgetauscht. Zusätzlich noch Windows 10 neu installiert und es ist wirklich ein merklicher Unterschied, so dass die Thinkpads für einfache Aufgaben noch immer ganz gut geeignet sind.
Es waren 3 lange und anstrengende Tage. Aber es gab viel neu oder erneut zu entdeckten. Vieles was man schon kannte und einges was einfach interessant war.
Gerade die eher nicht technischen Themen wie Mob-Programming bei sipgate, "A Brief History Of the Internet" und UX waren sehr interessant und auch motivierend, selbst mal wieder mehr nach vorne zu gehen. Auch wurde sehr oft erwähnt, dass die Menschen, die Standards, Frameworks und eben die Dinge machen, mit denen man täglich arbeitet, auch nur ganz normale Entwickler sind und auch über jede Idee/Bugifx oder Mithilfe sehr dankbar sind.
Und man solle nicht alte Fehler wiederholen sondern neue machen. Mehr Zeit für Experimente und keine Idee ist schlecht zu der Zeit der sie entwickelt wird, weil sie immer ein Problem löst. Ob sich die Lösung später als eher schlecht heraus stellt (wie Flash oder Java-Applets) muss sich erst noch zeigen.
Das mit wichtigste Thema war PWA (an sich kaum unterschiedlich zu den OWAs auf Firefox OS nur jetzt mit breiter Unterstützung), um Websites direkt zu Apps machen zu können und eine Interaktion mit dem Device zu erlauben.
Daher wird mein neues Experiment:
- PWA
- Vue.js für das Frontend
- Bootstrap 4 als CSS-Framework
- Fetch-API anstelle von Axios
- Daten werden nur von den momentan Teilnehmenden Devices bereit gestellt
- Die Plattform selbst hat keine klassische Persistenzschicht wie eine DB sondern bildet nur einen State für alle Devices ab
- also gibt es nur Daten-Caching aber keine Langzeitspeicherung
- JWT für den Login auf der Singlepage-App
- Backend mit Meecrowave oder Spring Boot.. da bin ich mir noch unsicher.. aber auf jeden Fall Java
Nach dem Ich mich etwas mit Redux beschäftigt habe, habe ich mir mal einen eher aktuellen Spiele-Prototypen von mir vorgenommen und geguckt, ob man diesen auf ein ähnliches Konzept umbauen kann. Also dass alles per Actions gesteuert wird. Alles was man macht wird per Action rein gereicht, in einer Loop(Interval) von einem Handler verarbeitet und dann gerendert, wenn mindestens eine Action ausgeführt wurde.
Nach einer schnellen Betrachtung wurde aber klar, dass ich da nicht viel umbauen konnte, weil die Engine schon rein der Logik wegen so implementiert wurde. Ich hab es einfach so schon gemacht ohne groß drüber nachzudenken. Ich hatte zusätzlich noch Action-Groups eingeführt, die dafür sorgen, dass immer nur die erste Action einer Gruppe ausgeführt wird (um Actors sich über die Map bewegen zu lassen, wobei alle Schritte vorberechnet sind und nicht vor dem Schritt dieser erst berechnet werden muss). Es gibt zwei Lanes: fast und slow. "slow" für das Bewegen von Actors auf der Map und "fast" für Eingaben und Dinge die an sich in Echtzeit da sein müssen. Ein kleine Verzögerung ist aber ok.
addIntervalEvent: function(eventType, eventArgs, group, lane){
this.interval.queue.push({lane: lane ? lane : 'slow',
type: eventType, args: eventArgs, parent: this.interval,
group: group});
},
performIntervallTick: function(lane){
//filter to perform events of a lane and remove this performed events
let filterCheck = [];
let render = false;
let newQueue = this.interval.queue.filter(item => {
let res = true;
if(item.lane == lane){
if(this.eventHandling[item.type] && (item.group === null || !filterCheck[item.group])){
this.eventHandling[item.type](item.args, item.parent, this);
filterCheck[item.group] = item.group;
res = false; //was performed and is removed from the queue
render = true;
}
}
return res;
});
this.interval.queue = newQueue;
//using the same method to trigger field-events
if(render){
this.globalKeyListener({keyCode: 0}, true);
this.renderViewport();
}
},
Hier bei ist der Controller der State und wird durch die Actions verändert. Eine Action wird mit einer Veränderung des State gleichgesetzt, da einmal oder zwei Rendern ohne das es nötig gewesen wäre in der Gesamtheit nichts ausmacht.
Was ich dabei gelernt habe ist, dass es schwer ist in JavaScript anders zu arbeiten, wenn man die Verarbeitung und die Ausgabe von einander entkoppelt, was gerade bei Anwendungen mit Grafik schwer ist nicht zu tun.
Heute saß ich vor der Dokumentation zu den neuen Hooks bei React und las mit durch welche Probleme die alle lösen sollen. Indirekt wurde gesagt, dass sie Redux unnötig machen sollen.. also war für mich die Zeit gekommen mir wirklich mal Redux anzusehen. Erstmal zu verstehen, was es tut, ist nicht ganz so einfach, wenn man sich deren Doku durchliest. Was gefühlt aber nur an deren Doku liegt, die viel zu zerstückelt ist, um einen schnellen Überblick zu bekommen.
Ich habe mit Hilfe von anderen Seiten dann heraus bekommen. Dass Redux einen State pro Reducer hält und der alle Actions bekommt und dann mit eigener Logik, die für ihn interessanten Actions ab arbeitet. Alter State geht rein und neuer geht raus. Eine Action hat einen Typ und ein Payload. Wenn sich der State ändert, wird etwas getriggert. Aber ich fand, dass doch für einfache Beispiele zu viel Code da war um es zu verstehen.
Um also das Prinzip von Redux zu verstehen habe ich dann mal 20min investiert und mir ein ähnliches Kontrukt geschaffen. Etwas Topic orientierter mit den States, so dass man die Reducer pro Action hat, aber vom Prinzip ist es alles relativ einfach und das Bootstrapping wurde daruch auch übersichtlicher.
Die meisten Beispiele zu Redux bestehen sowie so zu 50% aus React. Aber ich wollte ja Redux verstehen und nicht Redux+React (ja.. die gibt es wirklich auf getrennt von einander!)
Lief erstaunlicher Weise direkt wie es sollte (nach dem ein kleiner Fehler bei einer falschen Variablen behoben war).
Damit sollte man durch aus das gesamte Statemanagement einer Componente abbilden können. Wenn man nun noch Events verwenden würde, geht es schon stark in Richtung Reactive-Programming.
Bei Vue.js werden bei den Props, die an eine Unterkomponente übergeben werden, diese als Referenz übergeben. Wenn ich in der Unterkomponente etwas Ändere, werden diese Änderungen im selben Object durchgeführt, dass sich auch in der Oberkomponente befindet und ich kann diese Änderungen direkt dort verwenden. Ein Watcher sollte auch Änderungen erkennen können.
Bei React müßte ich eine callback-funktion mit in die Unterkomponente reinreichen und bei der Änderung diese antriggern, damit die Oberkomponente die geänderten Daten in denen eigenen State wieder übernehmen kann. Also wird in dem Sinne jede Reference, wie sie in Vue.js existiert hätte, durch eine selbst zu implementierende callback-Funktion ersetzt?
Macht das Sinn? Erzeugt es nicht nur mehr Arbeit und Code? Wo genau ist da der Vorteil? Oder habe ich da was falsch verstanden bei React?
Irgendwie werde ich mit React nicht wirklich warm. Es sind so Kleinigkeiten, die mich da stören oder mir das Gefühl geben, einiges wäre unnötig kompliziert in React.
Ein Problem bei Smarty 3 ist, dass man zwar sehr schön Blöcke überschreiben oder erweitern kann, es aber keine Möglichkeit gibt, die im Block vorhanden anderen Blöcke dan unangetastet zu lassen. Man muss in so einem Fall die nested Blöcke immer mit kopieren und mit dem Parent-Template immer wieder bei Änderungen abgleichen. Wenn z.B. ein Template einen Block mit einer <form> hat und darin dann die ganzen Eingabe-Möglichkeiten auch als Blöcke ausgelegt sind, muss man wenn man die Form-Action ändern will zwingend auch das ganze Form-Content Templating mit übernehmen.
Eine Möglichkeit das zu umgehen ist den Block rendern zu lassen und dann per String-Operationen das Ergebnis anzupassen. Primitiv aber auch sehr effektiv!
Falls man Formular von Shopware in anderen Contexts als dem forms-Controller einsetzt, kann es nötig sein, dass Template so anzupassen, damit es noch auf den forms-Controller zeigt und nicht auf den Controller in desen Context man gerade arbeitet.
Damit ist es auch schon erledigt und man kann anfangen Seiten der Gruppe zu zuordnen und sie werden entsprechend gerendert. Unterseiten und ähnliches sind auch möglich, wie frontend/index/footer-navigation.tpl zeigt. Die Gruppen findet man in der Datenbank in der Table s_cms_static_groups.
An sich ist das hier vollkommen logisch und man wundert sich warum man diesen Fehler überhaupt gemacht hat.. weil man den vorher nicht gemacht hat. Deswegen sollte man im Kopf behalten, dass wenn man optionale Parameter im Methodenaufruf im REST-Controller in Spring hat, diese null als Wert haben können müssen.
Einfach gesagt Integer verwenden und nicht int, weil das natürlich Probleme geben würde, wenn Spring null in einen int füllen möchte.
Die Scripts basieren auf dieser Anleitung von DigitalOcean.
Mit diesem Script werden der Master und alle Tags als Docker-Image gebaut, wobei der Master dann auch als latest-Tag abgelegt wird. D.h. der Master muss immer stable sein.. bei jedem Commit.
Alternative kann man auch sich auf verschiedene Tags-Notationen einigen, wobei nur die Tags als latest getaggt werden, wenn diese ein release-Tag sind. Hier muss man aufpassen, falls man eine alte Version
nachträglich einpflegen will.
Ich komme ja aus der Hibernate/JPA Ecke was ORMs angeht und habe auch als eines der ersten Plugins, das die Shopware-API betraf, mir ein Plugin geschrieben das POST und PUT gleichsetzt. Am Ende sehe ich nicht nur bei ORMs sondern auch bei REST-APIs keinen Vorteil darin zwischen CREATE und UPDATE beim Aufruf zu unterscheiden. Intern kann immer noch geprüft werden, ob eine Id gesetzt ist oder NULL/0 ist. Ich wurde CRUD eher durch ein RSD (READ SAVE DELETE) ersetzen. Welche Art von SAVE dann API intern ausgeführt wird, muss den Benutzer der API nicht interessieren.
Wenn die verwendete ID ein Business-Key ist hat es auch den Vorteil, dass man nicht bestimmen muss, ob man beim Speichern CREATE oder UPDATE aufrufen muss. Bei einem einheitlichen SAVE funktioniert es einfach und erspart viel Kommunikation mit dem Server.
Das ganze nur mal so zwischen durch... wollte ich nur mal sagen und nicht immer nur denken.
Wenn man verschiedene application.properties Dateien für verschiedene Spring Boot Anwendungen vorhält kann man diese übe einen VM Parameter auswählen. Wenn wir z.B. ein Profil für "local" haben, wo eine DB auf Localhost verwendet werden soll, geht es so:
-Dspring.profiles.active=local
Damit wird dann die application-local.properties verwendet.
"Das steht da nirgends drin", "Das ist viel zu ungenau", "ich kann da nicht raus lesen, dass da so etwas gefordert wird"... Userstories. In einer Userstory beschreib ein User was er mit dem Produkt machen will oder wie er das Produkt bedienen will. Jeden Falls kommt die Definition von Userstory oft so rüber. Aber jeder der mal mit einem Anwender zusammen Prozesse aufgenommen hat und sich dabei beschreiben lies, was der Benutzer eigentlich immer macht um zum Ziel zu kommen, weiß dass Benutzer nicht immer die zuverlässigste Quelle für korrekte oder vollständige Informationen ist. Was da manchmal raus kam.. damit will niemand einen Sprint planen. Ich halte Userstories für eine wichtige Sache, aber würde nie eine Userstory 1:1 in Tasks transferieren.
Mir gefällt diese Interpretation der Userstory als Hypothese sehr gut, weil mehr kann eine Userstory nicht sein. Eine Userstory ist der Lösungsweg einer Interpretation eines Problems oder Ziels. Niemand kann bei einer Userstory sicher sein, dass das Ziel richtig verstanden und seine Position im übergreifenden Gesamtbild richtig verstanden worden ist. Ist der Weg im gesamten Prozessablauf sinnvoll und schlank umgesetzt?
Wenn ich eine Userstory direkt von einem Benutzer bekomme, muss diese einfach nochmal gegen geprüft werden. Es gibt immer ein Problem, das zu lösen ist oder ein Ziel, das zu erreichen ist. Gerade wenn es um die Verbesserung eines vorhandenen Produkts geht, wo mehr zu tun ist, als ein paar GUI-Elemente neu zu ordnen, ist bis zur wirklichen Verwendung durch die Benutzer nie klar, ob die erhoffte Verbesserung wirklich eintritt. Oft ist nicht einmal klar, ob es nicht auch ungewollte Nebeneffekte gibt, die nicht bedacht wurden (die aber eingeplant werden müssen).
Man kennt es ja sicher, dass eine Abteilung mit neuen Anforderungen kommt, die alles besser machen sollen und man Tätigkeiten, die man gar nicht bräuchte, entfernt hat. Oft gucken, die dann sehr doof, wenn man denen erklärt, dass diese Tätigkeiten, aber für die nach gelagerten Prozesse in einer anderen Abteilung echt wichtige Daten liefern, die auch nur da her kommen können. Die Userstory war also eine Hypothese der Abteilung, die sich als falsch heraus stellte. Zum Glück noch bevor etwas umgesetzt wurde und es sich im Test oder gar im Produktivbetrieb herausstellen konnte.
Die im Artikel beschriebene Impact-Map bringt genau diese Übersicht mit und zwängt die Userstories in einen direkten Kontext in dem sie viel besser zu beurteilen und zu interpretieren sind sind, als wenn diese allein stehen würden.
- Welches Ziel soll insgesamt erreicht werden?
- Wer ist von diesen Änderungen betroffen? (Abteilungen, Kunden, etc)
- Welche einzelnen Änderungen sollen zum Gesamtziel führen? (Wo gibt es also momentan Probleme und Verbesserungspotential)
Erst dann kommen Epics und Userstories.
So steht über jeder Userstory ein Problem, dass zu lösen ist. Wenn eine Userstory eindeutig, dass Problem nicht löst, setzt man diese nicht um. Ähnliches gilt für Dinge die eindeutig fehlen um ein Problem zu lösen. "Da steht aber nirgends, dass man eine Benutzerverwaltung mit Rollen und Hierarchie will!".. aber es steht da, dass die Bereichsleiter Reports über die Tätigkeiten ihrer Abteilungen sehen wollen. Da würde einfach der wieder der Blick auf die Übergreifenden Prozesse vergessen und nur die Prozesse in den Abteilungen betrachtet. Also fängt man damit an eine Umgebung zu schaffen, bei der man sich Anmelden kann und ein Benutzer-Objekt mit Berechtigungen erhält, bevor man anfängt sensible Ansichten zu bauen, die diese Benutzer-Daten brauchen, um die richtigen Daten anzeigen zu können (und nicht zu viele Daten, die der Benutzer nicht sehen dürfte).
Und am Ende darf man nie vergessen, zu prüfen, ob eine Userstory auch wenn sie logisch klang, den gewünschten Effekt hatte. Dabei muss man schnell prüfen und messen, damit man schnell reagieren kann, um dann wieder rum schnell nachbessern zu können.
Userstories helfen also dabei den Kontext zu verstehen, aber nehmen einen nicht die Hauptaufgabe ab, nämlich als Entwickler eine Lösung für ein Problem zu entwickeln. Der Begriff Softwareentwickler beschreibt nicht was man entwickelt, sondern mit welchen Werkzeug man entwickelt!
Ich habe gestern angefangen mein Geburtstagsgeschenk "Schrödinger programmiert ABAP" zu lesen. Bis jetzt kann ich sagen, dass man schon mal ein gutes Gefühl bekommt wie man sich ein Dev-System einrichten kann und welche Teile bei den Anfängen elementar sind (z.B. das Logon-Tool mit seinen Load-Balancing Fähigkeiten).
In der nächsten Zeit werde ich mal gucken, ob ich es schaffe mir selbst ein SAP zu installieren (gibt es das auch für Docker?) und auch viel weiter lesen.
Auf die Art des Buches muss man sich aber erst einmal einlassen.. zum Glück sind nur die ersten Seiten etwas wirr und man findet sich schnell in die Struktur ein.
Wer sich sonst immer für Wildfly/Tomcat und JAX-RS für seine REST-API Lösungen entschieden hat wird sich mit Apache Meecrowave sehr schnell zu Hause fühlen. Im Grunde ist es auch nichts anderes als ein Tomcat mit JAX-RS nur dass die Setup-Phase fast komplett entfällt. Für Microservices und schnelle Lösungen hat man in wenigen Minuten eine funktionsfähige REST-API.
Für eine einfache REST-API braucht man die pom.xml, eine Klasse mit einer Main-Methode und einen REST-Endpoint.
@Path("test")
@ApplicationScoped
public class TestController {
@GET
@Produces(MediaType.APPLICATION_JSON)
public TestModel action(){
TestModel model = new TestModel();
model.setId(23);
model.setName("Test");
return model;
}
}
Der Endpoint ist jetzt erreichbar:
http://localhost:8080/test
Der Vorteil bei dieser Lösung ist, dass man sehr einfach ein Docker-Image mit dieser Anwendung erstellen kann, das man dann direkt deployen kann.
Durch das Meecrowave-Maven-Plugin wird eine meecrowave-meecrowave-distribution.zip im Target-Verzeichnis erstellt.
RUN apk --no-cache add bash
EXPOSE 8080
ENTRYPOINT["sh /app/meecrowave.sh start"]
Auch für Test gibt fertige Meecrowave-Packages, die man nutzen kann. Sonst geht natürlich auch einfach JUnit.
Wer sich jetzt fragt ob Spring Boot besser oder schlechter ist.. ich hatte jetzt mit beiden zu tun und am Ende ist beides an sich das Selbe mit ein jeweils anderen Libs. Beides ist für Microservices sehr gut geeignet.
Irgendwann fängt man an aus seinem großen Framework einzelne kleine Module heraus lösen zu wollen. Die will man dann als Composer-Requirements wieder einbinden. Zum Glück geht das sehr einfach, indem man einfach ein Repository zu seiner composer.json hinzufügt:
Manchmal will man später Dateien oder Verzeichnisse in die .gitignore aufnehmen, die man vorher nicht drin hatte und mit versioniert hatte. Das Hinzufügen zur gitignore reicht aber nicht, um die Dateien aus dem Repository verschwinden zu lassen.
Da muss man zuerst
git rm -r --cached .
ausführen und dann wieder alle Dateien adden. Dann werden die nun ignorierten Dateien als gelöscht in Git geführt.
Was man in Java teilweise mit Javassist gemacht hat und man für die Erkennung von Änderungen an Object-Values in JavaScript dringend braucht sind Proxy-Objekte.
Das geht zum Glück an sich ganz einfach.
<html>
<head>
<script type="text/javascript">
var x = {value: ""};
Ein sehr guter Wired-Artikel Auch 2029 wird es keine Künstliche Intelligenz geben, die diesen Namen verdient, der endlich mal klarstellt, dass das was man seit kurzen überall als KI verkauft, nichts weiteres ist als klassische Mustererkennung ist, wie man sie seit Anfang der 90er nutzt. Der klassische KI-Begriff, in dem um die Schaffung einer Intelligenz geht, hat damit garnichts zu tun.
Mich stört es wenn Firmen von KI sprechen und man dahinter nur einfache Datenanalyse mit stupiden Bedingungen und Gewichtungen erkennt. Vektoren zum Vergleichen mit bekannten Mustern sind jetzt auch nicht wirklich neu oder irgendwie intelligent.
Am Ende eines Sprints soll etwas heraus kommen, was man dem Kunden zeigen kann bzw deliverable ist. Kunden an sich können nur sehen was klickbar ist. Dinge die nicht klickbar sind sind für die meisten Kunden einfach nicht existent, weil diese zu meist keine technischen Anforderungen stellen sondern fachliche. Man Klickt etwas an und es passiert was und das ist das was der Kunde sieht und bewertet.
Aber muss es so sein? Es gibt viele Dinge innerhalb eines Sprints, die die Entwicklung und technische Basis voran bringen ohne das ein Anwender sie bemerkt oder sehen kann. Deswegen ist es vielleicht falsch nur den Kunden die Bewertung zu überlassen. Der Kunde muss nur am Ende etwas sehen, das man messen und dann validieren kann.
Angenommen, ich möchte mehr Automatisierung in der UI haben. Formulare sollen sich automatisch erzeugen und nicht mehr per Hand zusammen gebaut werden müssen. Kann ich das in einem Sprint nach der Definition liefern? Ja! Ich baue es ein und liefere dem Kunden am Ende des Sprints einen Mess-Fall. Genau so ob die Änderung die der Kunde sieht er nach dem Spring validiert werden kann, ob der erhoffte Impact eintritt, kann meine technische Änderung genau so zur selben Zeit getestet werden. Zwar nicht durch einen Anwender sondern durch die Daten des nächsten Sprints selbst, aber das Ergebnis ist das Selbe.
Ich liefere etwas und gebe dem Kunden etwas an die Hand, um die Hypothese auf der dieses gelieferte fußt, prüfen zu können. Ich sage, ich kann mit dieser Änderung im nächsten Sprint 6 neue Formulare in der UI liefern und nicht mehr nur 2. Das ist eine gute Annahme, die sich überprüfen lässt. Ob eine andere Userstory, die vom Kunden selbst kommt, am Ende das erhoffte liefert, weis man genau so wenig, wie diese Annahme, mit der ich den Form-Generator eingebaut habe.
Nach dem folgenden Sprint, gehe ich wieder zum Kunden und zeige ihm, was wir an Formularen gebaut haben. Nun prüft er, ob meine Annahme mit 6 Formularen erfüllt wurde. Vielleicht sind es nur 5 geworden oder wir hatten sogar Zeit über, in der wir noch ein Formular mehr hätten machen können... das ist gar nicht ganz so wichtig, weil sich heraus gestellt hat, dass es eine Verbesserung gab und damit meine technische Userstory erfüllt werden konnte und nicht nochmal neu bearbeitet werden oder als Fehlschlag einzustufen ist.
Ob man also klickt oder am Ende Zahlen vorlegt, ist für den Kunden dann egal. Man hat jeweils etwas gebaut, was sich in der Zeit danach bewähren muss und nur das was dann da heraus kommt zählt und nicht was am Ende des Sprint sichtbar war. Deswegen muss ich am ende des Sprints immer nur etwas liefern, was messbar ist. Nicht etwas was direkt sichtbar ist.
Wenn man mit JavaScript zu tun bekommt, führt leider kein Weg an Selenium vorbei. Das erst einmal zum laufen zu bekommen ist dabei auch nicht immer einfach. Ich habe dabei gelernt, dass Firefox nicht wirklich funktioniert und Chrome dagegen ohne Probleme funktioniert. Um Selenium zum Laufen zu bekommen brauchen wir einiges:
- eine aktuelle Version des Selenium Standalone Servers als JAR
- den Chrome-Driver für Selenium
- Java
dann kann man Selenium mit java -Dwebdriver.chrome.driver=/opt/selenium/chromedriver -jar selenium-server-standalone-X.X.X.jar starten. Den Driver kann man natürlich auch in anderen Verzeichnissen ablegen.
https://selenium-release.storage.googleapis.com/index.html
Um nun auch eigene Methoden wie Warten hinzuzufügen brauchen wir einen eigenen Context. Den legen wir unter features/bootstrap ab.
<?php
class TestContext extends \Behat\MinkExtension\Context\MinkContext {
/**
* @When I wait :arg1 seconds
*/
public function iWaitSeconds($seconds)
{
$this->getSession()->wait($seconds * 1000);
}
/**
* @When I click the :arg1 element accepting the alert
*/
public function iClickTheElementAcceptingTheAlert($selector)
{
$page = $this->getSession()->getPage();
$element = $page->find('css', $selector);
if (empty($element)) {
throw new Exception("No html element found for the selector ('$selector')");
}
Nun können wir Warten und sogar Javascript Dialoge bestätigen.
Wenn wir nun mit "bin/behat features/XXX.feature" unser Test Scenario XXX starten öffnet sich der Chrome-Browser und wir können alle Tests visuell mit verfolgen.
Leider kann man über den Orange Pi One nicht über den USB-Anschluss mit Strom versorgen sondern braucht ein 5V 2A Netzteil. Ich habe mir dieses Aukru 8 in 1 USB Ladegerät gekauft und mit den Adaptern passte es dann auch und der Adapter sitzt auch so, dass ich erst einmal den Karton als vorläufiges Gehäuse verwenden kann.
Damit stehen den Experimenten mit Motioneye OS nichts mehr im Weg. Wenn das nichts wird, kommt einfach RetroPi rauf :-)
Blog-entries by search-pattern/Tags:
Möchtest Du AdSense-Werbung erlauben und mir damit helfen die laufenden Kosten des Blogs tragen zu können?
Blog: Blog-entries by search-pattern/Tags:
