The Office Workplace Of The Future

Screens get more and more important in our daily lives. They got up to photo realistic sharpness. They got as flat as paper. Highly energy efficient and even bendable. But the future for the display manufacturers are bleak. Why? Because you will only need 2 displays to replace them all!

Since I first had an Occulus Rift DK1 on my head I tell my friends about this technology. But VR will not be the future of the workplace. VR is just a, very simple, stepping stone. I believe that hyper realistic Augmented Reality will be the future. It needs three technologies to come together to make that happen: High Resolution Ultra Realistic Semitransparent Imaging, Real Time Location Mapping and High Precision Spacial Location Technologies.

The Incredients

High Resolution Ultra Realistic Semitransparent Imaging is the obvious part. Lets unravel that adjective worm. First semitransparent. This is the basic difference between virtual reality and augmented reality. The first one is none transparent and just renders everything. The second one uses a (semi) transparent display and renders „over“ the picture you see through. Thus a augmented reality solution can also be a virtual reality solution by rendering over all the display, blocking out the real world.
High Resolution is the next adjective: Imagine an imaging system that can show you digital pictures that are so finely rasterized, that you can not see any pixels anymore. Sounds complicated? It’s actually not. If you have a display close to your eye, or maybe even in your eye (in form of a contact lens or an implant) you need only to reach the resolution of your eyes retina. With current 2D displays you have the problem, that you can move your eye closer to the display until you see the pixels, or farther away, where you „waste“ the high resolution. With an display in or directly in front of your eye, you can optimize that display to have exactly the needed resolution. The resolution is actually not that high and, sooner or later, will be build.
The next attribute is Ultra Realistic. This means, that the coloring and lighting of the object needs to be perfect. The problem is not the rendering part. The problem to solve here, is to recognize the lighting situation of the real world, so that the object you are rendering looks like it is really there. This ties in nicely with the second technology that is needed:

Real Time Location Mapping describes the capability to „scan“ the surrounding and building a precise digital model of it – in real time. Why is this necessary? Well if you want to put a virtual piece of paper on your desk, you need to know how high the desk is, the slope of the desk etc. Else you piece of paper could „float“ above the desk or sink into it which would destroy the immersive effect you want to create in the first place. Also you need this model to create physical correct behavior. If you drop a ball on a slope it should roll to the physically right direction.

High Precision Spacial Location Technologies are needed to place things in the real world and finding it again at the same place when you come back. It is also necessary for sharing objects between people in the same area. Maybe you want other people to see the same virtual picture on the wall.

This is how the future will look like

Lets imagine you are an IT guy, working on creating software systems. Your powerful IDE gives you lots of helpful views/widgets/windows to work on your code. In the old days you were limited to 1 or 2, rarely more displays (your boss didn’t want to pay for more). Now, you simply create as many virtual displays as you need and you position them around your place. Some could „stand“ on the desk, some less often used ones may float next to you in the air.

You are working together with 7 other people in a small crossfunctional team. You see Bob on his desk in the corner, albeit he works from home today. He just choose to transmit his presence into the office space, so that other people know where he is (and that the boss believes that he is working).

On the far wall of the room the team decided to project the production server logs and the build server status. So both things are always in sight. Basically the team defined that the wall is now a huge 5x3m screen. This information is location dependent and private. Only team members that come into the office will see this information. The calendar with the plan for physical presence in the office on the other hand is publicly shared. So everybody that comes in can see it. It is automatically updated from the database, no manual syncing of information between electronic and physical mediums is needed.

What are the consequences?

Well a very simple consequence is that you will no longer need displays on other gadgets. Phones can be created without display, maybe they become more like an wristband or the „StarTrek“ Communication button. You will neither need a PC/Laptop Monitor, projector nor a TV. This is bad news for display manufacturing companies. Either they jump on the AR train and lead the charge (to survive) or they will try to stop this evolution. History will tell which side they chose.

You also don’t need a dedicated wall/furniture for the now obsolete displays anymore. Architecture and interior design can now focus on other aspects of live, instead of building the living room around the TV.

Another consequence is, that the digital world will be everywhere. You can overlay videos over everything. In newspapers (if dead trees aka paper will still be used) or as commercials in the streets.

Another aspect is that windows and views are also obsolete. You can have jar dropping views in your small town basement apartment just as well as in a skyline loft. This can very well change the real estate market. AR will make anything possible as long as it is visual.

Where are we right now?

For this I would like to share a TED talk from April 2016. It is a showcase for Microsoft HoloLens. It is not yet there, but it is not to far away either.

Do you think I’m right, or where did I go wrong? Let me know in the comments.

Werbung

Was die Zukunft bringt

Effizienz und Produktivität ist für die Roboter. (Kevin Kelly)

Ich kenne Kevin Kelly von Tim Ferriss‘ Podcast. Er beschäftigt sich mit Trends und Technologien und ist als Mitgründer von „Wired Magazin“ hierfür kein schlechter Ansprechpartner. In seinem 1994 erschienenen Buch hat er sich bereits mit Dezentralisierung und Selbstorganisation (Schwarmintelligenz) beschäftigt. Dieser TED Talk ist sehr zu empfehlen:

Tip für den Gebrauchtwagenkauf

Ich war gestern in der Werkstatt und habe einige Verschleißteile reparieren lassen. Eine „Lesson Learned“ für den nächsten Gebrauchtwagenkauf:

Wenn der Wagen >100.000km runter hat, dann checken

• ob die Bremsen erneuert wurden. Und wenn ja, was gemacht wurde. Nur Vorn, V+H, Nur Scheiben oder Scheiben und Klötze? Ein Kompletter Bremssatz kostet je nach Fahrzeug 1000EUR +- 300EUR
• ob die Querlenker erneuert wurden. Und wenn ja, ob nur oben/unten oder beide. Die Dinger kosten komplett auch leicht 1000EUR.

Das sind Verschleißteile die nach 100.000 – 150.000km fällig werden.

Außerdem immer Fragen

• Wurde im Wagen geraucht?
• Sind Winterräder dazu?
• Wann wurden die Reifen zuletzt erneuert?

Agiles Schätzen mit Storypoints – Agile Estimating with Story Points

English Version below

Agiles Schätzen mit Storypoints

Komplexität, Aufwand, Zeit – was soll mit den Storypoints eigentlich geschätzt werden?

Wenn alle Userstories von ein und derselben Person bearbeitet werden würden, dann sollte am Ende gelten: Je größer die geschätzten Storypoints, desto länger hat es gedauert (Investierte Arbeitszeit = Aufwand).

Nun arbeiten wir aber im Team und wir alle wissen, dass es unterschiedliche Arbeitsgeschwindigkeiten gibt. Deshalb schätzen wir ja nicht in Zeit sondern Storypoints. Und Storypoints funktionieren immer im Vergleich mit anderen Aufgaben (relatives Schätzen), also „größer, kleiner, gleich“. Deshalb stellt euch folgende Frage beim Schätzen:

„Wenn ich die Story allein lösen müsste und ich alle Tools benutzen dürfte die im Team zur Verfügung stehen, würde ich dann länger, kürzer oder gleichlang für diese Story brauchen als für die andere Story?“

Jetzt kommt sofort der Einwand „Aber ich kann ja gar nicht alle Tools bedienen, bzw. mir fehlt Vorgehens-/Fachwissen etc.“ Das stimmt. Aber das fehlt euch bei allen Stories gleichermaßen und kürzt sich weg. Um „größer, kleiner, gleich“ abschätzen zu können reicht es also die Teammitglieder zu befragen, welche tatsächlich Ahnung von den anderen Aufgaben haben. Wenn die sagen „weniger als bei der anderen Story“, dann gilt das für euch bezüglich dieses Aufgabenteils wahrscheinlich auch.

