![]() |
Freies Entwickler-Treffen
Liebe DP-ler,
am Samstag, den 23.11.2013 findet in Mesum die fünfte Open Space Konferenz der Softwerkskammer Münster Osnabrück Bielefeld statt. Veranstaltungsort ist die OptiTime® GmbH & Co. KG in Rheine / Mesum.Von 9 bis 17 Uhr werden Softwareentwickler aus dem Münsterland - und darüber hinaus - über gute Softwareentwicklung diskutieren. Die Veranstaltung ist kostenlos. Gute Softwareentwicklung ist mit einer Handwerkskunst zu vergleichen. Gemäß dem Motto der Softwerkskammer "we learn, we care, we practice, we share" geht es darum, ein Bewusstsein für sauberen Quellcode zu schaffen, neue Trends und bekannte Werte zu vermitteln, praktische Arbeitstechniken zu üben und sich untereinander auszutauschen. Bei der Open Space Technology ( ![]() Erfahrene Softwareentwickler können hier neue Anregungen sammeln und ihr Wissen erweitern, der Nachwuchs aus den Hochschulen kann Einblicke in die Praxis gewinnen und Kontakte zu erfahrenen Praktikern knüpfen. Weitere Information unter ![]() Direkter Link zur Anmeldung: ![]() Mit freundlichem Gruß Ansgar Gosling PS: Ich habe im Vorfeld mit Daniel abgestimmt, ob ich die Werbetrommel drehen lassen darf |
AW: Freies Entwickler-Treffen
So, habe mich gerade angemeldet. Liegt ja durchaus noch in meinem Einzugsgebiet.
Das ist allerdings meine erste Open Space Veranstaltung. Bin gespannt, wie sowas abläuft. |
AW: Freies Entwickler-Treffen
habe schon ein paar openspaces mitgemacht. Jedes mal ist anders, aber jedes Mal macht's Spaß und man nimmt echt vieles an neuen Ideen mit. Gerne gesehen sind auch Leute die mit der Entwicklung zu tun haben, auch wenn sie nicht programmieren, z.B. Tester.
|
AW: Freies Entwickler-Treffen
So, ich war also gestern auf diesem OpenSpace und es war eine durchaus positive Erfahrung. Die Leute waren sehr nett und hilfsbereit und haben alles ausführlich erklärt, was angesichts der recht großen Zahl von Erstlingen sicher gut ankam.
Die Sessions waren eine Mischung aus Vorträgen, Diskussionen und Active Coding und wurden erst am Morgen festgelegt. Dabei hatte man selbst im Rahmen der Gruppe noch Möglichkeiten die Reihenfolge zu beeinflussen, wenn zwei interessante Sessions kollidierten. Natürlich war das nicht in jedem Fall lösbar. Der Anteil der teilnehmenden Delphi-Programmierer war offenbar alles andere als marginal. Leider kamen auch Kommentare wie "außen hui, innen pfui" - sachlich vollkommen haltlos und offenbar einer Kombination aus Unwissen und tiefgreifendem Vorurteil geschuldet. Immerhin konnte in einer agilen Coding-Session die Delphi-Anwendung im Gegensatz zu der Java-Lösung das korrekte Ergebnis liefern (Python war auch korrekt, nur nicht formatiert). Unproduktiv ist Delphi in jedem Fall aber nicht. Obwohl ich nicht glaube, daß das gerade hier die richtigen Leute erreicht: Zitat:
|
AW: Freies Entwickler-Treffen
Zitat:
1. Eine Sprache, die kein OOD anbietet, erzwingt schlechtes Design. (Q-Basic :stupid:) 2. Eine Sprache, die sowohl prozedurale Programmierung als auch OOP anbietet, lädt zu schlechtem Design ein (Delphi). 3. Eine Sprache, die nicht typsicher ist, lädt zu unsicherem Code ein. (C) Ein guter Softwerker wird in so gut wie jeder Sprache (auch Q-Basic) in der Lage sein, eine gute Architektur und Struktur unterzubringen. Allerdings wird ein mittelmäßiger Programmierer, was ja per Definitionem der Großteil der Programmierer ist, aus Bequemlichkeit die Paradigmen einer Programmiersprache verwenden, die sein Problem kurzfristig am schnellsten löst und nicht den Weg wählen, der langfristig am besten und saubersten ist (weil er eben mittelmäßig ist). Und Bequemlichkeit (oder von mir aus 'Zeitdruck', um eine beliebte Ausrede zu verwenden) liegt nun einmal in der Natur des mittelmäßigen Programmierers. Ich will hier sicherlich keinen Delphi-Flamewar starten, aber eine Programmiersprache, die den Spagat zwischen den 80er Jahren des letzten Jahrhunderts und heute schafft, muss zwangsweise in Kategorie 2 und 3 (s.o.) fallen und somit dem Durschnittsprogrammierer die Hintertür zu schlampigem aufhalten. Natürlich kann man mit C#/Java genauso schlampigen Code produzieren, aber es wird einem doch etwas schwerer gemacht: harte Casts gehen nur sehr umständlich, fehlende Rückgabewerte gar nicht, Range overflows sind so gut wie unmöglich usw. Bezüglich dem Schreiben von Tests ist meine Erfahrung die, das Tests nur so einfach zu schreiben sind, wie das Test/Mocking-Framework es zulässt. Wenn ich eine CLR/Runtimeumgebung habe, die mir alle Möglichkeiten bietet (was bei Delphi nicht der Fall ist), ist es logisch, das ich mit anderen Sprachen viel einfacher Tests schreiben kann. Auch andere Delphi-Schwächen (die eher Win32-Macken sind, aber egal) sind nicht gerade förderlich, wenn es ums Schreiben von (gemockten) Tests geht. Ganz so gleichwertig steht Delphi hier also nicht da. Allerdings ist es wirklich so, das die Urteile der Stammtischschwätzer auf Unwissenheit beruhen, denn wer z.B. Delphi als Macro-Skriptsprache in Erinnerung hat (ein Senior-Softwarearchitekt im vorletzten Projekt), der ist einfach nicht qualifiziert genug. So wie ich das sehe, kann Delphi durchaus mithalten und bietet mit der Option One-Codebase-many-Plattforms ein Alleinstellungsmerkmal, an das sich die anderen Sprachen / IDE messen müssen. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 18:05 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz