Comments for halllo welt

Comment on Automatically generating states with VS2010 UML tools and T4 by halllo

halllo — Fri, 25 Mar 2016 22:05:09 +0000

In reply to Letícia Gindri.

I have not checked with Visual Studio 2015 yet.

Comment on Automatically generating states with VS2010 UML tools and T4 by Letícia Gindri

Letícia Gindri — Tue, 16 Feb 2016 15:48:00 +0000

Does this process still work on VS Ultimate?? Thank you!

Comment on Faster prototypes with Just Objects Prototype by xyrus02

xyrus02 — Tue, 29 Dec 2015 19:00:52 +0000

Nice! Thanks :-)

Comment on Faster prototypes with Just Objects Prototype by Dew Drop – December 28, 2015 (#2159) | Morning Dew

Dew Drop – December 28, 2015 (#2159) | Morning Dew — Mon, 28 Dec 2015 12:35:43 +0000

[…] Faster prototypes with Just Objects Prototype (Manuel Naujoks) […]

Comment on Neuste Werkzeuge und Probleme by Uli Armbruster

Uli Armbruster — Thu, 10 Dec 2015 11:47:03 +0000

In reply to xyrus02.

Genau das wäre auch mein Vorschlag gewesen. Wenn es Defizite bei den Entwicklern geben sollte, stellt einen Lead Developer ein. Aber Architekten sollten sich damit nicht beschäftigen. Toller Kurs hierzu: http://app.pluralsight.com/training/player?course=gathering-good-requirements-developers&author=robert-bogue&name=gathering-good-requirements-developers-m2&clip=2&mode=live

Comment on Neuste Werkzeuge und Probleme by Uli Armbruster

Uli Armbruster — Thu, 10 Dec 2015 11:40:32 +0000

“In unserer Abteilung sehen sich die Architekten verantwortlich für den Einsatz von Entwicklungstools. Meiner Meinung nach ist das Schwachsinn. Entwicklungstools haben mit Softwarearchitektur nichts zu tun.” das hört sich für mich danach an, als wären die early adopters jetzt diejenigen, die statt den Architekten entscheiden. Generell sollte es doch eine Team Decision sein. Oder war das so gemeint, dass ohnehin immer umgestellt wird und die nur kurz diejenigen, die das noch nicht mitgekriegt haben, informieren?

“Warum stellen wir überhaupt um? Dabei geht es um Verbesserung und Innovation. Unter dem Strich ist die neue Version besser. Ansonst hätte es sie ja nicht geben müssen.” => Ich sage nur Windows 8…

“Die neuen Versionen haben weniger Fehler und neue Features.” => weniger Fehler? Also eine 1 Jahr lang nur mit bugfixes versorgte Version ist wohl stabiler als eine neue große Major-Version. Sowohl bei dir, als auch bei mir sind das aber lediglich Meinungen/Aussagen ohne Belege. Neben logischerweise neuen Features können ggf. aber auch alte rausgenommen worden sein! Hier mal ein richtig nerviger Bug im neuen ReSharper 10: https://youtrack.jetbrains.com/issue/RSRP-450980

“Wenn man sich nicht mit den neusten Tools beschäftigt, kann man auch nicht wissen wie diese das Arbeiten erleichtern und sogar beschleunigen.” => Dafür muss man nicht unbedingt gleich migrieren. Das kann man auch erst einmal in Coding Dojos angehen.

“Das ist wie beim Mergen von Branches. Je länger man wartet, desto weiter laufen die Pfade auseinander und desto schwieriger ist es, diese wieder zu vereinen.” => Vielleicht ein ungünstiges Beispiel, weil es hierfür sinnvolle Lösungen gibt. Stichwort rerere (https://git-scm.com/blog/2010/03/08/rerere.html)

Comment on Neuste Werkzeuge und Probleme by jocscha

jocscha — Tue, 08 Dec 2015 06:51:56 +0000

Hallo Manuel,
glaubst Du nicht, dass es auch mal Gruende geben kann nicht auf die neueste Version zu wechseln? Ich bin z.B. froh, dass wir nie VS2013 eingesetzt haben, aber finde es super jetzt VS2015 zu verwenden.
Natuerlich ist es, meiner Meinung nach, wichtig am selben Strang und in die selbe Richtung zu ziehen, aber manchmal muss es nicht immer sofort und gleich wenn es moeglich ist sein. Vielleicht sind Kollegen noch nicht so weit oder es gibt andere gute Gruende zu warten.
Ein gutes Entwicklungsteam und da zaehle ich die NichtEntwickelndenArchitekten nicht dazu, sollte das immer in einem gemeinsamen Entscheidungsprozess oder in einer gemeinsamen Entscheidung tun.
Es stellt sich naemlich die Frage, wenn es Entwicklerkollegen gibt, die immer vorauseilen und denen die Gruende, warum anderen nicht oder noch nicht wecjseln wollen egal sind, ob diese Entwicklerkollegen so gute Teamworker sind, ihre Qualitaet als sehr gute Softwareentwickler ausser Frage gestellt.

Teamwork sollte aus meiner Sicht das Zauberwort sein. Gemeinsam im Projekt bis zum Projektziel, dann hat auch jeder Freude, woraus Kreativitaet und Innovation entstehen und weiterentwickelt werden kann.

Comment on Neuste Werkzeuge und Probleme by xyrus02

xyrus02 — Mon, 07 Dec 2015 16:17:48 +0000

Hallo Manuel,

Ich befürchte tatsächlich, in eurem Team muss die Rolle des Softwarearchitekten einmal klar definiert werden. Irgendwie scheint sich das Bild eines Vorarbeiters eingeschlichen zu haben. Wenn ihr einen braucht, der den Entwicklern vorschreibt, wie sie entwickeln sollen, stellt einen “Lead developer” ein. Ansonsten schaut, dass sich euer Architekt um Architektur kümmert. So daneben ist deine Wikipedia-Definition nicht :-)

Viele Grüße

Comment on Neuste Werkzeuge und Probleme by Krisztina Hirth (@YellowBrickC)

Krisztina Hirth (@YellowBrickC) — Sun, 06 Dec 2015 18:37:56 +0000

Hallo Manuel,

Wir haben sicherlich auch unsere Protion von Problemen, aber solche hatten wir noch nie! Ich glaube, diese Probleme haben nichts mit Tools und Versionen zu tun. Mir drängen sich 2 Ideen in den Vordergrund:
1. Conways Law – wie unabhängig sind die Teams?
2. Ich hoffe, du hast nicht gerade die Entwickler “Bauarbeiter” genannt und die Architekten auf ein Podest gestellt?!

Gruß,
Krisztina

Comment on Null propagation for pre-C#6 by Dew Drop – March 13, 2015 (#1974) | Morning Dew

Dew Drop – March 13, 2015 (#1974) | Morning Dew — Fri, 13 Mar 2015 12:09:51 +0000

[…] Null propagation for pre-C#6 (Manuel Naujoks) […]