Abschließend noch ein Wort zu Unwägbarkeiten und Risiko. Schneller darf die Bearbeitung immer gehen. Probleme gibt es eher dann, wenn wir Risiken unterschätzen. Deshalb überlegt euch, wie der realistische Worst-Case aussehen könnte und wie aufwändig dieser im Vergleich zur Vergleichsstory ausfällt.

Agile Estimating with Story Points

Complexity, effort, time – what do we estimate when we use story points?

If all user stories are estimated and implemented by the very same person, than the rule should apply: The higher the story points, the more time had been invested (effort).

But we work in teams and as we know, we all have different working speeds. This is the reason why we use story points instead of time estimates. And story points work always in relation to other stories (relative estimation), means „smaller, same or bigger as the other story“. Thus, next time when you estimate ask yourself this question:

„If I had to implement this story all by myself, but I could use all the tools that are available to my team, would it take longer, shorter or as long as the reference story?“

But immediately you will say „But I can not use those tools“ or „I lack the process/domain knowledge etc.“. True – BUT this is true for all stories and therefore (because we estimate by comparing stories) cancels out of the estimation. To estimate „smaller, same or bigger“ you only need to ask those team members who know how to use the tools or have the knowledge. If they say „its less than the other story“ than this holds true if you would do the job.

One final word regarding risk or beeing unsure. It is always good to finish stuff faster. Problems arise (for the PO) if we under estimate tasks. Thus if you feel unsure, it is a good idea to think about the realistic worst case scenario and compare that with the reference story.

 

Vortrag zu Responsive Design by Kent Beck

Ich schaue gerade Kent Becks Vortrag zu Responsive Design an und versuche hier mal meine Gedanken zu den Thema nieder zu schreiben. Hier der Link:

http://www.infoq.com/presentations/responsive-design

Die Seite sieht etwas unübersichtlich aus. Nicht sofort zu erkennen war, dass das Video links nicht alles ist, sondern rechts daneben die Vortragsfolien parallel zum Video umschalten. Also nicht einfach (wie gewohnt) das Video in den Vollbildmodus schalten.

Retrospektive mit Karteikarten

Das sollte man auf Arbeit mal unseren Vordenkern vorschlagen. Hier wendete Kent das „Continuos Improvement“ Pattern auf sich selbst an. Wer macht das eigentlich sonst noch. Häufig wird herzlich gestritten, eine Lösung gefunden und schnell wieder an die Arbeit gegangen. Aber zu dokumentieren warum gestritten/um eine Lösung gerungen wurde und wie und warum das Ergebnis ist wie es ist, das passiert sehr selten. Wahrscheinlich einer der Gründe wieso Kent Beck ein so gefragter Entwickler ist. Er macht nicht nur, sondern er denkt auch darüber nach wieso er es so macht.

Designprinzipien

Kent erwähnt Designprinzipien als Leitfaden für die Entwicklung eines Softwaresystems. Ich kann das nur bestätigen und merke leider immer wieder, dass genau diese bei der Arbeit zwar allen bekannt sind, jedoch häufig nicht dokumentiert werden. Wenn dann Jahre später die ursprünglichen Programmierer weg sind und andere an dem System arbeiten (und andere Prinzipien anwenden) entsteht schnell schlecht wartbarer Code, da Entscheidungen nicht konsistent weiter geführt werden.

Problemlösungs- / Refactoringstrategien

Leap – Sprung

So wie ich Kent verstehe ist der Leap der gefährlichste, jedoch auch schnellste Weg eine Änderung zu erreichen. Solange ich glaube(!) es schaffen zu können sollte ich den Leap versuchen. Sobald ich aber (unterwegs) unsicher werde und das System nicht mehr läuft, gehe ich zurück zum Startpunkt und versuche eine alternative Methode. Kent bringt als Beispiel eine Anwendung wo er sein Designprinzip „Streams statt Filenames“ verletzt hatte. Er wollte nun die Filenames durch Streams ersetzen. Da er 4-5 Klassen anpassen musste ging er davon aus, dass er das so hinbekommt, und wagte den Sprung (Leap). Als er merkte, dass es zu undurchsichtig wurde, änderte er alles wieder zurück und versuchte einen anderen Ansatz.
Interessant war, dass Kent Beck, Author von JUnit, hier zugegeben hat, dass auch bei ihm hin und wieder keine gute Testabdeckung vorkommt. Um überhaupt zu wissen, ob ein Leap erfolgreich war, braucht man Testabdeckung. „Refactoring nur unter Testcoverage“ sollte jedem als Prinzip bekannt sein.

Parallel – Redundanz

Bei Parallel wird ein „zweiter Weg“ ein Problem zu lösen neben den aktuellen (nicht mehr gewollten) gestellt.
Kent bringt wieder das Beispiel „Ersetzen von Filenames durch Streams“. Hier kann man sich vorstellen, dass solch eine Änderung an diversen Stellen in einem SW System schnell unübersichtlich wird.
Kent sagt nun, dass die Parallel-Entwicklung ein sichererer Weg ist. Das kann man so hinnehmen, ich frage mich aber „An welchem Ende des Systems sollte man mit der Umstellung auf Streams beginnen“?

Ich glaube das man vom Ende her beginnen sollte. Also dort wo aktuell die Filenames aufgelöst und die Inhalte gelesen werden, schreibt man eine zweite Methode, welche einen Stream benutzt und zieht die Business-Logik dahin um. Man weiß, dass die Logik funktioniert. Einzig neuer Punkt ist nun, dass Streams statt File-Operationen genutzt werden. Tritt ein Fehler auf weiß man genau, wo man suchen muss. Alle anderen Klassen arbeiten weiter mit Filenames und rufen auch an meiner Klasse die alte Methode mit Filename auf. Die Alte Methode ist aktuell quasi leer. Statt dessen schreibe ich nun dort den Code zum umwandeln eines Filenames in einen Stream hinein und rufe meine neue Methode. Nachdem das alles funktioniert gehe ich zur der Klasse welche meine alte Methode aufruft und schreibe dort eine alternative Methode mit Streams. Diese kann jedoch sofort die neue Methode nutzen. Damit ist die alte Methode an der ersten Klasse nun nutzlos geworden und kann entfernt werden. So gehe ich schritt für Schritt voran und stelle den Code um.

Stepping Stones – Zwischenschritte

Wirklich klar wird das Prinzip durch die Phrase „Wenn ich XYZ hätte, wäre das nicht so schwer“. In so einem Fall baut man sich ein XYZ und macht dann weiter. Notfalls stellt man das XYZ erstmal neben (Parallel) den restlichen Code.
Stepping Stones können leicht overdesigned werden. Also KISS anwenden.

Simplification

Kernidee hier ist: Auf welche primitive Form kann ich das Problem eindampfen? Wenn ich z.B. die Aufgabe habe einen Differentialgleichungs-Löser zu schreiben, der mit bis zu 20 unbekannten arbeiten kann, dann wäre es eine gute Idee mit einem zu beginnen wo keine unbekannte enthalten ist. Und dann einen mit einer Unbekannten. Und dann einen mit zwei. Und dann fällt dabei fast schon von alleine der mit n Unbekannten hinten ab.

Successions – Abfolgen

Die restlichen Folien werden sehr schnell abgehandelt. Von Interesse fand ich die Idee der Successions. Kent vermutet, dass es bei der Arbeit immer wieder Schritte gibt die man nach und nach durchführt um erfolgreich zu sein. Eine dieser Abfolgen ist das bei Simplification erwähnte Prinzip erst „Eine Lösung für 1 Element herzustellen und dieses dann auf mehrere Elemente zu erweitern“ (First One – Than Many). Kent vermutet, dass es noch weitere solcher allgemeinen Abfolgen gibt.

