miradlo bloggt

• Blue Beanie Tag

Heute ist Blue Beanie Tag, zuerst las ich bei Robert davon, auch t3n berichtet darüber, es gibt eine facebook-Gruppe. Worum es geht?  Webstandards sollen ins Bewußtsein gerückt werden. Eine weitere Idee ist: Fünf Sätze zu diesem Thema zu formulieren, die für einen selbst wichtig erscheinen um Webstandards voran zu bringen.

Meine Wunschliste zu Webstandards

• Inhalte sind wichtig und sollten für alle zugänglich sein (kleines zartgrau auf weiß ist keine lesbare Schrift)
• Flash ist kein Designelement (als Navigation ist Flash immer falsch und auch sonst wird Flash oft überflüssigerweise eingesetzt)
• Grafische Captchas behindern alle Nutzer
• Formularelemente sollen ebenfalls mitwachsen je nach gewählter Schriftgröße (ich nutze eine Mindestschriftgröße und kann oft Formulare nicht nutzen, weil die Felder zu klein bemessen sind)
• valides HTML und CSS tun nicht weh und sind eine Grundlage für bessere Seiten für alle Nutzer

"Blaue Mützen : Blue Beanie : Webstandards : Adventskalender" vollständig lesen

Wieder mal was zur Bildbearbeitung mit Gimp, auch dieser Artikel gehört zur Serie hier im Blog zu Bildern und Grafiken. Häufig bekommt man ein Logo mit weißem Hintergrund, den man lieber transparent hätte, weil das Logo auf einen anderen Hintergrund soll. Das ist der einfachste Fall, der klappt fast vollständig nahezu automatisch (Ein Klick auf die Bilder führt zur größeren Abbildung.):

• Gimp Bild mit Transparenz erstellen (klicken vergrößert)
• Gimp Transparenz weitere Schritte (klicken vergrößert)
• Gimp Ergebnis mit Farbverlauf als Hintergrund (klicken vergrößert)

