This blog is about my pet-project (literally) of the last half year. I have a cat - Mio - which was quite lazy when it comes to hunting mice. In the 4 years before last summer he brought home maybe 10 mice. Last summer I moved to a place right next to a large field. As soon as Mio was allowed to use his new cat-door and go to explore his new home, he started hunting. And the thing with most cats that hunt is, that they bring their prey home. There are different theories why they would do that - either to show us humans what they hunted - or just to eat the mice in peace.
Anyway - Mio brought about 3 mice per night and choose to wake us every time. While waking up was bad enough - we also had to clean up the blood and the gall bladder. After about two weeks it was clear that we had to do something - and as I had just read about Microsofts Custom Vision and I was looking for a useful Raspberry PI project for a while, I decided to use the two tools to make sure I could sleep again. The first step was to make sure the Raspi could see the cat coming in - also during the night
Reacting on Motion
The next step was to make sure the Raspi would take images when Mio came home (or a bit simpler - everytime something moved). For that I used the Motion library which I installed as a service on my Raspi. I configured it to save the images into a folder. There is a possibility to directly execute a command when a new image is taken - but as I wanted to use node for all the processing and starting node is much too slow, I kept it just saving the files and used a file watcher within node to react on new images.
During the performance tuning I found the following important points:
Use relatively low resolution images (I used 640x480) - larger images make everything slower but don't really help to recognize things
Take about 6 images per second (framerate setting in motion) - more is too much for the Raspi but with less you loose too much time
Use fs.watch in node - its about 10 times faster than any other watcher function I tested
Optimize other motion settings to your liking - but do not use too many "automatic adjustments" - they need too much CPU
The following code was all that was needed to be able to check any movement visible in the camera
The next part - and the one that everyone told me would never work - was actually pretty simple. All that was needed was Mio bringing lots of mice to generate enough photos to learn from - and some cooperation from the people at CustomVision - thanks again! First I collected all the picture the camera took and sorted them by "cat with mouse" and "cat without mouse" - I uploaded them to CustomVision and tagged them (I ended up having 4 tags: cat, nocat, mouse, nomouse).
After the first few hundred images, I finally had time to connect the service directly - and then noticed that I can tag all images that are uploaded in their interface - much nicer then the sorting & uploading. For the connection to the service I created a separate (npm module that you can use to upload images and get the predictions back. I used the predictions to decide if the door should be closed (at this moment I just sent a mail with the image and a note that the door should have been closed. The "logic" to decide if I was certain enough to close the door is pretty simple: catValue > 0.8 && mouseValue > 0.5 && mouseValue > noMouseValue
Close the Door
Closing the door seemed to be the easiest thing to do. But - I still had to learn something new - how to work with servos. I bought the cheapest servo I could find (a "Makeblock 9g Micro Servo") and used double-faced adhesive tape to stick it onto the door in a way, that the moving element could block the door. I then tried to get the thing moving. If you have not used servos - read this to learn more: Wikipedia: Servo Control. In short - it is a very strange way to control something - at least for people used to digital controls. But of course there are NPM packages to hide the complexity. I used pi-fast-gpio which itself needs pixgpio to be installed. With that it was as simple as this:
const gpio = new piFastGpio();
gpio.connect("127.0.0.1", "8888", function(err) {
if (err) throw err;
gpioReady = true;
// make sure we close the connection when the script ends
process.on('exit', code => {
gpio.setServoPulsewidth(17, 0); // servo off
gpio.setServoPulsewidth(servo2GPIO, 0); // servo off
gpio.close();
logger.info('closed connection to gpio');
process.exit(code);
});
// Catch CTRL+C
process.on('SIGINT', () => { process.exit(0); });
// Catch uncaught exception
process.on('uncaughtException', err => { logger.error(`uncaught exception: ${err}`); process.exit(1); });
});
function moveServo(pulseWith, keepMotorRunning) {
clearInterval(gpioInterval);
clearTimeout(gpioStopTimeout);
gpioInterval = setInterval(function() {
gpio.setServoPulsewidth(17, pulseWith);
}, 20);
if (!keepMotorRunning) {
gpioStopTimeout = setTimeout(function() {
gpio.setServoPulsewidth(17, 0);
clearInterval(gpioInterval);
}, 500)
}
}
function closeDoor() {
clearTimeout(reopenTimeout);
reopenTimeout = setTimeout(function() {
openDoor();
}, keepDoorClosedFor);
moveServo(1200, true); // true let's the motor running - to have more power
}
function openDoor() {
clearTimeout(reopenTimeout);
moveServo(500);
}
This worked pretty well - but - cats are stronger than I thought:
After that I bought a second servo - this did only help partially - the next step now is to install a much stronger servo - I hope this will solve the issue once and for all!
Hallo zusammen! Heute schauen wir uns die vektorbasierte Suche an und warum sie die herkömmlichen Suchmethoden in den Schatten stellt. Lasst uns herausfinden, warum es sich lohnt, gerade jetzt in diese Technologie zu investieren.
Was ist vektorbasierte Suche?
Bevor wir loslegen, eine kurze Erklärung. Vektorbasierte Suche verwendet mathematische Modelle, um Wörter und Phrasen als Vektoren in einem mehrdimensionalen Raum darzustellen. Diese Vektoren erfassen die Bedeutung der Begriffe, basierend auf ihrem Kontext in grossen Datenmengen. Im Gegensatz dazu basieren herkömmliche Suchmethoden oft nur auf Schlüsselwörtern und einfachen, textbasierten Matching-Algorithmen.
Warum herkömmliche Suchmethoden nicht ausreichen
Eingeschränkte Genauigkeit
Herkömmliche Suchmethoden verlassen sich auf die genaue Übereinstimmung von Schlüsselwörtern. Das bedeutet, dass relevante Ergebnisse übersehen werden können, wenn sie nicht exakt die gesuchten Begriffe enthalten. Dies führt zu ungenauen und oft unbefriedigenden Suchergebnissen.
Fehlende Kontextverarbeitung
Kontext ist entscheidend für das Verständnis der Bedeutung von Wörtern und Phrasen. Traditionelle Suchen ignorieren oft den Kontext, was zu irrelevanten oder ungenauen Ergebnissen führt. Zum Beispiel könnte die Suche nach "Bank" sowohl Finanzinstitute als auch Sitzgelegenheiten zurückgeben, ohne zu unterscheiden, welchen Kontext der Nutzer meinte.
Die Vorteile der vektorbasierte Suche
Höhere Genauigkeit und Relevanz
Die vektorbasierte Suche versteht den Kontext und die semantische Bedeutung von Wörtern. Dadurch liefert sie relevantere Ergebnisse, selbst wenn die genauen Suchbegriffe nicht im Text vorkommen. Zum Beispiel erkennt sie, dass "Auto" und "Fahrzeug" ähnliche Bedeutungen haben und liefert passende Ergebnisse für beide Begriffe.
Verbesserte Nutzererfahrung
Dank ihrer Fähigkeit, kontextbezogene und bedeutungsvolle Ergebnisse zu liefern, verbessert die vektorbasierte Suche die Nutzererfahrung erheblich. Nutzer finden schneller, wonach sie suchen, was zu höherer Zufriedenheit und einer besseren Nutzung der Suchfunktionen führt.
Anpassungsfähigkeit an neue Trends
Vektorbasierte Suchmethoden können sich leichter an neue Sprachtrends und -gewohnheiten anpassen, da sie auf umfassenden Sprachmodellen basieren. Dies macht sie zukunftssicher und flexibel gegenüber Veränderungen in der Art und Weise, wie Menschen suchen und kommunizieren.
Effiziente Datenverarbeitung
Durch den Einsatz von Algorithmen des maschinellen Lernens und KI kann die vektorbasierte Suche grosse Datenmengen effizient verarbeiten und durchsuchen. Dies spart Zeit und Ressourcen im Vergleich zu herkömmlichen Suchmethoden, die oft langsamer und ressourcenintensiver sind.
Warum jetzt investieren?
Wettbewerbsvorteil
Unternehmen, die frühzeitig in vektorbasierte Suchtechnologien investieren, können sich einen entscheidenden Wettbewerbsvorteil sichern. Sie bieten ihren Nutzern eine überlegene Sucherfahrung, was zu höherer Kundenzufriedenheit und -bindung führt.
Zukunftssicherheit
Die Welt der Daten wächst exponentiell, und herkömmliche Suchmethoden stossen zunehmend an ihre Grenzen. Vektorbasierte Suchen sind besser gerüstet, um mit dieser Datenflut umzugehen und relevante Ergebnisse zu liefern. Eine Investition jetzt stellt sicher, dass Ihr Unternehmen auch in Zukunft wettbewerbsfähig bleibt.
Kostenersparnis
Obwohl die Implementierung vektorbasierter Suchtechnologien anfangs eine Investition erfordert, führen die Effizienz und Genauigkeit zu langfristigen Kosteneinsparungen. Weniger Ressourcen werden für die Verarbeitung irrelevanter Daten verschwendet, und die Nutzer finden schneller, was sie suchen, was die Produktivität steigert.
Wie viu helfen kann
Wir bei viu verstehen die Bedeutung von fortschrittlichen Suchtechnologien und wissen, wie man sie effektiv einsetzt. Unsere Experten begleiten dich durch den gesamten Prozess – von der Analyse deiner Bedürfnisse über die Entwicklung maßgeschneiderter Lösungen bis hin zur Implementierung und Optimierung.
Mit unserem Fokus auf Ideation & Innovation und einem benutzerzentrierten Ansatz entwickeln wir Suchlösungen, die nicht nur funktionieren, sondern echten Mehrwert bieten. Unser Ziel ist es, dir zu helfen, die Vorteile der vektorbasierte Suche voll auszuschöpfen und deinem Unternehmen den entscheidenden Vorsprung zu verschaffen.
Zusammengefasst
Die vektorbasierte Suche bietet eine präzisere, kontextbezogene und effizientere Möglichkeit, relevante Informationen zu finden. Angesichts der ständig wachsenden Datenmengen und der sich verändernden Suchgewohnheiten ist jetzt der perfekte Zeitpunkt, um in diese Technologie zu investieren. Mit viu an deiner Seite kannst du sicher sein, dass du die besten Lösungen erhältst, die sowohl technische Exzellenz als auch geschäftlichen Mehrwert bieten.
Also, worauf wartest du noch? Lass uns gemeinsam die Zukunft der Suche gestalten!
Obwohl wir in der Schweiz keine vollständige Schliessung hatten, haben die meisten Entwicklungsteams in den letzten drei Monaten von zu Hause aus gearbeitet und werden wahrscheinlich noch einige Wochen in ihren Heimbüros bleiben.
Während dieser Zeit mussten viele Teams Stories für ihren Scrum-Prozess schätzen. Nach einigen Versuchen mit Chat-Nachrichten haben wir schnell ein Tool eingesetzt, das wir einmal an einem VIUday entwickelt haben, um das VUE-Javascript-Framework zusammen mit Firebase für die Datenspeicherung kennenzulernen.
Das Tool ist bei weitem nicht perfekt und die UX war nicht wirklich durchdacht - aber es funktioniert - und wenn du das gleiche Bedürfnis hast und es ausprobieren willst, kannst du das gerne auf scrum.viu.ch tun.
Während dieser Unterschied dazu führt, dass das CMS den Inhalt über APIs in strukturierten Formaten anbieten muss und dementsprechend eine Wiederverwendung in verschiedensten Kanälen möglich wird, ist die andere damit einhergehende Änderung viel bedeutender. Und zwar führt die Loslösung vom Layout im CMS dazu, dass sich die Datenstruktur von «Seiten» und «Komponenten» lösen kann. Der Fokus wird stärker auf den eigentlichen Inhalt und dessen Struktur gelegt. Wohlverstanden, viele «traditionelle» CMS erlauben das auch, aber bei Headless CMS ist es die Grundannahme.
Dies hat einige Auswirklungen:
Fokus auf Inhalte und nicht auf Seiten
Kanal-Unabhängige Inhalte
Kein WYSIWYG Editieren (zumindest bei fast allen Headless CMS nicht)
Keine implizite Navigation (diese würde ja jeweils wieder nur für die Webseite funktionieren)
Gleichwohl werden die meisten Headless CMS Projekte einen oder mehrere «Seiten»-Inhaltstypen haben. Der meiste Inhalt sollte aber nicht in diesen Seiten liegen, sondern nur von der Seite angezogen werden. Der Inhalt kann also auch ohne Seite funktionieren (ein Chatbot, der FAQs beantwortet, sollte keine Links auf Seiten, sondern den Antwort-Text liefern).
Warum ist Headless jetzt in aller Munde?
Headless CMS gibt es schon seit geraumer Zeit – und einige «traditionelle» CMS unterstützen Headless Funktionalität seit vielen Jahren. Das Thema nahm aber erst in den letzten Jahren richtig an Fahrt auf. Dies liegt wohl vor allem an folgenden Punkten:
Die Multichannel-Wiederverwendung von Inhalten nimmt zu
Content Marketing gewann stark an Bedeutung – da hier viel Geld in Inhalte investiert wird, ist eine Wiederverwendung wichtiger denn je
Die unabhängige Implementierung des Web-Channels wurde mit Verwendung von Frontend-Technologien (z.B. React mit Next.js) einfacher
Die Anzahl interaktiver Elemente auf Webseiten nahm zu – diese Komponenten sind sehr oft auf strukturierte Daten angewiesen und können mit «Seiten» nicht viel anfangen
Mit responsiven Layouts mussten sich Editoren schon länger davon lösen, das Aussehen einer Seite genau definieren zu können
Was bedeutet das für Editoren und Marketing-Verantwortliche?
Für alle, die bisher mit «traditionellen» CMS gearbeitet haben, ist es wichtig die Änderungen genau zu verstehen und auch die Gründe und Vorteile, welche sich daraus ergeben, zu kennen. Nur so wird man über das anfängliche «ich kann die Seite gar nicht direkt editieren» hinwegkommen. Wenn das aber geschafft ist, wird auch für Editoren die Arbeit einfacher. Sie müssen sich nicht (oder nur beschränkt) um Komposition kümmern und können die Inhalte in genau den Strukturen abfüllen, welche dafür konzipiert wurden. Jeder Konsument der Inhalte ist dann verantwortlich für eine dem Kanal angepasste Darstellung.
Was bedeutet das für die Entwicklung?
Das CMS ist nicht mehr länger die Basis der Entwicklung. Die Wahl der verwendeten Frameworks und der Programmiersprache ist offen. Dies gibt viel Freiheit und ermöglicht die sinnvolle Nutzung von vorhandenem Wissen oder zum Teil sogar von bereits programmierten Artefakten (Styleguides, die z.B. auf React-Komponenten basieren können sehr leicht für das Rendering dieser Komponenten verwendet werden).
Auf der anderen Seite bedeutet dies auch, dass man auf einiges verzichten muss, was CMS bisher mitgebracht haben:
Authentifizierung / Berechtigungen
Session Management
Personalisierung / A/B-Testing
Navigations-Aufbau
…
Für diese Funktionalitäten gibt es wiederum Services, welche man kaufen kann. Aber selbst, wenn man einen solchen Service zuzieht muss die Integration selbst entwickelt werden. Dies bedeutet initial einen Mehraufwand – im Idealfall spart man sich diesen Aufwand aber an anderer Stelle wieder ein – und kann die Funktionalitäten in anderen Projekten wiederverwenden.
Integrationen
Heute gibt es kaum mehr ein Web-Projekt, welches nicht davon lebt, dass es eine oder mehrere Integrationen in Backend-Systeme zur Verfügung stellt und dem Benutzer damit Zugang zu den verschiedensten Self-Service-Funktionen ermöglicht. Sehr oft wird das CMS als Platform für diese Integrationen verwendet. Dies ist hier nicht mehr möglich. Es gibt prinzipiell zwei Varianten, wie man damit umgehen kann.
Integration über den Browser
Bei diesem Ansatz liefert der Server nur das «Gerüst» der Seite bzw. alle Inhalte, welche nicht aus dem Backend-System kommen. Der Browser lädt danach die Informationen direkt via API vom Backend-System nach. In Praxis wird hier fast immer noch ein weiterer Layer dazwischenstehen – aus Sicherheitsgründen und/oder um die Daten in eine Struktur zu bringen, welche für die Webapplikation sinnvoll ist.
Diese Integration bewährt sich vor allem, wenn eine Authentifizierung gegenüber dem Backend-System notwendig ist. Dabei muss nur der Browser das entsprechende Token besitzen (nach einem Login via Federated Authentication) und kann dieses dann für den Zugriff auf diverse Systeme und Daten verwenden.
Integration über die Rendering-Applikation
Sollten Daten integriert werden, welche unbedingt auch von Suchmaschinen indexiert werden sollen und dementsprechend öffentlich sind, macht eine Integration innerhalb der Rendering-Applikation für den Web-Kanal Sinn. Damit können diese Inhalte auf dem Server gerendert werden und eine Suchmaschine kann das fertige HTML lesen und indexieren. Dies ist übrigens auch einer der wichtigsten Gründe, weshalb Server-Side-Rendering (SSR) für so viele Inhalte wie möglich zur Verfügung stehen sollte.
Anbieter und Tools
Wir haben uns im Laufe der Zeit diverse Headless CMS angeschaut und diese auch teilweise ausprobiert. Dies soll aber kein Review der Anbieter werden. Wichtig ist bei der Auswahl auf jeden Fall, dass man sich (unter anderem) folgende Punkte anschaut:
Preis: Es gibt alles von gratis Systemen bis zu relativ teuren SaaS Angeboten.
Interface / Usability: Die Systeme unterscheiden sich stark in der Übersichtlichkeit, Geschwindigkeit und allgemeinen Editoren-Usability.
«Template»-Vererbung/Wiederverwendung: Welche Flexibilität man beim Aufbau der Inhaltstypen hat beeinflusst die «technische Sauberkeit» der Lösung oft stark und kann auch das Editieren vereinfachen oder unnötig komplex machen.
SDKs / Dokumentation: Für den Bau der Webseite oder anderer Kanäle stehen oft SDKs für verschiedene Programmiersprachen zur Verfügung. Wichtig ist die Qualität des SDKs da dadurch der Aufwand der Implementierung von Lösungen stark beeinflusst wird. Wichtig ist auch, dass die Dokumentation komplett ist und man vom Anbieter guten Support erhält.
Performance & Stabilität: Da viele Systeme von einem Headless CMS abhängig sein können, machen sich Probleme mit dem Headless CMS auch an vielen Stellen bemerkbar und viele Applikationen können dadurch ausgebremst werden.
Sitecore und Headless
Als langjähriger Sitecore Entwickler möchte ich natürlich auch erwähnt haben, dass sich Sitecore auch sehr gut als Headless CMS eignet. Es bringt (schon lange) die wichtigsten Features eines Headless CMS mit.
Freie Definition der Datenstrukturen
API-Zugriff auf alle Inhalte
Was bis 2017 gefehlt hatte war eine SDK für die Verwendung in den bekanntesten Frontend Frameworks. Dies wurde mit JSS aber eingeführt.
Zusätzlich zu den Funktionen eines Headless CMS bietet Sitecore auch Funktionen an, die man sich aus einem Enterprise CMS gewohnt ist, welche aber reine Headless-CMS meist nicht anbieten:
Authentifizierung / Autorisierung
Baumstruktur der Inhalte
Flexible Layouts (falls man die Seiten-Komposition den Editoren überlassen möchte)
Personalisierung / A/B-Testing
Analytics
u.v.m.
Sitecore hat im letzten Jahr klar kommuniziert, dass man in Zukunft (auch) auf SaaS-Angebote setzen wird. Man darf also gespannt sein, ob dies auch ein reines Headless Angebot wird (da dies verhindern würde, dass Sitecore Lösungen betreuen muss, welche Code von Dritten enthält). Mitte 2020 wird man hier wohl genaueres wissen.
Progressive Decoupling
Bei neuen Projekten stellt sich initial die Frage, ob ein Headless CMS oder ein eher traditioneller Ansatz gewählt werden soll. Viel häufiger (zumindest bei unseren Kunden) werden sowieso bereits beide Ansätze parallel eingesetzt. Meist gibt es ein «traditionelles» CMS, welches auch die meisten Seiten «produziert» und gleichzeitig via APIs Inhalte für Applikationen (Single Page Applications oder auch integrierte Komponenten) liefert.
Es ist also möglich die Vorteile beider Ansätze gleichzeitig zu nutzen – und damit natürlich auch einen Wechsel von Traditionell zu Headless schrittweise anzugehen. Dies kann insbesondere bei grossen und schon in die Jahre gekommenen Lösungen ein sinnvolles Vorgehen sein, um eine Modernisierung zu erreichen. Dabei fokussiert man am Anfang vor allem auf Inhalte und Daten, welche sich einfach strukturieren lassen (wie z.B. News, Blogs, Veranstaltungen, …) und bereits in anderen Kanälen benötigt werden.