Schlussfolgerung

Ein Vortrag den man sich durchaus mal anschauen sollte.

How to use JPA (and DBs) correctly

Today was a day of greater insights at work. We (Java guys and our DBA) have been discussing how to optimize database access from our Java application. Of course we use JPA (by OpenJPA).

We came to the conclusion, that we all are great fans of interfaces and separation of concerns, but we failed to apply it when we designed our persistence layer.

In our application, the jpa entities are exact copies of the tables in the database. Currently we do a refactoring of our database design, and this hits the application code hard.

The following steps to enlightenment we climbed today:

1. When you access the db by scenario/use case dependent views, you decouple the db design from the java entity design and vice versa. Whenever you change your db design, this goes with 0 effort for the java team.
2. JPA is capable of integrating values from several tables in one entity, thus JPA entities work like RW-views. Whenever the db design changes, you (should) only have to adjust the JPA annotations to get it working again.
3. Use good old component architecture for your Java/Application layer. Each component owns its own private JPA entities and some specific public transfer objects to send and receive information to and from a component.
4. Your private JPA entities hold only necessary information. This holds especially true for relations between entities. If you don’t need a relation in your component, just load it as an ID field instead. This will automatically cut unnecessary eager fetches.

If you have considered this points, also read this article on optimizing the use of JPA by

• eager fetching if you need all members of a collection instead of N+1 selects (you can do this with JQL fetch queries, too!)
• lazy loading if you don’t need related objects.
• JPA pagination instead of java pagination for big result sets.
• load specific columns if you don’t need the whole object.

Kein DRM in HTML5

Dieser Blogpost lag als Entwurf noch herum und sollte eigentlich vor einem halben Jahr online gegangen sein…

HTML ist ein Webstandard. Das dürfte mittlerweile jeder wissen. In seiner neuesten Version, HTML 5, liegt ein riesiges Potential für die Weiterentwicklung des Internets. Das hat unter anderem Google begriffen und promoted HTML 5 wie verrückt.

Scheinbar hat nun auch Microsoft dieses Potential gesehen und macht das was Microsoft halt dann so macht: Sachen kaputt. Aktuell versuchen Hersteller, darunter MS, das W3C (die Organisation welche die Webstandards verabschiedet) davon zu überzeugen DRM in HTML5 aufzunehmen. DRM ist „Digitales Rechte Management“, kurz das Zeug was dafür sorgt dass ihr eure gekauften MP3s nicht brennen könnt oder die DVD aus den USA in Deutschland nicht läuft. DRM ist der Feind des freien Internets. Andreas Romeyke hat dies schön zusammen gefasst:

DRM steht für Digital Rights Managment. Kurz gesagt, werden
metaphysische Güter künstlich verknappt, in dem diese an bestimmte Personen (Zahler) gekoppelt werden. Dies geschieht in der Regel durch Verschlüsselung, immer öfter zugleich mit zeitlicher und örtlicher Beschränkung des Zugriffs.

Das ist aus mehreren Gründen problematisch.

1. bei den metaphysischen Gütern handelt es sich idR. um digitalen Datenblock (zB. Bild, Musik, Video, Text) der eigentlich verlustfrei beliebig oft kopiert werden kann. Kurzum, endlich ist es der Menschheit gelungen Waren herzustellen, die niemals altern. Dann kommt jemand daher und läßt diese ohne Not künstlich altern.

2. die Kopplung an eine Person erfolgt in der Regel so, daß eine
Weitergabe des so behandelten metaphysischen Gutes nicht ohne weiteres möglich ist. Man kann das Gut zwar kopieren, aber kein anderer kann es nutzen. Das Gut ist personalisiert.

