Laden...

Forenbeiträge von mg.net Ingesamt 153 Beiträge

03.06.2012 - 20:36 Uhr

Als ich deinen Post gelesen habe, dann hatte ich angenommen, du wärst so um die 55 Jahre alt, oder älter. Wie soll denn das funktionieren, wenn wir alle bis 67 arbeiten sollen, uns aber mit 33 Jahren schon als zu alt zu bezeichnen um neue Wege zu gehen?

Nein, natürlich bist du damit keineswegs zu alt um den Beruf des Softwareentwicklers zu lernen, warum denn auch? Zumal in deinem Fall auch noch eine gewisse Affinität zum Thema gegeben ist.

Ich kann auch das Argument nicht nachvollziehen, das "einfache Programmierer" nicht gefragt wären. Es gibt in unserem Land etwa 300.000 Entwickler, Tendenz (zum allgemeinen Leidweisen) nur leicht steigend. Die Berufsaussichten sind hervorragend, die Verdienstmöglichkeiten allemal besser (im Schnitt) als Verkäufer. Ein Ende dieser Entwicklung ist, jedenfalls vorläufig, nicht absehbar. Beste Aussichten also für Quereinsteiger dieses gehobenen 😃 Alters.

In einem abhängigen Arbeitsverhältnis braucht es natürlich eine Form des Qualifikationsnachweises, keine Frage. Aber auch Anbieter von Aus- und Weiterbildung sind doch breit gestreut und zum Thema Fernunterricht gibt es in diesem Forum auch zahlreiche Posts.

Also, nur Mut zu dieser Veränderung!

10.05.2012 - 21:13 Uhr

Dafür ist doch eigentlich die Workflow Foundation da, wo die IF-Anwendung in XAML-Code hinterlegt werden kann.

12.04.2012 - 08:44 Uhr

Code in einem DataContract ist zwar möglich, aber meist nicht sinnvoll. Es werden keine vollständigen .NET-Objekte vom Server zum Client (und zurück hin) übertragen, sondern letztlich DTO (Data Transfer Objects), also letztlich XML-Dateien. Sonst wäre WCF auch kaum interoperabel. Das ist ja auch der Grund dafür, warum man DataMember auszeichnen muss - um explizit zu kennzeichnen, was übertragen werden soll (und zusätzliche Parameter pro Attribut spezifizieren zu können). Client und Server haben außerdem völlig eigene Versionen des DataContract. Wenn Du z. B. Code auf dem Server einem DataContract hinzufügst und dann auf dem Client einen Proxy generierst, dann fehlt der gesamte Code, weil eben nur die Daten für den Austausch eine Rolle spielen.

06.04.2012 - 18:53 Uhr

Hallo,

mit der Testautomatisierung verhält es sich wie mit vielen anderen Dingen: Zu Beginn sieht alles recht einfach aus. Ein paar Klicks simulieren und einige Werte in Controls ablesen. Damit lässt sich aber in der Praxis häufig nur ein geringer Prozentsatz der Software wirklich testen. Da gibt es z. B. Steuerelemente die gezeichnet werden, Grids, Treeviews, Listenansichten uvm. Mit der VS-Lösung greift man da bereits nach kurzer Zeit in die Tasten und entwickelt das alles selbst - allerdings, das muss man sagen, ist das auch nicht allzu schwer.

Der Markt bietet nun auch spezielle UI-Automation-Lösungen, wie z. B. Ranorex. Diese bieten erwartungsgemäß deutlich mehr, z. B. das Testen von Websiten mit Firefox, das automatische Ausführen Befüllen von Masken aus einer Datenbank heraus, das komfortable Adressieren von Controls oder eine komfortable API.

Dafür sind diese Tools nicht ganz preiswert. Und sie erfordern natürlich einen gewissen Einarbeitungsaufwand. Dennoch: Für komplexere Anwendungen und umfangreichere Automatisierungsaufgaben kann ich mir nicht vorstellen, wie man mit der in VS eingebauten Alternative auf einen grünen Zweig kommen sollte.

15.03.2012 - 13:11 Uhr

Ja, WCF implementiert eine "Auto-Open"-Funktion, öffnet also den Channel beim ersten Call automatisch. In einigen Fällen kann dies zu unerwünschten Resultaten führen, weil WCF bei mehreren Calls die Calls selbst in einer Warteschlange serialisiert. Die empfohlene Vorgehensweise ist daher immer Open aufzurufen. Aber, ehrlich, in den meisten Fällen dürfte das ziemlich egal sein.

Das mit der Performance kann ich Dir leider nicht pauschal beantworten. Das Schöne an WCF ist ja, dass sich die Bindings mit wenigen Mausklicks ändern lassen - also, einfach messen! Natürlich hängt das auch vom verwendeten Host ab und von den konkreten Binding-Parametern. Es ist übrigens auch möglich, http zu verwenden, aber einen binären Payload. Das ist m. E. nach sehr sinnvoll und wird auch häufig praktiziert.

14.03.2012 - 16:20 Uhr

Hallo Diräkt,

zu 1: zumindest ähnlicher Effekt, aber andere Realisierung, wobei die asynchrone Methode natürlich an Bedeutung gewinnt, mit .NET 4.5 und dem async/await-feature.

Zu 2: Ja, 1 Call pro Sekunde würde mich überhaupt nicht abschrecken. Da kommt durch indirekte Calls (Service2Serivce) oft eine viel, viel höhere Frequenz zustande. Bei unseren Systemen sind das schon einmal mehrere Tausend Calls in wenigen Minuten, alle Per-Call.

Zu 3: Beim Client hängt die Bedeutung von Open und Close stark vom verwendeten Binding ab. Beim zustandslosen Http ist das weniger problematisch, als beim zustandsbehafteten net.tcp. Aber auch hier gibt es eine einfache Regeln, von der man nur in (wenigen) begründeten Ausnahmefällen abweichen sollte: Open - Aktion durchführen - Close. Nun gibt es Fälle, in denen in kurzer Folge (z. B. in einer Schleife) zig-Serviceaufrufe stattfinden. Dann würde ich den Proxy nicht schließen. Aber andererseits sollten solche Aufrufe auch nicht vorkommen, weil sie viel zu fein-granular sind.

Zu 4: Da sehe ich wenig Probleme. Im Standard erlauben die meisten Firewalls doch ausgehende Verbindungen. Andererseits: http ist natürlich von Haus aus offen.

13.03.2012 - 21:51 Uhr

Zu 1:
Ja, das ist eine Client-Angelegenheit. Das Instanzmanagement auf dem Server ist davon nicht betroffen. Im Grunde geht es nur darum, den GUI-Thread während einer IO-Anfrage (was ein WCF-Aufruf im Grunde nun einmal ist) reaktiv zu halten.

Zu 2:
Sessions würde ich nur dann verwenden, wenn der Service auch wirklich wissen muss, was der Client zuvor gemacht hat. Und auch dann gibt es problemfreiere Möglichkeiten das zu realisieren. Wesentlich unkomplizierter ist eine ganz gewöhnliche Per-Call-Instanziierung.

Aber, Achtung: WCF kennt einige Mechanismen, um DoS-Angriffe abzuwehren, gerade bei netTcp-Binding können einem da die Einstellungen z. B. des TCP Port-Sharing-Services (bei IIS/WAS) einen Strich durch die Rechnung machen. Außerdem sind ggf. Throttling-Einschränkungen zu beachten.

Zu 3: Beim ServiceHost, nehme ich an? Ja, man kann den Servicehost selbst verwalten, was gerade bei Sessions keine schlechte Idee ist, weil so die Lebensdauer verlässlich bekannt ist.

Zu 4: Gerade bei Callbacks ist net.tcp viel einfacher, weil dieselbe Verbindung für beide Richtungen verwendet wird. Bei Http wird eine Duplex-Verbindung aufgebaut, der Service muss also eigenständig auf den Client zugreifen können.

20.01.2012 - 23:14 Uhr

Ja, das kann ich gut verstehen. Testen ist keine leichte Aufgabe und daher würde ich mit einer Lektüre beginnen, die die einzelnen Testmöglichkeiten in einen größeren Rahmen stellt, miteinander vergleicht und in Bezug zueinander stellt. Wann ist Unittesting angesagt und in welchem Umfang? Wie funktioniert exploratives Testen, worauf ist dabei zu achten? Gibt es Tools für Akzeptanztests? Wie kann man die eigenen Testfälle so aufbauen, dass man mit möglichst wenig Aufwand möglichst viel erreicht (z. B. bei der Testabdeckung)? Das wären einige mögliche Fragen.

"The Art of Unit Testing" scheint mir da kein guter Einstieg zu sein.

Mir persönlich gefallen die Bücher vom d.punkt-Verlag (z. B. Praxiswissen Softwaretest). Gut finde ich auch "Pragmatic Software Testing". In diese Bereich sind die besten Bücher wohl in englischer Sprache zu haben.

20.01.2012 - 23:05 Uhr

Ich kann da herbivore nur völlig zustimmen. Man muss es einmal ausprobiert haben, um zu sehen, ob man sich der Sache gewachsen fühlt oder nicht.

Dennoch, ein wenig Vorsicht kann nicht schaden und daher schlage ich vor, das Management in die eigene Überlegung mit einzubeziehen. Die Aussage sollte lauten: Ja, ich glaube das schaffe ich! Und trotzdem kann man eine "Rückfallmöglichkeit" vereinbaren, falls sich die Aufgabe dann später als unlösbar herausstellt. Das hat den Vorteil, dass man im Fall der Fälle das Gesicht wahren kann.

Was mich ein wenig stutzig macht ist der Jobtitel "Architekturmanager". Es ist sicher von Nutzen, wenn Du dir Deine Aufgaben und, vor allem, Deine Kompetenzen schriftlich geben lässt. Gibt es da noch jemanden, der die eigentliche Architektur aufstellt, wenn ja: Wie ist die Zusammenarbeit? Oder, eine weitere Frage: wie soll die damit verbundene Kontrollaufgabe um- und durchgesetzt werden? Gibt es Code-Reviews oder gar ein formelles Freigabeverfahren?

Außerdem verbietet einem niemanden, einmal mit den künftigen Kollegen zu sprechen - vorab und unverbindlich. Du wirst schon sehen wie sie reagieren und ob Sie dich akzeptieren werden - von offener Ablehnung über Desinteresse und Begeisterung ist da alles möglich.

29.12.2011 - 21:03 Uhr

Die Frage würde eigentlich eine sehr umfangreiche Antwort verlangen. Diese findest Du bei Google, keine Frage, daher an dieser Stelle ein paar Denkanstöße zum Anfangen.

Zunächst einmal: Ja, mit drei Schichten würde ich erst einmal anfangen. Wichtig ist dabei, dass die einzelnen Layer weitgehend umabhängig voneinander sind, vor allem in "eine Richtung". Dabei meine ich, dass die GUI-Schicht natürlich die Businesslogik-Schicht kennen muss (meistens jedenfalls), anders herum aber nicht. Grundlagen wie diese findest Du in jedem Buch über Softwarearchitektur.

Ansonsten gibt es natürlich feste Technologien, die einen gewissen Programmierstil erfordern, MVC oder MVVM zum Beispiel. Wenn Du einer solchen Technologie folgen willst, dann ist das Web die entsprechende Quelle, zum Beispiel MSDN.

Außerdem ist es natürlich immer eine gute Idee, Beispiele und Quellcode anderer Entwickler zu studieren. Codeplex ist da eine gute Anlaufstelle.

23.12.2011 - 10:06 Uhr

So richtig die Aussage von Abt ist, so wenig nützt sie auch in der Praxis. Wer möchte schon für ein kostenfreies Tool horrende Rechtsanwaltskosten bezahlen? Nur, um dann doch (im Wesentlichen) die Aussage zu bekommen: Das kommt darauf an!

Das gilt doch übrigens auch für diejenigen, die einen verklagen wollen. Gilt auch wiederum in beide Richtungen - was willst Du denn praktisch unternehmen, wenn jemand die Software von einem anderen Downloadserver herunterlädt?

Meine Erfahrung dazu ist: Meist wird alles nicht so heiß gegessen, wie es gekocht wird. Würde ich mich mit so etwas im Detail beschäftigen wollen? Nein! Also würde ich eines der vielen Standardlizenzmodelle verwenden, die es am freien Markt gibt. Klar, die mögen vielleicht nicht im Detail passen, aber - wie gesagt - es genügt nicht nur Ansprüche zu stellen, man muss sie dann auch durchsetzen können und wollen.

