Google+ als Facebook Killer? Das ist zu kurz gegriffen. Ich nutze die „Datenkrake“ gern

Google der Facebook Killer? Mag sein, dass viele von Facebook zu Google abwandern werden. Aber Google ist für mein Gefühl weit mehr. Geht man den Migrationsweg zu Google+ konsequent, und vergisst man zunächst mal die Bedenkenträger mit ihrer Datensammelpsychose, so ist für mich Google+ wieder zu einer zentralen Einstiegsstelle und zu meiner Arbeitsplattform im Netz geworden. Schon lange nutze ich Google Reader, um mich über die aktuellen Themen des Netzes auf dem Laufenden zu halten, arbeite intensiv mit Google Docs und Google Mail und jetzt migriert mein soziales Netz, und auch wenn das etwas überheblich klinge mag, vor allem die „wertvollen Kontakte“ zu Google+. Dank des Google+Twitter und Google+Facebook Plugins für Chrome, bleibe ich dennoch auch über meine Communities auf Facebook und Twitter auf dem Laufenden. Dank Android und dessen Synchronisationsmöglichkeiten habe ich meine Terminplanung komplett auf Google Calendar umgestellt, so daß meine Familie immer weiß, wo ich wann beruflich erreichbar bin und wir private und berufliche Termine perfekt koordinieren können. Und ein Backup unserer wichtigen Familienfotos liegt als privates Album bei Picasa.

Mein Büro liegt schon seit längerem in der (Google-) cloud.

 

Warum ich alles so zentralisiere? Warum ich mich in die „Fänge“ von Google begebe?

Weil ich Service erwarte, und zwar für all meine Bedürfnisse. So umfassend, wie das Google jetzt dank Google+ als weitere Erweiterung schafft, finde ich das nirgendwo sonst im Netz. Und wer mich jetzt dafür verdammt, der sollte mal hinterfragen, ob nicht jeder Microsoft Nutzer sich auch „in die Fänge“ von Microsoft, jeder Apple Nutzer nicht in die Klauen von Steve begibt? Ich denke, das tun wir nicht. Stets habe ich auch lokale Backups auf Festplatte, so daß ich, sollte mir der Dienst doch zu bedenklich erscheinen, dort weg. (Wer seine Daten nicht selbstverantwortlich sichert, hat meiner Ansicht nach sowieso noch nicht begriffen, wie man sicher und datenerhaltend im Netz arbeitet)

Selbst mein WLan ist mobil.

Aber ich sage, Google hat dasselbe Problem wie McDonalds. Alle schimpfen, aber wegen der hohen öffentlichen Aufmerksamkeit kann sich Google viel weniger schwerwiegende Fehler leisten, als andere Dienste.

Ich für meinen Teil habe dank der Dienste von Google viele  Aspekte meiner Arbeit im Netz optimiert, verbringe paradoxerweise oft gar weniger Zeit im Netz, weil ich mit den diversen Tools verschiedenste Prozesse automatisieren kann.

Google+ ist ein weiterer Teil, der für mich die Arbeit im Netz extrem erleichtert. Sollten die vermuteten Businessfunktionen wie Dashboard etc. tatsächlich kommen, dann noch einen Tick mehr.

Sorry, wenn ich nicht auf Google die Datenkrake bashe. Für mich stellt Google Dienste zur Verfügung, die meine Arbeit erleichtern. That’s what counts for me.

Mein Fazit vom Javaforum in Stuttgart #jfs2011 : Things are changing.

Ein Tag, konzentrierte News, Vorträge und viele Bekannte Gesichter (schön, dich wieder mal in Real Life getroffen zu haben @elektrojunge). Mein Fazit vom Javaforum ist gespalten.

Zum einen, viele  gute Vorträge, eine top Organisation, Aussteller, die offensichtlich auch wieder vertärkt Java Entwickler suchen. Aber was gefühlt mein Eindruck war. Irgendwie fehlt die Vision, wie es mit Java weitergehen soll. Seit der Übernahme durch Oracle ist die Szene misstrauisch geworden.

