Fast hätte ich darauf vergessen:
Unsere offizielle OOP Statistik:
5 Tage OOP
5 Übernachtungen in einem Businesshotel
25431 Schritte oder 22 km Herumgehen
5 (bzw. 4) Mittagessen in der Messe
10 Flaschen Getränke
2 Mal McDonalds
10 Taxifahrten
1 U-Bahnfahrt
8 Stunden 29 Minuten Zugfahrt
.. und das alles pro Person :)
Sunday 27 January 2008
Little Hint
If you are sitting in a train, and the police come and visit, don't be caught trying to entertain your colleague by explaining that you would create a web site trying to blackmail Mac users of the world. You get very funny looks and they spend far too long looking at your pasport.
Developing open-source Services using Apache CXF
This was a day long tutorial, given by Adrian Trenaman about how to create WSDL defined web service, using either either a SOAP, JMX or plain XML payload.
Adrian Trenaman works for Iona, which is a SOA consulting company. Iona have developed a framework on top of Apache CXF, called Fuse Service Framework. This is totally open source and Iona make money by providing service contracts, consultancy and training courses. This is the perfect example of where a company can make money by providing the core service for free.
Adrian was a softly spoken Irishman who had obviously given this course many times before in a much larger form. He wasted no time in working out what we could achieve in one day, helped us very quickly set up eclipse, and bombarded us with a massive amount of information.
Fuse SF, is a framework that allows you to create web services, either as a server or a client. A web service is something that a server provides via either HTTP or the Java Messaging Service (JMS). The service is defined via a WSDL document, which is a sort of mix between XSD and a basic XML document. In this document there is a definition of a port, which defines how this service can be accessed - i.e. its payload. Normally this is defined as a SOAP payload, which is a definition of a method call, and its return values in XML, wrapped up in a SOAP envelope.
With all these definitions, it seems that this would take a lot of work to actually create one of these services, there is certainly a lot of XSD definitions, XML marshaling and un-marshaling etc going on, on both the client and the server. Fuse FS makes this very easy. You can create a service either by creating an annotated java interface and implementation, or generating everything you need from the WSDL document. It works a bit like magic. Once I had my system configured correctly, I could create a simple service (one method call, one return) in about half an hour. This was very easy to test, because Fuse could also generate a client as well. A more interesting idea, would be to create a client in say Ruby, and then try to interact with the java server - which is the whole point of having a Service Oriented Architecture (SOA).
This was all very interesting and was a great advert for Fuse but what came later was much more significant. Fuse can be used to create a RESTful web service. Restful is now a big thing in the web world. The original idea came from Roy Fielding's Phd Thesis, and it has gone from strength to strength.
From a web service point of view, no WSDL is used, and all service operations are defined via HTTP URLs. The same URL can be used with different HTTP verbs (POST, GET, PUT and DELETE) to do different things. A URL with a DELETE verb would delete something, while GET would retrieve the same information. The other key idea is that there is no idea of a session between requests. All of that information will have to be passed via the URL. This is not a really really new - its functional programming at another level.
If you change the annotations on your Java interface and implementation, then Fuse will generate the other components you need to provide your service as a set of URLs. The payload could be simple XML. This service could also be sent to a web bowser, if the returning data was in the form of JSON- Java Script Object Notation.
If you compare the two ways of providing a web service, the RESTful idea seems a lot easier to handle on the client. We then, unfortunately, ran out of time, which was disappointing, but we did have to go home. I was happy that I took this course because I got to program and I got to learn something new.
If you think about it, Fuse is simply an implementation of model driven development, which is used to generate all the boring bits of web services automatically. I could imagine how much more boring it would be to generate such a service by hand and it is also something that the Spring-Hibernate people could learn from.
Adrian Trenaman works for Iona, which is a SOA consulting company. Iona have developed a framework on top of Apache CXF, called Fuse Service Framework. This is totally open source and Iona make money by providing service contracts, consultancy and training courses. This is the perfect example of where a company can make money by providing the core service for free.
Adrian was a softly spoken Irishman who had obviously given this course many times before in a much larger form. He wasted no time in working out what we could achieve in one day, helped us very quickly set up eclipse, and bombarded us with a massive amount of information.
Fuse SF, is a framework that allows you to create web services, either as a server or a client. A web service is something that a server provides via either HTTP or the Java Messaging Service (JMS). The service is defined via a WSDL document, which is a sort of mix between XSD and a basic XML document. In this document there is a definition of a port, which defines how this service can be accessed - i.e. its payload. Normally this is defined as a SOAP payload, which is a definition of a method call, and its return values in XML, wrapped up in a SOAP envelope.
With all these definitions, it seems that this would take a lot of work to actually create one of these services, there is certainly a lot of XSD definitions, XML marshaling and un-marshaling etc going on, on both the client and the server. Fuse FS makes this very easy. You can create a service either by creating an annotated java interface and implementation, or generating everything you need from the WSDL document. It works a bit like magic. Once I had my system configured correctly, I could create a simple service (one method call, one return) in about half an hour. This was very easy to test, because Fuse could also generate a client as well. A more interesting idea, would be to create a client in say Ruby, and then try to interact with the java server - which is the whole point of having a Service Oriented Architecture (SOA).
This was all very interesting and was a great advert for Fuse but what came later was much more significant. Fuse can be used to create a RESTful web service. Restful is now a big thing in the web world. The original idea came from Roy Fielding's Phd Thesis, and it has gone from strength to strength.
From a web service point of view, no WSDL is used, and all service operations are defined via HTTP URLs. The same URL can be used with different HTTP verbs (POST, GET, PUT and DELETE) to do different things. A URL with a DELETE verb would delete something, while GET would retrieve the same information. The other key idea is that there is no idea of a session between requests. All of that information will have to be passed via the URL. This is not a really really new - its functional programming at another level.
If you change the annotations on your Java interface and implementation, then Fuse will generate the other components you need to provide your service as a set of URLs. The payload could be simple XML. This service could also be sent to a web bowser, if the returning data was in the form of JSON- Java Script Object Notation.
If you compare the two ways of providing a web service, the RESTful idea seems a lot easier to handle on the client. We then, unfortunately, ran out of time, which was disappointing, but we did have to go home. I was happy that I took this course because I got to program and I got to learn something new.
If you think about it, Fuse is simply an implementation of model driven development, which is used to generate all the boring bits of web services automatically. I could imagine how much more boring it would be to generate such a service by hand and it is also something that the Spring-Hibernate people could learn from.
Saturday 26 January 2008
OOP day 5: Forced Feeback
Ein letzter Tag, ein letztes Post.
Tutorial: Lean Six Sigma and Design for Six Sigma for Software Engineering
wtf ;-) Ein etwas überdrehter Inder hat sieben Stunden lang auf uns eingeschrien (wirklich geschrien, ich hab was davon aufgenommen), um uns zu Six Sigma Gläubigen zu erziehen. Six Sigma ist eine Religion, und die funktionieren bekanntlich nur gut, wenn man daran glaubt. Das ganze Programm war ziemlich umfangreich und trickreich zusammengestellt, so dass man fast keine Chance hatte, die Fehler in der Logik zu erkennen (der Vortragende ist Consultant und davon leben Consultants).
Die einzige Frage die bleibt: Warum bin ich nicht in der ersten Pause gegangen? Zwei Gründe: Erstens ist es lustig zu sehen wie schlüssig die Ideen der Religion sind - und wo die Schwachstellen und Fehler liegen. Das ist ein bissi wie Rätsel lösen ;o) Und zweitens wolle ich immer schon wissen wie resisten ich gegen Gehirnwäsche bin, hehe ;-) Man gönnt sich ja sonst nix :)
Nach der indischen Gehirnwäsche war die Heimreise recht angenehm. Wir haben die Münchner U-Bahn ausprobiert (ich bevorzuge die Wiener) und JIT unsern ICE nach Hause erwischt. Das spannenste auf der Zugfahrt war eine Polizeikontrolle; scheinbar wurde gerade jemand gesucht.
In diesem Sinne, ich hoffe unser blogging aus München hat unterhalten, wenn nicht gibt's demnächst Six Sigma für alle, wahahahaha!
Tutorial: Lean Six Sigma and Design for Six Sigma for Software Engineering
wtf ;-) Ein etwas überdrehter Inder hat sieben Stunden lang auf uns eingeschrien (wirklich geschrien, ich hab was davon aufgenommen), um uns zu Six Sigma Gläubigen zu erziehen. Six Sigma ist eine Religion, und die funktionieren bekanntlich nur gut, wenn man daran glaubt. Das ganze Programm war ziemlich umfangreich und trickreich zusammengestellt, so dass man fast keine Chance hatte, die Fehler in der Logik zu erkennen (der Vortragende ist Consultant und davon leben Consultants).
Die einzige Frage die bleibt: Warum bin ich nicht in der ersten Pause gegangen? Zwei Gründe: Erstens ist es lustig zu sehen wie schlüssig die Ideen der Religion sind - und wo die Schwachstellen und Fehler liegen. Das ist ein bissi wie Rätsel lösen ;o) Und zweitens wolle ich immer schon wissen wie resisten ich gegen Gehirnwäsche bin, hehe ;-) Man gönnt sich ja sonst nix :)
Nach der indischen Gehirnwäsche war die Heimreise recht angenehm. Wir haben die Münchner U-Bahn ausprobiert (ich bevorzuge die Wiener) und JIT unsern ICE nach Hause erwischt. Das spannenste auf der Zugfahrt war eine Polizeikontrolle; scheinbar wurde gerade jemand gesucht.
In diesem Sinne, ich hoffe unser blogging aus München hat unterhalten, wenn nicht gibt's demnächst Six Sigma für alle, wahahahaha!
Thursday 24 January 2008
OOP day 4: Downhill Race
Der viere Tag der OOP war schon vom Aufbruch und dem baldigen Ende gekennzeichnet. Heute war auch der letzte Tag der Messe, morgen finden nur noch Kurse statt. Und trotz dieser Endzeitstimmung gab es heute einige freudige Überraschungen unter den Vorträgen – aber auch der wahrscheinlich schlechteste Vortrag der ganzen OOP.
Vortrag: Wie geht’s weiter mit Java?
Der langerwartete Auftritt von Angelika Langer! James hat sich extra auf Eclipse, Web und andere Vorträge verzichtet, nur um Angelika lauschen zu können. Darum lass ich ihm auch die Freude darüber zu berichten :)
Java 7.0 aus der ersten Reihe ;-)
It’s always the Goddamned Interfaces
Tim Lister again, in einem zu kurzen Vortrag über all die Interfaces, die nicht funktonieren können. Tim ist wie einer dieser Salesmen im Shopping-TV, die ewig weiter reden und dabei mit fast schon hypnotischen Kräften Hausfrauen vor die Glotze fesseln. Oder er wäre in einem anderen Leben TV-Prediger geworden.
Keynote: The role of Identity Services as a Foundation for Next-Generation Business Applications
Interessant. Wird vielleicht so sein. Trifft mich aber nicht wirklich.
Vortrag: Social Software: Zwischen Spielerei und Mehrwert
OMG! Diesen Vortrag hätte ich gerne auf Video. Ein klassisches Lehrbeispiel wie man in 60 Minuten alles, aber auch wirklich alles, falsch machen kann. Keine Substanz, schlechte Slides und keine Zeitplanung. Dazu ein schon schwacher Vortragender, der aber zudem noch bei einigen seiner eigenen Slides keine Ahnung vom Thema hatte. Wirklich lustig wurde es, als er Fragen nicht wirklich beantworten konnte und mehrere Zuhörer dann praktisch die Leitung an sich gerissen haben. Das war dann eine angeregte Diskussion, während der Vortragende noch immer versucht hat seine Slides weiter vorzulesen. Absolute classic.
Keynote: Why communities change everything
Hmm, ein paar Einblicke warum große Firmen Unsummen an die Entwickler von free software bezahlen (am Bsp. Eclipse), was sie sich davon erhoffen und wo es den vermeidlich größten Gewinn zu holen gibt. Naja.
All diese Firmen bezahlen für Eclipse. Wer findet das Logo von unseren Gehaltsabrechnungen wieder?
Vortrag: Java Multithreading im Zeichen von Mehrkernprozessoren
Wieder ein trockenes Thema im letzten regulären Slot (die Zeitplanung sollte wirklich überdacht werden), aber eigentlich gar nicht uninteressant. Die Vortragenden haben etwas zuviel reingepackt, aber die multithreading API ist bei der Einführung von Java 1.5 auch ziemlich untergegangen. Der Gedanke ein paar aufwendige Algorithmen multithreading zu machen ist schon verlockend.
Night School: Horizontal and vertical traceability: crucial for development of safety relevant systems
Ah, Titel klingt schon wie ein eingewachsener Zehennagel. Ich haben niemanden gesehen der beim Lesen des Titels nicht das Gesicht verzogen hat. Und um ganz ehrlich zu sein: Die Wahl der Nightschool war eigentlich ein einfaches Ausschlussverfahren, wobei eine Alternative nicht stattgefunden hat und die anderen beiden für mich noch uninteressanter waren. Ich hatte also keine Erwartungen an den Vortrag – und wurde sehr überrascht. Es war super!
Colin Hood hat sehr kurzweilig und mit der richtigen Prise Humor vom Sinn der Verbindung von Informationen erzählt. Und Colin Hood ist ein Consultant, dem man gerne zuhört – selbst beim letzten Vortrag des Abends. Er war ein Entwickler der alten Schule, die noch mit echter Hardware gearbeitet haben ;-) Es tut mir richtig leid für ihn, da offenbar die meisten Besucher die Night School schon gestrichen hatten, es waren nur vielleicht 17 Leute beim Vortrag. Aber eigentlich tun mir die Leute leid, die den kurzen Exkurs nicht hören konnten. Wenn er wieder bei einer Tagung spricht auf keinen Fall verpassen!
Zum Schluss noch der kulinarische Report. Die Nachspeisen waren jeden Tag ausgezeichnet. Herziges Beispiel: Mini-Muffins! Keine 2 cm im Durchmesser.
Vortrag: Wie geht’s weiter mit Java?
Der langerwartete Auftritt von Angelika Langer! James hat sich extra auf Eclipse, Web und andere Vorträge verzichtet, nur um Angelika lauschen zu können. Darum lass ich ihm auch die Freude darüber zu berichten :)
Java 7.0 aus der ersten Reihe ;-)It’s always the Goddamned Interfaces
Tim Lister again, in einem zu kurzen Vortrag über all die Interfaces, die nicht funktonieren können. Tim ist wie einer dieser Salesmen im Shopping-TV, die ewig weiter reden und dabei mit fast schon hypnotischen Kräften Hausfrauen vor die Glotze fesseln. Oder er wäre in einem anderen Leben TV-Prediger geworden.
Keynote: The role of Identity Services as a Foundation for Next-Generation Business Applications
Interessant. Wird vielleicht so sein. Trifft mich aber nicht wirklich.
Vortrag: Social Software: Zwischen Spielerei und Mehrwert
OMG! Diesen Vortrag hätte ich gerne auf Video. Ein klassisches Lehrbeispiel wie man in 60 Minuten alles, aber auch wirklich alles, falsch machen kann. Keine Substanz, schlechte Slides und keine Zeitplanung. Dazu ein schon schwacher Vortragender, der aber zudem noch bei einigen seiner eigenen Slides keine Ahnung vom Thema hatte. Wirklich lustig wurde es, als er Fragen nicht wirklich beantworten konnte und mehrere Zuhörer dann praktisch die Leitung an sich gerissen haben. Das war dann eine angeregte Diskussion, während der Vortragende noch immer versucht hat seine Slides weiter vorzulesen. Absolute classic.
Keynote: Why communities change everything
Hmm, ein paar Einblicke warum große Firmen Unsummen an die Entwickler von free software bezahlen (am Bsp. Eclipse), was sie sich davon erhoffen und wo es den vermeidlich größten Gewinn zu holen gibt. Naja.
All diese Firmen bezahlen für Eclipse. Wer findet das Logo von unseren Gehaltsabrechnungen wieder?Vortrag: Java Multithreading im Zeichen von Mehrkernprozessoren
Wieder ein trockenes Thema im letzten regulären Slot (die Zeitplanung sollte wirklich überdacht werden), aber eigentlich gar nicht uninteressant. Die Vortragenden haben etwas zuviel reingepackt, aber die multithreading API ist bei der Einführung von Java 1.5 auch ziemlich untergegangen. Der Gedanke ein paar aufwendige Algorithmen multithreading zu machen ist schon verlockend.
Night School: Horizontal and vertical traceability: crucial for development of safety relevant systems
Ah, Titel klingt schon wie ein eingewachsener Zehennagel. Ich haben niemanden gesehen der beim Lesen des Titels nicht das Gesicht verzogen hat. Und um ganz ehrlich zu sein: Die Wahl der Nightschool war eigentlich ein einfaches Ausschlussverfahren, wobei eine Alternative nicht stattgefunden hat und die anderen beiden für mich noch uninteressanter waren. Ich hatte also keine Erwartungen an den Vortrag – und wurde sehr überrascht. Es war super!
Colin Hood hat sehr kurzweilig und mit der richtigen Prise Humor vom Sinn der Verbindung von Informationen erzählt. Und Colin Hood ist ein Consultant, dem man gerne zuhört – selbst beim letzten Vortrag des Abends. Er war ein Entwickler der alten Schule, die noch mit echter Hardware gearbeitet haben ;-) Es tut mir richtig leid für ihn, da offenbar die meisten Besucher die Night School schon gestrichen hatten, es waren nur vielleicht 17 Leute beim Vortrag. Aber eigentlich tun mir die Leute leid, die den kurzen Exkurs nicht hören konnten. Wenn er wieder bei einer Tagung spricht auf keinen Fall verpassen!
Zum Schluss noch der kulinarische Report. Die Nachspeisen waren jeden Tag ausgezeichnet. Herziges Beispiel: Mini-Muffins! Keine 2 cm im Durchmesser.
Domain Driven Design
Eric Evans was a softly spoken American who came over to talk about the strategy we should use when trying to build large systems. Eric Evans is the author of a book called Domain Driven Design which contains a set of ideas that seems to fit well with agile processes. His talk was focused on using his techniques a defined in hisbook.
Eric started out by talking about a company that tried to create a new system out of two old legacy systems. The plan was to spend a year building a platform for the new system, spend a year writing the old code onto the platform and then spend another year creating new stuff. Eric thought that this was a recipe for disaster.
He then went on to define things like domain and model and context, and argued that a model has to serve a particular use and that it does not have to be completely accurate. He followed this by demonstrating that you can come up with an inaccurate model of an elephant, and still come up with something useful that you can use. He then said that each system will have its own model, defined in its own context. Models of similar things will be different in different systems, because these system's contexts are different. You can come up with a context map for your various systems if you agree with this idea.
Eric then advised us to try and find the core part of our domain in our systems, because this is the part of the system that gives the most value to the business. This is the part that gives the business's customers a reason for buying from this company.
Going back to the example, Eric postulated that the core part of the business, was the part that was going to have the changes applied to it in the third year of the old development cycle. If this was true, then this is far too long to wait. The legacy systems would have probably had those changes applied to them and the new system would still be trying to catch up. Eric's solution was to create a little platform that would act as an interface between the two old legacy systems and the new system, and then just build the changes into it. This could probably be achieved in 12-18 months - a much more realistic time scale.
The only hole in this idea would be if you needed to kill a legacy system as soon as possible, because maybe it was costing you a fortune in licensing fees for the hardware or something. This does not kill the idea, though, and we could all see that this new part would be an excellent start point for moving other parts of the domain onto the new system.
And all this at eight o'clock in the evening.
Eric started out by talking about a company that tried to create a new system out of two old legacy systems. The plan was to spend a year building a platform for the new system, spend a year writing the old code onto the platform and then spend another year creating new stuff. Eric thought that this was a recipe for disaster.
He then went on to define things like domain and model and context, and argued that a model has to serve a particular use and that it does not have to be completely accurate. He followed this by demonstrating that you can come up with an inaccurate model of an elephant, and still come up with something useful that you can use. He then said that each system will have its own model, defined in its own context. Models of similar things will be different in different systems, because these system's contexts are different. You can come up with a context map for your various systems if you agree with this idea.
Eric then advised us to try and find the core part of our domain in our systems, because this is the part of the system that gives the most value to the business. This is the part that gives the business's customers a reason for buying from this company.
Going back to the example, Eric postulated that the core part of the business, was the part that was going to have the changes applied to it in the third year of the old development cycle. If this was true, then this is far too long to wait. The legacy systems would have probably had those changes applied to them and the new system would still be trying to catch up. Eric's solution was to create a little platform that would act as an interface between the two old legacy systems and the new system, and then just build the changes into it. This could probably be achieved in 12-18 months - a much more realistic time scale.
The only hole in this idea would be if you needed to kill a legacy system as soon as possible, because maybe it was costing you a fortune in licensing fees for the hardware or something. This does not kill the idea, though, and we could all see that this new part would be an excellent start point for moving other parts of the domain onto the new system.
And all this at eight o'clock in the evening.
It's always the God-Damned Interfaces
I had the pleasure, today of seeing Mr. Tim Lister in action again. Tim Lister is one of those people whom you just like to listen to. I have listened to a few talks this week that I struggled to keep awake in, but I am sure if Tim Lister was doing them I would have had absolutely no problem keeping awake at all.
Tim Lister's talk was more or less about identifying the interfaces that bridge two worlds in your system, and making sure you have a deal with the risk that that entails, when you try and create new functionality that bridges those two worlds. Simple really, and it hit our nail on the head for one of our problems. His primary prescription would be to make sure that you implement an end-to-end process in your system as soon as possible. In this way you guarantee that everyone gets a lot of early feedback and you find out exaclty how much real work it will be to get the job done.
That's the best thing about Tim Lister. You get education and a show. But he also a super salesman. He is one of those guys that you just know will say "there's even more in my new book", and you really don't mind. Who needs to be a Jedi when you can do that?
Tim Lister's talk was more or less about identifying the interfaces that bridge two worlds in your system, and making sure you have a deal with the risk that that entails, when you try and create new functionality that bridges those two worlds. Simple really, and it hit our nail on the head for one of our problems. His primary prescription would be to make sure that you implement an end-to-end process in your system as soon as possible. In this way you guarantee that everyone gets a lot of early feedback and you find out exaclty how much real work it will be to get the job done.
That's the best thing about Tim Lister. You get education and a show. But he also a super salesman. He is one of those guys that you just know will say "there's even more in my new book", and you really don't mind. Who needs to be a Jedi when you can do that?
Wie geht's weiter mit Java?
This was a talk by Klaus Kreft and Angelika Langer, about what could possibly be in Java version 7.0.
The core of the talk hit language extensions (closures and concise instance declarations), new module functionality and other bits and pieces that could come in. All the items discussed had come out of the Java Community Process, more specifically the Java Specification Request (JSR) system.
Closures and concise instance declarations come from the demands of developers who want scripting language extensions to the core Java language - mainly because the enjoy using them in these languages. Now, I am a big fan of scripting languages, and the power that they give the developer, but the syntax that was recommended didn't look so good to me. The new Concise instance declarations syntax was also crap.
The new module functionality seemed to me to be a straight rip-off from maven. The idea of a super-package declaration that stops certain other packages being access able in a jar file, did seem to have merit. There is another JSR about the OSGi core service platform model, which is a more dynamic version of the modules idea. From what the gurus said, then this one would be the one to vote for. Unfortunately, this part of the talk was given by Frau Langer. She, like all the other female presenters, spoke far too quickly and I started drifting off in the middle. ho hum.
Finally there was a JSR for Swing, which is something I will have to look at, and a JSR about units and quantities that you could use in your application to convert between meters and feet with very little overhead.
Although it was in German, this was a nice technical start to day 4 of our conference.
Wednesday 23 January 2008
Keine Angst vor Vampieren!
Einer Sache kann man sich sicher sein: Hier in München braucht man keine Angst vor Vampieren haben! Die Messe München hat ausgeklügelte Schutzvorrichtungen für den Ernstfall einer Bedrohung durch Vampire (vgl. 30 days of night) vorgesehen!
Impossant: Abwerfbahre Sperrvorrichtungen die automatisch Pfählen!
Trainingset mit lackierten Holzpfählen in Spielform, um das sichere pfählen von Untoten jederzeit üben zu können!
Koordinationsspiel, um im Ernstfall mit schnellen Reaktionen Bissattacken ausweichen zu können.
Alles in allem eine bissfeste Sache. Ich gebe der Messe vier von fünf Buffy-Punkten.
Impossant: Abwerfbahre Sperrvorrichtungen die automatisch Pfählen!
Trainingset mit lackierten Holzpfählen in Spielform, um das sichere pfählen von Untoten jederzeit üben zu können!
Koordinationsspiel, um im Ernstfall mit schnellen Reaktionen Bissattacken ausweichen zu können.Alles in allem eine bissfeste Sache. Ich gebe der Messe vier von fünf Buffy-Punkten.
OOP day 3: Learning curve
Halbzeit! Und endlich ein Tag mit abwechslungsreichen Vorträgen. Allerdings auch ein langer Tag mit vier Vorträgen, zwei Keynotes und einer Nightschool. Und keine Bilder, weil die Synchronisation der Geräte heute an dem japanischen Vista scheitert...
Vortrag: Use Cases: Popularity, Pitfalls and Practices
Kevlin Henney again at his best. Im Moment mein favorite Guru der OOP. Sehr direkt, sehr praktixnah, sehr eindeutig darüber, was Usecases alles NICHT sind und was man alles weglassen kann ohne sich schlecht zu fühlen. Überhaupt der erste Usecase-Vortrag ohne den schlechten Nachgeschmack von Buzzwords. Ich habe fast das Bedürfnis einen Usecase zu schreiben ... aber das vergeht sicher wieder ;-)
Vortrag: Soft Skills fördern den Projekterfolg
Echt? Das wäre mir niiieee eingefallen. Wie der Vortragende so entschieden betont hat: „Es gibt keine Realität.“ Also einfach eine andere Matrix wählen und schon ist das ganze Projekt anders :-)
Keynote: The Future of Software Delivery
Was ist noch geekiger als ein Guru? Ein Evangelist! Nach viel flavor, evangelistic stuff und Geschichten von ihren Kinder hat Terry Quatrani dann doch die IBM Werbung rausgelassen: Die Zukunft heißt Jazz (http://jazz.net/). Treibende Kraft hinter Jazz ist Erich Gamer, bekannt von Eclipse und Patterns (also auch Guru). Der Gedanke hinter Jazz ist (vereinfacht) eine IDE für (örtlich verteilte) Entwicklergruppen mit integrierter Prozessunterstützung und Kommunikationstools. Die Idee schaut durchaus interessant aus, die Entwicklung wird offen mit Community gemacht, der Source ist lesbar, nur das Endprodukt wird kostenpflichtig. Das sollten wir weiter verfolgen.
Vortrag: Was Regeln regeln: Architekturen mit Geschäftregeln
Oh, echter Code auf Powerpoint slides. Tasty :-) Der Gedanke mit einer Rule Engine die Algorithmen in Konvertern zu kapseln ist schon verlockend. Die Integration in Java scheint schon ziemlich fortgeschritten zu sein, auch wenn es an einem Standard noch mangelt. Vor allem das präsentierte JBoss-Drools wirkt sehr nett. Da muss ich ein Auge drauf werfen.
Keynote: The Power of Project Patterns
Oh, guru time again. Tim Lister und Peter Hruschka präsentieren die klassischen behavioral Patterns, die sie in Unternehmen kennengelernt haben (>Adrenalin-Junkies und Formular-Zombies). Sehr lustig, sehr wahr, sehr Dilbert. Mañana!
Vortrag: Refactoring von Softwarearchitekturen
Wieder ein anstrengendes Thema im späten Timeslot. Ein interessantes Thema, aber leider ein etwas unübersichtlicher Vortrag. Aber sicher was lesenswertes für unsere Architekten.
Nightschool: What every software architect should know about testing!
Nette, aber vorhersehbare Wunschliste aus der Sicht eines Testers, gewürzt mit ein bissi jammern. Tester haben es nicht leicht ;-) Sehr lustige live Demonstration von Testkonzepten mit acht Freiwilligen, die einen Tisch heben mussten. Ja, wir sollten mehr testen ... aber die Architekten sollten Systeme besser mit einem Blick aufs Testen designen ;-)
The Road Less Travelled
This was a talk by Jason Ayers about how we, as developers, should evaluate new technologies without getting caught up in the hype. Mr. Ayers is the Managing Director of Cincom, which is a vendor of a version of Smalltalk, so he was obviously going to use this talk from his viewpoint.
He pushed that idea that we can change our implementation language if we want to because there are now so many out there in various states of maturity. The best reason for a change would be in gaining a competitive edge, with the proviso that the programmer should enjoy using the language.
He demonstrated a technique called a radar diagram that could be used to compare the different features of several languages together an he was obviously keen in pushing smalltalk as a viable alternative.
At the end of the session I asked him why he thought Java took off suddenly at the end of the nineties, and he said that it was because one vendor of smalltalk turned down the chance to make an embedded version of smalltalk for Netscape - i.e. Smalltalk turned down the chance to reach a huge audience.
I have heard that story before, anyone remember how DOS got onto the IBM PC? Because the maker of CP/M turned them down first. Aah, so this is how things happen.
He pushed that idea that we can change our implementation language if we want to because there are now so many out there in various states of maturity. The best reason for a change would be in gaining a competitive edge, with the proviso that the programmer should enjoy using the language.
He demonstrated a technique called a radar diagram that could be used to compare the different features of several languages together an he was obviously keen in pushing smalltalk as a viable alternative.
At the end of the session I asked him why he thought Java took off suddenly at the end of the nineties, and he said that it was because one vendor of smalltalk turned down the chance to make an embedded version of smalltalk for Netscape - i.e. Smalltalk turned down the chance to reach a huge audience.
I have heard that story before, anyone remember how DOS got onto the IBM PC? Because the maker of CP/M turned them down first. Aah, so this is how things happen.
Case Study: The New Guardian.co.uk
This was a very interesting war story by Erik Dörenburg and Matthew Wall, which was about how they have created a new version of the guardian.co.uk using a java web stack and agile development processes.
The interesting points were their idea of an architects role. They assumed a coaching role and only made a design decision when it was clear that a couple of teams had hit a similar problem and one of them had come up with a better technical solution. They were also strong proponents of Domain Driven Design, which forces everyone involved to use the same language for the same idea in the application up to the point training the end users in simple uml diagramming and teaching concepts such as inheritance and composition and then making the developers create components in the code that have the same name.
Both of these ideas can be found in Martin Fowler's books, who is the Chief Scientist at Thoughtworks, which is where Erik Dörnberg works. It sounds like to me then that, in this case, the consultant really earned his corn.
The interesting points were their idea of an architects role. They assumed a coaching role and only made a design decision when it was clear that a couple of teams had hit a similar problem and one of them had come up with a better technical solution. They were also strong proponents of Domain Driven Design, which forces everyone involved to use the same language for the same idea in the application up to the point training the end users in simple uml diagramming and teaching concepts such as inheritance and composition and then making the developers create components in the code that have the same name.
Both of these ideas can be found in Martin Fowler's books, who is the Chief Scientist at Thoughtworks, which is where Erik Dörnberg works. It sounds like to me then that, in this case, the consultant really earned his corn.
Model Based Full Code Generation Case Studies
This was a case-study type talk by a very nice Finn, by the name of Juha-Pekka Tolaven. He showed 17 different examples from around the world where model based code generation was successfully used. Examples ranged from configuration data generation for telecoms switches to generating whole interactions in a car infotainment system.
I got the idea that when the domain was sufficiently small, then it was possible to create a parser that could generate a complete set of code for a specific environment or set of environments. The trick was to start small and have a real domain expert nearby. With these pre-requisites in place, generation times were about 3 times shorter than using normal methods (this was proven, by the way, in a control study in the United States Air Force) .
Many of the examples had used the Eclipse Modelling Framework, or the Rich Client Environment as a gui and many were used on specific platforms - you didnt see code being generated for windows-linux-mac etc,etc,etc, but there was a large variation in target languages (Assembler, Python, C++, XML and Java).
The style of the talk was also excellent. English, was obviously not Mr. Tolaven's mother toungue, but he used a very slow, clear, style that would be a lesson to the German native speakers making presentations here.
I got the idea that when the domain was sufficiently small, then it was possible to create a parser that could generate a complete set of code for a specific environment or set of environments. The trick was to start small and have a real domain expert nearby. With these pre-requisites in place, generation times were about 3 times shorter than using normal methods (this was proven, by the way, in a control study in the United States Air Force) .
Many of the examples had used the Eclipse Modelling Framework, or the Rich Client Environment as a gui and many were used on specific platforms - you didnt see code being generated for windows-linux-mac etc,etc,etc, but there was a large variation in target languages (Assembler, Python, C++, XML and Java).
The style of the talk was also excellent. English, was obviously not Mr. Tolaven's mother toungue, but he used a very slow, clear, style that would be a lesson to the German native speakers making presentations here.
Tuesday 22 January 2008
OOP day 2: Requirements day
Ein guter Tag beginnt mit einem besseren Requirement ;-) Der heutige Tag war dem schwerverdaulichen Schwerpunkt Requirements gewidmet. Mahlzeit. Alles in allem eine zache Sache, aber bekanntlich stirbt die Hoffnung zu letzt. Vielleicht ist ja doch der eine oder andere Gedanke praktisch verwendbar ;-)
Vortrag: Mastering Requirements Engineering – A Mini Tutorial
Hmm, bekanntes Zeug, bekannter Terminologie, bekannte Vormittagsmüdigkeit. Ah, der Vortragende hat eine Businesshistory bei der uns völlig unbekannten Firma Alcatel. Favorite quote: „Traceability ist ein Lieblingsthema von vielen CMMI-Junkies.“
Keynote: Innovation – zwischen Buzzword, Management und Intuition?
rofl - St. Gallen läßt grüßen :-)
Die Keynotes sind jetzt im Saal 1. Der ist super und wäre der perfekte Kinosaal.
Vortrag: Requirements Engineering in Offshore Projekten
Der Vortrag hat sehr ambivalente Gefühle hinterlassen. Die Beschreibung eines realen Offshore Projekts mit 40 Kollegen in Indien ist grundsätzlich eine sehr interessante Sache. Aber wenn ich mir bei manchen Details denke „Das hätte ich anders gemacht“, dann ist das ein schlechtes Zeichen. Aber immerhin habe ich jetzt Ideen, wie man ein paar Probleme vielleicht lösen könnte.
Keynote: How Simple is too simple?
Die aufwendigste Grafik der Keynote.
Erik and Dan
Vortrag: Deltaanforderungen – Gutes Requirements Engineering trotz Altlasten
Der ganze Vortrag lässt sich wunderbar auf ein Wort zusammenfassen: Usecase-Fragmente. Im Ernst, es klingt zwar trivial, aber es könnte für uns brauchbar sein (und es scheint nicht einmal weh zu tun, beim Anwenden). Faszinierend übrigens auch die weibliche Beteiligung an diesem Thema im Publikum. Die Vortragende Chris Rupp ist offenbar ein role model für requirements fangirls. (PS: Mehr zum Thema fanboys gibt´s am Donnerstag von James :-))
Vortrag: Von der Anforderung zum An(wendungs)fall – Die Anforderungen im Modell
Als letzter Vortrag des Tages SysML Modellierung von Requirements zu präsentieren ist keine leichte Sache. Dafür hat sich Tim Weilkiens eigentlich gut geschlagen. Bin aber noch nicht ganz sicher, ob etwas von der Modellierung bei uns umsetzbar ist.
Zum Schluss noch ein Bild von einer Guerilla Werbeaktion. Wenn man den ganzen Tag einen orangen Schutzhelm mit Werbung herumgeschleppt hat (man musste ihn nicht am Kopf tragen ;-), konnte man ein iphone gewinnen. Also hab ich James überzeugt auch einen Helm herumzutragen und – eh klar – er ist schon für die engere Gewinnerwahl ausgewählt worden. Lucky bastard.
Impressionen vom zweiten Tag
Heute war der erste Messetag. Man sollte annehmen es war überlaufen, aber es war doch nicht sooo viel los...
Common Sense over Conservatism - Is Ruby on Rails ready for the enterprise?
This was a different type of talk from Dan North, who works for Thoughtworks in England. Dan was not keen at all on Powerpoint presentations, and worked off of what looked like a few scribbled notes in a diary.
Dan started by talking about what Ruby on Rails is and what it is good for. It is a set of packages, written in Ruby, that enable you to develop a database backed web application - very quickly, mainly because it uses Convention over Configuration and it is written in Ruby. Something that takes ten lines to write in java can only take one line in Ruby - that saves a lot of time.
Ruby on Rails scales really, well but in a different way to java apps. It works in the same way as a LAMP deployment - you only need loads of PC boxes behind an IP load-balancer instead of a big box made by sun or IBM, that has loads of memory and contains an app that creates threads by the thousand. Ruby on Rails works best for things like admin pages or reporting solutions where you only have a few users and the requirements change almost daily.
Rails is Ready - unfortunately the enterprise is not. Programming in a dynamic language is a totally different kettle of fish to programming in a statically typed language, like Java. For it to really take off, loads more Java programmers will have to go through the pain of learning Ruby and then organisations will have to be brave enough to try it out.
Dan was a very clever guy, who made a very good case - and he didn't try to sell me a book!
Dan started by talking about what Ruby on Rails is and what it is good for. It is a set of packages, written in Ruby, that enable you to develop a database backed web application - very quickly, mainly because it uses Convention over Configuration and it is written in Ruby. Something that takes ten lines to write in java can only take one line in Ruby - that saves a lot of time.
Ruby on Rails scales really, well but in a different way to java apps. It works in the same way as a LAMP deployment - you only need loads of PC boxes behind an IP load-balancer instead of a big box made by sun or IBM, that has loads of memory and contains an app that creates threads by the thousand. Ruby on Rails works best for things like admin pages or reporting solutions where you only have a few users and the requirements change almost daily.
Rails is Ready - unfortunately the enterprise is not. Programming in a dynamic language is a totally different kettle of fish to programming in a statically typed language, like Java. For it to really take off, loads more Java programmers will have to go through the pain of learning Ruby and then organisations will have to be brave enough to try it out.
Dan was a very clever guy, who made a very good case - and he didn't try to sell me a book!
Retrospektiven
This talk was by Jutta Eckstein and was about why and how you should run what we would call lessons learned meetings. In the Agile world, these are called Retrospectives, and should be run at the end of every iteration, or heartbeat (what the difference is, I'm not sure, but hey I am sure that there is one).
Frau Eckstein demonstrated by her command of the subject and the tone of her presentation that she really knew about what makes such a meeting tick. She started by talking about being non-judgemental and assuming that everyone is trying their best in the team and then she recommended trying to come up with some sort of success criteria (of what the meeting should achive) before the meeting. She gave a few tips about what to do in such a meetings (Time-lining, Human Sociogram), and recommened that the members should try and concentrate on a few action points afterwards, as opposed to many, because that increases the chance of changing something.
I asked her after the talk, whether she had seen any patterns of classic mistakes that teams make and she said that there will be a keynote speech about this subject later in the conference. That would be interesting, because I get the gut feeling that there are many teams making the same mistakes, and that there are probably some standard answers out there. If these became public knowledge and there were some pointers about how to avoid making these mistakes in the first place, then the overall productivity of the industry would be raised.
Frau Eckstein demonstrated by her command of the subject and the tone of her presentation that she really knew about what makes such a meeting tick. She started by talking about being non-judgemental and assuming that everyone is trying their best in the team and then she recommended trying to come up with some sort of success criteria (of what the meeting should achive) before the meeting. She gave a few tips about what to do in such a meetings (Time-lining, Human Sociogram), and recommened that the members should try and concentrate on a few action points afterwards, as opposed to many, because that increases the chance of changing something.
I asked her after the talk, whether she had seen any patterns of classic mistakes that teams make and she said that there will be a keynote speech about this subject later in the conference. That would be interesting, because I get the gut feeling that there are many teams making the same mistakes, and that there are probably some standard answers out there. If these became public knowledge and there were some pointers about how to avoid making these mistakes in the first place, then the overall productivity of the industry would be raised.
Monday 21 January 2008
UFO-Alarm im Speisesaal
Kein Blog ohne lustige Bilder (wäre ja gelacht, wenn wir das nicht geschafft hätten mit all der Technik, die wir mitgeschleppt haben). Hier eine architektonische Impression aus dem Speisesaal der Messe München :-) Das bringt mich zum Thema Essen: Hohe Qualität, aber nur ein Menü :-/
Day One
Tutorial: Pattern Oriented Software Architecture
I went to this tutorial as well, which I thought was OK.
Frank Buschmann is someone that has really lived creating and building a big, distributed system, and it showed. He is rather tall, but stooped and is very animated when he speaks. He definitely lives for the code and maybe has seen a few too many software corpses for his own good.Kevlin Henney on the other hand, is your typical relaxed consultant - guru, who seems to take everything in his stride (i.e. "OK, relax there Frank, everything will be all right..."). Together they make a good team and they interacted reasonably well, swapping over from each other after a couple of slides.
The basic idea that I got from the tutorial was that an architect can create a whole system just by applying one pattern after another to accommodate the forces working on the system to be developed. This idea was originally put forward by Christopher Alexander in his book, The Timeless Way Of Building, which was about applying things like the courtyard pattern to make a building a nice place to live in.
In software development, there are many different patterns and most have been "discovered" to work under a specific context. For instance, the Gang of Four patterns in that famous book are now seen to be a set of patterns for building frameworks (i.e something like swing or struts) and not really applications. Application patterns are much more context dependent. A pattern used for a logging service in a distributed environment would be different to the same service used in a non-distributed environment, because the forces under consideration are different in those contexts.
Buschman and Henney are both distributed system experts and they have spent a long time documenting and publishing a book or two on these types of patterns, so their examples were from this domain. They told a story demonstrating how they built a system using these ideas, and did things like applying the domain object pattern onto the big ball of mud at the start and using something called a half object pattern to span object state over several parts of a distributed system. I thought these ideas seemed reasonable, especially when they emphasised things like coding to an interface and layering your code properly.
At the end of the session I asked Kevlin if he thought that test driven development could be of any use in this way of building systems, and he surprised me by saying that it is no coincidence that the primary discoverers of the design patterns movement were also the primary movers in the test driven development movement. Its clear to me now that you can't really build high quality software without unit tests.
In summary, there is a lot more to patterns than the gang of four, and I have yet another set of books to stick on my wish list.
Keynote : Software and Services - Konvergenz von Web 2.0, SOA and SaaS
Microsoft have made some good games in the past (for example Urban Assault) , but I had some bad experiences programming Visual Basic as a noob, so I had this sinking feeling when
I saw the name Microsoft on the slides. It looks like Microsoft are going to try to support open
APIs in the future. I'm not sure though, because it was late and it was in German, and the word 'monetise' appeared on several slides). I wanted to ask Ms. Sondermann if she knew when the next version of Combat Flight Simulator was coming out, but she didn't take any questions at the end.
Night School : 10 Ideas Java Guys Should Steal From Ruby
In my night school I saw Bruce Tate. Bruce was a major league Java guru and has written several super java books, one of which really helped me in learn spring. Bruce turned out to be a very, loud, active, enthusiastic speaker who still looked like he can ride up a mountain or two. I guess he was so loud because otherwise we would have fallen asleep, but the information he gave out should have kept everyone awake.
His theme is that there are several ideas in Ruby language and the community that could be used to improve the overall process of programming in Java. He gave several examples using closures, continuations and meta-programming, demonstrating how easy it is to write small pieces of code that do a lot in this language. He also pushed the idea of Convention over Configuration (which has been picked up by Maven) , using the trash can (when something has been deprecated, eventually throw it away) and obsessing over testing (exactly).
All in all, a very cool talk, but I think someone called Bruce should be wrestling crocodiles for a living on Australian TV. Something to consider for the future if the old Ruby thing doesn't work out.
I went to this tutorial as well, which I thought was OK.
Frank Buschmann is someone that has really lived creating and building a big, distributed system, and it showed. He is rather tall, but stooped and is very animated when he speaks. He definitely lives for the code and maybe has seen a few too many software corpses for his own good.Kevlin Henney on the other hand, is your typical relaxed consultant - guru, who seems to take everything in his stride (i.e. "OK, relax there Frank, everything will be all right..."). Together they make a good team and they interacted reasonably well, swapping over from each other after a couple of slides.
The basic idea that I got from the tutorial was that an architect can create a whole system just by applying one pattern after another to accommodate the forces working on the system to be developed. This idea was originally put forward by Christopher Alexander in his book, The Timeless Way Of Building, which was about applying things like the courtyard pattern to make a building a nice place to live in.
In software development, there are many different patterns and most have been "discovered" to work under a specific context. For instance, the Gang of Four patterns in that famous book are now seen to be a set of patterns for building frameworks (i.e something like swing or struts) and not really applications. Application patterns are much more context dependent. A pattern used for a logging service in a distributed environment would be different to the same service used in a non-distributed environment, because the forces under consideration are different in those contexts.
Buschman and Henney are both distributed system experts and they have spent a long time documenting and publishing a book or two on these types of patterns, so their examples were from this domain. They told a story demonstrating how they built a system using these ideas, and did things like applying the domain object pattern onto the big ball of mud at the start and using something called a half object pattern to span object state over several parts of a distributed system. I thought these ideas seemed reasonable, especially when they emphasised things like coding to an interface and layering your code properly.
At the end of the session I asked Kevlin if he thought that test driven development could be of any use in this way of building systems, and he surprised me by saying that it is no coincidence that the primary discoverers of the design patterns movement were also the primary movers in the test driven development movement. Its clear to me now that you can't really build high quality software without unit tests.
In summary, there is a lot more to patterns than the gang of four, and I have yet another set of books to stick on my wish list.
Keynote : Software and Services - Konvergenz von Web 2.0, SOA and SaaS
Microsoft have made some good games in the past (for example Urban Assault) , but I had some bad experiences programming Visual Basic as a noob, so I had this sinking feeling when
I saw the name Microsoft on the slides. It looks like Microsoft are going to try to support open
APIs in the future. I'm not sure though, because it was late and it was in German, and the word 'monetise' appeared on several slides). I wanted to ask Ms. Sondermann if she knew when the next version of Combat Flight Simulator was coming out, but she didn't take any questions at the end.
Night School : 10 Ideas Java Guys Should Steal From Ruby
In my night school I saw Bruce Tate. Bruce was a major league Java guru and has written several super java books, one of which really helped me in learn spring. Bruce turned out to be a very, loud, active, enthusiastic speaker who still looked like he can ride up a mountain or two. I guess he was so loud because otherwise we would have fallen asleep, but the information he gave out should have kept everyone awake.
His theme is that there are several ideas in Ruby language and the community that could be used to improve the overall process of programming in Java. He gave several examples using closures, continuations and meta-programming, demonstrating how easy it is to write small pieces of code that do a lot in this language. He also pushed the idea of Convention over Configuration (which has been picked up by Maven) , using the trash can (when something has been deprecated, eventually throw it away) and obsessing over testing (exactly).
All in all, a very cool talk, but I think someone called Bruce should be wrestling crocodiles for a living on Australian TV. Something to consider for the future if the old Ruby thing doesn't work out.
OOP day 1
München, hier sind wir! Anreise und Hotel haben super geklappt (auch wenn das Hotel WLAN überall AUSSER in den Zimmern funktioniert). Spannend war es beim Empfang der Tagung, wir waren nämlich nicht angemeldet!? Da wir nicht die einzigen ohne Anmeldung waren, kann es durchaus sein, daß der Veranstalter Daten verschlammt hat. Ich hoffe das läßt sich noch klären, die Gebühren vor Ort waren ja saftig.
Ansonst läuft hier alles mit deutscher Ordnung ab. Wir haben unsere Ausweise auf deren Rückseiten auch alle reservierten Vorträge gedruckt sind (weil nur die dürfen wir besuchen). Die Ausweise werden bei jeder Veranstaltung gescannt und dann noch beim Mittagessen und Abendsnack. Bei den Toiletten haben sie uns noch nicht gescannt, aber das kommt sicher noch…
Ansonst läuft hier alles mit deutscher Ordnung ab. Wir haben unsere Ausweise auf deren Rückseiten auch alle reservierten Vorträge gedruckt sind (weil nur die dürfen wir besuchen). Die Ausweise werden bei jeder Veranstaltung gescannt und dann noch beim Mittagessen und Abendsnack. Bei den Toiletten haben sie uns noch nicht gescannt, aber das kommt sicher noch…
Tutorial: Pattern-Oriented Software Architecture
Gleich zu Beginn eine positive Überraschung: Frank Buschmann und Kevlin Henney sind ein wirklich gut eingespieltes Moderatorenteam, die sich mit Witz und Elan über Pattern als Architektur-Konzeptionshilfe auslassen. Im besondern geht es darum von den (bekannten) alleinstehenden Pattern zu verzahnten Pattern (complements und compounds; eine Klasse erfüllt Rollen in meherern Pattern!) und weiter zu Pattern Stories und Pattern Sequences (die Reihenfolge in der man mit Pattern Requirements erfüllt begrenzt das weitere Design) bis zu einer Pattern Language. Da ist brauchbares für unser Legacy System dabei! Pattern Language ist imho momentan noch zu guru (James ist begeistert davon ;-), aber Pattern Stories wären ganz praktisch für ADDs. Und die Pattern Complements und Compounds sind eigendlich Basics, um Pattern richtig anzuwenden. Ja, das Tutorial hat uns ziemlich begeistert und die Unterlagen sind echt angenehm zu lesen.
Keynote: Microsoft: “Software und Services – Konvergenz“:
Wow, time for buzzword bingo. Die MS Tante hat ihren Werbevortrag sehr brav auswendig gelernt. Aber in einer MS Präsentation die Logos von Firefox, Apache, Redhat u.s.w. zu sehen war den Spaß wert ;-)
Nochmal Frank Buschmann, aber nach dem langen Tag schon etwas angeschlagen. Der Vortrag war ein bißchem am Titel vorbei. Die ganze Reihe von Warstories über gescheitere Projekte war zwar sehr praxisnah, aber Fehler machen wir auch selber genug ;-) Was ich am interessantesten gefunden habe, war ein Beispiel mit einem fast schon „soft“ agile Ansatz. Statt den nervigen daily/weekly Meeting eine Art interner Milestone alle 4 (oder gar 6) Wochen, bei dem einfach der aktuelle Stand mit dem geplanten Soll verglichen wird. Damit kann man Entwicklungen in die falsche Richtung immer noch rechtzeitig abfangen, ohne gleich inkrementell arbeiten zu müssen. Das wäre vielleicht etwas für uns.
First Impressions
We arrived in Munich at about 11:00 last night via a lovely 4 hour trip on the train. I entertained Sascha by showing him some recorded games of IL2 - Sturmovik, where I was continuously killed by all those people that actually know how to fly a virtual Spitfire. Don't worry C, I will get you yet!
As we travelled to the hotel from the station, my first impressions of Munich were that everything was very clean (like every German town) , but the streets themselves were very, very, very wide (i.e. crossing the road costs the average person about half an hour) . I guess Munich is probably more like L.A. than New York. The hotel is very new, and has Premiere Sport on the telly, so I can follow Liverpool vs Aston Villa (Benayoun has just scored - woohoo).
The hotel and the conference centre are both in the middle of nowhere, but the centre is near an underground station, so maybe we will be able to have a little look at Munich later in the week (bring your walking boots Sascha).
The conference proper starts tomorrow, so today was a tutorial day with a night school.Unfortunately the conference organisers had lost our registration forms. Thanks, M for your help with the payment!
As we travelled to the hotel from the station, my first impressions of Munich were that everything was very clean (like every German town) , but the streets themselves were very, very, very wide (i.e. crossing the road costs the average person about half an hour) . I guess Munich is probably more like L.A. than New York. The hotel is very new, and has Premiere Sport on the telly, so I can follow Liverpool vs Aston Villa (Benayoun has just scored - woohoo).
The hotel and the conference centre are both in the middle of nowhere, but the centre is near an underground station, so maybe we will be able to have a little look at Munich later in the week (bring your walking boots Sascha).
The conference proper starts tomorrow, so today was a tutorial day with a night school.Unfortunately the conference organisers had lost our registration forms. Thanks, M for your help with the payment!
Subscribe to:
Posts (Atom)