• Bild automatisch zuschneiden sorgt dafür, dass überflüssige Ränder entfernt werden
• neue Ebene erstellen, die braucht man, falls auch innerhalb des Logos etwas weiß ist und bleiben soll
• Auswahl nach Farbe
• Farbe zu Transparenz (weiß ist die Grundeinstellung) bei anderen Farben diese mit der Pipette bestimmen und im Dialog Farbe zu Transparenz entsprechend angeben
• das Bild vergrößert anschauen -  manchmal ist es gut die Auswahl noch um 1 Pixel zu vergrößern um saubere Kanten zu bekommen
• wenn wie im Beispiel zuviel weiß entfernt wurde, so lässt sich das auf der vorhin schon erstellten Ebene leicht korrigieren, in dem man einfach wieder mit weiß nachmalt (die Ebene hat den Vorzug, dass man nicht sehr genau malen muss, z.B. das Weiß in "crew" lässt wird ja vom orange überdeckt
• ich speichere solche Änderungen dann als Gimp-Original-Datei im .xcf-Format ab, anschließend exportiere ich das Ergebnis als *.png oder *.gif (*.jpg kann keine Transparenz)
• falls ich z.B. einen Farbverlauf als Hintergrund möchte so erstelle ich eine dritte Ebene mit dem Farbverlauf
• im Ebenenfenster lassen sich Ebenen verschieben, unterschiedlich stapeln, ihre Sichtbarkeit ein- und ausschalten
• beim Export des Ergebnisses werden diese Ebenen dann wieder zusammengefügt, falls man später nochmal was ändern möchte lohnt sich die erzeugte *.xcf-Version
• fertig

Für komplizierteres Ausschneiden und Freistellen ist auch die Quick-Mask eine gute Idee. Eine Anleitung gibt's  z.B. bei Rowi:  GIMP einfach maskieren mit der Quick-Mask

Ich bin ja seit langem immer mal wieder dabei von Gentoo auf (K)Ubuntu umzustellen. Am liebsten hätte ich drei Tage Zeit, einfach zum Rumbasteln, dann wäre das meiste einfach mal erledigt. Aber so tröpfchenweise ist es mühsam. Wenn ich nach einiger Zeit wieder an Ubuntu gehe, bleibe ich meist erstmal kurz hängen und muss überlegen, was war wo und wie geht das. Denn klar, mir fehlt die Übung. Erschwerend kommt hinzu, dass ich auf meinem produktiv genutzten Rechner noch immer KDE 3.5 nutze und so auch mit KDE 4 noch nicht in jeglicher Hinsicht vertraut bin. Wäre ich jetzt ruhig und geduldig und nähme mir viel Zeit, dann wäre es sicher einfacher. Aber seit Wochen ist es immer mal so kurz am Rande, dass ich etwas mit Ubuntu mache, meist dann wenn irgendwas beim anderen System hakt oder nicht ganz sicher ist. Dieses Mal war es mein spezieller Freund WordPress. Beim Aktualisieren von Blogs klappte mal wieder in keinem Browser der Umgang mit dem Adminbereich wie erhofft. Weitere Blogs auf die neueste Version anheben, ohne zu wissen, ob ich mit der nachher noch arbeiten kann, ist nicht grad sinnvoll. Auf tacita, meinem Produktivrechner brauchte der Firefox teils mehrere Minuten, um im Adminbereich vom Dashboard auf einen Artikel umzuschalten. Das ist nicht akzeptabel. Im Konqueror ging gar nichts, da lässt sich der Adminbereich gar nicht mehr bedienen. Opera ist zwar schnell, aber der Fehler, dass Absätze und Zeilenumbrüche nicht erhalten bleiben ist immernoch da, das geht also auch nicht. Meist arbeitete ich für Blogs in den letzten Monaten mit Seamonkey, leider lässt der sich mit der neuesten WP-Version gar nicht mehr ein. Weil also all das nicht klappte, testete Roland kurz auf dem Asus, dort waren die Antwortzeiten nicht so unterschiedlich zwischen beiden Versionen. Deshalb musste ich also mal weiter testen und nahm Ubuntu. Der Firefox ist grad noch aktueller und hat noch keinerlei Plugins, die irgendwas beeinflussen könnten. Tatsächlich lässt sich dann selbst der dicke Klotz WordPress 2.8.3 noch einigermaßen bedienen. Wenn ich schon dran bin, dann will ich ja auch immer noch ein bisschen weiterkommen mit meiner Umstellung. Gleich als erstes wollte Ubuntu mein W-LAN wieder nicht mehr finden, das ließ sich recht schnell lösen. Danach blieb ich an Eclipse hängen, was nicht tat, was ich wollte, bis ich etwas intensiver recherchiert und probiert hatte. Ein Rechner ohne die eigenen Daten ist auf Dauer ja auch ein bisschen langweilig. Also wollte ich daran was ändern, nun die passenden IPs für den Zugriff auf die anderen Rechner mit meinen Daten in  die /etc/hosts eintragen ist nicht schwierig, nachdem ich kapiert hatte, dass ich jetzt entweder kwrite installiere oder mich halt doch mal noch an Kate gewöhne... Ja, ich kann das auch mit dem vi, aber ich war nie, bin nicht und will auch nicht überwiegend mit Konsole arbeiten. Manchmal ist das sehr praktisch, als Backup, wenn der grafische Schnickschnack ausfällt eine perfekte Lösung, aber für mich nicht meine Lieblingslösung. Soweit so schön, grad von tollen grafischen Lösungen geredet, aber ich bin ja nicht konsequent, für manches mag ich das Zeug wieder nicht, ich wollte einen ganz einfachen normalen rsync zwischen xaver, der (K)Ubuntu-Maschine und tacita, meinem Produktivrechner. Weil ich nur kann, was für mich logisch ist, geht mein rsync von der Quelle zum Ziel, andersrum kapiere ich es nicht. Tja, und genau das ging wieder nicht, von xaver auf tacita kam ich per ssh und und sftp, da hätte wahrscheinlich auch der rsync geklappt, aber umgekehert war wieder nichts zu wollen. Von tacita aus gelang mir einfach kein Zugriff auf xaver. Nun gut, ich soll ja nicht so bockig sein, also doch wieder Klickibunti um mal irgendwo anzufangen. Also halt dolphin mit sftp auf tacita, von dort dann mit echtem Mausschubsen Ordner auf xaver kopieren. Hässliche Variante, aber sie funktioniert, also doch nicht soo doof. Ich muss nicht erwähnen, dass mir das grafische K-Menü irgendwann unterwegs mal wieder abhanden kam, oder? Aber das kenne ich ja schon, dafür gibt's per rechter Maustaste

• zum klassischen Menü wechseln

nicht so hübsch, ohne Suchfunktion, aber mit dem Vorzug, es funktioniert einfach. Insgesamt ist es jedoch alles noch mühsam, weil mir auf Anhieb grundsätzlich nur einfällt, was ich bei Gentoo und KDE 3.5 tun würde, weder habe ich Ubuntu so recht im Griff, noch bediene ich bislang KDE 4 intuitiv. Aber mal so über Nacht ein paar Daten kopieren lassen ist prima, dann passiert was, ich habe das Gefühl ich habe was getan und kann die beiden Rechner problemlos allein lassen, denn die kopieren oder eben nicht, ob ich jetzt dabei bin oder auch nicht. Perfekt ist grad, dass xaver und tacita identische Rechner sind, wenigstens bezogen auf Optik und Handhabung  muss ich nicht nachdenken.

Flyer, die später im Offsetdruck gedruckt werden sollen, können nicht mit Textverarbeitungsprogrammen erstellt werden. Scribus ist kostenlos und dafür gemacht auch mit professionellen Ansprüchen zurecht zu kommen. Deshalb mal ein weiterer Teil der Serie hier im Blog zu Bildern und Grafiken, der ein Spaltenlayout erklärt, eine andere Schriftfüllung zeigt und noch ein paar Linktipps zu anderen Anleitungen.

• Scribus Spalten erstellen
  

• Neues Dokument erstellen in gewünschter Größe und Form
• passende Hilfslinien Datei -> Allgemeine Einstellungen -> links auf Hilfslinien
• Hilfslinien anzeigen lassen -> OK
• Menü Seite -> Hilfslinien bearbeiten im Feld Spalten Zwischenraum aktivieren
• Hilfslinien müssen zur gewünschten Aufteilung passen, können jedoch auch später noch ergänzt werden:
• aus dem Lineal mit gedrückter Maustaste ziehen ergibt weitere Linien die passend verschiebbar sind

"Flyer erstellen : Schrift mit einem Bild füllen ::: Scribus" vollständig lesen

• WordPress Statistik 19% unpatched
• Serendipity Statistik 0% unpatched
• Firefox 3.0 Statistik0% unpatched
• Firefox 3.5 Statistik 0% unpatched

Dirk hat in meiner Session beim Barcamp Liechtenstein als es um Blogsoftware ging secunia.com erwähnt und inzwischen auch selbst darüber berichtet. secunia ist ein Unternehmen welches regelmäßig verschiedenste Software untersucht. Dabei schaut das Unternehmen nach Sicherheitslücken und beurteilt in weiteren Untersuchungen wie damit umgegangen wurde. Die Screenshots zeigen schon anhand der Farbwahl im Ampelstil, ob alles in Ordnung ist, oder ob es Probleme gibt. Bei späteren Prüfungen wird geschaut, ob die Ratschläge umgesetzt wurden, daraus ergeben sich die Hinweise auf den Lösungstatus:

• Unpatched
• Vendor Patched
• Vendor Workaround
• Partial Fixed

Ausnahmsweise lassen ich die englischen Originalbegriffe stehen, da es aus meiner Sicht keine sinnvollen, gebräuchlichen, deutschen Übersetzungen gibt. Weiterhin wird angegeben in wieweit die Sicherheitsratschläge zu bewerten sind.  In folgenden Stufen wird angegeben für wie kritisch die gefundenen Lücken gehalten werden.

• Extremely
• Highly
• Moderately
• Less
• Not

Da in den Kommentaren diese Woche der Vergleich auch mit Firefox kam, führe ich auch den mit auf.

Blogsoftware

• Serendipity 1.x (0% unpatched)
• Wordpress 2.x (19% unpatched)

Firefox-Browser

• Firefox 3.0 (0% unpatched)
• Firefox 3.5 (0% unpatched)

Betriebssysteme

• Ubuntu 9.04 (0% unpatched)
• Windows Vista (5% unpatched)
• Mac OS X (5% unpatched)

Ich meine, diese Werte bestätigen ganz klar, dass es kein sinnvolles Konzept gibt, wie WordPress mit Fehlern und Lücken umgeht. Denn gefunden werden Fehler auch bei anderer Software, allerdings bemüht man sich da entsprechende Lücken umgehend zu schließen. Ganz im Gegensatz zu dem, wie es scheint, wenn es viele Updates gibt, ist es bei WordPress trotzdem wohl nicht sonderlich wichtig Lücken zu schließen, sonst könnten nicht 19% weiterhin offen bleiben...

Ich betreue einige WordPress-Blogs und das nicht nur als Hobby. Ich habe mich inzwischen ja auch schon mehr als einmal dazu geäußert, was mich an WordPress deutlich stört, siehe die diversen Artikel auch dazu in der Kategorie WordPress. Ein erster Blick z.B. auf Wikipedia scheint gar nicht so schlimm, denn die neuen Versionen wurden wie folgt veröffentlicht:

WordPress-Versionen 2008 und 2009

• Hinweise WordPress aktualisieren

• WordPress 2.5 erschien im März 2008
• WordPress 2.6 erschien im Juli 2008
• WordPress 2.7 erschien im Dezember 2008
• WordPress 2.8 erschien im Juni 2009
• WordPress 2.9 erscheint voraussichtlich im  Dezember 2009

Das Ganze sieht schon anders aus, wenn die zwischendurch veröffentlichten kleinen Updates mit dabei stehen; die deutschen Versionen inklusive der Zwischenversionen laut Archiv von WordPress Deutschland:

• WordPress 2.5 erschien im April 2008
• WordPress 2.5.1 erschien im April 2008
• WordPress 2.6 erschien im Juli 2008
• WordPress 2.6.1 erschien im August 2008
• WordPress 2.6.2 erschien im September 2008
• WordPress 2.6.3 erschien im Oktober 2008
• WordPress 2.6.5 erschien im November 2008
• WordPress 2.7 erschien im Dezember 2008
• WordPress 2.7.1 erschien im Februar 2009
• WordPress 2.8 erschien im Juni 2009
• WordPress 2.8.1 erschien im Juli 2009
• WordPress 2.8.2 erschien im Juli 2009
• WordPress 2.8.3 erschien im August 2009
• WordPress 2.8.4 erschien im August 2009
• WordPress 2.8.5 erschien im Oktober 2009
• WordPress 2.8.6 erschien im November 2009
• WordPress 2.9 erscheint voraussichtlich im  Dezember 2009

In diesem Jahr waren es damit bereits neun Updates. Meist ging es um Sicherheitsupdates, sprich gerade die Zwischenversionen sind damit wichtig und sollten auf jeden Fall aktualisiert werden.

Plugins und ihre Aktualisierungen

Ich kenne kein WordPress-Blog welches nicht auch einige Plugins einsetzt, um weitere Funktionen hinzuzufügen. Die Plugin-Updates kommen irgendwann zwischendurch und auch hier kann es sein, dass es um Sicherheitsprobleme geht, die gelöst wurden. Anfangs machte ich regelmäßig Plugin-Updates sobald diese veröffentlicht wurden. Doch als ich mehrfach danach einen oder mehrere Fehler hatte, weil die neue Version eines Plugins zu irgendwas anderem nicht passte, hörte ich damit auf. Inzwischen aktualisiere ich Plugins nur in Notfällen, sprich wenn eine Sicherheitslücke zu stopfen ist, ansonsthref="http://miradlo.net/bloggt/index.php?768-s"">Version eines Plugins zu irgendwas anderem nicht passte, hörte ich damit auf. Inzwischen aktualisiere ich Plugins nur in Notfällen, sprich wenn eine Sicherheitslücke zu stopfen ist, ansonsten werden Plugins nur noch gemeinsam mit einem Update aktualisiert. Die Zwischenversionen bestehen ja nur aus einigen Dateien, die überspielt werden können, es ist also keine vollständige Änderung aller Dateien nötig. An sich sollte diese Zwischenupdates daher problemlos funktionieren und keine Seiteneffekte haben. Doch das klappt leider oft nicht, mal ein Beispiel wie es bei einem Update lief, welches schon ein bisschen länger her ist:

Aktualisieren mehrerer Blogs

Wie schon mehrfach beschrieben, ich aktualisiere immer erst lokal, teste dann und spiele erst danach die jeweilige Änderung auch online ein. Einige Male habe ich es auf einem Testblog versucht automatisch zu aktualisieren, es klappte jedoch - wenn überhaupt -nie so, dass ich das bei einem Blog mit echten Inhalten risikieren würde.  Ich begann WordPress auf diversen Blogs zu aktualisieren. Ich lud mir WP 2.8.3 runter, so wie die aktuellen Versionen der genutzten Plugins. Ich hatte das erste Blog gerade aktualisiert und war dabei das zweite zu bearbeiten, als bereits das erste Plugin wieder nicht mehr aktuell war. Also auch da die neue Version runtergeladen. Abends beim Testen lief es auf meinem Rechner lokal erst mal ganz schlecht. Ein noch langsamerer Adminbereich als bisher schon, in weiteren Browsern entweder gleich schlecht benutzbar oder noch weiter verschlechtert. Ich bin schon einiges gewohnt, aber ich brauche wenigstens einen Browser, mit dem sich auch der WordPress-Adminbereich bedienen lässt.  Ich installierte mir einen Firefox ohne Add-Ons, damit ging es dann einigermaßen. Inzwischen liefen zwei Blogs auf 2.8.3 auch online. Noch während ich lokal die Updates für weitere Blogs testete, Plugins aktualisierte und den ein oder anderen Wunsch für Änderungen umsetzte, las ich dass die 2.8.3 auch keine gute Idee sei. Ich hatte jedoch schon die Updates bei 2.8.1 und 2.8.2 auf dem ein oder anderen Blog abbrechen müssen, weil ich bereits lokal feststellte, dass damit das Blog nicht mehr lief. Für die 2.8.3  kamen ständig neue Vorschläge, wie der unsichere Login zu reparieren wäre. Na bravo! Ich blieb also erstmal an den Anpassungen und Erweiterungen die in einigen Blogs zu machen waren. Am dritten Tag beschloss ich jetzt doch noch weiter zu aktualisieren und um das abzuschließen. Zunächst schaute ich was auf dem nächsten zu aktualisierenden Blog noch zu tun ist und: "Juhu! ein Update!" Ja, es ist toll, dass der Fehler damit behoben wird. Das ändert allerdings nichts daran, dass ich jetzt also erstmal die ersten beiden Blogs vom Tag zuvor erneut aktualisieren musste. Dieses Mal probierte ich es ohne nochmaliges Sichern und Plugins abschalten, solange war die letzte Aktualisierung ja noch nicht her, als das lokal lief, riskierte ich es auch online. Ja, die zwei nur von 2.8.3 auf 2.8.4 zu aktualisierenden Blogs waren tatsächlich kein Problem; alles andere aber schon. Ein Blog zickte nochmal bevor es sich überreden ließ, doch so zu tun, als sei alles in Ordnung. Zwischendurch musste ich jeweils wieder die online-Versionen aus Kundenprojekten holen, um nicht versehentlich was zu überschreiben, denn ich kann ein Blog ja nicht über zwei, drei Tage einfach abschalten.

Fazit WordPress nutzen

Die Updates sind in keinster Weise planbar, denn z.B.  die 2.9 war für November angekündigt, ob sie jetzt noch dieses Jahr kommt ist nicht klar. Die Zwischenversionen kommen, wenn einehref="http://miradlo.net/bloggt/index.php?37-s"">aktualisiere immer erst lokal, teste dann und spiele erst danach die jeweilige Änderung auch online ein. Einige Male habe ich es auf einem Testblog versucht automatisch zu aktualisieren, es klappte jedoch - wenn überhaupt -nie so, dass ich das bei einem Blog mit echten Inhalten risikieren würde.  Ich begann WordPress auf diversen Blogs zu aktualisieren. Ich lud mir WP 2.8.3 runter, so wie die aktuellen Versionen der genutzten Plugins. Ich hatte das erste Blog gerade aktualisiert und war dabei das zweite zu bearbeiten, als bereits das erste Plugin wieder nicht mehr aktuell war. Also auch da die neue Version runtergeladen. Abends beim Testen lief es auf meinem Rechner lokal erst mal ganz schlecht. Ein noch langsamerer Adminbereich als bisher schon, in weiteren Browsern entweder gleich schlecht benutzbar oder noch weiter verschlechtert. Ich bin schon einiges gewohnt, aber ich brauche wenigstens einen Browser, mit dem sich auch der WordPress-Adminbereich bedienen lässt.  Ich installierte mir einen Firefox ohne Add-Ons, damit ging es dann einigermaßen. Inzwischen liefen zwei Blogs auf 2.8.3 auch online. Noch während ich lokal die Updates für weitere Blogs testete, Plugins aktualisierte und den ein oder anderen Wunsch für Änderungen umsetzte, las ich dass die 2.8.3 auch keine gute Idee sei. Ich hatte jedoch schon die Updates bei 2.8.1 und 2.8.2 auf dem ein oder anderen Blog abbrechen müssen, weil ich bereits lokal feststellte, dass damit das Blog nicht mehr lief. Für die 2.8.3  kamen ständig neue Vorschläge, wie der unsichere Login zu reparieren wäre. Na bravo! Ich blieb also erstmal an den Anpassungen und Erweiterungen die in einigen Blogs zu machen waren. Am dritten Tag beschloss ich jetzt doch noch weiter zu aktualisieren und um das abzuschließen. Zunächst schaute ich was auf dem nächsten zu aktualisierenden Blog noch zu tun ist und: "Juhu! ein Update!" Ja, es ist toll, dass der Fehler damit behoben wird. Das ändert allerdings nichts daran, dass ich jetzt also erstmal die ersten beiden Blogs vom Tag zuvor erneut aktualisieren musste. Dieses Mal probierte ich es ohne nochmaliges Sichern und Plugins abschalten, solange war die letzte Aktualisierung ja noch nicht her, als das lokal lief, riskierte ich es auch online. Ja, die zwei nur von 2.8.3 auf 2.8.4 zu aktualisierenden Blogs waren tatsächlich kein Problem; alles andere aber schon. Ein Blog zickte nochmal bevor es sich überreden ließ, doch so zu tun, als sei alles in Ordnung. Zwischendurch musste ich jeweils wieder die online-Versionen aus Kundenprojekten holen, um nicht versehentlich was zu überschreiben, denn ich kann ein Blog ja nicht über zwei, drei Tage einfach abschalten.

Fazit WordPress nutzen

Die Updates sind in keinster Weise planbar, denn z.B.  die 2.9 war für November angekündigt, ob sie jetzt noch dieses Jahr kommt ist nicht klar. Die Zwischenversionen kommen, wenn eine Lücke bekannt wird und groß genug ist, um repariert zu werden. Ich kann jedoch in meinen Arbeitslauf nicht ständig vorsichtshalber drei Tage einplanen, in denen ich sofort, wenn ein Update erscheint, alles andere stoppe und absage, um mich dann um WordPress zu kümmern. Unterm Strich kostet mich eine Aktualisierung pro Blog zwischen einigen Stunden bis zu ein oder zwei Tagen, wenn eine Fehlersuche aufwändiger wird. Ginge es hierbei um ein Update pro Jahr, dann wäre es noch akzeptabel, bei einem Update etwa alle sechs Wochen geht das einfach nicht, denn kein Kunde ist bereit das nach Aufwand auch nur annähernd zu bezahlen. Denn selbst bei einem Stundensatz von nur 50 Euro wären das jährlich rund 2500.- Euro nur für Aktualisierungen und kleine Anpassungen. Ich bin deshalb inzwischen dazu übergegangen, dass ich für neu aufzusetzende Blogs WordPress nicht mehr anbiete, eine Ausnahme sind Portale mit WordPress MU und BuddyPress, weil sich da der Aufwand ja auf viele Einzelblogs verteilt und weil es zur Zeit keine echte Alternative dafür gibt.

• Rechnermuseum miradlo

Dirk fragte in einem Beitrag nach dem idealen Arbeitsplatz. Inzwischen gibt es einige Kommentare und darauf verweisende Beiträge, sowie von ihm selbst zwei Folgeartikel. Seinen eigenen Beitrag gibt's unter mein idealer Arbeitsplatz, sowie Gedanken zu einem Remote-Arbeitsplatz unter Arbeiten aus der Ferne. Wie immer bei solchen Themen habe ich zunächst nur den Einstiegsartikel gelesen, weil ich zunächst meine Sichtweise unbeeinflusst überlegen möchte.

Mein idealer Arbeitsplatz in der IT

Was mir wichtig ist, zeigt teils schon meine berufliche Laufbahn.

"Der ideale IT-Arbeitsplatz : Umfrage" vollständig lesen