Das zeigte für mich auch der Vortrag „Das nächste große (Java-) Ding. Das hier die Klammer um Java auftauchte, war sicher gewollt. Mittlerweile stößt Java an seine Grenzen, die Erweiterbarkeit ist längst nicht mehr so einfach und die Virtual Machine limitiert manche grammatikalischen Erweiterungen.

Die Idee der JVM wird sicher weiterhin Bestand haben, aber ob auch Java noch die zweistelligen Versionsnummern erleben wird. Ich wage es nicht zu prognostizieren.

Letztlich war ich aber am verblüfftesten von der geringen Zahl an Tracks zum Thema mobile Computing. Mittlerweile gehen knapp 20%  der deutschen Nutzer via Smartphone ins Internet, jeder vierte Haushalt besitzt ein solches Device und der Markt für Tablets boomt gerade. Dann aber nur zwei Tracks dazu anzubieten war mir eindeutig zu wenig.

Es gibt so viele wichtige Aspekte zu berücksichtigen und wenn ein Bereich die Entwickler in den nächsten Jahren verstärkt beschäftigen wird, dann der mobile Endgerätebereich.

(Kleine Anmerkung am Rande: Schon auf dem Weg zum Veranstaltungsort vielen mir viele QR Codes an Litfaßsäulen oder in Schaufenstern auf und auch auf dem Javaforum waren viele QR Codes zu finden. Ein neuer Trend? Ich prognostiziere ja bereits länger dieses Jahr als das Jahr des QR Codes. Mal sehen, ob ich am Ende recht behalte?)

Ansonsten aber, danke für einen hochinteressanten, informativen und sehr gut organisierten Event, den ich nächstes Jahr sicher wieder besuchen werde.

Was ich mitgenommen habe, ein IT-Projekt braucht IT affine Mitarbeiter. Projektmanagement ist ein Full Time Job und kann nicht parallel zum Tagesgeschäft laufen. Mobile Endgeräte dürfen nicht vernachlässigt werden und es muss auch hier ein Bewusstsein für Datenschutz und saubere, sicherheitsbewusste Programmierung existieren. REST und ähnliche Technologien sind ein spannender neuer Ansatz, um Dienste auf mobile Endgeräte zu bringen, ohne komplizierte Zugriffschnittstellen und aufwändige Programmieranforderungen.

Java is here to stay but may leave in a few years.

See you all next year at #jfs2012

Javaforum Stuttgart 2011 #jfs2011 Live Blogging Vortrag 6

Vortrag 6: Restful API design
Warum REST mehr als HTTP mit XML ist

REST= Representational State Transfer

Representational State Transfer. Bunt.

Als Beispiel wird „ein Büchershop (guess which one)“ genutzt.

Das ganze soll jetzt auf Mobile Endgeräte, „wir brauchen eine App“
Also braucht man eine Api.
die zu implementierenden Schnittstellen sind aus dem „Legacy“ System vorgegeben.
REST möchte:

 

Für eine Web API
http bewusst nutzen

Bedenken, das Web ist ein verteiltes Medium

Vorkenntnisse über APIs sollten minimiert werden (einfache Einarbeitung).

1 Methode ergibt eine REssource
also Buch Nr Buch-ID —-> http://site/api/book/book-id

2 Methoden, eine Ressource

addToCart
getCartInfo

http://site/api/cart/cart-id

Man muss sich immer die Frage stellen, was kommt in die URI, was in die Parameter
Alles was ein „Ding“ ist in die Uri, der Rest in die Parameter
Aktionen entsprechen Methoden

Aktionen auf Ressourcen sind nicht Teil der URI sondern http-Methoden

Dies ist später in
der API Doku zu beschreiben
Übliche Verhaltensmuster sind
GET->Anzeigen
Post Anlegen oder Ergänzen
PUT Anlegen oder Schreiben

Es sind pro Entity mehrere URI möglich

Http Möglichkeiten nutzen, Error Meldungen, Last Sharing etc.

Caching kann im Header eingestellt werden, also nutzen, gerade auch für mobile Geräte.

ETags definieren den Zustand einer Ressource. Auch diese sind sinnvoll!

Links: Echtes REST

 

Link-Semantik definieren

Ressourcen mit Referenzen verknüpfen

Wissen über die API also verlagern in die Link Annotation

Die Art des Links kann in einem Annotation type wie rel definiert werden.

 

Javaforum Stuttgart 2011 #jfs2011 Live Blogging Vortrag 5

Vortrag 5:
Safety First, Android sicher programmieren!

@elektrojunge on stage

Es gibt Dinge zu beachten, die nur für mobile Endgeräte gelten.
Android ist strukturiert wie ein Orchester mit vielen „Spielern“, verschiedensten Komponenten, die erst zur Laufzeit miteinander verknüpft durch die „Intents“ die Messengerkomponenten. Wie kann ich nun diese Komponenten absichern, wenn Intents schief laufen.

Es gibt das grobgranulare Sicherheitsmodell basierend auf der Sicherheit des Linux Kernels, der die Prozesse isoliert.
Desktop hat Single UID
Android hat UID per Application
Applikationen, die mit dem gleichen Schlüssel signiert sind, können mit der gleichen UID laufen.
Die Kommunikation zwischen Apps läuft über eine Binder IPC

Weiterer Schutz->Sandboxing von Applikationen
Ich kann nur meine eigenen Ressourcen ansprechen.
Jede App läuft in einer eigenen Instanz der Dalvik VM.
Kommunikation über spezielle Interfaces.

Weiterer Sicherheitsmechanismus
Signieren von Applikationen
Verantwortlich für die Signatur ist der Entwickler
Zertifizierung durch Entwickler und in Verantwortung des Entwicklers
Vertrauen in Entwickler durch Erstellung guter Anwendungen

Daneben Feingranulares Sicherheitskonzept
Basiert auf Permissions
Permissions schränken die Möglichkeiten ein, was Prozesse tun können.
Benutzer erkennt das an den angegebenen Rechten, die die App bei der Installation fordert.

Es gibt:
System permissions Erlaubnis auf Systemdienste zuzugreifen (z.B) Kalender oder Adressbuch
Custom permissions
Permission groups
Permission trees

Definiert werden die Permissions im Android Manifest.
Informationen über Apps und laufende Prozesse kann über PackageManager oder ActivityManager
PackageManager -> Installierte Programme
ActivityManager -> Laufende Programme

Wo sind die Verantwortlichkeiten des Entwicklers?

Per Default kann eine App vom „Umfeld“ nichts sehen.

Component wird exportiert durch android:exported im Intentsfilter

Intents sind vergleichbar mit Messengerobjekten
Niemals sensitive Daten in einen Intent
Ebenso von Anfang an angeben, wer den Intent sehen können soll.
Intentfilter filtern keine schädlichen Intents!
Ein Angreifer kann die Priorität seiner Intentfilter erhöhen.
Bei Intentfiltern spezifische Aktionen und Kategorien angeben und Datenfilter

Activities

Benuten von Activity android:permissions = „de.otw.android.HARM_USER_DATA“

Die Permissions werden in startActivity() bzw. startActivityforResult() geprüft.

Services

Client-> Intent.setComponent() um den Service eindeutig zu identifizieren.

Achtung bei der Verwendung von Binder Interface.

Genehmigung für ServiceConnection im Package Manager prüfen, vor dem Austausch sensitiver Daten.

Server: Genehmigung mit erzwingen
Feingranularere Zugriffskontrolle durch Verwendung von Binder und Context Hilfsfunktionen

Broadcast Receiver

Receiver: Wiederum eine Genehmigung erzwingen

Sender: Immer darüber nachdenken, wer den Intent empfangen können soll. Also einfordern einer Permission und Definieren des Empfängers des Intents.

Don’t user sticky broadcasts for sensitive data!

ContentProvider

Achtung, beim Verwenden eines ContentProvider intern, android:exported=“false“ explizit setzen.
Lese und Schreibrechte trennen
android:readPermission
android;writePermission

TAg schränkt zur Compiletime uri Zugriffe ein.

Mitkönne erlaubte Pfade für uri Zugriffe angegeben werden.

Tips:
Jegliche empfangene Daten aus einem Intent prüfen
SQL Statement und Daten die es enthält klar trennen.

Selection fields final machen um Kontaminierung aus Zufall zu vermeiden

Selektionen komplett vermeiden, Content_uris verwenden.

File I/O

Files, DB und geteilte Preferenzen könne mit Berechtigung installiert werden

Bei Zugriffsberechtigungen auf Datenbanken immer an die Konsequenzen denken und immer den User fragen.
Daten auf SD Karte NIE unverschlüsselt ablegen.

IMMER DRAN DENKEN Nutzerdaten SICHER speichern.

So wenig Permissions wie möglich, anstelle einer Permission manchmal besser ein Dialog.

Javaforum Stuttgart 2011 #jfs2011 Live Blogging Vortrag 4

Vortrag 4:

Java in der Cloud – Aktuelle Möglichkeiten und Entwicklungen

Was ist die Cloud?
Infrastructure as Service
Virtuelle Server, vergleichbar mit Virtualisierung

Manage Everything yourself
Player sind z.B. Amazon Webservices
VMWare
Platform as a Service
Virtual App Server
werden meist von den Providern gemanagt.
Skalierung wird vom Anbieter gemanagt.
Beispiele Cloudfoundry oder Google App Engine

Software as a service

Software aus der Cloud meist ebenso relevant für User wie Entwickler
Beispiele: Salesforce
Google Mail

Cloud Modelle:

Public -> Für die Öffentlichkeit verfügbar

Private -> Nur für eine Organisation verfügbar

Community -> Für mehrere Organisationen verfügbar

Hybrid -> Kombination verschiedener Modelle

Warum Cloud überhaupt machen

Public Cloud: Zahl nur, was du brauchst
Billige Art, Lastspitzen zu behandeln
Transparentes Kostenmodell

Private Cloud:
Besser Verwendung der Ressourcen
Kosten können abgerechnet werden
Der nächste Schritt nach der Virtualisierung

Business Agility
Deployment von Anwendungen per Maus Klick
Testumgebungen sehr einfach und günstig. Zahlen nur beim Testen.
Die Anwendung skaliert automatisch

Werner Vogels (CTO Amazon) sagt: Ihre Ingenieure brauchen 70% der Zeit für Skalierbarkeit und Technologie-> Deshalb Cloud

Plattform der Zukunft
Ausfallsicherheit, Automatische Verteilung, neue Computer einzurichten wird trivial
Günstige Systeme mit hoher Verfügbarkeit und Datenhaltungssicherheit
Sieht so aus wie Google, Amazon, Facebook

Wie sieht das für den Java Entwickler aus

Wie gehe ich mit Lastspitzen um? Ich brauche mehr App Server Instancen
Nach dem Peak müssen sie auch wieder gestoppt werden
Elastic Scaling als Stichwort
Was der Entwickler am Ende hat:
Eine Werkzeug, das eine Anwendung nimmt und daraus eine VM erzugt, mit der gesamten nötigen Infrastruktur.
Diese kann dynamisch hoch und runter skalieren.

Wir benötigen Werkzeuge zur Installation der Software
Die Infrastruktur verwalten
Benutzer einrichten

Tools sind z.B. Puppet, Chef etc.
Quasi eine Factory für VMs
Für lokale Installationen existiert „Vagrant“
Vorteile: Sehr flexibel
Arbeitet für jetwede Infrastruktur und Anwendung
Arbeitet auf komplexen Installationen mit versch. Komponenten
Verschiedene Anwendungen können auf verschiedene Knoten deployt werden.

Aber noch besser geht es:

Anwendung auf einer PaaS Umgebung also Plattform as a Service deployen
Vorteil: Nützlicher, da ein Server sowieso installiert werden müssten
Automatische Skalierung
Zusätzliche Dienste im Angebot

Aber:
Weniger flexibel
Vordefiniertes Entwicklungsmodell
Lernkurve für das Programmiermodell
Existierender Code ggf. schwer zu migrieren.

Mogliche PaaS Plattformen
Google App Engine
Java Unterstützung aber sehr restriktive Umgebung mit Java Classes White List
Fokus auf NoSQL

Begrenzung der startbaren Applikationen
Limit auf Antwortzeit (30sec)
Kein Zugriff auf OS oder Server

Daher wurden spezielle Frameworks entwickelt
(Gaelyk for Groovy)

Aber besser laut Vortragendem

Amazon Elastic Beanstalk

Basierend auf der EC2 Infrastruktur
plus Auto Scaling und S3
Dazu Linux, OpenJDK und Tomcat

Zur Zeit im Betatest im Osten der USA
Es gibt Eclipse Plugin
Es unterstützt Versionsverwaltung für Applications, sowie Elastic Scaling
Einfaches Monitoring ist eingebaut
Detailierte Kontrolle über die Umgebung ist möglich.
Zugang aufs OS und Tomcat Logs

Spring basierte Demoanwendung ist vorhanden und es existiert ein Relational Database Service (RDS) für enterprise scale MySQL und andere Amazon Web Services
Skalierungseinheit 1 VM = 1 Server

Weiterer Ansatz
VMWare Cloud Foundry
Open Source Projekt bei GitHub unter der Apache2 Lizenz

Sehr neu, noch ohne kommerzielle Angebote

Kann Ruby, Java und Node.js laufen lassen
Verschiedene Frameworks werden unterstützt
Kann überall gehostet werden, wird von der Community erweitert, z.B. Support für Erlang, PHP, Python

Es existiert ein Eclipse Plugin
Es unterstützt elastic scaling…. Ok, man kann es bauen.
Aehnlich normalen EJB Umgebungen mit Tomcat und MySQL
Läuft auf ubuntu
es teilen sich n Server eine virtuelle Maschine, damit geht die Skalierung feingranularer.
Angebotene Dienste sind
RDB Service
Key Value Store
Document Store
Messaging Service
Mehr kommt
Es gibt auch eine API zum Erstellen der eigenen Services

Zusammenfassend
Cloud wird aus drei Gründen kommen: Kosten, Business Agility, Platform of the Future
Google App Engine Pionier aber veraltet

Amazon Beanstalks: Standing on the shoulde of Giants

Cloudbees: Für Entwickler

Spannend scheint CloudFoundry: Open Source mit einer grossen aktiven Community, lauffähig auf ubuntu!

Javaforum Stuttgart 2011 #jfs2011 Live Blogging Vortrag 3

Vortrag 3:

Das nächste große Ding
Programmiersprachen für die JVM

Java ist in gewissem Sinne bereits Legacy.

Was ist eine große Programmiersprache?

C, C++, Java sind groß -> Pascal eher nicht, Modula auch nicht
Große Sprachen erlauben große Projekte

Sprachen, die sich modernisieren werden nicht zwangsweise besser, eher komplexer.

Eine große Sprache ist wichtig, weit verbreitet, berufsentscheidend und etabliert.

Es kommt aber NICHT auf die Syntax an.
Wichtig ist auch die Community!

Das nächste große Ding läuft vermutlich auf der JVM.

Konkurriert mit Java.
Und ersetzt Java und macht möglicherweise noch andere überflüssig.

