Sonntag, 23. Februar 2014

Perl... Really!!!

Samstag, 22. Februar 2014

How to stop your subordinates from becoming creative since everyone knows it’s the real threat …

Donnerstag, 1. August 2013

Manual testing is immoral!
It’s not just dumb, and it is dumb!
IT IS IMMORAL!

Great Presentation by Uncle Bob (Robert Cecil Martin) where he talks about the original meaning of the scrum Master role, the importance of Testing and how 'scrum' and 'agile' took the wrong path. I could not find it in better quality…


Better quality Link of 'The Land that Scrum Forgot'

Freitag, 12. Juli 2013

U need a programming language. Simple as that.

David Heinemeier Hansson talks about how ruby on rails lowers the bar and make programming more accessible. He stress the fact that 'There's No Such Thing as a "Pure" Programmer' but in the end accomplishing great thinks in programming can’t be easy, it takes thousands of decisions, so we will still need some language of expression, a programming language.

Full Interview on Talk on 'big Thing'


Montag, 11. Januar 2010

Positionierung von JUnit Tests innerhalb eines Projekts

Neulich ergab sich bei mir auf der Arbeit eine Diskussion über eine auf den ersten Blick relativ banale Angelegenheit. Die Unstimmigkeiten betrafen den Speicherort von JUnit Tests innerhalb eines Projekts. In diesem Fall war es ein Eclipse Java Projekt, doch sicherlich gelten die ähnliche Argumente für jede Projektstruktur mit einer Package basierten Sprache und einem Testframework.

Fragestellung


Folgende Frage stellt sich nun: Sollen die JUnit Tests in einem extra Source Ordner mit dem Namen "test", "JUnit" etc. abgelgegt werden oder sollen die Testklassen im gleichen Sourceordner liegen wie die zu testenden Klassen. Darüber das die Klassen und die Tests jeweils im gleichen Package liegen sollten waren wir uns aus verschiedensten Gründen einig. Die Fragestellung ist also welche Package Struktur die bessere Wahl ist:
1)

ODER
2)

Hier ist die Beschreibung der Problematik und eine Antwort die unter junit.sourceforge zu finden ist: link

Überlegungen


Für die Lösung 1) spricht, dass man auf einen Blick sieht welche Klassen einen Unittest haben und welche noch einen brauchen. Wird eine Klasse umbenannt oder verschoben ist es sehr schwer den dazugehörigen Unittest bei diesem Schritt zu übersehen. Die JUnit Tests sind darüber hinaus aus jeder Ansicht schnell zu öffnen und können per ANT relativ einfach aus dem build Prozess herausgenommen werden.

Für die Lösung 2) spricht die Tatsache, dass die große Anzahl an Tests den Inhalt der einzelnen Packages aufblähen und nicht zu Übersichtlichkeit der Projektansicht beitragen. Der Buildprozess wird vereinfacht. Mock Klassen, Infrastrukturklassen sowie Helper Klassen die nur für das Testen notwendig sind können hier gemeinsam mit den eigentlichen Testklassen relativ einfach untergebracht werden.

Im Netzt findet man unter dem Verweis auf "Best Practice of testing" in der Regel fast Ausschließlich die Anwendung der Lösung 2).
z.B. hier "It is considered a best practice in testing, to separate the test case code from the application code."

Nur selten trifft man auch auf die Argumente, die für die Lösung 1) sprechen.

Schlussfolgerungen


Will man in einem relativ kleinen Projekt das Testen enforcen so wird die Lösung 1) wohl die passendste sein.
In größeren Projekten wo mit Hilfe von Spring beim Testen ganze Architekturschichten ausgetauscht bzw. gemockt werden können und das Verständnis um die Notwendigkeit von Tests bereits vorhanden ist, wird die Lösung 2) wohl am effizientesten sein.

Dienstag, 5. Januar 2010

Wie macht man Geld mit Web 2.0

Viele fragen sich ja wie kann ich mit Web 2.0 Geld verdienen. Klar, da gibt es viele Antworten aber ich habe wohl noch nirgends eine kreativere und einfachere Möglichkeit gesehen als mit dieser Seite. Hier beschreibt der Autor was er dafür gemacht hat. Dass er ein Paar Twitter followers hatte ist sicher nicht von der Hand zu weisen. Schräg ist dieses ausnutzen der Pandemie Angst, mit dem einfachsten Konzept den man sich überhaupt überlegen kann, schon.

Montag, 30. November 2009

Neues aus einem meiner Projekte: Angebotsassistent

Trotz immenser Einsparpotentiale sowohl für die Bieter, als auch für die Vergabestellen kann sich die elektronische Vergabe in Deutschland immer noch nicht wirklich durchsetzen. Ein Grund dafür ist in der hier schädlichen „Vielfalt“, an technischen Voraussetzungen, Plattformen und Geschäftsmodellen, zu sehen. Bereits heute existieren deutschlandweit über 40 unterschiedliche Vergabeplattformen, Tendenz steigend. Ein überregional agierender Bieter muss eine große Menge an Lösungen unterschiedlicher Anbieter beherrschen. Dies ist heute der wichtigste Grund, wieso eVergabe hinter den, in sie gesteckten Erwartungen, bleibt. Die Lösung für diese Problematik liegt in Erstens: Einer weitreihenden Standardisierung der Schnittstellen und Austauschformate und Zweitens: Der Bereitstellung einer einheitlichen Lösung, eines Multiplattform-Bieterwerkzeugs, das nach Möglichkeit alle vorhandenen Vergabeplattformen bedienen kann.

Dem Problem der Standardisierung im Bereich eVergabe widmet sich seit einiger Zeit das von BeschA BMI ins Leben gerufene Projekt XVergabe. Die Initiative wurde bereits 2007 im Rahmen der Standardisierungsinitiative XÖV als zentrales Vorhaben von Deutschland Online begründet. Der erklärte Wille war und ist: Standards für den elektronischen Datenverkehr in Behörden zu schaffen. Hier wurden bereits wichtige Grundsteine gelegt, wie die deutschlandweite Standardisierung der Bekanntmachung. Die Administration Intelligence AG hat sich von Anfang an rege beteiligt und wirkt neben den anderen Plattform und Lösungsanbietern wie Subreport Verlage Schawe GmbH und Cosinex GmbH an Entscheidungsfindung und der Entstehung neuer Standards mit. Hierbei wird die Administration Intelligence AG vom Lehrstuhl für BWL und Wirtschaftsinformatik der Julius-Maximilians-Universität Würzburg unterstützt. Dabei ist die Aufgabe des Lehrstuhls nicht nur auf die zukunftweisende, sichere und technisch verlässliche Umsetzung der Standards zu achten, sondern auch die Interessen der Bieter zu wahren. Denn für einen bieterseitig effizienten Angebotsprozess ist neben der universellen Verfügbarkeit der Vergabeunterlagen, auch die einfache und schnelle Angebotserstellung von großer Bedeutung. So ist nicht jedes Formular oder Leistungsverzeichnis, welches in einer Behörde erstellt worden ist, selbsterklärend und nicht jede Verfahrenseigenheit der unterschiedlichen Vergabestellen sofort nachvollziehbar und einleuchtend. Eine Standardisierung der Austauschformate und Arbeitsabläufe macht eine geführte Angebotserstellung, fachliche Prüfung der Angebotsunterlagen sowie eine sichere und valide Angebotsabgabe erst möglich. Hier machte die Administration Intelligence AG erst vor Kurzem von Sich reden, als sie die in Zusammenarbeit mit den Würzburger Wissenschaftlern entwickelte und bereits verfügbare Bietersoftware vorstellte.

Die besagte Lösung ist der AI ANGEBOTSASSISTENT, das Multi-Plattform-Bieter-Werkzeug der AI AG und ist nach einer Registrierung kostenlos zum Herunterladen verfügbar. Das Ziel war es den Unternehmen ein Werkzeug anzubieten, mit dem eine größere Anzahl an verschiedenen Plattformen, bedient werden kann. Die Lösung unterstützt derzeit eine noch kleine, aber signifikante Anzahl an Vergabeplattformen. Diese wird in den kommenden Monaten aber immer weiter ausgebaut. Wichtige Features, wie die plattformübergreifende Suche in Vergabeunterlagen und Bekanntmachungstexten sowie die Verwaltung von Zugangsdaten für die unterschiedlichen Vergabeplattformen, aber auch eine geführte und rechtsichere Angebotserstellung sowie Angebotsabgabe bietet die Lösung schon jetzt. Viele weitere Merkmale, an denen der Lehrstuhl für BWL und Wirtschaftsinformatik der Universität Würzburg maßgeblich mitgewirkt hat, werden in Kürze die Lösung bereichern.

Die Probleme, die bei der Entwicklung eines Multi-Plattform-Bieter-Clients entstehen, liegen auf der Hand. Die Lösung muss viele separate Plattformen bedienen. Selbst unterschiedliche Plattformen eines Herstellers liegen oft in verschiedenen Versionen vor und müssen technisch jeweils anders angesprochen werden. Weiterhin sind die unterschiedlichen Geschäftsmodelle ein großes Hindernis. So erhebt die Hessische Ausschreibungs­datenbank, kurz HAD, für nicht Hessische Bieter eine Gebühr. Vergabe24 verfolgt dagegen gleich mehrere Geschäftsmodelle. Ein weiteres Problem ist die Zentrale Anmeldung, das sogenannte SSO. Hier muss beachtet werden, dass die Sicherheitsvorkehrungen und die geforderte Daten von Plattform zu Plattform variieren. Um einen konsistenten Datenbestand zu erreichen und mögliche Doubletten zu vermeiden, musste hier viel Aufwand betrieben werden. Die gesammelten Erfahrungen haben die Würzburger Wissenschaftler bereits dem XVergabe Gremium präsentiert. In Zusammenarbeit mit der Administration Intelligence AG plant der Lehrstuhl für BWL und Wirtschaftsinformatik Universität Würzburg mittelfristig die verwendete Schnittstelle sowie die Standardaustauschformate zu veröffentlichen um so die XVergabe voranzubringen.

Nun sind auch andere Hersteller bemüht hier Abhilfe zu schaffen so wird eine Initiative die vor Allem durch Subreport Verlage Schawe GmbH und das Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS vorangetrieben wird, zuletzt immer wieder ins Gespräch gebracht. Noch gibt es kein offizielles Release-Termin jedoch darf man auf weitere Entwicklungen in diesem Bereich gespannt sein.


Abschließend kann man sagen, dass sich die elektronische Vergabe immer weiter durchsetzen wird weil es elementare Vorteile gegenüber dem Papierverfahren bietet. Die Multi-Plattform-Bieter-Clients können dieser Entwicklung jedoch einen großen Schub verleihen. Die Entwicklung des Bieters zum Kunden und zur wichtigsten Zielgruppe im Bereich eVergabe wird jedenfalls nicht mehr aufzuhalten sein und wird für weitere Wichtigen Impulse in diesem Marktsegment sorgen.