Wenn die einzige Steckdose, die an der selben Phase hängt, die aus der Garage kommt und Wlan nicht bis in die Garage reicht.... es funktioniert sehr und darüber wird auch die SAT>IP Lösung laufen.
Und auch die Überwachungskamera funktioniert darüber.
Mein eines eigenes Shopware Plugin hat seinen ersten reallife Einsatz und wird wohl noch mal etwas erweitert.. wenn alles so funktioniert wie ich es hoffe.
Jetzt mit dem Haus reicht es nicht mehr nur die Wohnungstür zu zuschliessen. Da viele Einbrüche über Garten und Terrassentür geschehen soll der Garten überwacht werden. Die Tür ist sicher und ein motorisierter Rollladen sichert nochmals ab. Also geht es mehr darum mögliche Einbruchsversuche zu dokumentieren.
Es ist ein ieGeek 720p IPCam für außen und mit LAN + WLAN. SD-Karte ist wohl auch möglich, ich will aber lieber FTP verwenden.
NAS mit FTP-Server kommt dann als nächstes und dann wird die Kamera installiert und kann benutzt werden. Die Bildqualität (720p) gefällt mir aber schon sehr gut.
Nachdem ich mich jetzt einige Tage lang mit Kotlin beschäftigt habe, bin ich noch etwas zwiegespalten, ob Kotlin mit seinen Ansätzen, es wirklich besser oder einfach nur anders macht.
Einiges was da an Java kritisiert werde, halte ich in Java sogar für besser gelöst, wobei ich aber durch aus die Kritik verstehe. Zum Beispiel haben== und equals() schon genug Leute/Einsteiger verwirrt.
Kotlin macht es anders. == und === sind wirklich logisch und nachvollziehbar. Es folgt der Umsetzung in PHP oder JavaScript. == vergleicht den Wert und === vergleicht die Referenz.
Aber ist == als Ersatz für equals() wirklich besser?
Date d = new Date();
MyDateImpl md = new MyDateImpl();
Es ist durchaus möglich das eine Klasse von mir sich mit sich mit einer standard
Java-Klasse vergleichen lässt, aber die standard Java-Klasse nicht mit meiner, da deren Existenz der standard Java-Klasse natürlich vollkommen unbekannt ist.
val d = Date()
val md = MyDate()
if(d == md){
println("== 1")
}
if(md == d){
println("== 1")
}
Ist das jetzt beides das selbe? Konnte ich auf die Schnelle nicht heraus finden.. werde ich wohl mal testen müssen.
Ist es falsch das Java einen zwingt eine Exception zu fangen, wenn explizit eine geworfen werden kann.
Also das Fehler dort behandelt werden, wo sie auftreten und man sie nicht immer bis ganz nach oben reichen sollte?
public class ThrowExample {
private void method1() throws Exception {
throw new Exception("test");
}
public void call() throws Exception {
this.method3();
}
}
Bei Java kann es so nie passieren, dass am Ende eine Exception auftaucht, von der man nie wusste, dass sie geworfen wurde. Weil sie entweder schon mit einem Try-Catch-Block gefangen wurde oder aber man über die Existenz dieses Exception mit Hilfe des "throws" an der Methode direkt informiert wird.
PHP hat mit Exception ab PHP 7.0 viel verbessert, aber um die Wahrheit zu sagen, ist das was ich noch gerne hätte ein "throws" damit ich weiß, dass in der Methode, die ich gerade verwende, das Werfen einer Exception implementiert wurde.
Fehler Behandlung ist schwer und Exceptions als brauchbare Fehlermeldungen an den Benutzer hoch zu reichen ist nicht einfach... aber einfach dann die Exceptions bis zum Benutzer durch laufen zu lassen ist doch eher der falsche Weg und ein gutes Exception-Handling Framework wäre die bessere Lösung gewesen.
Deswegen sehen ist den Verzicht auf den Zwang Exceptions fangen zu müssen in Kotlin eher negativ und nicht als Vorteil.Nur als einen Punkt nun dem Entwickler aufgehalst wird (er muss sich nun darum kümmern, dass Exceptions richtig behandelt werden), wo vorher der Compiler einen dabei unterstützt hat auch alle Exceptions richtig zu behandeln.
Ich hatte bei der Entwicklung von mein-online-adventskalender.de schon sehr darauf geachtet, dass es sich leicht integrieren lässt. Aber bei meinem Test mit Shopware hat sich gezeigt, dass es auch wirklich gut klappt.
Ich hab es über ein Iframe-Element in einer Einkaufswelt eingebunden. Das Element sollte eine Höhe von 1350 haben auf dem Desktop.
Vielleicht baue ich im Herbst ja noch mal ein richtiges Plugin dafür :-)
Die Spiele-Entwicklung mit JavaScript und dem Canvas war eine wirklich gute Zeit... man fühlte sich wie ein Künstler.. man war kreativ und hat kein Geld verdient damit.
Wenn man in JavaScript mit dem Date-Object arbeitet und mit dem Jahr rechnen will, immer dran denken, dass man getFullYear() verwenden muss und nicht getYear().
Sonst sitzt man da und wundert sich mal wieder warum man gerade im Jahr 118 ist und nicht in 2018.
In den nächsten Tage werde ich meinen Samstag in Bremen beim Oldtimer mit dem Switch GmbH Time-System in einen Blog-Post zusammen fassen. Es geht um RFID, Zeitmessungen, Notebooks als Werkzeug und nicht als Deko-Objekt, Thinkspads, Surface und viel viel viel Regen.
Momentan steht bei mir an ein Plugin für Shopware zu entwickeln.
Das erste Problem dabei ist nicht mal, wie das funktioniert, weil das ist im Internet mehrfach gut erklärt, sondern wie man seine Entwicklungsumgebung aufsetzt.
Shopware ist schnell installiert. Aber man will für ein Plugin ja nicht immer das gesamte Shopware mit im Projekt haben. Also wird nur das Verzeichnis aus custom/plugins/ als Projekt-Verzeichnis gewählt.
Bei Eclipse kann man Projektverzeichnisse außerhalb des Workspaces anlegen.
Nun hat man das Problem, dass einem die ganzen Klassen von Shopware fehlen und man so viele Warnings und keine Autovervollständigung hätte.
Über Properties > PHP > Source Paths > Build Path kann man externe Source-Verzeichnisse verlinken.
ich habe das engine-Verzeichnis von Shopware gewählt und noch zusätzlich dessen vendor-Verzeichnis.
Die PHPUnit Tests werfen dann zwar noch Fehler. Aber die Plugin-Klasse von Shopware wird schon einmal gefunden und damit ist der erste Schritt schon getan.
Damit kann meine Arbeit an meinem ersten Shopware-Plugin jetzt anfangen.
Manchmal hat man das Problem, dass man vor Ort keinen Strom hat. Notebooks lösen das Problem. Doof nur wenn man auch zusätzliche Geräte wie RFID-Reader oder Netzwerk-Switches mit versorgen muss. Ich werde Samstag mal ein Akku-Pack testen. Eigenlicht ist es für mobile Blitzanlagen gedacht, aber mit etwas Glück funktioniert es auch für andere Geräte.
- sehr kleine Ansicht des TinyMCE und keine gute Code-Ansicht (wie Codemirror oder so)
- Bilder werden immer mit festen Pixelwerten skaliert
- Es kommen CSS-Klassen hinein die man nicht will
- IMG sind z.B. immer Block-Elemente und nicht inline wie man es erwarten würde und dann geht einfache "text-align:center;" nicht
- Das Handling von ausgeblendeten Elementen ist nicht wirklich gut
- Das Scaling-Verhalten der Banner lässt sich nicht konfigurieren
- Direkte Rahmenstyles für die Boxen wäre toll
- kein Undo
- Ein Grid wie in Bootstrap mit automatischer Anpassung an die Bildschirmbreiten fehlt, auch wenn die vorhandene Lösung schon ganz ok ist
- Im- und Export von Einkaufswelten kommt erst mit 5.3 - Am Ende muss man doch relativ oft an den HTML-Code und CSS-Klassen und so anpassen
Aber man muss am Ende doch nochmal sagen.. für mich ist es die Beste Lösung, die es momentan gibt und auch durchaus von Leuten bedienbar ist, die wenig mit HTML und WebDesign zu tun haben.
Wenn man mit dem sBasket von Shopware zutun hat und auch mal selbst was in den Basket legen möchte und dann vielleicht ist das was man rein tun möchte kein standard Artikel sondern ein Rabat oder ähnliches, kommt man schnell zu dem Feld Modus/Mode.
Um die Magicnumbers zu decodieren muss man etwas tiefer suchen.. in der cart_item.tpl.. wäre jeder sofort drauf gekommen.. oder?
{* Constants for the different basket item types *}
{$IS_PRODUCT = 0}
{$IS_PREMIUM_PRODUCT = 1}
{$IS_VOUCHER = 2}
{$IS_REBATE = 3}
{$IS_SURCHARGE_DISCOUNT = 4}
Gutscheine findet man also dann bei Einträgen mit dem Mode 2. Gerade bei Exports von Bestellungen für externe Systeme kann dieser Mode sehr praktisch sein.
Die Einträge mit der 3 werden bei jedem Anzeigen neu aufgebaut und somit werden Positionen, die man einfach in die DB schreibt auch sofort wieder gelöscht. Für den Zweck scheint Mode 4 der richtige zu sein. Wobei ich dort noch Probleme mit dem Löschen habe, aber das kann ich sicher noch über ein Event oder Hook lösen.
Morgen beginnen die Test meiner ersten beiden Shopware Plugins. Teilweise sehen sie auch wirklich wie "die ersten" aus, auch wenn ich nochmal viel nachgebessert habe. Aber gerade optisch ist noch viel Raum nach Oben. Bis Freitag kann man da sicher noch was machen, um auch optisch noch was besseres abliefern zu können.
Weitere und bessere Plugins, aber erst einmal ohne Oberflächen, sondern als Unterstützung für Entwickler und Designer, folgen dann hoffentlich in den nächsten Wochen und Monaten.
Zeitmessungen bei Rennen müssen nicht immer mit RFID gemacht werden. Man kann auch ganz einfach einen PC, ein Tablet oder ein Smartphone pro Messstation nehmen und eine Person muss nur auf die Teilnehmer-Nummer klicken/drücken, um eine Messung zu speichern.
Für die meisten Rennen im Amateurbereich ist die Genauigkeit mehr als ausreichend. Also ein vollständiger Ersatz für Stoppuhren oder andere Smartphone-Apps, die man sonst für Kontrollmessungen verwenden würde.
Und alles natürlich dann in Echtzeit auf dem Server.