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.
bezahlt von 
