Viele Entwickler setzen mittlerweile auf die Unterstützung von automatisierten Tests und gewährleisten dadurch ein frühe Fehlererkennung, geringere Kosten bei der Behebung und schlussendlich eine hohe Qualität. Dennoch können Fehler nicht vollkommen ausgeschlossen werden.
Einer der Gründe hierfür ist, dass die Tests in der Regel nur in Testsystemen ausgeführt werden. Somit ist eine Aussage hinsichtlich der Funktionsweise im Produktivsystem nicht gegeben. Anwender überraschen uns Entwickler gerne mit unkonventionellen Eingaben oder einer eigenwilligen Bedienung der Software. Dies kann unter Umständen zu schiefen Datenständen führen. Was also in der Entwicklungs- bzw. Testumgebung funktioniert, muss dies noch lange nicht in der Produktivumgebung tun. Was kann man nun unternehmen, um eine bessere Aussage treffen zu können?
Eine Möglichkeit besteht im Blue Green Deployment. Dabei besteht das Produktivsystem zweimal. Einmal als blaue, einmal als grüne Linie. Aktiv ist immer nur eines der beiden Systeme. Das inaktive System kann für Tests herangezogen werden. Dabei können die Systeme auf unterschiedlicher (aber ähnlicher) Hardware oder VMs laufen.
Ein neues Release wird dabei immer am inaktiven System eingespielt und getestet. Sind alle Tests erfolgreich und stehen alle Funktionen zur Verfügung, wird das inaktive zum aktiven System und umgekehrt. In anderen Worten: War das blaue System aktiv und das grüne System inaktiv, dann erhielt das grüne System das Update und wurde nach erfolgreichen Tests aktiv. Nun ist das blaue System inaktiv und erhält das nächste kommende Update.
Dies bietet natürlich auch noch weitere Vorteile. So ist es sehr schnell möglich, wieder auf die alte Version zurückzugehen (Rollback). Zudem steht ein zweites System bei Ausfällen (Hardware etc.) zur Verfügung.
Die zusätzliche Sicherheit bringt jedoch einige Herausforderungen hinsichtlich Infrastruktur, Deploymentprozess, aber auch der Entwicklung (z.B. Umgang mit Schemaänderungen an der Datenbank) mit sich. Belohnt wird man durch eine höhere Ausfallssicherheit und einer möglichen (verbesserten) Aussage über die Funktionsfähigkeit eines neuen Releases im Produktivsystem.
Darauf aufbauend kann ein Canary Deployment eine noch bessere Aussagekraft im Produktiveinsatz geben.
In der Standardeinstellung (für die meisten wohl ok, für Softwareentwickler richtig grausam), sind die Funktionstasten nur die zweite Belegung auf der Tastatur. In der primären Belegung werden die Multimedia-Tasten verwendet. Wer mit Funktionstasten arbeitet, kommt damit überhaupt nicht klar, vor allem, weil es auch einen Bruch in der bisherigen Bedienung darstellt.
Zum Glück kann dies im BIOS umgestellt werden. Nachfolgend siehst du die Standardeinstellung.
Dell XPS 13 Bios
Wähle einfach Lock Mode Enable/Secondary im Abschnitt POST Behavior/Fn Lock Options und schon sind die Funktionstasten wieder ohne Fn zu verwenden.
Heute habe ich wieder einmal Musik ausgepackt, die ich schon länger nicht mehr gehört habe. Spontan erinnerte ich mich an frühere Konzertbesuche und war überrascht, wie intensiv sich die Erinnerungen ausfühlen.
Es waren hauptsächlich kleine Konzerte, mein Musikgeschmack lag abseits des Mainstreams (das tut er zum Glück immer noch, bin jedoch dahingehend offener geworden). Da waren Konzerte von Subway to Sally, ganz besonders ist mir das Konzert von Nightwish 2000 in positiver Erinnerung. Das war noch ein paar Jahre bevor Nightwish auf MTV gespielt wurde – ein kurzer Hype, aber das Konzert 4 Jahre später, war um Dimensionen größer.
Eines der besten Konzerte überhaupt, war von Tanzwut. Es muss 1998, 1999 gewesen sein, so genau weiß ich es nicht mehr. Mehr als 20 Leute, inklusive Band, waren wohl nicht da, aber der Sänger hat sich ins Zeug (bzw. die “Menschenmenge”) geworfen und richtig Stimmung gemacht. So muss dann wohl eine Privatvorstellung sein. Hautnah dran, quasi schon selbst auf der Bühne (denn die Bühne kam de facto ins Publikum).
Im Gegensatz dazu, habe ich auch richtig große Konzerte erlebt. Depeche Mode, Metallica oder aber AC/DC (mit über 115.000 Besuchern war es das bis dato größte Konzert Österreichs). Keine Frage, diese Konzerte waren gut, aber man sah ihnen an, dass etwas fehlte. Es lag nicht an der Stimmung oder den Besuchern, aber der “Spirit” fehlte für mich.
Was aber will ich damit sagen?
Als ich damals die Konzerte von unbekannten Bands besuchte (gemessen am Bekanntheitsgrad von Metallica und Co.) war mir in keinster Weise bewusst, wie sehr sie mir alle in Erinnerung bleiben würden und wie stark die damit verbundenen Emotionen sind. Ich bin meinem Herzen gefolgt und habe mich nicht dem Mainstream (dem Marketing) hingegeben. “Belohnt” wurde ich durch tolle Erlebnisse, viel Spaß und wunderbaren Erinnerungen.
Es war alles viel ehrlicher (wenngleich da natürlich auch Poser dabei waren, keine Frage) und bodenständiger – schließlich konnten nicht alle ausschließlich von der Musik leben (umso mehr warfen sie sich ins Zeug).
Das kann man auch aufs Berufsleben umlegen. Manche suchen sich die Jobs, die mehr Kohle bringen und arbeiten, ohne Herzblut, ohne Glaube an die Sache. Die Erinnerungen auf den höchsten Bonus gerichtet, oder aber ganz anders, auf das, was man erreicht hat. Auf ein tolles Produkt oder Service, auf zufriedene Kunden, die das erhielten, was sie wirklich brauchten – und nicht, was den höchsten Bonus versprach.
Zwar kann man sich im Berufsleben nicht immer alles aussuchen, aber viele haben die Möglichkeit, ihren Beruf selbst zu wählen, zu entscheiden, in welcher Branche sie arbeiten möchten usw. Wem das verwehrt ist, bleibt immer noch die persönliche Einstellung. Mit Freundlichkeit, Humor und Engagement kann vieles überwunden, erschaffen und verbessert werden – und wenn es nur darum geht, es erträglicher zu machen. Es steht und fällt soviel mit dem eigenen Herzblut und den Werten. Es zahlt sich aus, diesen Weg zu gehen, auch wenn er mühevoller ist. Ein Rockstar zu sein, ist sicher geil, aber nicht, wenn man sich dafür verbiegen muss.
Nur Leidenschaft liefert außergewöhnliche Ergebnisse.
Richtig gute Ergebnisse und Leistungen entstehen nur durch ausreichend Leidenschaft für das Thema oder die Sache. Nur dann lassen sich auch andere Menschen und Teams begeistern. Tolles wird ohne Übermengen an Energie erzeugt. Fehlt das, dann ist etwas faul. Mit der Umgebung, mit der eigenen Einstellung oder schlicht mit dem Vorhaben.
Ich fühle mich geehrt, heute einen Gastbeitrag eines hoch geschätzten Community-Kollegens hosten zu dürfen. Er ist allerorts bekannt und ein interessanter und beliebter Gesprächspartner: Peter Nowak. In diesem Beitrag wird das Thema “Der Mensch als Gewohnheitstier” und wie aktiv unterstützt werden kann, anhand eines Praxisbeispiels, behandelt.
Meine Historie liegt in der Entwicklung von Anwendungen. Damals habe ich schon nicht verstanden, wieso man so viel Überzeugungsarbeit benötigt, andere Personen von seinen Ideen zu überzeugen. Schlimmer noch – die Wahrheit war direkt vor Ihnen, aber die Kunden konnten es nicht sehen. Mit meinem Wechsel in den Bereich der Beratung waren es nun Systeme, die ich den Kunden anbot. Aber auch hier wieder das gleiche Problem: Während die Wahrheit vor Ihnen lag, konnten Sie es nicht sehen.
Ich habe mittlerweile gelernt, wieso es so ist: Man hat einerseits verlernt zu Lernen und dann war das noch das Problem mit dem Vertrauen. Dazu aber später mehr.
Das Problem
Durch meinen Werdegang habe ich gelernt, dass das Thema Vertrauen und Lernen weitaus wichtiger sind, als die Technik, die ich damals gelernt habe. Es ist schon sehr wertvoll für mich, mich neuen Situationen und Herausforderungen anpassen zu können – eine Eigenschaft, die Viele im Verlauf der Zeit verlieren.
Aus diesem Grund finde ich es faszinierend, dass Probleme aus dem Business auch in ganz alltäglichen Bereichen auftauchen: Dem Vorgang des Einkaufens.
Mein favorisierter Supermarkt hat letztes Jahr ein Future Store Konzept bei den Kassen umgesetzt. Während Selbstbedienungskassen bereits ein alter Hut sind, so hat man insbesondere den Prozess des Bezahlens an der Kasse optimiert.
Ist-Zustand
Bisher ist es so, dass man mit seinem Einkaufswagen zum Förderband vorfährt, dort die Waren auflegt, mit dem Wagen zur Kasse vorfährt und dort alles über den Scanner erfasst wird. Abgeschlossen wird mit dem Bezahlvorgang, egal ob mit Bargeld oder bargeldlos.
Das Problem für einen Selbst ist – man steht (gefühlt) immer an der falschen Kasse. Entweder sind es die Personen, die langsam die Ware vorne auf das Band legen, oder die Person, die mit kleinen Münzen bezahlt und aus diesem Grund den Bezahlvorgang in die Länge zieht.
Veränderter Prozess
Der besagte Supermarkt hat den Prozess mit Hilfe neuer Systeme verändert. Vor Kopf des Kassensystems steht nun der Verkäufer. Man fährt den Einkaufswagen zu ihm und er packt für einen dann die Ware aus dem Einkaufswagen auf das Band, wobei es zeitgleich eingescannt wird. Am Ende des Bandes steht ein leerer Einkaufswagen, den der Kunde dann wieder befüllt. Ist der Vorgang abgeschlossen, dann bezahlt der Kunde autark die Waren an einem von zwei Terminals, die zu diesem Kassensystem gehören – egal ob mit Bargeld oder Karte.
Foto von Peter Nowak
Die Vorteile dieser Änderung liegen auf der Hand, den damit werden zwei Flaschenhälse des Prozesses eliminiert: Die Blockade des Verkäufers durch den synchronen Bezahlvorgang, wie auch der Scanprozess, der während des Bezahlvorgangs durch den blockierten Verkäufer nicht fortgesetzt werden kann. Das Resultat ist, dass die Schlangen an der Kasse massiv minimiert wurden und der Bezahlvorgang somit schneller abläuft.
Erfolg auf ganzer Linie, oder?
Ich persönlich freute mich, dieses System zum ersten Mal zu testen. Die Neugier eine neue Erfahrung zu machen, dass ein alter Prozess geändert wird und zu sehen, wie dieser in der Realität funktioniert waren spannend. Ich finde bis heute die Änderung großartig.
Doch dieses Projekt ist eins, dass abgeschlossen ist. Ziel war es die Zeit des Bezahlvorgangs zu minimieren – und das wurde auch erreicht. Das neue Kassensystem hat sich bewährt – und auch der Hersteller ist zufrieden. Typisches Wasserfallmodell eben.
Da ich hier wöchentlich einkaufen gehe, ist mir nach kurzer Zeit aufgefallen, dass diese Optimierung des Bezahlvorgangs nicht überall auf Gegenliebe stößt. Aber warum nicht? Häufig höre ich ein Gemecker von der Seite. Erst gestern wieder hörte ich einen Kunden sagen „Und das soll der Fortschritt sein?“. Was war passiert?
Fehlendes Changemanagement für die Kunden
Während der Anfangsphase das Personal noch üppig vorhanden war, um das neu ausgerollte System dem Kunden zu erklären, fehlt dies nach einem Jahr natürlich. Zwar sind die Verkäufer redlich bemüht es dennoch zu tun, aber nicht immer haben Sie die Möglichkeit dazu, denn der Kunde will ja fertig werden und sich nicht mit Veränderungen aufhalten. Was man hier vergessen hat ist, dass selbst heute neue Kunden in das Geschäft kommen, die das System einfach nicht kennen und mit einem Kulturschock konfrontiert sind.
Meistens sieht man dies Verhalten der Unzufriedenheit bei Personen ab 45 / 50 Jahren. Sie verstehen nicht, wieso man etwas, was man einmal gelernt hat, nun unbedingt verändert muss. Seit über 30 Jahren hat man seinen Wagen ans Band gefahren, entladen und hinten bezahlt. Und nun fehlt auf einmal am Bezahlterminal das eine Interaktion mit einem Menschen und man muss sich mit so einem Automaten abgeben. Da muss man erst einmal Suchen, wo das Geld hinein muss, oder wo ich die Karte reinschiebe. Und dann auch noch ein Touchscreen. Was soll der Quatsch? Der Kunde muss sich nun mit etwas Auseinandersetzen, was er über Jahre mittlerweile als banal empfunden hat. Er wird förmlich dazu gezwungen, was Unmut erzeugt.
Wie also besser machen?
Meistens hat man immer noch ein bis zwei Minuten, bis man zum Bezahlvorgang kommt. Ein einfacher, permanenter und gut lesbarer Aufsteller vor jeder Kasse wäre hier hilfreich. Einfache Piktogramme, wie man sie aus Anleitungen eines berühmten schwedischen Möbelhauses oder aus den Sicherheitsanweisungen aus dem Flugzeug kennt, wären kostengünstig herzustellen. Für Neukunden hätte es den Vorteil, dass sie sich bereits geistig auf eine aufkommende Veränderung einstellen könnten und der Stress, akut auf eine veränderte Situation reagieren zu müssen, wäre minimiert.
Fazit
Gerade in einer Zeit, in der alles schneller wird (ob nun positiv oder negativ gesehen), sind es genau solche Momente, wo man sich Zeit nehmen muss noch einmal das große Ganze zu betrachten und nochmal zu prüfen, ob man auch alles bedacht hat. Die zweite Variante wäre eine Kundenbefragung durchzuführen, oder sich als Mitarbeiter der Kassensysteme einfach mal Zeit nehmen und beobachten, wie sich das System entwickelt hat. Leider wird das wohl aber nie passieren, denn ich denke, dass das Projekt abgeschlossen ist.
Peter Nowak ist Buchautor und altbekanntes Communitymitglied im Microsoftumfeld. Als Entwickler gestartet, wofür er auch 10 Jahre jeweils mit dem Microsoft MVP Award ausgezeichnet wurde, entwickelte er sich zum IT Architekten weiter. Mittlerweile nutzt er jedoch seinen IT Background, um Kunden mit Kreativtechniken und Ideenworkshops zu unterstützen. Während er in der Vergangenheit jede Menge WIE-Fragen geklärt hat, unterstützt er nun Kunden bei der Klärung der WAS- und WOZU-Fragen in den Bereichen Innovation und Digitalisierung, wie auch dem Portfolioaufbau und -management.
Sie erreichen Peter via @PeNoWiMo oder über LinkedIn
Über Microservices gibt es zahlreiche Bücher und noch viel mehr Artikel. Darin finden sich darin auch viele Erfahrungen, Tipps, Meinungen und jede Menge Vorteile. Als einer dieser Vorteile taucht gerne die Wahlfreiheit der verwendeten Sprache/Plattform auf. Darauf möchte ich in diesem Beitrag näher eingehen.
Grundaussage
Ein Microservice ist eigenständig. Es läuft in einer passenden Umgebung. Alleine, oder zusammen mit anderen Microservices. Jedes Microservice kann für eine andere Plattform/Programmiersprache (C++, Java, .NET, Haskell, Rust, etc.) entwickelt werden.
Die Vorteile:
Die Umsetzung kann mit der Plattform/Programmiersprache umgesetzt werden, mit der sich die Anforderungen am besten abbilden lassen.
Softwareentwickler müssen nicht mehr dieselbe Plattform/Programmiersprache lernen, sondern können ein Microservice mit bereits vorhandenen Kenntnissen umsetzen. Das spart Zeit und bietet Vorteile bei der Suche neuer EntwicklerInnen.
Was bedeuten diese Vorteile in der Realität?
Machbarkeit/Realitätsnähe
Bei der Mitarbeitersuche nicht mehr auf eine Plattform Rücksicht nehmen zu müssen, klingt gut. Gerade in Zeiten, in denen jeder Softwareentwickler umkämpft, wie nie zuvor, ist.
Für das Unternehmen (und in weiterer Folge auch den Mitarbeitern) ergibt sich jedoch ein anderes Bild:
Neue Plattformen benötigen zusätzliches Know-how. Eine Entwicklungsmaschine ist schnell eingerichtet, für den Produktivbetrieb gelten andere Anforderungen hinsichtlich Administration, Konfiguration, Sicherheit usw. Es entstehen zusätzliche Kosten und Risiken.
Wer pflegt und führt die Weiterentwicklung fort, wenn der ursprüngliche Entwickler nicht (mehr) verfügbar ist? Durch Krankheit, Unfall oder Kündigung kann ein erheblicher Aufwand durch Know-how-Verlust auf das Unternehmen zukommen. Nicht selten wird Software neu entwickelt, weil dies insgesamt günstiger kommt.
Um Themen wie Performance-Optimierungen etc. bewältigen zu können, bedarf es tiefgreifenden Wissens über den Technologiestack. Denselben Grad an Tiefe über mehrere Plattformen hinweg aufzubauen und dabei auch am aktuellen Stand zu bleiben, ist eine aufwändige und damit kostenintensive Angelegenheit – und auf lange Frist in der Regeln nicht machbar.
Bei einem Blick auf die Unternehmensverteilung in Österreich, sind 99,8% der Unternehmen laut WKO im Jahr 2017 99,8% der Unternehmen den KMU zuzuordnen (0-249 Mitarbeiter). In Deutschland sieht dieses Bild ähnlich aus. Hier sind es laut Statista 99,6%.
Internationale Großkonzerne sind aufgrund der vorhandenen Mittel im Vorteil. Einschlägige Softwareunternehmen an der oberen Grenze, die zudem mit einem einzigen Produkt am Markt sind, könnten dies ebenfalls bewältigen. Der Rest sollte tunlichst die Finger davon lassen.
Fazit
Nicht jeder genannte Vorteil, entpuppt sich als solcher. Microservices haben ihre Daseinsberechtigung. Einzelne Services auf unterschiedlichen Plattformen aufsetzen zu können, kann in manchen Fällen tatsächlich sinnvoll und hilfreich sein. Tatsächlich muss dies im Sinne der Wirtschaftlichkeit hinterfragt werden und keinesfalls frei von jedem Entwickler im Unternehmen entschieden werden können.
Much has already been written about automated software testing – by me as well. Still there are so many developers out there, who say automated tests only costs money and time and so they rather put their time into building more functionality. Because this is, what the customer needs – they think. Some developers even think they are godlike, their code can’t have any defects, so there is no need for automated software testing. My experience tells another story though …
Automated testing is so expensive
Many years ago, I was developing a SaaS solution with a team of developers. We created a monolithic service having many features, but we wrote no automated tests. Every three or four months there was a “testing phase”. Everyone in the company (~ ten people) had to test the software the whole daylong. This lasted for about two weeks and resulted in lists of hundreds of bugs. The following few weeks were used to fix all those bugs, no new features were implemented.
Some years later, we decided to move to a new technology for our user interface (ASP.NET web forms to AngularJS). As part of this change my team got the chance to transform the monolithic application into several microservices. As the lead of this team, I promoted the implementation of automated tests. We wrote unit tests as well as integration tests for our web API endpoints. Even our Angular front-end code had been tested. Each team member had to run all tests before committing changes to our source control.
What do you think was the result of introducing automated tests?
We only had three to four bugs a month reported by colleagues or customers and could focus on building new features and a better user experience, improve performance and do research. No more testing and bug fixing weeks. That saved us so much money! Unbelievable. And we really loved it.
But writing tests costs time/money
This is the number one argument. Of course, it does! But: The more tests you write and the better you get at it, the less time you need. You will not only learn how to write tests very fast, you’ll also gain a sense for what is important to test.
So, writing unit and/or integration tests costs money. Right now. However, it saves money in the future. Neglecting to write tests saves money now, but costs dearly in the future. Let us have a look into the details.
Costs for writing tests
Again, writing tests needs time. However, every test helps to avoid failures in future. Of course, bugs can arise and you have to fix them, but you can do that in a test-driven manner. Write a test which assumes the correct behavior, then fix the bug until everything is fine and the test completes successfully. This failure will not bother you anymore in future.
Depending on your software, your test coverage and the used types of automated tests, you still may need to perform manual tests as well though.
Costs for not writing tests
In case you don’t want to deliver untested software, you have to do manual testing to find bugs. For these tests, detailed test cases are necessary. In reality, they too hardly exist if there was a decision against automated testing – costs are the basis of such decisions.
Doing manual tests is very time-consuming. It is reasonable to test manually even if you have automated tests, but the expenditure of time will be much higher if there are no automated tests.
Only relying on manual tests cause some negative effects (and they are cost-effective):
The software developer has to try to understand the code again when bugs are found weeks or months after the implementation. The sooner the bug was found, the better.
Generally, more bugs will be reported by customers if there is no automated testing. This ties up a lot of resources on the customers side and of course also at your own company (someone has to file the ticket, try to reproduce the bug, manage development planning, another testing phase has to be planned, a new release has to be scheduled and delivered, release notes have to be communicated and so forth).
In case of unit tests, the software design will be clearer and coupling will be lower. If you work actively with unit tests you tend to be in intensive care of the software design because you think about usage of your classes and methods. This leads to less complexity and higher maintainability.
Deployment could be relatively easy in case of a SaaS solution but that would become much more complex (and expensive) if you have a lot of on premises installations, especially in complex industrial infrastructures.
Positive side effects
I run all tests before committing my changes to the source control. This provides instant feedback and things can get fixed immediately.
Automated tests are an investment in the future of your software as well as your company. Someday a refactoring will be necessary. Automated tests greatly minimize the risk that accidental behavior changes occur, even when the software design or the implementation changes.
There is another cool thing about automated tests: Run them with a nightly build and log the execution times into a database. This makes it possible to trace performance of your software. Doing this daily provides a great feedback about the impact of the implementations made.
Conclusion
In reality, it is much more expensive to neglect to write tests. Some ignore the fact that the costs will incur much later. They just see less cost in development, but this is – in my opinion – a big mistake. My advice is to write both unit tests whenever reasonable, as well as integration tests for your entire API.
Während die einen alle ihre Daten in die Cloud packen, gehen andere bewusster mit ihren Daten um. Sie suchen sich Lösungen, die sie nicht zur Abgabe der Kontrolle über ihre Daten zwingen. Wer ein System von Synology besitzt, bekommt eine solche Lösung frei Haus: Note Station.
Note Station wird auf dem eigenen Synology-Gerät installiert und stellt dann ein Service für die Verwaltung von benutzerbezogenen Notizen und Aufgaben zur Verfügung.
Funktionsumgang
Mittlerweile ist die Note Station nicht mehr ganz so jung und der Fuktionsumfang kann sich richtig sehen lassen:
Notizen
Notizbücher
Suchfunktion
Tagging
Attachments
Inline-Bilder
Audio-Aufnahmen
Diagramme
Verschlüsseln von Notizen
Anzeige im Präsentationsmodus
Interessant sind auch die Smart-Notizbücher. Diese können mit Schlagwörtern versehen werden und suchen alle passenden Notizen aus den vorhandenen Notizbüchern.
Aufgaben
Erinnerungen
Favoriten-Markierung
Unteraufgaben
Prioritäten
Integration zu Notizen
Neben einer Desktop-Version steht auch eine App für mobile Endgeräte (Android und iOS) zur Verfügung. Darüber steht ein Offlinemodus zur Verfügung.
Teilen
Notizen können natürlich auch mit anderen Personen geteilt werden. Dies ist sowohl für am System vorhandenen Benutzer bzw. Gruppen möglich, als auch extern. Das externe Teilen funktioniert über einen Teilen-Link. Ein externer Zugriff auf das Synology-Gerät musste zuvor über die System-Einstellungen eingerichtet werden.
Apps
Neben Apps für den Desktop (Windows und Mac), stehen auch entsprechende Apps für Android und iOS zur Verfügung. Die Desktop-App ist über das Download-Center verfügbar, die mobilen Apps über die jeweiligen App-Stores.
Synchronisation
Die Synchronisations-Möglichkeiten sind abhängig vom eingerichteten System. Ist die Synology-Station nur im eigenn Netzwerk verfügbar, kann auch nur darin synchronisiert werden. Ist eine externe Nutzung (z.B. via QuickConnect) eingerichtet, erfolgt eine Synchronisation überall. Die Synchronisation erfolgt problemlos und zuverlässig.
Einschränkungen
Ein Feature fehlt mir wirklich sehr: die Archivierung einzelner Notizen. Es können ganze Notizbücher archiviert werden, einzelne Notizen hingegen nicht. Dies bedeutet mit der Zeit entweder eine lange Liste von Notizen im Notizbuch oder man verschiebt diese in ein eigenes Notizbuch. Alternativ werden alte/aufgearbeteite Notizen gelöscht, was nicht immer wünschenswert ist.
Zudem würde ich mir eine Markdown-Unterstützung wünschen.
Fazit
Wer keine klassischen Cloud-Lösung für die Verwaltung seiner Notizen, Audioaufnahmen, Aufgaben etc. verwenden möchte und zudem ein Synology-System zur Verfügung hat, der findet in der Note Station eine zuverlässige Lösung. In der täglichen Verwendung gibt es keine Einschränkungen was den Zugriff, die Synchronisation und die Zusammenarbeit betrifft.
Was macht Amazon, Google, Apple und Facebook aus? Warum haben sie diese derartige Größe und marktbeherrschende Situation erlangt? Nach welchen Maßstäben werden Produkte so derartig beliebt? Welche Strategien wenden diese Unternehmen an und was ist eigentlich ihr Kerngeschäft?
Das Buch The Four – Die geheime DNA von Amazon, Apple, Facebook und Google versucht diese und viele weitere Fragen zu beantworten. Ein Blick hinter die Kulissen zeigt, was diese Unternehmen im Hintergrund tun und was davon tatsächlich vermarktet wird bzw. wie Informationen dargestellt werden. Interessant ist zudem der Blick auf die angewandten Strategien der vier Unternehmen. Auch die engste Konkurrenz wird beleuchtet und deren Chancen bewertet – allerdings bezieht sich dies nur auf US-amerikanische Unternehmen (abgesehen von Alibaba).
Dieses Buch bietet viele interessante Aspekte und einen – wenngleich manchmal auch reißerischen Blick hinter die Fassade. Getrübt wird das Leseerlebnis durch häufiges Wiederholen derselben Aussagen. Um ein Drittel könnte das Buch so wohl gekürzt werden. Insgesamt liest es sich flüssig und bietet gute Informationen und vor allem sehr viele weiterführende Quellen, welche die Ausführungen untermauern bzw. für Überprüfungen herhalten können. Der Schreibstil ist etwas ungewöhnlich, aber man kommt relativ schnell hinein.
Grundsätzlich ist es kein Fehler, dieses Buch zu lesen. Es gibt allerdings einige Punkte, die man deutlich verbessern hätte können: Das Thema sind große, globale Unternehmen. Die Sichtweise ist jedoch hauptsächlich auf den US-amerikanischen Markt beschränkt. Das ist zwar grundsätzlich verständlich, passt aber eben nicht zum globalen Aspekt des Gegenstandes. Die bereits erwähnten Wiederholungen könnten mit noch detaillierteren Informationen ersetzt werden. Zudem sind einige Gedanken unsortiert und wirken dadurch etwas unausgegoren oder einfach nur fehl am Platz. Die Karrieretipps im letzten Kapitel kann man – aus meiner Sicht – getrost weglassen. Der Großteil steht bereits in den vorderen Kapiteln und der Rest funktioniert für den Großteil der Arbeitnehmer am europäischen Markt ohnehin nicht (bzw. sind die Tipps nicht zulässig).
Alles in allem bietet das Buch interessante Aspekte, Hintergrundinformationen und Analysen. Wer sich tiefgreifend mit den Unternehmen beschäftigt hat, wird das meiste wohl kennen. Wer Interesse an den Unternehmen hat, sich aber noch nicht die Zeit für Recherchen nahm, der findet hier sicherlich ein gutes Buch. Zwingend muss man es nicht lesen.
Was macht einen guten Leader aus? Was tut er, was soll er tun, was sollte er können? Ich hatte so mein Bild eines Leaders und dachte, dass mir, Real Leaders Don’t Follow wird mir weiterhelfen, dieses Bild zu schärfen.
Aus meiner Sicht, geht es hauptsächlich darum, anderen ein Vorbild zu sein und ihnen einen klaren Weg vorzugeben. Einen Weg, der sinnvoll erscheint und allen Beteiligten Mehrwert verspricht. Der Kunde möchte seine Prozesse optimieren, sein Potential ausschöpfen, neue Möglichkeiten erhalten. Die eigenen Kollegen möchten etwas Sinnvolles erschaffen, etwas, dauch gebraucht wird (sich verkaufen lässt) und das in einer technisch sauberen Art.
After all, the goal of the book is to get you to formulate your own views and make smart decisions based on real-world experience. Implicit in that concept is that you follow no one’s doctrines—including mine.
Wozu dann aber über 300 Seiten durchkaufen? Das Buch ist gespickt mit Erfahrungen, unterschiedlichen Sichtweisen und Beispielen. Sie helfen, das eigene Gefühl zu schärfen.
If there’s one lesson I learned the hard way, it’s that you never get ahead by following anyone down a gilded path.
Ratschläge sind von diesem Buch nicht zu erwarten, wie sollten diese auch für die eigene Situation passend sein? Vielmehr vermittelt es eine überaus anregende Perspektive auf das gesamte Thema.
Inspiration doesn’t come from outside you. It comes from inside. It comes from your emotions, your passion. That’s what drives you. That’s what inspires you.
Selten habe ich ein Businessbuch gelesen, das eine Empfehlung so verdient hat. Deshalb möchte ich auch gar nicht zu viel verraten. Lies es selbst, es macht sich bezahlt.
It’s so important to test your software automatically. Unit Tests are really great for testing small, atomic parts. But you have to ensure that your complete systems works as expected. This is where web API tests comes into play.
First, some words about the motivation behind this article: A lot of people don’t want to write test code and one of the reasons most state first is that they have too little time for it. In reality, tests reduce maintenance costs enormously – not only for the development team , but also for support or DevOps team. The most important thing to do is, to integrate your tests into your CI tool to execute them automatically and periodically.
There are several starting points into this topic. Let’s have a look.
Available API specification
Some of you might specify your web API using API Blueprint or Swagger. Both provides a high-level API description language. Those enable you to generate your web API as well as your tests from the API specification.
There are – of course – reasons to create code, but it’s not advisable to generate critical parts of a web API automatically. To create the tests automatically can be a good thing though – certtain limitations apply, which will be discussed further on.
Using tools to document API
Very often you have to work with an existing web API, but got no documentation about it. To get “help” some install tools like Swagger to generate documentation at runtime. This is pretty cool to get an overview of all existing endpoints.
This gives you the possibility to add examples for each endpoint, which is necessary to generate the tests. To achieve this, you have to implement several interfaces have to be implemented, and that . Ayields s a result you have a lot of source code to be able to generate tests from your API documentation.
So there are two possible solutions:
Take the effort and create a specification based on your existing API. As a benefit, your will be able to automatically generate tests from that specification.
Implement your tests manually.
Existing API without any documentation
Not everyone knows about API specifications, Open API and so on. A lot of developers just write their APIs. You can do that, but you won’t have any specifications, which also makes it harder for third parties (like buisness partners etc.) to your your API.
Of course, you can create a specification later, but doing this upfront saves a lot of effort. By using tools like Swagger, you are able to create at least a helpful documentation of your web API. To generate your tests automatically from this documentation needs a lot of additional source code. That’s not to be preferred.
You have two possibilities:
Create your own coded testing project
Script something using tools like HTTPie and bash etc.
Creating a testing infrastructure by code
There are important reasons to also implement testing code manually:
It’s not enough to just test your API against its specification, you also need to know if your implementation does really work
Testing APIs also requires to test (business) workflows. This can’t be done by tests that were created automatically for single endpoints.
For my tests I use XUnit. This is – originally – a unit testing framework, but it also provides interfaces for ordering your tests. Ordered tests are necessary to test workflows.
First, you need to implement an attribute to be able to order your tests:
public class TestOrderAttribute : Attribute
{
public int Priority { get; set; }
public TestOrderAttribute(int priority)
{
Priority = priority;
}
}
Then you need a mechanism to order your tests within a single test case:
public class TestPriorityOrderer : ITestCaseOrderer
{
public IEnumerable<ttestcase> OrderTestCases<ttestcase>(IEnumerable<ttestcase> testCases) where TTestCase : ITestCase
{
SortedList<int ttestcase="ttestcase"> sortedTestCases = new SortedList<int ttestcase="ttestcase">();
foreach (var testCase in testCases)
{
var methodInfo = testCase.TestMethod.Method;
var attribute = methodInfo.GetCustomAttributes((typeof(TestOrderAttribute).AssemblyQualifiedName)).FirstOrDefault();
var priority = attribute.GetNamedArgument<int>("Priority");
sortedTestCases.Add(priority, testCase);
}
return sortedTestCases.Values.ToList();
}
}
Last but not least, you need to order all existing test cases:
public class TestCollectionOrderer : ITestCollectionOrderer
{
public IEnumerable<itestcollection> OrderTestCollections(IEnumerable<itestcollection> testCollections)
{
return testCollections.OrderBy(GetOrder);
}
private static int GetOrder(ITestCollection testCollection)
{
var i = testCollection.DisplayName.LastIndexOf(' ');
if (i <= -1)
return 0;
var className = testCollection.DisplayName.Substring(i + 1);
var type = Type.GetType(className);
if (type == null)
return 0;
var attr = type.GetCustomAttribute<testorderattribute>();
return attr?.Priority ?? 0;
}
}
At a single point within your testing assembly set necessary configurations:
To configure your test class, set the test case orderer as well as the test order:
[TestCaseOrderer("TestPriorityOrderer", "IntegrationTests")]
[TestOrder(10)]
public class AuthenticationTest { ... }
Your test methods (facts) have to be configured as well:
[Fact, TestOrder(20)]
public async void LoginWithCorrectCredentials_ShouldBeOk()
Alright, this is all you need to run your web API tests.
You will gain the bests results when you combine the requirement that all tests need to run successfully BEFORE new code is commited into your source repository, with also setting up automatic test runs within your CI infrastructure.
Happy coding!
Cookie-Einstellungen
Auf dieser Website werden Cookie verwendet. Diese werden für den Betrieb der Website benötigt oder helfen uns dabei, die Website zu verbessern.
Alle Cookies zulassen
Auswahl speichern
Individuelle Einstellungen
Individuelle Einstellungen
Dies ist eine Übersicht aller Cookies, die auf der Website verwendet werden. Sie haben die Möglichkeit, individuelle Cookie-Einstellungen vorzunehmen. Geben Sie einzelnen Cookies oder ganzen Gruppen Ihre Einwilligung. Essentielle Cookies lassen sich nicht deaktivieren.
Speichern
Abbrechen
Essenziell (1)
Essenzielle Cookies werden für die grundlegende Funktionalität der Website benötigt.