Ein anderer Weg sind Lizenzverträge, die gegen Gebühr über eine entsprechende Mustertexte-Seite im Internet angeboten werden.

06.12.2011 - 18:27 Uhr

Im Web findet man Wrapper um den Windows Installer herum - vielleicht eine Lösung?

06.12.2011 - 18:25 Uhr

Zunächst einmal kann es nicht schaden (= notwendig), in der Fremschlüsseltabelle einen Index auf die Fremdschlüsselspalte zu legen, es sei denn, die Werte wären sehr ungleichmäßig verteilt, was aber vermutlich nicht der Fall ist.

Überhaupt arbeitet der Query Optimizer nach eigenen Regeln. Ein Index wird verwendet, sofern dieser einen Nutzen daraus erkennen kann. Nicht immer ist die Verwendung eines Index sinnvoll, es gibt durchaus Fälle, in denen es schneller ist, große Datenmengen von der Festplatte (weitgehend sequentiell) zu lesen. Das hat im Wesentlichen mit der Selektivität zu tun. Dazu wird der SQL-Server sich die Verteilung der Werte in den Indexspalten anschauen, wofür dieser umfangreichere Statistiken unterhält. Ist die Selektivität des Index besonders hoch, dann wird dieser den Index verwenden. Allerdings (üblicherweise) nicht mehrere Indizes, sofern die Indizes nicht miteinander verknüpft sind - sprich mehrere Spalten in einem Index zusammengefasst sind. Und dann spielt noch die Reihenfolge eine Rolle.

Aller Voraussicht nach lautet die Antwort auf Frage 1 also Ja!
Zu 2: Nicht direkt, aber sogenannte materialisierte Views (indizierte Views) sind möglich, die ebenfalls Indizes haben können. Ist aber in aller Regel nicht nötig.
Zu 3: So ist es, jedenfalls für maximale Suchperformance und wieder unter der Maßgabe, dass der Index tatsächlich eine gute Filterwirkung aufweist (= hohe Selektivität). Indizes sind eben - wie vieles im SQL-Server - letztendlich auch nur Bäume, die nicht von jedem beliebigen Element aus durchlaufen werden können. Die Reihenfolge der Indexspalten ist also wichtig, eine gewisse Redundanz in solchen Fällen nicht immer zu vermeiden.

Übrigens, der SQL-Server zeigt Dir sowohl den prognostizierten als auch den tatsächlichen Ausführungsplan an, wenn Du ihn darum bittest. Das berücksichtigt dann auch Deinen konkreten Fall.

24.11.2011 - 22:28 Uhr

Unter "premature Optimization" vermeiden verstehe ich aber nicht, dass während der Entwicklung nicht auf Performance geachtet werden sollte, sondern vielmehr, dass das Optimieren sich auch auszahlen muss, was man ohne Messen oft nicht beurteilen kann. Und viele Optimierungen verschlechtern wiederum andere Code-Eigenschaften. Feature by Design ist so ein weiterer Slogan, was wieder zu der optimization zwischen den Ohren passen würde.

24.11.2011 - 21:07 Uhr

Ich kann mich an einen Vortrag auf einer Konferenz erinnern. Ein Entwickler stellte dort sein Projekt für eine große Versicherungsgesellschaft vor, bei dem es um die Verarbeitung riesiger Datenmengen ging. Er erstellte seine Anwendungen in C#, obwohl viele seiner Kollegen lieber C++ bevorzugten und ihn kritisch beäugten.

Er hatte sich sehr intensiv mit dem Thema C#/IL und Performance beschäftigt und alles bis ins Detail nachgemessen. Sein Fazit: C# kann genauso schnell sein wie C++, richtig angewendet. Beim Numbercrunching spielen viele Dinge eine Rolle: Die Objektinitalisierungszeit, die (sehr hohen) Kosten für Fehlerbehandlung (try/catch), oder Finessen bei Berechnungen.

Wie schon gesagt: Pauschalaussagen sind da wenig hilfreich, Messungen schon.

24.11.2011 - 21:01 Uhr

Zu den Indizes: Ein Index verlangsamt Insert- und Update-Operationen, weil er gepflegt werden will und der SQL-Server die Statistiken updaten muss. Eine feste Größe gibt es nicht, aber als Faustregel ist Deine Idee gar nicht schlecht. Ein Index funktioniert am besten, wenn er besonders selektiv ist, also im Idealfall direkt zum gewünschten Datensatz führt. Bei Bit-Feldern ist das oft nicht der Fall, weil dort ja nur zwei Zustände herrschen - dort macht ein Index dann u. U. keinen Sinn.

Ein left join stellt kein Problem dar, solange die Verknüpfung stimmt (on-Bedingung).

Ob das System die Daten schnell darstellen kann hängt natürlich auch davon ab, wie groß die zurückzugebende Datenmenge ist. Sind es nur wenige Datensätze - dann sollte die Abfrage im Bruchteil einer Sekunde erledigt sein. Sind es sehr viele Datensätze, dann kann freilich die Darstellung der Daten selbst schon viel Zeit in Anspruch nehmen.

24.11.2011 - 16:25 Uhr

Ehrlich gesagt, bei dieser Datenmenge würde ich mir darüber gar keine Gedanken machen. 400 Tausend Datensätze in der Master, vielleicht 1,2 Millionen Datensätze in der Detailtabelle ist für einen SQL-Server wirklich nicht besonders viel, weder für die Version 2005, noch für 2008 oder 2008R2.

Wie sich das System im Detail verhält, ist freilich eine Sache der konkreten Abfrage. Der SQL-Server besitzt einen recht komplexen Query Optimizer, der anhand der SQL-Anfrage einen physischen Abfrageplan generiert. Dabei hängt es von verschiedenen Faktoren ab, wie
*Gibt es Indizes, wenn ja: Sind diese verwendbar? *Wie ist die Werteverteilung, was wiederum Auswirkung auf die Verwendung des Indizes hat. Der SQL-Server speichert und pflegt für solche Fälle Statistiken *Wie sieht der SQL-Befehl selbst aus (ein einfacher Join, oder - im extremsten Fall - ein cross join) *Wie ist die Hardware bestückt, insbesondere: Arbeitsspeicher? *Was läuft sonst noch, gibt es eine bremsende Last auf dem System? *Gibt es Datensatzsperren?

Aber, wie gesagt, das sollte kein Problem sein. Übrigens auch nicht bei der zehnfachen Datenmenge, sofern die richtigen Indizes vorhanden sind, die Abfrage vernünftig formuliert wurde und der SQL-Server nicht gerade aus dem letzten Loch pfeift.

23.11.2011 - 09:05 Uhr

Ich bilde seit mehr als 10 Jahren aus und bin mit den staatlichen Schulen überhaupt nicht zufrieden - und wir haben in unserer Region 3 die für unsere Azubis in Frage kommen. Das ist aber nur bedingt eine Sache der Schulen, denn man muss bedenken:
*Bei Verkürzung mit Abitur sind die Azubis keine zwei Jahre mehr im der Ausbildung *Davon abzuziehen sind die Ferien *Ebenso Krankheit und andere Abwesenheiten *Dann gibt es noch Fächer wie Deutsch, Englisch oder Ethik, die nicht unmittelbar mit der Entwicklung zu tun haben *Dazu kommen noch ausgefallen Stunden (oder vielmehr davon weg) *Und die Zeit, die für Schulaufgaben und Exen weggeht *Und natürlich ist da noch Sozialkunde und die Dinge, die eher in den Bereich Systemadministration gehen *Zu guter Letzt gibt es noch Phasen, wie berufliche Bildungswoche oder die Prüfungsvorbereitung

Bei all dem bleibt für die Entwicklung nicht mehr viel Zeit übrig, weswegen die Entwickler das Entwickeln vor allem im Ausbildungsbetrieb lernen und eben nicht mehr an der Schule. Das ist für mich das gravierendste Problem des ganzen Systems.

05.10.2011 - 00:01 Uhr

Das Zertifikat an sich ist neutral oder positiv zu bewerten. Im schlechtesten Fall wird es ignoriert, im besten Fall liest der Personalverantwortliche das hinein, was seine Erfahrung hergibt. Diese Menschen sind halt so wenig standardisierbar wie andere auch.

Ich sehe aber ein weiteres Hauptproblem: Bewerber legen gerne Zertifikate bei, ohne darauf einzugehen. Sie meinen, das Zertifikat würde schon für sich sprechen. Das tut es meist nicht. Denn zum Einen sind wohl vielen "Personalern" die Inhalte völlig fremd und zum Anderen ist der Markt auch recht unübersichtlich - es gibt ja nicht nur die Microsoft-Zertifikate. Also: Warum nicht die Beweggründe kurz schildern, oder die Inhalte in einem Satz zusammenfassen? Am besten wäre natürlich ein kausaler Zusammenhang, also wie die erlernten Inhalte praktisch von Nutzen waren. Es geht also nicht nur darum eine Prüfung zu bestehen, sondern auch darum diese Leistung zu verkaufen.

11.08.2011 - 13:09 Uhr

Hallo shacknet,

ich glaube man muss den Markt in zwei Bereiche aufteilen: Professionelle Lösungen und Hobbylösungen. Die professionellen Lösungen haben den Vorteil, dass deren Technologie auch noch in zehn Jahren zu haben ist. Außerdem bieten sie ein breites Spektrum an Anwendungsmöglichkeiten, von der simplen Rollosteuerung bis zur Steuerung von Hotels. Bekanntestes Beispiel: KNX (bzw. EIB). Das ist zunächst einmal ein Busprotokoll. Man benötigt dafür Aktoren und Sensoren, die z. B. auf die Hutschiene montiert werden, oder im Raum selbst über normierte serielle Leitungen. Darauf aufbauend gibt es dann viele Softwarelösungen, zum Beispiel von Gira. Diese wiederum bringen mehr oder weniger umfangreiche Möglichkeiten zur Erweiterbarkeit mit - je nach Software und lizenziertem Umfang. Bei Gira ist es zum Beispiel der Homeserver. KNX ist recht teuer, aber es funktioniert halt auch zuverlässig - nicht nur für uns ITler, sondern auch für die Hausangehörigen. Gibt es übrigens auch für Funk und für die Stromleitung.

Dann gibt es, wie gesagt, die Lösungen, die ich als Hobbylösungen bezeichnen möchte. Homematic ist so ein Anbieter (Homematic Homepage). Diese Lösungen sind zum Teil ebenfalls wirklich leistungsfähig, aber eher Insellösungen, im Vergleich zu weltweiten Standards jedenfalls.

Wichtig ist halt nicht nur die Software. Sensoren und Aktoren werden in jedem Fall benötigt und diese müssen halt entsprechende Normen erfüllen. Gute Hardware kostet immer einen gewissen Betrag. Außerdem ist es interessant, welche Rückwege es gibt. Nehmen wir einen Dimmer: Dort ist die einzustellende Größe natürlich der Dimmwert (z. B. von 0-255), aber für eine komfortable Haussteuerung ist es eben auch nützlich, wenn man abfragen kann, welcher Wert gerade eingestellt ist. Und von hier aus kann man natürlich alles machen: Rollos hochfahren bei Sturm, den Zustand der Aktoren übers Web afragen, das Hoflicht einschalten über eine Funkfernbedienung usw. usf.

01.08.2011 - 22:39 Uhr

Die meisten Bücher gehen auf das Thema Projektkostenplanung und -controlling nicht näher ein. Eventuell sind daher zwei Bücher sinnvoll.

Ich vermute jetzt mal, dass Du das Thema von Grund auf lernen möchtest.

Ein recht umfangreiches, aber auch brauchbares Buch ist "Handbuch IT-Projektmanagement", erschienen beim Hanser-Verlag. Dort steht eigentlich alles Wichtige drin, eben bis auf die Details zur den Projektkosten.

Ebenfalls interessant sind einige Werke, die einem gewissen Modell folgen. Dort vor allem PBMoK (Project Management Body of Knowledge). Dort gibt es auch ein Buch zur aktuellen Version. Ein etwas witziger geschriebenes Buch gibt es auch von oReilly (in englischer Sprache): Head First PMP (Second Edition). Darin sind auch Fragen und Lösungen enthalten.

Ein wenig abseits vom Mainstream sind die SCRUM-Bücher. Hier kann ich das Werk vom dpunkt Verlag empfehlen.

Auch nicht schlecht, recht dick und ebenfalls in englischer Sprache: Effective Project Management: Traditional, Agile, Extreme von WILEY.

Überhaupt gibt es im englischsprachigen Bereich mehr Bücher, die manchmal auch einfach unterhaltsamer geschrieben sind, als die deutschsprachigen Werke.

Zum Schluss noch ein Buch zum Stöbern und Querlesen: 97 Things Every Project Manager Should Know, ebenfalls von oReilly.

28.06.2011 - 23:23 Uhr

Die Frage lautet ja auch: Was bedeutet denn agil in der konkreten Kunden- und Vertragsbeziehung? Agil bezüglich der Vorgehensweise, agil im Hinblick auf die Entwicklungsweise (z. B. frühe Prototypen, häufige Auslieferungen) oder agil bezüglich des zu entwickelnden Umfangs? Oder eine Kombination davon?

Die meisten Kunden wird es herzlich wenig interessieren, wie das interne Entwicklungsmodell des Dienstleisters aussieht. Er kauft einen gewissen Funktionsumfang zu einem gewissen Preis und erwartet eine Lieferung zum zugesagten Termin. Agilität kommt schon deshalb ins Spiel, weil das Pflichtenheft meist genug Raum für Interpretationen lässt und das eine oder andere zudem vergessen wurde. Und auf Entwicklerseite ist Agilität gelebte Entwicklungskultur.

Agilität setzt immer einen festen Grundrahmen voraus, in dessen Grenzen agil gehandelt werden kann. So ist es zum Beispiel nicht unüblich eine Grundfunktionalität fest zu vereinbaren und dem Kunden das Recht einzuräumen, während des Projektes aus einer Liste vorher besprochener Anforderungen auszuwählen. Dann entweder im Rahmen eines vereinbarten Werkpreises oder per Aufpreisliste.

Auch bei agilen Modellen gibt es feste Bezugsgrößen. Bei Scrum zum Beispiel das Backlog, das vom "Product Owner" priorisiert und einzelnen Sprints zugeordnet wird. Die Zuordnung ist agil, auch die Aufteilung auf das Team. Über den Inhalt des Sprints wird aber (im Normalfall) nicht mehr diskutiert.

Ich würde das magische Dreieck von "der-schlingel" noch um differenzieren wollen (zum magischen Viereck). Gut bedeutet sowohl : Gut (= Qualität) und Viel (=Funktionsumfang). Es ist klar, dass es hinsichtlich der Qualität feste Größen geben muss, weil Qualität auch Kosten und Zeit bedingt.

Zu guter Letzt hängt es auch von der Vorgeschichte zwischen Kunden und Dienstleister ab. Hat das Modell in der Vergangenheit schon funktioniert? Besteht ein gesundes Vertrauensverhältnis? Besteht die Bereitschaft beider Seiten zu Kompromisse? Die Liste ließe sich weiter fortführen.

Ich selbst bin recht unglücklich über den inflationären Umgang mit dem Begriff "Agil", der oft genug noch als seligpreisend und allumfassend verkauft wird. Und so gibt es nur eine sichere Erkenntnis: Agil ist zunächst nur ein Adjektiv. Es kommt immer darauf an, was man daraus macht.

09.06.2011 - 20:16 Uhr

Auf Deutsch kenne ich keines, aber die Bücher von Apress sind recht gut. Es gibt sie für Anfänger und Fortgeschrittene.

09.06.2011 - 20:13 Uhr

Ja, das Interface wird eher höherwertige, fachlich getriebene Methoden aufweisen.

09.06.2011 - 11:02 Uhr

Ein dritter Service wäre dann ein "Orchestration-Service". Grundsätzlich ist ein solcher sinnvoll, wenn er selbst einen Mehrwert anbietet, sonst nicht. Häufig ist das die "Prozesssicht", wofür er sich dann bei anderen Services bedient.

Ein Beispiel:
Nehmen wir an, es gäbe zwei Services: Einen Rechnungs-Service und einen Kunden-Service. Bei einer Bestellung werden beide benötigt, der Rechnungs-Service erstellt den Rechnungsbeleg, der Kundenservice erfasst die zugehörigen Kundendaten. Ein Client würde in diesem Fall einige Geschäftslogik implementieren müssen, würde er selbst die beiden Services verwenden wollen. Daher ist es hier sinnvoll, einen "Bestell-Service" als Orchestration-Service zu verwenden. Dennoch können weiterhin auch die anderen Services benutzt werden, beispielsweise dann, wenn es lediglich darum geht, die Adresse eines Kunden zu ändern.

Findest Du dich in diesem Beispiel wieder? Dann schlage ich vor, einen dritten Service anzulegen. Wenn es nur darum geht, dass dieser dritte Service Aufrufe bündelt, ohne neue Geschäftslogik zu implementieren, dann sollte darauf verzichtet werden. Aber wie immer gilt: Auch hier hängt es vom Kontext ab.

27.05.2011 - 13:00 Uhr

Ich nehme an, das Binding ist netTcpBinding? Ist TCP-Port Sharing dann eingerichtet und konfiguriert?

12.05.2011 - 13:03 Uhr

Ich füge noch hinzu, dass Windows erst einmal ohne deutsche Stimme daherkommt. Es gibt einige Anbieter die das anbieten und auch große Qualitätsunterschiede.

Einen guten Überblick bietet:

Deutschsprachige TTS-Stimmen

12.05.2011 - 08:07 Uhr

Vor einigen Jahren habe ich die Entwicklung in Indien betreut und war auch schon ein paar Mal vor Ort. Pauschale Aussagen wegen der Codequalität kann man nicht treffen. Es hängt, wie immer, von den Entwicklern ab, die den Code schreiben. Und da gibt es in Indien dieselbse Qualitäts-Spannbreite wie in Deutschland.

Dass Outsourcing nicht in jedem Fall interessant ist, hat einen einfachen Grund: Bei weitem nicht jedes Projekt eignet sich dafür. Es muss zunächst einmal hervorragend spezifiziert sein; was nicht spezifziert ist bekommt man nicht, oder falsch umgesetzt. Dann müssen Spezifikation und Programm in englischer Sprache sein. Es gibt zwar Sprachprogramme bei den Dienstleistern in Indien, aber das sind eher Maßnahmen zur Kundenbindung. Das Projekt muss außerdem groß genug sein, damit sich der Aufwand zur Durchsprache der Spezifikation (am besten vor Ort), der Einarbeitung der dortigen Mitarbeiter und der Kontrolle lohnt. Weiterhin sind agile Prozesse schwieriger umzusetzen, nicht nur wegen des Zeitunterschieds, sondern auch wegen der Mentalität der Menschen in Indien; man kann von Entwicklern im Outsourcing natürlich nicht dieselbe Einsatzbereitschaft erwarten, wie von Kollegen im gleichen Unternehmen - Ausnahmen mögen diese Regel bestätigen. Oursourcing eignet sich auch nicht, wenn etwas schon gestern fertig sein sollte.

Neben diesen projektspezifischen Merkmalen gibt es noch den Kulturunterschied: Wenigstens in Indien ist der Mitarbeiterwechsel in den Gesellschaften recht hoch. Außerdem läuft in Indien praktisch alles anders ab. Man darf daher nicht erwarten, dass die Mitarbeiter dort Transferwissen in den Prozess einbringen können; unser Sozialwesen, die Gepflogenheiten des europäischen Geschäftsverkehrs und andere Dinge sind dort einfach unbekannt.

Rechnet man das alles zusammen, dann steht fest: Man muss schon sehr genau überlegen, ob sich Outsourcing lohnt - erst recht in kulturfremden und weit entfernten Ländern. Das soll nicht heißen, dass ich keine guten Erfahrungen damit gemacht hätte, aber der Trend geht einfach hin zu schneller, agiler Softwareentwicklung mit kurzen Releaseabständen - und genau da stößt Oursourcing an seine Grenzen.

21.04.2011 - 15:28 Uhr

WCF ist im Kern eine interoperable Technologie, auch wenn das Microsoft-eigene netTcpBinding eine Kommunikation mit anderen Systemen erst einmal verhindert. DataTables sind (für gewöhnlich) eine ganz schlechte Idee, das serialisierte Ergebnis ist haarsträubend.

Der bevorzugte Weg in WCF sind Data Contracts. Sie sind dafür gemacht und erlauben auch eine gewisse Kontrolle darüber, wie der Inhalt serialisiert wird - wenn das überhaupt benötigt wird.

Sich selbst um die Serialisierung zu kümmern ist in aller Regel nicht notwendig, es geht aber natürlich. Wenn spezielle Streaming-Szenarien unterstützt werden sollen, oder ganz besondere Anforderungen an die Sicherheit gestellt werden, dann kann das ein gangbarer Weg sein.

Also klar: Option Data Contracts.

12.04.2011 - 22:07 Uhr

Das Qualitätsmanagement begleitet eine Entwicklung von deren Beginn (Anforderungsanalyse) bis zu deren logischem Ende, der Inbetriebnahme und dem Übergang von der Projekt- in die Softwarepflegephase. Qualitätsmanagement an sich hat zum Ziel, die Qualität zu planen, sie zu steuern und zu kontrollieren.

In der SW-E sind die wesentlichsten Merkmale von Qualität sicherlich die Abwesenheit von Fehlern, die Erfüllung der funktionalen und nicht-funktionalen Anforderungen, sowie Erfüllung übergreifender Anforderungen an Software, zum Beispiel an Wartbarkeit und Evolvierbarkeit.

Qualität findet aber nicht einfach statt, sie braucht einen Rahmen, sie benötigt Werkzeuge, Verfahren, Verantwortliche und dgl. Das beste Pferd im Stall ist daher der Softwaretest, oder besser gesagt: Die vielen Softwaretests, die den Prozess der SW-Erstellung begleiten.

Testmanagement ist nun dafür da, den Prozess des Softwaretestens zu organisieren und zu standardisieren. Dazu gehört selbst wiederum eine Menge, beispielsweise die Definition von Testfällen, oder überhaupt die Frage, welche Tests in welcher Projektphase anzuwenden sind.

11.04.2011 - 15:31 Uhr

Na wenn das so ist!

Aber, mal ehrlich: Ich finde es recht ungezogen, jemandem - den man nicht kennt - zu unterstellen, er verstünde den Sinn von etwas nicht, bloß weil man selbst einer Aussage nicht zustimmen kann. Ich glaube übrigens auch nicht an "trottelige Admins".

Nein, Virtualisierung ist kein Mehrwert an sich. Es ist auch nicht immer sinnvoll, ganze Betriebssysteme mit dem jeweiligen Ausführungskontext zu duplizieren und aus wenigen GB Nutzdaten, viele GB Verwaltungsdaten hinzuzufügen.

08.04.2011 - 09:59 Uhr

Ich sehe das ein wenig anders. Virtualisierung an sich stellt keinen Mehrwert dar und erst recht bessert sich dadurch nicht die Performance. Im Gegenteil: Schon allein das Aufsetzen von Hyper-V führt zu einer Gesamtreduzierung der IO-Performance, im Detail natürlich abhängig natürlich vom Betriebssystem und anderen Faktoren.

Die Frage ist doch: Warum ist die Performance langsam? Sind es Abfragen, die schlecht optimiert sind? Ist das durch häufiges, grobes Locking versursacht? Sind es fehlende oder korrupte Indizes? Stimmt die DB-Struktur? ...

Die allerbesten Ergebnisse bringen - in aller Regel - Anpassungen der Software. Nicht selten sind da Größenordnungen möglich. Auch ich habe zudem sehr gute Erfahrungen mit der Steigerung der RAM-Größe gemacht und, auch das hilft, mit dem Einsatz moderner Festplatten. Konkrete Empfehlungen sind einigermaßen schwierig, weil wir ja nicht wissen, welche RAM-Kapazität dein Server z. B. hat und wie groß die Datenbanken sind.

25.01.2011 - 11:43 Uhr

Ja, bitte. Wie lautet die E-Mail.

25.01.2011 - 10:35 Uhr

Es gibt bei dieser Sache natürlich einen ganz praktischen Aspekt: Die Mandantenauswahl erfolgt i.d.R. im Client und muss sich durch alle Services durchziehen, die sich wiederum gegenseitig verwenden.

Die Auswahl eines Mandanten hat verschiedene Auswirkungen. Die wichtigste Auswirkung ist wahrscheinlich bei Deinem Projekt der Connection-String, aber in vielen Anwendungen gibt es noch weitere: Zum Beispiel die verwendeten Berichte oder Beleglayouts oder Rechenregeln.

Das so ziemlich dümmste was passieren könnte ist, wenn durch Fehlkonfigurationen Daten kreuz und quer geschrieben würden.

Von Sessions, jedweder Art, rate ich dringend ab. Falsch umgesetzt wird daraus schnell ein Strick.

Eine Möglichkeit der Mandantentrennung ist zum Beispiel die Unterscheidung im Hosting. Kommt der IIS zum Einsatz könnte für jeden Mandant ein Application Pool mit eigener Identität zum Einsatz kommen. Die Rechte könnten dann konsistent durchgezogen werden, so dass ein Client indirekt über die Services nur in die Datenbank schreiben könnte, die dem jeweiligen Mandant entspricht. Ein weiterer Vorteil ist die Isolation der einzelnen Mandanten im Hosting-Prozess.

Eleganter geht das aber über eine Custom Extension, wie schon angedeutet. Das kann zum Beispiel so gelöst werden, dass an jeden Message Header Zusatzinformationen angehängt werden, in Deinem Beispiel der ausgewählte Mandant (oder Connection String). Außerdem kann so auch gleich der Host und der angemeldete Benutzer übertragen werden, für den Fall, dass man ihn später zu Protokollierzwecken in die Datenbank schreiben möchte.

Wir haben so etwas seit Jahren im Einsatz. Wenn Du möchstest, dann schicke ich Dir den Quellcode und eine kurze Anleitung zu.

21.09.2010 - 14:13 Uhr

Hallo ralfw,

also ich empfinde EBC (2.0) als eine interessante Möglichkeit, Beziehungsgeflechte flexibler und unabhängiger zu gestalten, als dies bisher möglich und üblich ist.

Dennoch zögere ich noch, vor allem aus praktischen Erwägungen heraus. Es stellen sich mir noch einige Fragen, die, vor allem, den Produktionsalltag betreffen:*Wie groß gestaltet sich der Einarbeitungsaufwand für die Entwickler? *Was ist zu standardisieren und in welchem Umfang? *Welche Auswirkungen ergeben sich für die Tests, von den Unittests bis zu den Akzeptanztests, von der Testfallplanung bis zur (automatisierten) Testdurchführung *In welcher Weise ist das Deployment betroffen, im Hinblick auf die Granularität der Anwendung (also deploybare Einheiten) und im Hinblick auf die etablierten Continous-Delivery-Prozesse, die bereits automatisiert sind *...

Gibt es denn eine Implementierung die du empfehlen kannst und die sich so als Lehrstück und Spielwiese eignet (und deren Quellen natürlich offen sind)?

06.08.2010 - 14:28 Uhr

Vielleicht verstehe ich das Problem nicht recht, aber es ist doch ohne weiteres möglich, den Rückgabetyp als zum Beispiel "Gerät" zu deklarieren, als tatsächlich übergebenen Typ aber eine Ableitung davon, sagen wir "Temperaturregelung".

Wichtig ist doch nur, dass das KnowTyp-Attribut angegeben wird, auf der Basisklasse, für jede abgeleitete Klasse.

06.08.2010 - 11:41 Uhr

Eine Möglichkeit wäre:
Aspose
Wirklich günstig ist das aber auch nicht.

06.08.2010 - 11:39 Uhr

Qualität hat nun mal seinen Preis

So ist es. Ein guter Name ist natürlich keine Garantie für eine gute Arbeit, aber die Wahrscheinlichkeit steigt doch ganz erheblich. Ich habe im Laufe der Jahre schon mit vielen Webdesignern zusammengearbeitet und die besten hatten immer ein ganzes Team in der Hinterhand.
Gutes Design ist m. E. nach eine Kombination aus gekonntem Handwerk und vorhandenem Talent. Wenn dazu noch ein Mangel an Geschäftstüchtigkeit kommt, dann kann es auch mal sehr preiswert werden. Aber für gewöhnlich wissen gute Designer recht genau was sie wert sind.
Wenn das Projekt nicht gerade sehr klein ist dann erstellen viele Designer auch gerne einmal kostenfrei ein, zwei oder drei Muster.

02.08.2010 - 16:39 Uhr

Rein praktisch gesehen macht das keinen großen Unterschied. Ich persönlich hoste alle Dienste mit gleichen Thema (zum Beispiel Kunden oder Finanzen) in einer Webapplikation. Wenn die Dienste recht groß werden dann kann es zu Problemen mit der Größe der web.config kommen, die man aber mit Verweisen auch lösen kann.

04.07.2010 - 22:39 Uhr

Also ich habe bei der AKAD studiert, ebenfalls Wirtschaftsinformatik. Wenn ich überlege, dann würde ich es wieder tun. Sehr seriös und professionell.

Man muss seine Urlaubsplanung aber schon sehr nach den Präsenztagen ausrichten. Wenn man das in 3 Jahren schaffen möchte, dann ist nicht viel Zeit zum Trödeln da.

Die Materialien waren zu meiner Zeit nicht die aktuellsten. Das ist einerseits schade, andererseits aber auch verständlich: Im Studium geht es mehr um allgemeine Zusammenhänge, weniger um konkrete Produkte.

25.06.2010 - 09:57 Uhr

Also verteilte Software, das wäre mir als Grund gegen einen O/R-Mapper zu wenig.

Die folgenden Fälle eignen sich aus meiner Sicht nicht für O/R-Mapping:
*Massendatenoperationen *Mehrere Projekte untereinander die nicht verbunden sind und die alle auf dieselbe Datenbank zugreifen *Triviale Lösungen *Spezielle Anforderungen an das SQL, wie Locking-Optimierung oder Volltextsuche

24.06.2010 - 21:09 Uhr

Und natürlich ist der Platz auf einer SSD viel teuerer als auf einem herkömmlichen Medium.

21.06.2010 - 09:34 Uhr

Ich glaube nich dass es Einzelentscheidungen geben sollte pro oder contra Unit-Tests. Das ist eine Sache der Entwicklungsphilosophie des Hauses, der verwendeten Werkzeuge und - ja auch - eine Sache der Projektplanung.

Man stelle sich einmal vor: Jeder Entwickler muss ständig gegen Windmühlen ankämpfen und immer wieder den Nutzen argumentieren. Die benötigte Zeit für Unittests muss sich irgendwo in der Projektplanung wiederfinden. Und das Team selbst sollte über die verwendeten Werkzeuge dafür entscheiden. Ist diese einmalig getroffen, warum nicht auch mit dem Chef zusammen?, dann kann sich die Diskussion nur noch auf Zeitpunkt und Umfang konzentrieren. Und da wird ein wenig Kompromissbereitschaft notwendig sein.

Was natürlich nicht geht ist, dass jeder Entwickler seine eigenen Werkzeuge und seine eigene Systematik in den Entwicklungsprozess einbringt und dann zur Wahrheit erhebt. Vielleicht gibt es noch einen zweiten Entwickler der, sagen wir mal EF bevorzugt und sich ebenfalls nicht "dreinreden" lässt? Sollen dann beide Technologien verwendet werden - und wer entscheidet in einem solchen Konfliktfall? Das ist Sache des Entwicklungsleiters. Er muss vereinheitlichen ohne gleichzumachen und Kompromisse finden ohne allzusehr einzuschränken.

Und wenn ein Entwickler wichtige Dinge nicht umsetzen kann, beispielsweise Unit-Tests, dann muss er irgendwann entscheiden - bleiben und akzeptieren oder den nächsten Schritt machen und ein Unternehmen suchen, für das Unit-Tests selbstverständlich sind.

20.06.2010 - 22:29 Uhr

Also das mit den Chefs ist so eine Sache der Argumentation. Niemend möchte Zeit und Geld in Tests investieren, sondern für fertige Software. Fehlerfreiheit wird da schnell als Selbstverständlichkeit abgetan. Die Argumentation muss vielmehr lauten: Für x Tage mehr haben wir über den gesamten Lebenszyklus der Anwendung Ruhe, für eine ganze Reihe möglichweise auftretender Fehler. Das spart Supportaufwände, manuelle Tests, erhöht die Kundenzufriedenheit und erlaubt dann wieder den Blick auf Funktionalität - und wir können ruhiger schlafen.

Ich persönlich halte das Argument der persönlichen Reflexion für sehr gewichtig, es ändert einfach die Einstellung des Entwicklers.

Das richtige Maß für den "gewissen Aufwand" halte ich aber für wichtig, wo liegt er denn? Natürlich, bei jeder Anwendung und für jede Funktion irgendwo anders. Aber gibt es vernünftige Metriken, Vergleiche oder eine Hilfe für den gesunden Menschenverstand?

Was mir persönlich gut gefällt sind die neuen Einschränkungen im TFS und die neuen Testmethoden in Visual Studio 2010. Sie erlauben es, in einzelnen Fällen, Unittests auf höheren Ebenen durchzuführen (beispielsweise durch die Automated UI Tests) und dennoch geht die Automatisierung nicht verloren.

18.06.2010 - 09:34 Uhr

Doch, und auch ich schalte es eigentlich (nahezu) immer ab.

Ich denke ein Grund für den niedrig erscheinenden Retry-Timeout ist, dass Microsoft einfach lange Antwortzeiten für einen Call nach dem Request/Reply-Mechanismus nicht für sinnvoll hält.

Vermutlich werden die meisten Entwickler die Option aus "Vorsicht" aktivieren, ohne sich um die Konsequenzen wirklich Gedanken zu machen.

In einer Duplex-Kommunikation lässt sich das ja konfigurieren und, wie Du ja schreibst, in einer One-Way-Kommunikation - erst recht wenn Sessions im Spiel sind - kann die Option durchaus sinnvoll sein.

12.06.2010 - 21:52 Uhr

Auf Technet findet sich eine Dokumentation, allerdings weniger entwicklerbezogen. Es ist schon ein Trauerspiel mit der MSMQ-Doku.

http://technet.microsoft.com/en-us/library/cc732184.aspx

09.06.2010 - 16:12 Uhr

Die Original-Fehlermeldung ist nichtssagend, das ist häufig so bei WCF. Um Fehler zu tracen macht es Sinn, die Servicemethode in einen try-catch-Block zu packen und im catch-Block den Fehler zu protokollieren. Anschließend mit throw die Exception erneut auslösen, damit sie beim Client ankommt.

Für Debugging-Zwecke gibt es noch die Option IncludeExceptionDetailsInFault, damit der Client mehr Informationen vom Service bekommt. (serviceDebug).

31.05.2010 - 21:04 Uhr

1000 Werte pro Sekunde: Das sollte kein Problem sein. Es stellt sich allerdings schon die Frage, welchen Mehrwert die WCF für Dein Projekt mitbringt. Die Stärken von WCF kommen da eigentlich nicht zum Tragen.

Wenn mit WCF, dann wäre eine Kommunikation über einen Service-Bus von Vorteil, oder - als zweitbeste Lösung - einen Callback vom Service zum Client, dann eben jede Sekunde einmal.

Wie auch immer, ich empfehle eine einfache Übertragung. Also - wenn möglich - keine 1000 Objekte zum Client übertragen, sonder, wie vorgeschlagen, ein Array oder ein anderes, einfaches, Konstrukt.

28.05.2010 - 09:29 Uhr

Erster Ansatz: Sicherheit ausschalten (auf dem Client, als auch auf dem Service). Das geht schnell und grenzt schon mal das Themenfeld ein.

27.05.2010 - 16:04 Uhr

Support im Sinne von Unterstützung: Nein. Support im Sinne der Gewährleistung: Ja, ich finde da hat herbivore absolut recht. Aber eine Wandlung bei einem Euro wäre wohl nicht allzu schlimm. Das Recht zur Nachbesserung oder Wandlung lässt sich ja leicht in den AGBs regeln.

Aber bei aller Vorsicht: Man muss auch die Verhältnismäßigkeit berücksichtigen. Mit Anwälten und Rechtsberatungen (seitens der Entwickler) könnte kein Apple Store überleben und es würde auch kaum einer Shareware vertreiben. Auch bei Klagen gibt es nicht umsonst entsprechende Grundsätze der Verhältnismäßigkeit.

Schwierig wird es wohl wenn es zu einem Fehlverhalten des Programmes kommt und dadurch Schaden entsteht, beispielsweise die Arbeitszeit des Anwenders.

Vor Abmahnungen hätte ich hingegen wieder weniger Sorgen.