Die guten Seiten von Java sind heute nicht mehr relevant. Objektorientierung, Threads, Packages, Sandbox etc. sind zwar gut aber „old school“.

Bestimmte Probleme lassen sich mit Objektorientierung sehr gut lösen, aber nur die. Mit einem Löffel kann man auch eine Baugrube ausheben.

Auch sonst gute Aspekte wie: kein goto, Kein Überladen von Operatoren, kein typedef, kein Präprozessor
Schönes Zitat: „Die jungen Leute kennen keine Pointer mehr“

Technologie-Sprung
NICHT alles ist aber ein Objekt. Dinge, die wir für alle Datentypen machen müssen, müssen wir auch für alle Datentypen tun.

Die primäre Weisung es muss rückwärtskompatibel sein

Sekundäre Weisung
Das Java „Feeling“ sichern
Die konzeptuelle Integrität sichern.

Java hat Probleme mit Generics und Closures

Anderungswünsche
foreach auch für Maps
Switch-break-fix
Abfangen von unmoglichen Checked Exceptions
und diverse moderne Elemente anderer Sprachen.
Die Frage ist nicht die Menge an zu schreibendem Code, sondern wie lesbar ist der Code der „zukünftigen“ Sprache.

gewünscht:
Sprachorientierte Programmierung
Unveränderlichkeit
Funktionale Programmierung
Nebenläufigkeit und Parallelität

Auf jeden Fall eine Art Paradigmenwechsel

Javaforum Stuttgart 2011 #jfs2011 Live Blogging Vortrag 2

Vortrag 2:

Funktionieren agile und dynamische Entwicklungsprozesse nur in dynamischen und agilen Unternehmen?

Entwicklungsprozess funktionieren, wenn die Ziele erreicht werden, das berühmte Dreieck Qualität, Kosten und Termin wird präsentiert.

Der Prozess bei Gebit ist iterativ, inkrementell, mehrfach paralleler Entwicklungsprozess, also Modell-Driven
Interpreter Framework, kein Generatorenframework, also interpretieren des Modells zur Laufzeit.

Gebit setzt agile Methoden wie
Parrprogrammierung, Testgetriebene Entwicklung und Refactoring

Auch hier fällt das Stichwort Continous Integration wieder.

Erstes Fallbeispiel: Projekt Entwicklung Kassensystem, Ablösung von Standardsoftware mit zahlreichen Schnittstellen zu Backend Systemen.
Bei GEBIT lag auch die Testverantwortung.
Die Beauftragung erfolgte immer in Monatssteps->Gefiel das Ergebnis bis dann->Nächster Step.
Die Entwicklung erfolgte alleine durch GEBIT.
Insgesamt 15 Monate bis zu ersten produktiven Implementierung.
Schlüssel zum Erfolg:
-Paarweise Spezifikation
-Volle Konzentration von Auftraggeber und Nehmer auf das Projekt
-Eskalierte Themen wurden ernst genommen
-Betroffene zu Beteiligten machen.

Zweites Fallbeispiel: Sachbearbeiteranwendung in einer Behörde.
Ablösung von 2 Altverfahren, 12,3kg Specs von mehr als 50 Autoren (Projekt lief bereits lange)

Testautomatisierung in hohem Mß durch MA des Kunden

Problem bei diesem Projekt, keine wirklichen ITler in der IT Abteilung der Behörde

Keine Projektleitung beim Kunden, da Mitarbeiter maximal 20-30% der Zeit für Projektleitung
Projekt für Einführung und Betrieb fehlte aber völlig.
Keiner der beteiligten Mitarbeiter war Vollzeit im Projekt, maximale Zuordnung war 50% im Projekt.
D.h. Oft laufen IT Projekte in IT fernen Unternehmen, ohne das Bewußtsein für die Bedürfnisse eines IT-Projektes.

Herausforderungen: Agile Methoden waren gesetzt
Es wurde sich am V-Modell orientiert
Umfangreiche Mitwirkungsleistungen des Auftraggebers wegen Budget