3. Wegen 2. sind die Hersteller auf den Trick gekommen, daß Kunde ja kein Gut mehr kauft (und damit nicht in dessen Besitz übergeht), sondern man über DRM erzwingen kann, daß dieser nur eine Nutzungslizenz erwirbt. Sprich, dem Kunden kann man wieder etwas wegnehmen und der muß dann ggf. bei  mehrfacher Nutzung auch mehrmalks blechen. Beispiel
Video, bei einem Kaufvideo kaufe ich einmal und kann mir dies mit Freunden dann immer wieder angucken, wenn ich es „lizensiere“, zB. Video on Demand, dann bezahle ich für *jedesmal* gucken.

4. durch die Personalisierung erfahre ich Dinge über jeden
einzelnen Kunden. Eine Deanonymisierung findet statt.

5. Das kulturelle Erbe ist gefährdet. Während zum Beispiel gedruckte Bücher ihren Besitzer überlebten und heute ein wertvoller Schatz sind (und oftmals der einzige, der überlebt hat), ist es bei DRM behafteten Büchern nahezu unmöglich, diese nach dem Tode zu nutzen. Ganz besonders fatal wird es, wenn die Firma ihren Lizenzserver abschaltet und man auf den dann wertlosen, verschlüsselten Gütern sitzenbleibt und man von heute auf morgen digitalen Müll besitzt.

Damit das W3C diesen Fehler nicht begeht müssen möglichst viele Nutzer das W3C darauf Aufmerksam machen. Dafür gibt es diese Petition:

http://www.defectivebydesign.org/no-drm-in-html5

Bitte gerne weitersagen.

Buy a new Smart Phone – Handyvergleich

Short description in English and link to the compare sheet below.

Schon Mitte des letzten Jahres hatte ich mir vorgenommen meinen Handyanbieter (Debitel) zu wechseln und mir ein Smartphone zu kaufen. Als das Nexus 4 heraus kam glaubte ich zu wissen was für ein Handy es wird. Allerdings kam ja Google nicht hinterher mit dem liefern…

Auf einem Stammtisch zeigte dann eine Piratin ihr Handy her. Es war zwar schon etwas älter aber trotzdem war ich baff: 4 Simkarten und TV-Empfänger in einem Handy??? Was war das denn für ein Teil? Sie sagte ein „China-Handy“.

Mein Interesse war geweckt und ich suchte gezielt nach China Handys. Ich habe dann eine Spreadsheet angelegt und alle Daten aller interessanten Handys (inklusive der Handys die ich vorher in der engeren Auswahl hatte) dort rein geklimpert und ausgewertet. Was war das Resultat?

Das Nexus4 war zu dem Zeitpunkt das technisch beste Handy in der Gruppe (das S3 war mir zu teuer und deshalb nicht dabei) ABER in Sachen Preis-Leistung war es trotzdem nicht in den Top10!

Hier das File: Handyvergleich.xls

Ich hatte mich in der Zwischenzeit mit dem Gedanken ein DualSim-Handy zu besitzen angefreundet und so habe ich mir das Jiayu G3 gekauft. Nach einem Viertel-Jahr kann ich sagen, dass es eine gute Entscheidung war. Es funktioniert und es hat mich sicher als Navi nach Rom und zurück gebracht.
Es ist allerdings nicht perfekt: Der Lautsprecher ist etwas „grell“. Das ist aber ok, da das Smartphone 90% der Zeit als „Mobile Device“ genutzt wird und nur 10% als Telefone.

Ich habe das Sheet heute nochmal aktualisiert mit 4 weiteren Modellen. Das beste (aber auch mit 260Eur teuerste) davon ist wirklich ein Knaller da es trotz des hohen Preises auch die Preis-Leistungs-Wertung gewinnt und das Nexus4 als Technologie-Führer ablöst.

—————

English

Last winter I was searching for a mobile device. I’ve been introduced to „china mobile“ accidentally in a bar. I did some research and compiled a spread sheet (see here) to compare the china phones with the western phones I liked. I finally ended up with buying a Jiayu G3 dual sim phone. After 3 months of usage I can tell: definitely a good choice. Check out the sheet.