Hoher Headcount auf Kundenseite
aber Teilzeitkräfte, Tagesgeschäft, Altverfahren

Projektteams ohne Projekterfahrung. Das ist oft ein grosse Problem. Order by Mufti funktioniert hier nicht.

Die IT Affinität fehlte bei 90% des Projektteams, auch keine Seltenheit, leider oft sogar eine gewisse versteckte Aversion.

Es gab oft Spannungen zwischen den Linientätigkeiten und dem Projekt, oder wie ich immer sage, ENTWEDER Projekt ODER Linie, beides GEHT NICHT!
(Sorry, hier muss ich schreien)

Es wurde nur verwaltet, nicht proaktiv gesteuert. Auch dies kein seltenes Phänomen, meist wird mehr Wert auf Excel Schlachten und Statusberichte gelegt, als auf die aktive in Angriff Nahme der Entwicklungsherausforderungen. Der Entwickler ist meist das kleinste Rädchen, das das ganze einfache Programmierzeugs macht. Hierarchische Strukturen fressen gerade in grossen IT Projekten oft wichtige PT und Ressourcen.
Hier wurde die Agilität „ausgelagert“ zu den GEBIT Entwicklern.
Das Kernteam war mit dem Projektverlauf sehr zufrieden, aber die Mitwirkungsleistungen waren nicht in time. Es gibt immer noch Aufgaben, obwohl das Projekt zu Ende ist.

Kein Vorgehensmodell kann einen Erfolg erzwingen. Auch das Umfeld muss stimmen. Und da krankt es meist. IT Projekte ohne Mitarbeiter mit „Lust an der IT“ werden grausam!

Lessons learned:
Veränderung der Kommunikationskultur schwierig
Prozesse in Behörde dauern länger als lange.
Steuerung des Projektes notwendig
Spezifikationsänderungen nachvollziehbar dokumentieren
Stimmige Chemie kompensiert vieles
Betroffene zu Beteiligten machen
Spannungsfeld Fakten und Zahlen < -> Zweckoptimismus

Javaforum Stuttgart 2011 #jsf2011 Live Blogging Vortrag 1

Vortrag 1:

Top 10 Tools für mehr Spass beim Entwickeln

Inhaltlich ein Querschnitt über die Tools aus der Community für Clean Code, mehr Spass bei der Arbeit (Dilbert, Comics Fun bei der Arbeit), das sind Punkte, die zwar in freien Arbeitsenvironments sinnvoll sind, dann aber verlangen, dass der Entwickler selbstgesteuert arbeiten darf. Oft ist dies in grossen Unternehmen aber nicht möglich.
Auch die Tools sind eher dann realistisch, wenn man als Entwickler die Freiheit hat, Tools, die man selbst schätzt zu installieren. Auch dies ist in den typischen Grossunternehmen mit angehängter IT Abteilung nur bedingt realistisch.

Spannend, Eclipse Mousefeed-Plugin empfiehlt passende Tastenkürzel
Weiteres Werkzeug-> Continous Integration, da sind wir gerade dran, also auf einem guten Weg. Phyllis ist als Testtool interessant um Regressiontests zu automatisieren.
Auch in diesem Vortrag zeigt sich wieder, Gamification muss nicht auf das Alltagsleben und die Freizeit beschränkt sein. Auch in der Arbeitswelt kann ein gewisses Maß an Gamification die Motivation, speziell in den kreativen und den wissenbasierten Jobs erhöhen. Stichwort z.B. TDGotchi um die Testerstellungsmotivation zu erhöhen.

Und letztlich, aber wirklich nicht sehr überraschend. Weiterbildung auf allen Kanälen. Hackathons/Hackergarten, Blogs etc. Wir müssen offener sein, mehr berücksichtigen, dass nicht alle gleich arbeiten. Gute Arbeit hat auch sehr viel mit einem guten Arbeitsumfeld zu tun.